Summary
InvoicePlane contains a local file inclusion vulnerability in its e-invoice XML generation flow, where an attacker may influence a database-derived identifier used to construct a PHP file path. A low-privileged attacker who can alter e-invoice configuration may use path traversal to include an existing PHP file; code execution generally requires a separate file-upload or file-write capability.
Affected context
The issue occurs in deployments using InvoicePlane's e-invoice generation functionality when the XML configuration helper resolves a database-derived identifier into a PHP path without sufficiently restricting its value. Exploitability depends on whether a low-privileged user can influence the relevant e-invoice configuration and whether a suitable PHP file is accessible through the resulting path.
Exploit preconditions
- Attack surface: E-invoice configuration and XML generation
- Required access: Low-privileged access capable of influencing the relevant configuration
- Trigger point: Invocation of
Invoices::generate_xml() - Required file condition: A PHP file must exist at a path reachable through the manipulated identifier
- Why exploitation is possible: The identifier is incorporated into a PHP include path without adequate traversal and allowlist validation
- Additional execution condition: Code execution may require a separate file-upload or file-write primitive
Why this happens
The underlying flaw is an unsafe filename construction and inclusion pattern. InvoicePlane derives an identifier from database-backed configuration, appends it to a helper-directory path, and includes the resulting PHP file without enforcing a constrained filename or canonical-path policy. This behavior maps primarily to CWE-98, Improper Control of Filename for Include or Require Statement, with CWE-22 reflecting the associated path traversal risk.
Potential impact
- An attacker may read or execute an existing PHP file through the vulnerable include path
- Application behavior or generated invoice processing may be altered
- Sensitive local application data could be exposed, depending on the included file
- Server-side code execution could occur if an attacker also has a file-upload or file-write capability
- Account or application integrity may be compromised
General mitigation guidance
Mitigation generally focuses on removing user-controlled path construction and
preventing dynamic inclusion of PHP files.
Common defensive patterns include:
- Using fixed, internally mapped configuration identifiers rather than raw path components
- Allowlisting permitted filenames and rejecting traversal sequences
- Canonicalizing paths and verifying that the resolved path remains within an intended directory
- Replacing dynamic PHP inclusion with structured data parsing or static application logic
- Separating writable upload or cache directories from executable code locations
- Applying least privilege to application, database, and filesystem access
- Treating configuration values as untrusted even when they originate from a database
How teams detect issues like this
Organizations can look for this class of issue through:
- Static analysis rules identifying dynamic
include,require, or equivalent PHP path operations - Code review checks for database-derived or request-derived values used in filesystem paths
- Tests covering traversal sequences, encoded separators, absolute paths, and canonicalization bypasses
- Runtime monitoring for unusual PHP file access from configuration or helper directories
- Policy enforcement that prevents web-process write access to executable application directories
- Automated security review tools that flag uncontrolled filename and include-path construction
