phpMyFAQ EUVD-2026-71014

Exploitation requires an active, authenticated session in phpMyFAQ-the attacker must hold any valid user account on the instance (PR:L). No special roles or elevated permissions are needed beyond basic authenticated access. The vulnerable endpoint is the user control panel PUT API, which is exposed by default in all phpMyFAQ deployments before 4.1.8. No specific configuration is required to be vulnerable. Limiting factors: unauthenticated attackers cannot exploit this without first obtaining credentials; instances not exposed to untrusted authenticated users (e.g., internal-only deployments with no self-registration) have significantly reduced risk. The CSRF token requirement prevents cross-site exploitation but does not mitigate attacker-initiated direct API requests.

The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N) yields a score of 7.1, reflecting a network-accessible, low-complexity attack requiring only a low-privilege session with no user interaction needed and high integrity impact. Real-world risk is notably higher than the base score suggests because a low-privilege attacker can escalate to administrator by overwriting admin credentials, effectively achieving full application compromise. The PR:L requirement is the primary limiting factor-an attacker must already have a valid authenticated session, requiring either legitimate access or a prior credential theft. No KEV listing and no public POC are identified, meaning exploitation is currently limited to actors with session access. EPSS data was not supplied. The 'Authentication Bypass' tag in input metadata is a loose fit: authentication is not bypassed; rather, the password-change control within the authenticated workflow is bypassed. The core risk is broken access control in a privileged operation.

An attacker with a low-privilege phpMyFAQ account-obtained through legitimate registration or credential theft-crafts a PUT request to the user data update endpoint, supplying only a valid CSRF token and a target user ID with a chosen new password. Without any current-password check, the application accepts the request and overwrites the administrator's credentials. The attacker then logs in as administrator while the legitimate admin is locked out.