phpMyFAQ EUVD-2026-103331

Requires an authenticated delegated-administrator account that holds the addnews and delnews rights but lacks the editnews (NEWS_EDIT) right; the vulnerable endpoint PUT /admin/api/news/update erroneously authorizes against the NEWS_DELETE permission. The attacker must read the valid update-news CSRF token from their own session cookie. Limiting factors: this is not exploitable by unauthenticated or anonymous users (PR:H), it only applies to installations that use delegated/multi-admin accounts with these specific granular rights, and impact is confined to modifying public-facing news items (integrity only) with no data disclosure or service disruption.

This is a medium-severity, authenticated authorization flaw (CWE-863) with a realistically constrained risk profile. The provided CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:H/UI:N, VI:L only, VC/VA:N, score 5.1) is internally consistent with the description: exploitation is network-reachable and low-complexity, but requires high privileges (PR:H) - specifically an existing delegated-admin account already holding the addnews and delnews rights. The only impact is low integrity (public-facing news content tampering); there is no confidentiality or availability impact. No EPSS score, no CISA KEV listing, and no POC indicator were provided, so exploitation status is 'no public exploit identified at time of analysis.' The signals do not conflict - they uniformly point to a privilege-boundary/least-privilege bug rather than a broadly exploitable intrusion vector. Net: this is a legitimate fix-in-the-next-maintenance-cycle issue for multi-admin phpMyFAQ installs, not an emergency; the PR:H requirement and integrity-only impact keep real-world risk modest. The practical concern is insider or over-provisioned-delegate abuse and defacement/misinformation on the public front page, not remote unauthenticated compromise.

A multi-admin phpMyFAQ deployment grants a lower-tier delegated administrator only addnews and delnews rights, intending to deny them edit capability. Because PUT /admin/api/news/update checks the NEWS_DELETE permission instead of NEWS_EDIT, that delegate reads the update-news CSRF token from their own authenticated session cookie and issues the request, rewriting any news item's header, body, author, link, and active flag as shown on the public homepage. No public exploit code was identified; the attack is low-complexity but requires the attacker to already hold a privileged delegated-admin account.