CVE-2026-24744: InvoicePlane Stored XSS Vulnerability

CVE-2026-24744 Overview

A Stored Cross-Site Scripting (XSS) vulnerability has been identified in InvoicePlane, a self-hosted open source application for managing invoices, clients, and payments. The vulnerability exists in the Edit Invoices functionality of InvoicePlane version 1.7.0, where the application fails to properly validate user input at the invoice_number parameter. Although administrator privileges are required to exploit this vulnerability, it can lead to severe consequences including unauthorized modification of application data, creation of persistent backdoors through stored malicious scripts, and full compromise of the application's integrity.

Critical Impact

Stored XSS in the invoice editing function allows authenticated administrators to inject persistent malicious scripts that execute in the context of any user viewing the affected invoice, potentially leading to session hijacking, data theft, or application takeover.

Affected Products

• InvoicePlane version 1.7.0
• Earlier versions may also be affected (unconfirmed)

Discovery Timeline

• 2026-02-18 - CVE-2026-24744 published to NVD
• 2026-02-19 - Last updated in NVD database

Technical Details for CVE-2026-24744

Vulnerability Analysis

This Stored Cross-Site Scripting vulnerability is classified under CWE-79 (Improper Neutralization of Input During Web Page Generation). The flaw resides in the invoice editing functionality where the invoice_number parameter accepts and stores unsanitized user input. When the malicious payload is rendered in the browser context of other users viewing the invoice, the injected script executes with their session privileges.

The vulnerability requires network access and administrator-level authentication to exploit initially, but the stored nature of the XSS means the malicious payload persists and affects any subsequent user who views the compromised invoice record. This persistence mechanism amplifies the impact beyond the initial attacker's session.

Root Cause

The root cause is insufficient input validation and output encoding in the invoice editing form handler. The application stores the raw invoice_number value directly in the database without sanitization, and subsequently renders it without proper HTML entity encoding. This allows an attacker to embed JavaScript or HTML content that executes when the invoice data is displayed.

Attack Vector

The attack is network-based, requiring an authenticated administrator to access the invoice editing functionality. The attacker modifies the invoice_number field to include a malicious script payload such as <script>alert(document.cookie)</script> or more sophisticated payloads designed to exfiltrate session tokens, modify application data, or create persistent backdoors. Once stored, the malicious script executes automatically when any user views the affected invoice.

The security patch addresses this vulnerability by updating the form validation library and framework dependencies:

// Security patch in application/libraries/MY_Form_validation.php
 
    public function run($config = null, &$data = null)
    {
-        if (is_object($config)) {
-            $this->CI = &$config;
-        }
+        (is_object($config)) && $this->CI = &$config;

        return parent::run($data);
    }

Source: GitHub Commit Update

Additionally, the framework dependency was updated:

// Security patch in index.php
 * This variable must contain the name of your "system" directory.
 * Set the path if it is not in the same directory as this file.
 */
-$system_path = 'vendor/codeigniter/framework/system';
+$system_path = 'vendor/pocketarc/codeigniter/system';

/*
 *---------------------------------------------------------------

Source: GitHub Commit Update

Detection Methods for CVE-2026-24744

Indicators of Compromise

• Unusual JavaScript or HTML tags present in invoice_number fields within the database
• Invoice records containing encoded script payloads such as <script>, onerror=, onload=, or similar XSS vectors
• Web server access logs showing suspicious POST requests to invoice editing endpoints with encoded payloads
• Unexpected outbound network connections originating from client browsers when viewing invoices

Detection Strategies

• Implement Web Application Firewall (WAF) rules to detect and block XSS patterns in request parameters
• Deploy Content Security Policy (CSP) headers to prevent inline script execution and unauthorized script sources
• Monitor database fields for invoice records containing HTML/JavaScript syntax patterns
• Review application logs for administrative users modifying invoice numbers with suspicious content

Monitoring Recommendations

• Enable detailed audit logging for all invoice modification operations
• Configure real-time alerting for CSP violation reports from client browsers
• Implement database integrity monitoring to detect unauthorized modifications to invoice records
• Deploy endpoint detection and response (EDR) solutions to identify suspicious browser behavior patterns

How to Mitigate CVE-2026-24744

Immediate Actions Required

• Upgrade InvoicePlane to version 1.7.1 or later immediately
• Review existing invoice records in the database for potentially malicious content in the invoice_number field
• Implement Content Security Policy headers to mitigate the impact of any undetected stored XSS payloads
• Restrict administrative access to trusted users only and enforce strong authentication mechanisms

Patch Information

The vulnerability has been patched in InvoicePlane version 1.7.1. The fix updates the form validation library and underlying CodeIgniter framework dependency to properly sanitize user input. Organizations running InvoicePlane 1.7.0 should upgrade immediately.

For detailed patch information, refer to the GitHub Security Advisory GHSA-5mxx-553h-m62w and the security commit.

Workarounds

• If immediate patching is not possible, restrict access to the invoice editing functionality to a minimal set of trusted administrators
• Implement a Web Application Firewall (WAF) with XSS detection rules to filter malicious payloads
• Deploy strict Content Security Policy headers to prevent inline script execution
• Manually sanitize existing invoice_number database fields to remove any potentially malicious content

# Example Content Security Policy header configuration for Apache
# Add to .htaccess or Apache configuration
Header set Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; object-src 'none'; frame-ancestors 'self';"