CVE-2026-54347: Froxlor: Stored XSS in DNS TXT Record Content Allows Customer-to-Admin Account Takeover

Published Aug 18, 2026
·
Updated

Summary

A stored Cross-Site Scripting (XSS) vulnerability in Froxlor's DNS editor allows an authenticated user with DNS editor access (customer role) to inject arbitrary JavaScript into any administrator's browser session. When an administrator views the DNS configuration of an affected domain, the payload executes automatically — enabling complete admin account takeover, credential theft, and full server compromise.

---

Details

Three code locations combine to create this vulnerability:

1. Input validation does not strip HTML special characters — lib/Froxlor/Api/Commands/DomainZones.php:158

php // Only strips non-printable chars. < and > (0x3C/0x3E) pass through unmodified. $content = pregreplace('/[^\x09\x20-\x7E]/', '', $content); $content = Dns::encloseTXTContent($content); // only wraps in quotes, no HTML encoding

2. Display callback returns raw HTML without escaping — lib/Froxlor/UI/Callbacks/Text.php:95

php public static function wordwrap(array $attributes): string { return wordwrap($attributes['data'], 100, '<br>', true); // no htmlspecialchars() }

3. Twig template renders the callback output with |raw — templates/Froxlor/table/table.html.twig:57

twig {% else %} {{ td.data|raw }} {# string from wordwrap() — rendered without escaping #} {% endif %}

The DNS editor table assigns [Text::class, 'wordwrap'] as the callback for the content column (lib/tablelisting/tablelisting.dns.php:58). The callback returns a non-iterable string, so the template falls to the |raw branch.

Additionally, the Content Security Policy header (lib/Froxlor/UI/Panel/UI.php:140) includes 'unsafe-inline', rendering CSP completely ineffective as a mitigation:

Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; ...

---

PoC <img width="2025" height="1144" alt="image" src="https://github.com/user-attachments/assets/f6808b24-c4b6-4bd2-9673-d7ddc4939794" />

Prerequisites: Froxlor running with DNS enabled (system.dnsenabled = 1), at least one domain with DNS editor enabled, and a user account (customer or admin) with DNS editor access.

Step 1 — Inject the payload (via web UI or API as any DNS-enabled user):

Navigate to the DNS editor for any domain, add a TXT record with: - Record: @ - Type: TXT - Content: <img src=x onerror=alert(document.domain)>

Step 2 — Trigger:

No interaction is required beyond page navigation. The payload fires automatically on page load the moment any logged-in administrator visits:

http://TARGET/admindomains.php?page=domaindnseditor&domainid=<id>

This URL is part of the normal admin workflow (domain management → DNS editor). No clicking, no form submission, no special conditions — visiting the URL is sufficient.

Verify via command line (login + fetch in one line):

bash T=$(curl -sc /tmp/c http://TARGET/index.php | grep -oP 'csrf-token" content="\K[^"]+') && \ curl -sc /tmp/c -b /tmp/c http://TARGET/index.php \ -d "loginname=admin&password=PASS&dologin=1&send=send&csrftoken=$T" -o /dev/null && \ curl -sb /tmp/c "http://TARGET/admindomains.php?page=domaindnseditor&domainid=ID" \ | grep -o '<img src=x[^>]>'

Expected output confirming unescaped payload in page source:

<img src=x onerror=alert(document.domain)>

In a browser session the alert() fires immediately — no clicks required.

---

Impact

Type: Stored Cross-Site Scripting (Stored XSS)

Who is impacted: Any Froxlor installation with DNS editor functionality enabled. The attack requires a low-privilege customer account with dnsenabled = 1 — a standard feature granted to hosting customers. The victim is any administrator who views the affected domain's DNS configuration.

A real-world attacker would replace alert() with a payload that silently exfiltrates the admin session cookie, then uses it to create a backdoor admin account, read all customer credentials, or execute arbitrary commands on the underlying server through Froxlor's system configuration interface.

---

Fix

Apply one of the following:

Option A (recommended) — Remove |raw from the table template:

twig {# templates/Froxlor/table/table.html.twig:57 #} {{ td.data }} {# Twig auto-escaping handles it #}

Callbacks that intentionally return HTML (e.g. action buttons) should return a structured array with a macro key instead of a raw string.

Option B — Escape in the callback:

php // lib/Froxlor/UI/Callbacks/Text.php public static function wordwrap(array $attributes): string { return wordwrap(htmlspecialchars($attributes['data'], ENTQUOTES, 'UTF-8'), 100, '<br>', true); }

Option C — Sanitize at input:

php // lib/Froxlor/Api/Commands/DomainZones.php after line 160 $content = htmlspecialchars($content, ENTQUOTES, 'UTF-8');

Also remove 'unsafe-inline' and 'unsafe-eval' from the CSP header in lib/Froxlor/UI/Panel/UI.php:140.

--- If possible, please apply for a CVE when publishing.

Other sources

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.

MITRE

Affected Software

2 affected componentsFixes available
Froxlor<2.3.8
composer/froxlor/froxlor<=2.3.7
2.3.8

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade composer/froxlor/froxlor to a version that resolves this vulnerability.

    Fixed in 2.3.8
  2. Upgrade

    Upgrade Froxlor to a version that resolves this vulnerability.

    Fixed in 2.3.8
  3. Configuration

    In lib/Froxlor/UI/Panel/UI.php:140, edit the Content-Security-Policy header to remove 'unsafe-inline' and 'unsafe-eval' so inline scripts and eval are not allowed.

    Froxlor CSP header (lib/Froxlor/UI/Panel/UI.php:140) Content-Security-Policy = Remove 'unsafe-inline' and 'unsafe-eval' from the CSP header
  4. Configuration

    In templates/Froxlor/table/table.html.twig around line 57, change the DNS editor table cell rendering from {{ td.data|raw }} (raw HTML) to the escaped form (e.g., {{ td.data }}) so the callback output is not injected as raw HTML/JS.

    Froxlor DNS editor TXT content rendering (templates/Froxlor/table/table.html.twig:57) Twig rendering filter for td.data = Avoid rendering with |raw; rely on Twig auto-escaping
  5. Configuration

    In lib/Froxlor/UI/Callbacks/Text.php (wordwrap callback), escape the TXT record content before wrapping, e.g. use htmlspecialchars($content, ENT_QUOTES, 'UTF-8') so HTML special characters do not pass through unmodified.

    Froxlor Text callback wordwrap (lib/Froxlor/UI/Callbacks/Text.php:95) HTML escaping of callback return value = Apply htmlspecialchars with ENT_QUOTES and UTF-8 before wordwrap
  6. Operational

    Review DNS TXT records added by customers with dnsenabled = 1, identify any stored payloads in TXT content (e.g., HTML/JS-bearing content), and remove/replace them to prevent ongoing execution in admin sessions after the code/config fixes are applied.

Event History

Aug 18, 2026
CVE Published
via MITRE·08:16 PM
Data Sourced
via MITRE·08:16 PM
DescriptionSeverityWeakness
Advisory Published
via GitHub·08:47 PM
Data Sourced
via GitHub·08:47 PM
DescriptionSeverityWeaknessAffected Software

Frequently Asked Questions

1

Who is exposed to this issue?

Froxlor deployments prior to 2.3.8 are affected where authenticated customers have access to edit DNS TXT records and administrators review those domains' DNS configuration. Administrators are the immediate execution target because the stored payload runs in their browser session when they view the affected configuration.

2

What does an attacker need to exploit it?

An attacker needs an authenticated customer account with DNS editor access and must be able to submit malicious HTML or JavaScript in a DNS TXT record. Exploitation also requires an administrator to view the affected domain's DNS configuration.

3

What can be done if patching is not immediately possible?

Upgrade Froxlor to version 2.3.8, which fixes the issue. If an upgrade cannot happen immediately, restrict DNS editor access for untrusted customer accounts and avoid viewing DNS configurations containing customer-controlled TXT record content.

4

How can I check for possible exploitation or malicious content?

Review DNS TXT records created or modified by customer accounts for HTML special characters or JavaScript-bearing content, particularly on domains whose DNS configuration was viewed by administrators. Affected records are those whose content can be rendered through the DNS configuration interface.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203