CVE-2026-33628: Invoice Ninja Stored XSS Vulnerability

CVE-2026-33628 Overview

Invoice Ninja, a source-available invoice, quote, project and time-tracking application built with Laravel, contains a stored Cross-Site Scripting (XSS) vulnerability in version v5.13.0. The vulnerability exists in the invoice line item description field, which fails to properly sanitize user input before rendering. Attackers with authenticated access can inject malicious XSS payloads that execute when invoices are rendered in the PDF preview or client portal, potentially compromising user sessions and sensitive data.

Critical Impact

Stored XSS payloads in invoice line item descriptions execute when invoices are viewed in PDF preview or client portal, enabling session hijacking, credential theft, and unauthorized actions on behalf of legitimate users.

Affected Products

• Invoice Ninja v5.13.0
• Invoice Ninja versions prior to v5.13.4

Discovery Timeline

• 2026-03-26 - CVE CVE-2026-33628 published to NVD
• 2026-03-26 - Last updated in NVD database

Technical Details for CVE-2026-33628

Vulnerability Analysis

This vulnerability is classified as CWE-79 (Cross-Site Scripting). The root issue stems from insufficient input sanitization in the invoice line item description processing. When users create or edit invoices, the line item description field was not being passed through the purify::clean() sanitization function before rendering. This allowed attackers to craft payloads that bypass the existing XSS denylist filter.

The vulnerability requires authenticated access (low privileges) and user interaction to trigger, as victims must view the malicious invoice through the PDF preview or client portal. Due to the changed scope characteristic, successful exploitation can impact resources beyond the vulnerable component, potentially affecting other users viewing the same invoice or the broader portal session context.

Root Cause

The line item description field in Invoice Ninja v5.13.0 lacked proper sanitization. While other input fields utilized the purify::clean() function to strip potentially malicious content, the line item description bypassed this security control. The existing XSS denylist filter proved insufficient, as attackers could craft payloads using HTML entity encoding (such as < and &# sequences) to evade detection.

Attack Vector

The attack requires network access and authenticated credentials with at least low-level privileges. An attacker can inject malicious JavaScript payloads into invoice line item descriptions. When legitimate users (such as clients or administrators) view the invoice through the PDF preview or client portal, the XSS payload executes in their browser context. This can lead to session token theft, credential harvesting, or unauthorized actions performed on behalf of the victim.

// Security patch in app/Http/Requests/Product/StoreProductRequest.php
// Source: https://github.com/invoiceninja/invoiceninja/commit/b81a3fc302573fc4a53d61e8537dd19154ce1091

         $input['tax_name2'] ??= '';
         $input['tax_name3'] ??= '';
 
+        foreach (['notes', 'product_key', 'custom_value1', 'custom_value2', 'custom_value3', 'custom_value4'] as $field) {
+            if (isset($input[$field]) && is_string($input[$field]) && (str_contains($input[$field], '<') || str_contains($input[$field], '<') || str_contains($input[$field], '&#'))) {
+                $input[$field] = \App\Services\Pdf\Purify::clean($input[$field], true);
+            }
+        }
+
         $this->replace($input);
     }
 }

The patch adds sanitization by checking for HTML-related characters (<, <, &#) and applying Purify::clean() to multiple fields including notes, product_key, and custom value fields.

Detection Methods for CVE-2026-33628

Indicators of Compromise

• Presence of HTML tags or JavaScript code within invoice line item descriptions in the database
• Encoded HTML entities such as <script or <script patterns in product notes or line item fields
• Unusual client-side script execution or network requests originating from invoice preview pages

Detection Strategies

• Implement Content Security Policy (CSP) headers to detect and report unauthorized script execution
• Monitor application logs for suspicious invoice creation or modification activities containing script-like content
• Deploy Web Application Firewall (WAF) rules to detect XSS payload patterns in POST requests to invoice endpoints

Monitoring Recommendations

• Enable verbose logging for invoice creation and modification endpoints
• Configure alerting for database entries containing encoded HTML entities or script tags in description fields
• Monitor client portal access logs for unusual session behavior following invoice views

How to Mitigate CVE-2026-33628

Immediate Actions Required

• Upgrade Invoice Ninja to version v5.13.4 or later immediately
• Audit existing invoice line item descriptions for potential malicious payloads
• Review product notes and custom value fields for any injected XSS content
• Consider temporarily restricting invoice creation privileges to trusted users until patched

Patch Information

The vendor has addressed this vulnerability in Invoice Ninja v5.13.4 by implementing purify::clean() sanitization on line item descriptions and related fields. The fix adds comprehensive input validation that checks for HTML tag indicators (<, <, &#) and sanitizes content before processing.

For detailed patch information, refer to:

• GitHub Security Advisory GHSA-98wm-cxpw-847p
• GitHub Release v5.13.4
• GitHub Commit b81a3fc

Workarounds

• Implement strict Content Security Policy (CSP) headers to mitigate XSS impact by restricting inline script execution
• Deploy a Web Application Firewall (WAF) with XSS detection rules targeting invoice-related endpoints
• Manually sanitize existing invoice data by searching for and removing HTML/script content from line item descriptions

# Configuration example - Add CSP headers in Laravel middleware or web server config
# For Apache (.htaccess or httpd.conf):
Header set Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline';"

# For Nginx (nginx.conf or site configuration):
add_header Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline';";