Description

froxlor is a server administration panel. In versions 2.3.10 and earlier, Validate::validateUrl rejects carriage return and line feed characters only in the path, query and fragment components returned by parse_url, and never inspects the userinfo (user:pass@) components. This is an incomplete fix for GHSA-c3p2. An authenticated low-privilege customer with subdomain-create rights (no admin or change_serversettings privilege required) can supply a subdomain redirect URL that carries a CR/LF payload in the userinfo portion (e.g. http://user%0areturn 200 "pwned";%0a@evil.com/). The value passes validation, survives IDNA encoding, and is written verbatim into the generated nginx or Apache vhost configuration, allowing the attacker to break out of the emitted directive and inject arbitrary web-server configuration lines. froxlor regenerates and reloads the web-server configuration as root, so the injected directives take effect server-wide and can hijack responses or read local files. The issue is fixed in version 2.3.12.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.9",
  "pubDate": "2026-09-26T14:16:57.753Z",
  "pubdate": "2026-09-26T14:16:57.753Z",
  "executiveSummary": "Froxlor versions 2.3.10 and earlier are susceptible to a configuration injection vulnerability stemming from insufficient input validation within the Validate::validateUrl function.\nThe vulnerability allows an authenticated low-privileged user with subdomain-create permissions to bypass existing security filters and inject arbitrary directives into the generated nginx or Apache web-server configuration files.\nBecause the web-server configuration is regenerated and reloaded by the root user, the injection facilitates local file read or response hijacking, effectively escalating privileges to that of the system administrator.\nThe root cause is an incomplete fix for GHSA-c3p2, where the validation logic fails to inspect the userinfo component (user:pass@) of a URL for carriage return (CR) and line feed (LF) characters.\nAn attacker can exploit this by crafting a malicious URL containing newline-delimited configuration directives that survive IDNA encoding and are subsequently written verbatim into system-wide configuration files.\nImmediate remediation involves upgrading to version 2.3.12 or later to address the validation defect.",
  "technicalDetails": "The vulnerability exists within the Validate::validateUrl function, which is responsible for sanitizing user-supplied URLs before they are persisted into web-server configuration templates.\nWhile previous updates addressed CRLF injection in the path, query, and fragment components of a URL as identified by parse_url, the function fails to sanitize the userinfo component. This creates a bypass vector where an attacker can embed control characters such as %0a (Line Feed) within the user portion of the URL string.\nThe attack flow begins with an authenticated customer possessing subdomain-creation rights. The attacker crafts a subdomain redirect URL containing an injected payload, such as 'http://user%0areturn 200 \"pwned\";%0a@evil.com/'.\nDuring the validation process, Validate::validateUrl only scans the path, query, and fragment components. Consequently, the userinfo payload passes validation checks. The input then proceeds to the IDNA encoding stage, where it remains intact, and is eventually concatenated directly into the backend web-server configuration files (nginx or Apache).\nWhen the froxlor panel triggers a configuration regeneration and reload process, the injected CRLF characters force the web server to interpret the subsequent string as a new configuration directive rather than part of the intended URL. Because the process that triggers the configuration reload runs with root privileges, the injected directives are executed with full system authority.\nThe impact of this vulnerability is critical. An attacker can break out of the intended directive context to inject arbitrary server configurations. Examples of post-exploitation activity include, but are not limited to, redirecting traffic for server-wide request hijacking, modifying access control lists, or reading arbitrary local files through directive-based exposure.\nThis vulnerability affects all versions of froxlor up to and including 2.3.10. It requires basic authentication as a user with sufficient permissions to define a subdomain redirect, but does not require administrative or high-level server-setting modification privileges, making it a viable target for low-privilege accounts in multi-tenant environments."
}