Description

Froxlor 2.0.0 through 2.3.10 is vulnerable to stored cross-site scripting. When a customer (the lowest-privileged authenticated role) uploads an SSL certificate for one of their own domains, the Certificates API add()/update() methods parse it with openssl_x509_parse() and store the issuer organization (issuer['O']) value verbatim without sanitization. Froxlor's table-listing renderer then emits scalar cells through Twig's `raw` filter, disabling HTML auto-escaping, so when an administrator or reseller opens Domains > SSL certificates the attacker-supplied issuer value executes as script in the privileged user's session. This crosses a privilege boundary from customer to admin and can result in full administrator account takeover; because a Froxlor admin controls webserver, DNS, and PHP configuration applied by a cron job running as root, the issue can be further escalated to command execution as root on the managed server. The issue is fixed in Froxlor 2.3.12.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.7",
  "pubDate": "2026-09-26T14:16:58.230Z",
  "pubdate": "2026-09-26T14:16:58.230Z",
  "executiveSummary": "Froxlor versions 2.0.0 through 2.3.10 contain a critical stored Cross-Site Scripting (XSS) vulnerability within the SSL certificate management functionality. The flaw originates from the insecure handling of X.509 certificate data, specifically the issuer organization field, which is parsed and stored without proper input sanitization. This vulnerability allows an authenticated customer to inject malicious JavaScript into the application's administrative interface.\nThe impact of this vulnerability is severe, as it facilitates a cross-privilege boundary attack. By forcing a privileged user, such as an administrator or reseller, to view the compromised certificate listing, an attacker can execute arbitrary scripts within the victim's session. Given the elevated permissions of Froxlor administrators—who manage webserver, DNS, and PHP configurations that are subsequently processed by root-privileged cron jobs—the successful exploitation of this XSS vulnerability can be chained to achieve full remote code execution and complete system compromise. The vulnerability requires authenticated access as a customer and is resolved in version 2.3.12.",
  "technicalDetails": "The vulnerability resides within the Certificates API add() and update() methods of Froxlor. When a user uploads an SSL certificate, the application utilizes the PHP openssl_x509_parse() function to extract metadata from the certificate file. Specifically, the 'issuer' array element containing the organization ('O') field is extracted. The application fails to sanitize this string, storing the raw, potentially malicious, input directly into the database.\nThe exploitation occurs due to an improper implementation of output encoding in the user interface. The Froxlor table-listing renderer for the 'Domains > SSL certificates' view utilizes the Twig template engine. Within these templates, the application employs the 'raw' filter when rendering the issuer organization string. The 'raw' filter instructs Twig to bypass its default HTML auto-escaping mechanisms, rendering the attacker-supplied content exactly as it is stored in the database.\nThe attack flow is as follows: 1. An attacker, authenticated with a customer-level account, crafts a malicious SSL certificate where the issuer organization field contains a functional JavaScript payload (e.g., <script>fetch('...')</script>). 2. The attacker uploads this certificate via the Certificates API. 3. The API parses the certificate and stores the payload in the database without sanitization. 4. The attacker waits for an administrator or reseller to navigate to the 'Domains > SSL certificates' page within the Froxlor control panel. 5. When the privileged user loads this page, the server fetches the malicious string from the database and embeds it directly into the HTML response via the Twig 'raw' filter. 6. The victim's browser executes the script in the context of the administrator's session.\nThe post-exploitation impact is critical. Because an administrator account in Froxlor possesses the authority to modify webserver configurations, PHP settings, and DNS records, the attacker can leverage the compromised session to modify these configurations. Since Froxlor’s backend tasks are periodically executed by cron jobs running with root privileges, the attacker can inject malicious code or configurations that the system will subsequently execute with root-level permissions, leading to full server compromise."
}