phpMyFAQ EUVD-2026-103312

Exploitation requires an authenticated account holding the global edit_faq permission (CVSS PR:L); it cannot be performed by anonymous or unauthenticated users. Given such an account, no further special conditions apply - the attacker simply calls the REST endpoint PUT /api/v3.1/faq/update and references the numeric ID of any FAQ, including restricted ones they cannot otherwise view, against a default configuration of the affected phpMyFAQ versions. The practical limiting factors are therefore the presence of the REST API being enabled/reachable and how broadly the edit_faq permission is granted: deployments that assign edit_faq only to fully-trusted administrators face low realistic risk, while those granting it to many content editors are directly exposed.

This is a genuine but conditional priority, not a widespread-emergency flaw. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N, score 8.7) confirms network-reachable, low-complexity exploitation requiring only low privileges (PR:L) and no user interaction, with high confidentiality and integrity impact (VC:H/VI:H) and low availability impact (VA:L). The key limiting signal is PR:L: this is NOT an unauthenticated attack - an attacker must already hold a valid account with the global edit_faq permission, which narrows the threat surface to insiders, low-trust editorial accounts, or attackers who have obtained such credentials. No EPSS score, no CISA KEV listing, and no public POC are present in the provided data, so there is no evidence of active or at-scale exploitation; the signals are therefore internally consistent (a high-impact but privilege-gated authorization flaw) rather than conflicting. CWE-639 (broken object-level authorization) is a well-understood, easily weaponized class once an authenticated session exists, so remediation should be prioritized for any deployment that grants edit_faq to semi-trusted or numerous users, while installations where edit_faq is tightly restricted to fully-trusted administrators face materially lower real-world risk.

A low-privilege content editor who holds the edit_faq permission, but who is not authorized to view a restricted/moderated FAQ entry, sends a crafted PUT request to /api/v3.1/faq/update supplying the ID of that restricted FAQ. The endpoint checks only the global edit_faq permission and not access to the specific object, so the attacker overwrites the restricted entry's content, bypasses moderation, and flips its publication state to public. No public exploit code is identified at time of analysis, but exploitation is trivial given a valid authenticated session.