CVE-2026-71233 in InvoiceNinja
Summary
by MITRE • 08/05/2026
InvoiceNinja v5-stable renders an invoice or quote's "terms" field in the client portal using Laravel Blade's raw output directive {!! $entity->terms !!} (resources/views/portal/ninja2020/invoices/includes/terms.blade.php) with no HTML sanitization. StoreInvoiceRequest.php only strips newlines from the field and does not purify HTML. An authenticated user with invoice creation access can set the terms field via the REST API (PUT /api/v1/invoices/{id}) to an HTML/JavaScript payload that executes in the client's browser when they view the invoice, enabling session cookie theft and client account takeover. This is a distinct code path from the previously published invoice line-item description field XSS (GHSA-98wm-cxpw-847p / CVE-2026-33628).
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/05/2026
This vulnerability exists in InvoiceNinja v5-stable where the application fails to properly sanitize user input when rendering invoice terms in the client portal. The core issue stems from the use of Laravel Blade's raw output directive {!} in the template file resources/views/portal/ninja2020/invoices/includes/terms.blade.php without any HTML sanitization or content validation. The StoreInvoiceRequest.php validation logic only removes newlines from the terms field but does not implement proper HTML purification, creating an attack surface for cross-site scripting exploits.
The technical flaw represents a classic stored cross-site scripting vulnerability that operates through the REST API endpoint PUT /api/v1/invoices/{id}. An authenticated attacker with invoice creation privileges can craft malicious HTML or JavaScript content in the terms field, which gets persisted to the database and subsequently executed in the victim's browser when viewing the invoice. This vulnerability is distinct from previously identified issues affecting line item descriptions, as it targets a separate code path within the application's rendering logic. The lack of input sanitization combined with the use of raw output directives creates an ideal environment for malicious payloads to execute with the privileges of the authenticated user.
The operational impact of this vulnerability extends beyond simple script execution to full account takeover capabilities. When victims view invoices containing malicious terms, their session cookies can be harvested by attackers through techniques such as document.cookie theft or beaconing to external domains. This allows unauthorized parties to impersonate legitimate users and access sensitive financial information, potentially leading to data breaches, fraudulent transactions, and complete compromise of client accounts. The vulnerability affects any authenticated user who can create invoices, making it particularly dangerous in multi-user environments where privilege escalation is possible.
Mitigation strategies should focus on implementing comprehensive input sanitization at multiple layers within the application architecture. The most critical immediate fix involves integrating HTML purifier libraries or similar security tools to sanitize all user-provided content before storage, specifically targeting the terms field in invoice creation workflows. Additionally, the application should adopt Content Security Policy headers to prevent unauthorized script execution and implement proper output encoding for all dynamic content rendered in templates. Organizations should also consider privilege escalation controls to limit who can modify critical invoice fields and implement monitoring for suspicious API activity patterns. This vulnerability aligns with CWE-79 (Cross-site Scripting) and maps to ATT&CK technique T1531 (Account Access Removal) through session hijacking capabilities, while the REST API exposure corresponds to T1071.004 (Application Layer Protocol: DNS) and T1190 (Exploit Public-Facing Application) tactics in threat modeling frameworks.