CVE-2026-111894 in phpMyFAQ
Summary
by MITRE • 10/17/2026
phpMyFAQ 3.2.1 before 4.1.9 and 4.2.0-alpha before 4.2.0-beta contains a stored cross-site scripting vulnerability that allows authenticated content authors to inject JavaScript by embedding iframes with data:text/html sources in FAQ or News content. Attackers can bypass the hostless media-host allowlist in FaqHelper::cleanUpContent(), which is rendered via Twig's raw filter, to run phishing interfaces or top-frame redirects for viewers.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/18/2026
The vulnerability identified in phpMyFAQ versions 3.2.1 through 4.1.9 and version 4.2.0-alpha prior to 4.2.0-beta represents a significant security flaw within the content management subsystem of the application. This stored cross-site scripting (XSS) vulnerability specifically targets authenticated users who possess content authoring privileges, such as those with roles allowing them to create or edit FAQs and news items. The core technical issue stems from an insufficient sanitization process applied when processing user-supplied input for media sources. Specifically, the FaqHelper::cleanUpContent() function fails to adequately validate iframe src attributes that utilize data URIs, particularly those employing the data:text/html scheme. This oversight allows malicious actors to inject arbitrary HTML and JavaScript code directly into stored content fields rather than merely transient request parameters.
The exploitation mechanism relies on the attacker embedding an iframe element with a source attribute set to a crafted data URI containing executable script logic. Because phpMyFAQ utilizes Twig as its templating engine, the rendered output is subject to specific filtering rules defined in the application's configuration and codebase. The vulnerability arises because the allowlist for hostless media sources does not explicitly block or properly sanitize the data:text/html protocol scheme. Consequently, when an administrator or another user views the compromised FAQ entry or news item, the browser interprets the injected iframe as a legitimate resource. Twig’s raw filter is then applied to this content, which prevents automatic HTML escaping and ensures that the malicious script executes within the context of the victim's session.
From an operational impact perspective, this vulnerability enables severe consequences including account takeover via phishing campaigns or session hijacking through top-frame redirection attacks. An attacker can craft a deceptive login page hosted within the injected iframe, tricking users into submitting their credentials to the attacker-controlled server. Alternatively, the script can force the browser window to redirect away from phpMyFAQ entirely, potentially leading victims to malicious websites designed for malware distribution or further social engineering efforts. Since the payload is stored in the database, every user who views the affected content becomes a potential victim without requiring any additional interaction beyond page load, significantly increasing the attack surface and persistence of the threat.
This flaw aligns with CWE-79, which classifies improper neutralization of input during web page generation as cross-site scripting. The specific technique of using data URIs to bypass allowlists is also indicative of CWE-829, where inclusion of a function from an unintended control sphere occurs due to insufficient validation of external inputs. In terms of the MITRE ATT&CK framework, this vulnerability facilitates techniques associated with T1059, Command and Scripting Interpreter, specifically through browser-based execution via JavaScript. It also supports T1566, Phishing, by enabling the delivery of credential harvesting interfaces within a trusted domain context, thereby increasing user trust in the malicious content.
To mitigate this risk, immediate action is required to update phpMyFAQ to version 4.2.0-beta or later where these sanitization checks have been corrected. For organizations unable to upgrade immediately, implementing strict Content Security Policy (CSP) headers can help restrict the execution of inline scripts and limit iframe sources to trusted domains only. Additionally, deploying a Web Application Firewall with rules capable of detecting data URI injection attempts may provide an additional layer of defense. Administrators should also review existing content for any signs of compromise by searching for suspicious iframe tags or data URIs within FAQ and news entries. Regular security audits focusing on input validation logic in templating engines are essential to prevent similar vulnerabilities from being introduced during future development cycles.