phpMyFAQ EUVD-2026-103330

Requires a valid, already-activated phpMyFAQ user account of any (non-admin) privilege level - the attacker must be authenticated (PR:L), so anonymous/unauthenticated access to the data is not possible. The affected feature is the admin dashboard endpoint /admin/index.php/, which fails to check admin authorization. Limiting factors: the instance must allow the attacker to obtain an activated account (self-registration enabled, or a provisioned low-privilege login), and the exposure is read-only disclosure of unpublished FAQs, admin edit URLs, recent user identities, and site statistics - no write, modification, or availability impact. Fixed in 4.1.9 and 4.2.0-beta.

This is a medium-severity information-disclosure issue, not a top-tier priority. The vendor-supplied CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N) scores 5.3 and is internally consistent with the description: network-reachable, low attack complexity, but requiring an authenticated low-privilege account (PR:L) and causing only limited confidentiality impact (VC:L) with no integrity or availability effect. CWE-862 (Missing Authorization) aligns with the described behavior. No EPSS score, no CISA KEV listing, and no public POC were provided, so there is no signal of active or imminent exploitation - this is confirmed actively exploited only if KEV says so, which it does not here; status is: no public exploit identified at time of analysis. The main caveat is that the input Tags label this an 'Authentication Bypass,' which conflicts with the description and CWE-862: authentication is REQUIRED (any activated account), and it is authorization that is missing - defenders should treat this as a privilege/authorization flaw, not an auth bypass. Overall real-world risk is moderate-to-low: it is useful for an attacker who already has a foothold account to harvest reconnaissance data, but it does not grant code execution, write access, or unauthenticated entry.

An attacker self-registers or uses any activated non-admin account on a phpMyFAQ instance, then simply browses to /admin/index.php/. Because the dashboard fails to enforce admin-level authorization, the attacker reads unpublished FAQ questions, admin edit URLs, recent user identities, and site statistics - useful reconnaissance for further targeting. No public exploit code is referenced, but the request requires only a normal browser and a valid low-privilege login.