CVE-2026-71233

This is CVE-2026-71233: a stored XSS in InvoiceNinja's terms field. An authenticated user with invoice creation access can inject JavaScript through the terms parameter. When other users view that invoice via the client portal, the payload executes in their browsers — making this a stored XSS with third-party victim scope, not a self-XSS. The technical root cause is straightforward: the terms field is rendered in a Blade template using the raw output directive `{!! $entity->terms !!}`, which outputs HTML without escaping. The StoreInvoiceRequest validator only strips newlines from the terms input — it performs no HTML sanitization and rejects nothing. The malicious payload is stored verbatim and only gets "escaped" at render time, which is too late when the template uses raw output. This is not a new vulnerability class for InvoiceNinja. CVE-2026-33628 patched the same pattern in line-item descriptions, and CVE-2026-71233 is the proof that the fix was scoped too narrowly. The underlying architectural problem — `{!! !!}` applied to user-supplied content without upstream sanitization — was never corrected. It was patched at one coordinate and left intact everywhere else. The blast radius matters more than usual here. The terms field renders in the client portal, a multi-party interface where your victims are your own clients. An attacker creates one invoice with a payload, and every client who opens that invoice has their session exposed. If InvoiceNinja's session cookies lack httpOnly flags (a historical Laravel pattern), the payload can exfiltrate credentials directly. This is a broadcast mechanism, not a targeted one. The deeper failure is the API boundary. StoreInvoiceRequest accepts HTML and persists it unchanged. The sanitization decision is pushed to the view layer — backwards. Either reject HTML at input validation, or apply a sanitizer like HTMLPurifier before storage. The template layer should never need raw output on user content. What to do: audit your InvoiceNinja deployment for other Blade templates using `{!! !!}` on any field that originates from user input — client portal templates are the priority. Check your session cookie configuration for httpOnly and Secure flags. Consider disabling raw output on user-supplied fields entirely and enforcing escaped output at the template level. The next instance of this pattern is almost certainly waiting in another template InvoiceNinja hasn't audited yet.

Reviewed through automated stages and approved by a human before publication.