CVE-2026-56736: phpMyFAQ Stored XSS via Admin Review

Overview

phpMyFAQ, an open-source FAQ management web application, is affected by CVE-2026-56736, a stored cross-site scripting (XSS) vulnerability tracked upstream as GHSA-pgwp-vc7q-cvj3. The flaw allows any unauthenticated visitor — or a low-privileged registered user — to submit a crafted FAQ entry from the public-facing frontend that plants persistent JavaScript. That payload survives the application's sanitization pipeline and executes in an administrator's browser the moment the admin opens the submission in the Admin FAQ Editor to review, approve, or edit it. Because the script runs in the admin's authenticated session, the practical outcome is session theft and potential full admin account takeover. The issue carries a CVSS v3.1 score of 8.2 (High), with vector AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N, and was published September 24, 2026. It is fixed in phpMyFAQ 4.2.0-alpha.

Technical Details

CWE Classification: CWE-79 (Improper Neutralization of Input During Web Page Generation / Cross-Site Scripting).

How It Works

The vulnerability lives in the gap between phpMyFAQ's input sanitization and how the Admin FAQ Editor renders stored content:

1. Submission — An unauthenticated or low-privileged user submits a new FAQ entry (or comment/edit) through the public frontend, embedding a payload in a field such as the FAQ question, answer, or keywords using HTML-encoded characters designed to slip past the initial filter.
2. Flawed sanitization order — On the way in, phpMyFAQ applies strip_tags() to the submitted content, which appears to remove executable markup. However, the application later calls html_entity_decode() on the same content — converting the previously-encoded entities back into live, executable HTML after the strip_tags() pass has already let them through unmodified.
3. Unsafe rendering in the admin template — When an administrator opens the pending or existing FAQ entry in the Admin FAQ Editor, the decoded content is rendered through a Twig template using the |raw filter, which disables Twig's automatic output escaping entirely. There is no output-side sanitization to catch what the flawed encode/decode chain missed.
4. Execution in the admin context — The injected JavaScript runs with the full privileges of the administrator's authenticated session, giving the attacker a path to steal session cookies, forge admin actions, or pivot to broader compromise of the FAQ instance.

The root cause is a classic sanitize-then-decode ordering bug: encoding-based filter bypasses are only effective if nothing downstream reverses the encoding before the content reaches a sink that executes it. Here, html_entity_decode() does exactly that immediately before an unescaped |raw render.

Impact Assessment

Who Is At Risk

Potential Attack Chains

• Session hijack → admin panel takeover — The attacker's script exfiltrates the admin's session cookie to an external endpoint; the attacker replays it to gain full administrative access to phpMyFAQ.
• Persistent backdoor via content tampering — With admin access obtained via the stolen session, the attacker edits other FAQ entries to plant additional stored payloads, creating a self-sustaining XSS foothold that survives remediation of the original entry.
• Credential harvesting via DOM manipulation — The injected script rewrites the admin UI (e.g., a fake re-authentication prompt) to capture the administrator's actual login credentials rather than just the session token.
• Chaining with other disclosed phpMyFAQ issues — CVE-2026-56736 was disclosed alongside related phpMyFAQ advisories, including an authentication bypass (CVE-2026-56737) and a SQL injection in StopWords::add() (CVE-2026-56738). An attacker could use this stored XSS to gain an initial administrative foothold and then leverage a co-disclosed flaw to escalate further or exfiltrate the underlying database.

Mitigation

Immediate Actions

1. Upgrade to phpMyFAQ 4.2.0-alpha or later — This is the only complete fix; it corrects the sanitize/decode ordering and removes the unsafe |raw rendering of user-submitted content in the Admin FAQ Editor.
2. Restrict or disable anonymous FAQ submission — If upgrading is not immediately possible, temporarily disable frontend submissions from unauthenticated or low-privileged users, or route all submissions through manual pre-moderation outside the vulnerable review flow.
3. Rotate admin session secrets — After patching, invalidate existing administrator sessions and force re-authentication, in case a payload was already planted and reviewed prior to remediation.
4. Audit existing FAQ content — Review recently submitted or edited FAQ entries, comments, and keyword fields for encoded script fragments (e.g., HTML-entity-encoded <script> tags or event handler attributes) that may already be stored.

Detection Opportunities

• Review the Admin FAQ Editor render path — Search the phpMyFAQ template layer for |raw filter usage on any field that originates from user-submitted content; this is the sink that made the bypass exploitable.
• Inspect stored FAQ records for entity-encoded payloads — Query the FAQ, comment, and keyword tables for values containing <, &#, or double-encoded sequences that would decode into <script>, onerror=, onload=, or similar executable constructs.
• Monitor admin-session network activity — Unexpected outbound requests from the admin panel origin (beaconing to unfamiliar domains) immediately after opening a FAQ entry for review is a strong indicator of active exploitation.
• Check web server and WAF logs — Look for FAQ submission requests containing HTML-entity-encoded script markup in the question, answer, or keyword parameters.

Defence-in-Depth

• Enforce Content Security Policy (CSP) on the admin panel to restrict inline script execution and unauthorized outbound connections, reducing the impact even if an XSS payload executes.
• Set HttpOnly and Secure flags on admin session cookies so that even a successful script injection cannot directly read the session token via document.cookie.
• Apply the principle of least privilege to admin accounts — separate the "review submissions" role from full administrative capability where phpMyFAQ's permission model allows it, limiting blast radius if a reviewer's session is compromised.
• Adopt a web application firewall (WAF) rule set tuned for stored-XSS patterns on form submission endpoints as a compensating control until the upgrade is deployed.
• Track phpMyFAQ security advisories going forward — this disclosure was one of three related phpMyFAQ CVEs released the same day, suggesting an active third-party security review of the codebase; expect further advisories and patches in the near term.

Key Takeaways

1. CVE-2026-56736 is a stored XSS in phpMyFAQ, fixed in 4.2.0-alpha, allowing unauthenticated attackers to target administrators.
2. The root cause is an encode/decode ordering flaw — html_entity_decode() reverses strip_tags() filtering before an unescaped Twig |raw render in the Admin FAQ Editor.
3. Exploitation requires no authentication to inject the payload, only that an administrator later reviews the malicious submission (UI:R in the CVSS vector).
4. Successful exploitation enables session theft and admin account takeover, with a path to further content tampering and database exposure.
5. Upgrading to phpMyFAQ 4.2.0-alpha or later is the only complete remediation; interim mitigations include disabling anonymous submissions and rotating admin sessions.
6. This CVE was disclosed alongside CVE-2026-56737 (authentication bypass) and CVE-2026-56738 (SQL injection), so patch reviews should account for chained exploitation across all three.

References

• NVD — CVE-2026-56736
• GitLab Advisory Database — CVE-2026-56736 (GHSA-pgwp-vc7q-cvj3)
• OSV.dev — GHSA-pgwp-vc7q-cvj3