phpMyFAQ EUVD-2025-32505

Exploitation requires that user self-registration is enabled on the phpMyFAQ instance (so an attacker can create accounts at all) and that the installation's business logic - specifically password reset, notifications, or administrative actions - uses the email address as an account identifier rather than the unique user_id. Escalation to account takeover or privilege escalation additionally requires that a privileged/admin account already exists under the email the attacker targets, as stated by the advisory ('in certain configurations, may lead to...'). The vulnerable function is createUser in RegistrationHelper.php / User.php, which prior to 4.0.13 performed no emailExists() check. Limiting factors: no account takeover occurs in deployments that key flows off the unique user ID, no privileged victim account under the target email means impact is limited to accountability loss and spam/duplicate pollution, and registration must be open to anonymous users.

The signals in this case conflict sharply and the headline CVSS 9.8 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) overstates real-world risk. The description itself qualifies the severe outcomes - privilege escalation and account takeover occur only 'in certain configurations' where email is the sole identifier for password-reset or administrative flows, which contradicts the AC:L/no-conditions assumption baked into the 9.8 score. EPSS is just 0.05% (16th percentile), indicating very low probability of exploitation at scale, and the vulnerability is NOT in CISA KEV, so there is no confirmed active exploitation. A public PoC does exist (GHSA-9wj2-4hcm-r74j), but it merely demonstrates creating two accounts with the same email and both appearing in the admin user list - not a working account-takeover exploit. The underlying weakness (CWE-284, improper enforcement of email uniqueness at registration) is a business-logic/accountability flaw; its escalation to C:H/I:H/A:H depends on deployment-specific conditions (email-only password reset AND an existing privileged account sharing the target email) that the advisory explicitly frames as conditional. Net: this is a legitimate hardening fix worth patching, but the combination of low EPSS, no KEV listing, a non-weaponized PoC, and conditional impact makes it a moderate real-world priority rather than a critical emergency - the 9.8 should be treated with skepticism and the C/I/A:H impacts verified against the actual deployment before prioritizing.

On a phpMyFAQ instance with open self-service registration, an attacker registers a new account using the same email address as an existing (ideally privileged) user; because uniqueness is not enforced, both accounts coexist. If the site's password-reset or notification logic keys off the email rather than the unique user ID, the attacker can leverage this ambiguity to intercept reset flows or impersonate the victim. A public PoC exists but only proves duplicate-account creation, not a turnkey takeover.