phpMyFAQ EUVD-2026-103325

Exploitation requires the attacker to hold an authenticated phpMyFAQ account with content-author privileges (PR:L) able to create or edit FAQ or News content. The specific vector is embedding an iframe element with a data:text/html source, which evades the hostless media-host allowlist in FaqHelper::cleanUpContent() because the resulting content is emitted through Twig's raw filter without escaping. Payload execution additionally requires a victim to view the affected FAQ/News entry (UI:P). Limiting factors: affected versions are phpMyFAQ 3.2.1 through before 4.1.9 and 4.2.0-alpha before 4.2.0-beta (upgrade to 4.1.9 or 4.2.0-beta remediates), the attacker cannot be fully anonymous, and impact is confined to the viewer's browser session rather than the server.

This is a medium-severity stored XSS (CWE-79) with a vendor/VulnCheck CVSS 4.0 base score of 5.1, and the signals are internally consistent rather than conflicting. The vector (AV:N/AC:L/AT:N/PR:L/UI:P/VC:L/VI:L/VA:N with subsequent-system SC:L/SI:L) describes a network-reachable but privilege-gated flaw: PR:L confirms the attacker must already be an authenticated content author, and UI:P requires a victim to passively view the poisoned FAQ or News entry. No EPSS score, CISA KEV listing, or public POC is present in the provided data, so exploitation likelihood signals are absent rather than elevated - there is no evidence of active exploitation or weaponization. The limited confidentiality/integrity impact (L/L) and lack of availability impact keep this well below critical. Net: this is a genuine but modest-priority issue best handled via normal patching cadence, not an emergency - the author-level privilege requirement and need for victim interaction substantially constrain real-world abuse, and nothing in the data elevates it to a widespread or actively exploited threat.

An attacker with content-author credentials creates or edits an FAQ or News entry, embedding an iframe whose source is a data:text/html URI that bypasses the hostless media-host allowlist enforced by FaqHelper::cleanUpContent(); because the content is output through Twig's raw filter, the markup is rendered unsanitized. When a logged-in user or visitor views the entry, the attacker-controlled HTML/JavaScript executes in their browser, enabling a phishing interface or a top-frame redirect. No public exploit code is identified at time of analysis, though the advisory describes the technique in enough detail to reproduce it.