CVE-2026-46361: phpMyFAQ Stored XSS Vulnerability

CVE-2026-46361 Overview

CVE-2026-46361 is a stored cross-site scripting (XSS) vulnerability [CWE-79] in phpMyFAQ versions before 4.1.2. The flaw resides in search.twig, where the result.question and result.answerPreview variables are rendered using the Twig raw filter, which disables autoescape protection. Attackers with FAQ editor privileges can inject HTML-entity-encoded payloads that bypass the html_entity_decode(strip_tags()) sanitization in SearchController.php. Once stored, the payload executes JavaScript in the browser of every visitor who views the search results, including administrators.

Critical Impact

Authenticated editors can plant persistent JavaScript that runs in administrator sessions, enabling account takeover, privilege escalation, and theft of session tokens across the entire phpMyFAQ instance.

Affected Products

• phpMyFAQ versions prior to 4.1.2
• Self-hosted phpMyFAQ deployments using the default search template
• Multi-tenant FAQ portals where editors are not fully trusted

Discovery Timeline

• 2026-05-15 - CVE-2026-46361 published to NVD
• 2026-05-18 - Last updated in NVD database

Technical Details for CVE-2026-46361

Vulnerability Analysis

The vulnerability is a stored XSS issue in phpMyFAQ's search results view. Twig templates apply autoescape by default, converting characters such as <, >, and " into HTML entities before rendering. The search.twig template explicitly applies the raw filter to result.question and result.answerPreview, disabling that protection. Any HTML present in those fields is rendered as live markup.

The server-side controller attempts to sanitize input through html_entity_decode(strip_tags()) in SearchController.php. This pipeline runs strip_tags() first on the user input, then decodes HTML entities. An attacker can submit payloads where the script tags are themselves entity-encoded, so strip_tags() sees no tags to remove. The subsequent html_entity_decode() call restores the original tag characters, which are then rendered unescaped by the raw filter.

Exploitation requires editor-level privileges (PR:H) and a victim interaction (UI:R), such as viewing search results. Because the payload is stored in FAQ content and rendered to every visitor, the scope changes (S:C) and confidentiality impact is high.

Root Cause

The root cause is the combination of two unsafe patterns: explicit use of Twig's raw filter on attacker-controllable data, and a sanitization routine that decodes HTML entities after tag stripping. Either weakness alone would be exploitable; together they guarantee that encoded markup survives sanitization and reaches the DOM as executable code.

Attack Vector

An authenticated user with the FAQ editor role creates or edits an FAQ entry containing an HTML-entity-encoded JavaScript payload in the question or answer body. The content is stored in the database. When any user, including an administrator, performs a search that returns the malicious entry, the browser executes the injected script under the origin of the phpMyFAQ instance. The attacker can then exfiltrate session cookies, perform actions on behalf of administrators, or pivot to further compromise.

No verified public exploit code is available. See the GitHub Security Advisory GHSA-pqh6-8fxf-jx22 and the VulnCheck Advisory on phpMyFAQ for technical details.

Detection Methods for CVE-2026-46361

Indicators of Compromise

• FAQ entries containing HTML-entity-encoded sequences such as <script>, <script>, or <script> in question or answer fields
• Unexpected outbound requests from administrator browsers shortly after viewing the FAQ search page
• New or modified administrator accounts created without a corresponding authenticated administrator session in audit logs
• Edits to FAQ content originating from low-privilege editor accounts that include unusual JavaScript-related strings

Detection Strategies

• Query the phpMyFAQ database for FAQ records whose question or answer columns contain encoded tag sequences or javascript: URIs
• Review web server access logs for /search or /index.php?action=search requests followed by anomalous POST requests from administrator sessions
• Inspect Twig templates for any remaining use of the raw filter applied to user-controllable variables

Monitoring Recommendations

• Enable a strict Content Security Policy (CSP) and monitor report-uri or report-to endpoints for violations originating from the FAQ search page
• Forward phpMyFAQ application and web server logs to a centralized logging platform and alert on entity-encoded script patterns in POST bodies
• Audit editor-role activity for content changes that include long encoded strings or atypical character sequences

How to Mitigate CVE-2026-46361

Immediate Actions Required

• Upgrade phpMyFAQ to version 4.1.2 or later on all production and staging instances
• Audit all FAQ entries created or modified by editor accounts since the last known-clean backup and remove any encoded HTML payloads
• Rotate administrator session cookies and credentials if exposure to the vulnerable template is suspected
• Review the editor role membership and remove accounts that no longer require content authoring privileges

Patch Information

The vendor fixed the issue in phpMyFAQ 4.1.2. The patch removes the raw filter from result.question and result.answerPreview in search.twig, restoring Twig's default autoescape behavior. The sanitization logic in SearchController.php should also be reviewed against the upstream changes. Refer to the GitHub Security Advisory GHSA-pqh6-8fxf-jx22 for the authoritative remediation guidance.

Workarounds

• Manually edit search.twig to remove the raw filter from result.question and result.answerPreview until the upgrade can be scheduled
• Restrict the FAQ editor role to fully trusted users and require multi-factor authentication for all privileged accounts
• Deploy a Content Security Policy that disallows inline scripts (script-src 'self') to limit the impact of any injected payload
• Place the phpMyFAQ instance behind a web application firewall with rules that block entity-encoded <script> patterns in POST bodies

# Example restrictive Content Security Policy header for nginx
add_header Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'" always;