phpMyFAQ CVE-2026-46363

Attacker must possess an authenticated phpMyFAQ account with FAQ_ADD permission assigned (PR:L). This permission is typically granted to content editors, FAQ managers, or support staff roles - not available to anonymous users or default user accounts. The vulnerability exists in both FAQ creation (/admin/api/faq/create) and update (/admin/api/faq/update) endpoints, both requiring valid CSRF tokens for the authenticated session. Attack complexity is low (AC:L) with no special server configuration required - default phpMyFAQ installations are vulnerable. User interaction is required (UI:R) because stored payloads only execute when other users view the malicious FAQ through the web interface or search results. The changed scope (S:C) means impact extends beyond the attacker's privilege level to affect all site visitors including administrators. Exploitation is NOT limited by network location (AV:N allows remote attack), server configuration, or specific deployment modes. The key limiting factor is the FAQ_ADD permission requirement - organizations that restrict FAQ editing to highly trusted accounts have reduced exposure, while those with distributed content management models face higher risk.

CVSS 5.4 (Medium) reflects network accessibility (AV:N) with low attack complexity (AC:L) but requires authenticated access with low privileges (PR:L) and user interaction (UI:R). The changed scope (S:C) is critical - it indicates the vulnerability can impact resources beyond the vulnerable component's security scope, meaning an attacker with FAQ editor permissions can execute JavaScript in the security context of all site visitors, including administrators. The confidentiality and integrity impacts are rated Low (C:L/I:L) with no availability impact (A:N), typical for XSS that can steal session tokens or perform actions as the victim but doesn't directly crash systems. Real-world risk assessment factors: (1) Authentication requirement significantly reduces attack surface compared to unauthenticated XSS - attacker must first obtain or compromise an account with FAQ_ADD permission, (2) User interaction requirement (UI:R) means victims must view the malicious FAQ, but this is highly likely in a FAQ system's normal usage patterns, (3) Publicly available exploit code exists via the GitHub security advisory GHSA-f5p7-2c9q-8896 with working proof-of-concept curl commands and payload examples, lowering exploitation barrier, (4) No CISA KEV listing suggests no confirmed mass exploitation campaigns, but stored XSS in content management systems is a proven attack vector for session hijacking and privilege escalation. The encode-decode bypass demonstrates sophisticated understanding of the sanitization logic, indicating this may be researcher-discovered rather than attacker-disclosed. Priority should be high for internet-facing phpMyFAQ installations with multiple user roles, moderate for internal-only deployments with trusted editors. Patch availability in version 4.1.2 provides clear remediation path.

An attacker with a low-privilege account possessing FAQ_ADD permission (such as a content editor or support staff member) crafts a malicious FAQ entry containing a <script> tag in the question or answer field. The payload is designed to steal session cookies or perform actions as authenticated users. When legitimate site visitors or administrators browse the FAQ section or use the search functionality, the stored JavaScript executes in their browser context with their privileges, potentially exfiltrating authentication tokens to attacker-controlled infrastructure or creating administrative accounts. Publicly available proof-of-concept code from GHSA-f5p7-2c9q-8896 demonstrates the exact curl command and JSON payload structure required, including valid CSRF token handling, significantly lowering technical barriers for exploitation.