CVE-2026-111048 in FOSSBilling
Summary
by MITRE • 11/02/2026
FOSSBilling is an open source billing and client-management platform. From 0.1.0 until 0.8.9, the admin/support/note_create endpoint stores the note parameter without sanitization in the support_ticket_note table, and src/modules/Support/templates/admin/mod_support_tickets.html.twig renders each stored support ticket note through innerHTML in the admin ticket list. A staff user with only the support.manage_tickets permission can store HTML or JavaScript that executes when another staff member opens the ticket notes. The script runs with the viewing staff member's session and privileges, can read a CSRF token and accessible client or invoice data, and can perform administrative actions available to the viewer, including a Super Administrator. The ticket detail page is not affected because its Twig rendering uses autoescaping. This issue is fixed in version 0.8.9.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 11/02/2026
FOSSBilling represents an open-source billing and client-management platform widely used by hosting providers and digital service agencies to manage subscriptions, invoices, and customer support interactions. Within the architecture of this application, specifically between versions 0.1.0 and 0.8.9, a critical security flaw exists in how administrative staff interact with support ticket notes. The vulnerability stems from an improper neutralization of special elements within the input stream, commonly categorized under CWE-79 as Cross-Site Scripting (XSS). This specific implementation allows for stored XSS attacks that persist on the server side and are executed by victims upon viewing affected content, rather than requiring immediate user interaction with a crafted link.
The technical root cause lies in two distinct components of the application's codebase working in tandem to create an exploitable chain. First, the endpoint located at admin/support/note_create accepts input for support ticket notes but fails to sanitize or encode HTML special characters before storing them in the database table named support_ticket_note. This lack of server-side validation means that arbitrary HTML and JavaScript payloads can be persisted alongside legitimate ticket data. Second, the frontend rendering logic found in src/modules/Support/templates/admin/mod_support_tickets.html.twig utilizes innerHTML to display these stored notes within the admin ticket list interface. Unlike modern templating engines that often escape output by default, this specific template explicitly renders raw content, thereby executing any embedded scripts immediately upon page load or view refresh.
The operational impact of this vulnerability is severe due to its broad accessibility and high-privilege execution context. The flaw can be triggered by a staff member possessing only the support.manage_tickets permission, which is a relatively low-level privilege intended for basic customer service tasks rather than administrative control. Once an attacker with these limited privileges injects malicious code into a ticket note, any subsequent administrator or senior staff member who views that specific ticket will have their browser execute the script within their own session context. This effectively bypasses standard access controls because the malicious script inherits the full permissions of the viewing user.
Consequently, if an attacker targets a Super Administrator or another high-privilege account, they can perform actions far beyond the scope of basic support management. The injected JavaScript can read sensitive data such as Cross-Site Request Forgery (CSRF) tokens, which are typically used to prevent state-changing requests from being forged by third parties. By extracting these tokens, an attacker can bypass CSRF protections and issue authenticated requests on behalf of the victim. Furthermore, the script has access to client personal information, invoice details, and billing data stored in the session or DOM, leading to significant confidentiality breaches. The attacker could also perform administrative actions such as modifying user accounts, changing system configurations, or deleting records, effectively achieving full account takeover for any targeted staff member.
It is important to note that this vulnerability does not affect all parts of the application uniformly. The ticket detail page itself remains secure because its corresponding Twig template utilizes autoescaping features provided by the templating engine. This means that while the list view in the admin panel is vulnerable, viewing the full details of a single ticket from within that detailed view context will render the content safely as text rather than executable code. However, this partial mitigation does not negate the severity of the flaw, as the initial vector via the ticket list remains fully exploitable and serves as an effective entry point for further attacks.
To mitigate this vulnerability, organizations running FOSSBilling versions prior to 0.8.9 must upgrade immediately to version 0.8.9 or later, where the issue has been resolved through proper input sanitization at storage time and output encoding at rendering time. For environments that cannot yet upgrade, temporary mitigations include implementing strict Content Security Policy headers to restrict script execution sources and disabling JavaScript in administrative interfaces if feasible, though these are less effective than patching the underlying code flaw. Additionally, enforcing multi-factor authentication for all staff accounts can reduce the impact of session hijacking or credential theft resulting from such exploits.
From a threat intelligence perspective, this vulnerability aligns with MITRE ATT&CK techniques related to Client-Side Scripting Injection and potentially Credential Access via Browser Session Hijacking if combined with other vectors. The ability to steal CSRF tokens places it in close proximity to techniques involving the extraction of authentication artifacts. Security teams should audit their FOSSBilling instances for any signs of persistent scripts within support ticket notes, as attackers may have already exploited this flaw during the window between vulnerability disclosure and patch deployment. Regular security assessments focusing on input validation and output encoding practices are essential to prevent similar CWE-79 occurrences in other web applications managing sensitive user data.