phpMyFAQ EUVD-2026-30597

Attacker must have authenticated access to phpMyFAQ with FAQ_EDIT permission enabled for their account. This permission is typically granted to content editors and administrators but not to anonymous or basic authenticated users. The phpMyFAQ installation must have SVG upload functionality enabled (default configuration in vulnerable versions). Victim exploitation requires user interaction-victims must click on the malicious SVG link embedded in FAQ content; simply viewing the FAQ page does not trigger JavaScript execution. The uploaded SVG must be served from the phpMyFAQ application origin with image/svg+xml MIME type, which is the default behavior. Exploitation is limited to stored XSS impact: attackers can execute JavaScript in victims' browsers but cannot directly compromise the server or bypass the need for initial authenticated access. The vulnerability does not provide privilege escalation to FAQ_EDIT permission itself-attackers must already possess this permission or compromise an account that has it. Small installations with single administrator and no content editors have lower practical risk; multi-user installations with distributed content management are at higher risk.

The CVSS v3.1 vector (AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N) yields a base score of 5.4 (Medium), which accurately reflects the attack requirements and impact. Network vector (AV:N) and low complexity (AC:L) indicate the vulnerability is exploitable remotely without special conditions once authentication is obtained. Low privileges required (PR:L) means attackers need authenticated access with FAQ_EDIT permission, limiting the initial attack surface to trusted users or compromised accounts. User interaction required (UI:R) is a critical limiting factor-victims must click the malicious SVG link for JavaScript execution, reducing exploitation probability versus fully automated attacks. Scope change (S:C) correctly captures that the XSS executes in the context of other users' sessions, enabling session hijacking, credential theft, or actions performed as the victim. Confidentiality and Integrity impacts are both Low (C:L/I:L) because while the attacker can read session data and modify content within the victim's browser context, direct server-side compromise is not achievable through XSS alone. No EPSS score or KEV listing is available, suggesting this vulnerability has not been observed in widespread exploitation campaigns. However, the presence of a detailed GitHub security advisory (GHSA-whqh-9pq5-c7r3) with technical proof-of-concept significantly lowers the barrier to exploitation-any authenticated attacker with FAQ_EDIT permission can weaponize this using the documented technique. The real-world risk is moderate: organizations using phpMyFAQ with multiple authenticated content editors face risk of privilege escalation (lower-privilege editor compromising administrator) or watering-hole attacks targeting FAQ readers. Small installations with tight access control and limited FAQ_EDIT users face lower risk. The required authentication and user interaction prevent mass-exploitation worms but do not prevent targeted attacks against high-value phpMyFAQ deployments. Priority should be MEDIUM-patch promptly but not emergency-level unless your phpMyFAQ installation has many authenticated users or contains sensitive data accessible via XSS.

An authenticated attacker with FAQ_EDIT permission logs into phpMyFAQ and navigates to the image upload interface at /admin/api/content/images. The attacker crafts a malicious SVG file containing an <a> element with href attribute encoding the string 'javascript:alert(document.domain)' using five levels of ampersand nesting around numeric HTML entities: <svg><a href="&amp;amp;amp;amp;amp;#106;&amp;amp;amp;amp;amp;#97;&amp;amp;amp;amp;amp;#118;...">Click me</a></svg>. After upload, the SVG is stored unsanitized in content/user/images/ and served with image/svg+xml MIME type. The attacker shares a link to a FAQ entry containing the uploaded SVG. When a victim (including administrators) views the FAQ and clicks the 'Click me' link in the SVG, the browser's XML parser decodes the nested entities, reconstructing the javascript: URL, and executes the attacker's JavaScript in the victim's session context. The attacker can then exfiltrate session cookies, perform actions as the victim, or inject additional malicious content into the FAQ system. VulnCheck advisory provides proof-of-concept demonstrating this exact attack path with working payload.