phpMyFAQ CVE-2025-68951

Requires that public self-registration is enabled (security.enableRegistration = true) so an unauthenticated attacker can create an account and control the display_name/real-name field; the attacker submits an HTML-entity-encoded payload (e.g. '<img src=x onerror=alert(1)>') which UserData.php decodes via html_entity_decode and users.twig renders with the Twig |raw filter. Execution is gated on an administrator actually opening the admin user list page (/admin/user/list), i.e. UI:R is mandatory - the payload is inert until an admin views it. Limiting factors: registration may be disabled in hardened deployments, impact is confined to the admin-panel context, and successful session/CSRF-token theft depends on cookie flags (HttpOnly/SameSite). Affected only in phpMyFAQ 4.0.14 and 4.0.15; patched in 4.0.16.

This is a genuine but moderate-priority issue, not an urgent emergency. The CVSS 3.1 base score of 6.1 (AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N) reflects a network-reachable, low-complexity, unauthenticated stored XSS with a scope change (attacker-registered user payload executes in the privileged admin context) but only Low confidentiality/integrity impact and no availability impact. No EPSS score, no CISA KEV listing, and no SSVC decision were provided in the input, so widespread or automated exploitation cannot be asserted. However, the GitHub Security Advisory (GHSA-jv8r-hv7q-p6vc) contains a complete, working proof-of-concept (register a user, set display name to '<img src=x onerror=alert(1)>', admin views user list), so publicly available exploit code effectively exists even though no structured POC/KEV flag was supplied. The key tempering factors are that exploitation requires UI:R (an administrator must actually open the admin user list) and that the self-registration feature (security.enableRegistration=true) must be enabled, which is not guaranteed in every deployment. The CVSS signals are internally consistent with the description - no conflicts were observed - so the realistic verdict is: a legitimate, patch-worthy admin-targeted XSS with a confirmed fix, meriting prompt patching but not drop-everything escalation absent any exploitation telemetry.

An unauthenticated attacker uses the public self-registration page to create an account, setting the display/real name to an HTML-entity-encoded payload such as '<img src=x onerror=alert(1)>'. The value is stored, then html_entity_decode'd on read and rendered through Twig's |raw filter when an administrator opens the admin user list, executing attacker JavaScript in the admin's authenticated session. A minimal, reproducible PoC is published in the vendor's GitHub Security Advisory.