CVE-2026-54347 in Froxlor
Summary
by MITRE • 08/19/2026
Froxlor is open source server administration software. Prior to 2.3.8, DNS TXT record content accepted by lib/Froxlor/Api/Commands/DomainZones.php can contain HTML special characters, lib/Froxlor/UI/Callbacks/Text.php returns the content from Text::wordwrap without HTML escaping, and templates/Froxlor/table/table.html.twig renders the callback result with the raw filter. An authenticated customer with DNS editor access can store JavaScript-bearing content in a TXT record. When an administrator views the affected domain's DNS configuration, the payload executes automatically in the administrator's browser session, which can expose session data or perform privileged panel actions. This issue is fixed in version 2.3.8.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/19/2026
The vulnerability identified in Froxlor versions prior to 2.3.8 represents a significant security flaw rooted in improper neutralization of user input within the application's DNS management module, specifically classified under CWE-79 as Cross-Site Scripting (XSS). The root cause lies in the handling of DNS TXT record content through multiple layers of the software stack that fail to enforce proper output encoding. When an authenticated customer possessing DNS editor privileges submits a domain zone update, the system accepts raw input for TXT records without sanitizing HTML special characters. This lack of validation at the ingestion point allows attackers to inject malicious scripts into the database-backed configuration data.
The exploitation path is further facilitated by how the application processes and renders this stored data. The function within lib/Froxlor/UI/Callbacks/Text.php retrieves the content from Text::wordwrap but critically fails to apply HTML escaping before passing it forward. Subsequently, the template engine responsible for rendering the administrative interface, specifically templates/Froxlor/table/table.html.twig, utilizes a raw filter when displaying this callback result. This combination of unescaped data retrieval and explicit instruction to render output without encoding creates a classic stored XSS vulnerability where malicious payloads are persistently stored on the server and executed in the context of other users' browsers upon viewing.
The operational impact is severe because it allows an authenticated user with limited privileges, such as DNS editor access, to escalate their influence by targeting higher-privileged roles like administrators. When an administrator views the affected domain's DNS configuration page, the browser automatically executes the injected JavaScript payload within the context of that session. This execution environment grants the attacker full access to sensitive information associated with the administrator's account, including authentication tokens and personal data. Furthermore, because the script runs in a privileged context, it can perform actions on behalf of the administrator, such as modifying system settings, creating new user accounts, or deleting critical configurations, effectively compromising the integrity and confidentiality of the entire server administration panel.
From an offensive security perspective, this vulnerability aligns with MITRE ATT&CK techniques related to Client-Side Scripting Injection (T1059) and potentially Account Manipulation if used to create backdoor users. The attack vector is classified as remote but requires authentication, placing it in the category of authenticated attacks that exploit trust relationships within the application's role-based access control model. To mitigate this risk, immediate action must be taken by upgrading Froxlor to version 2.3.8 or later, where these input validation and output encoding flaws have been addressed. In environments where an upgrade is not immediately feasible, implementing a Web Application Firewall with rules designed to detect and block script injection in DNS record fields can provide temporary protection. Additionally, enforcing strict Content Security Policy headers that restrict the execution of inline scripts on administrative pages would significantly reduce the impact of any successfully injected payloads by preventing them from executing even if they are rendered into the DOM.