CVE-2025-59943: High Duplicate Account Flaw in phpMyFAQ

CVE-2025-59943 is a high severity (CVSS 8.1) flaw in phpMyFAQ where email uniqueness is not enforced at registration. Several accounts can share one address, which can lead to account takeover in some configurations. Upgrade to 4.0.13. The sections below cover who is affected, how to check, and what to do now.

What's affected

From GitHub advisory GHSA-9wj2-4hcm-r74j, the Composer package thorsten/phpmyfaq from 4.0.7 up to but not including 4.0.13 is affected, and the fix is in 4.0.13.

There is a small difference between sources. The NVD text says versions 4.0 nightly of 3 October 2025 and below, while the advisory gives the 4.0.7 to 4.0.12 range. Use the advisory range, and if you run any other 4.0 build, upgrade anyway.

How to check if you're exposed

Check your version in the admin panel or with Composer:

composer show thorsten/phpmyfaq

Then look for accounts that already share an address. A query like this on the users table shows them, though table and column names depend on your version, so check your schema first:

SELECT email, COUNT(*) FROM faquserdata GROUP BY email HAVING COUNT(*) > 1;

Any result is worth a manual review, especially if one of the accounts has admin rights.

What to do now

1. Upgrade phpMyFAQ to 4.0.13 or later.
2. Query for duplicate email addresses and review each pair.
3. Remove or merge duplicate accounts you cannot explain, and reset credentials for affected users.
4. Restrict who can self register, or require email confirmation.
5. Add a unique database constraint on email after you clean up the data.

Why it matters

The record maps this to CWE-284, improper access control, and CWE-286, incorrect user management. The application treats email as an identity in places such as password reset, notifications and admin actions, yet does not guarantee that each email belongs to one account. Any process that looks up a user by email can then pick the wrong one.

The advisory lists the possible effects: loss of auditability, ambiguity in password reset, privilege escalation if one of the duplicate accounts is an administrator, and spam from mass registration. The vector in the record requires user interaction. It is not on the CISA KEV list. Uniqueness is best enforced in two places, in code and in a database constraint, so a future code change cannot undo it.

Authorization flaws are different from authentication flaws. The user may be properly logged in, yet the application fails to check whether that user is allowed to perform the specific action. These bugs are common in APIs because every endpoint has to repeat the check, and one missing check is enough.

The most useful test is to try each privileged action as an ordinary user and as an anonymous one, and confirm the server refuses both. Automated tests that do this for every route catch the regression the next time someone adds an endpoint.

Safeguard can help you find this one in your own software. The free in-browser dependency scan at gold.safeguard.sh/scan reads your manifest or lockfile and shows which known vulnerabilities your declared dependencies carry, including transitive ones. Reachability analysis then helps you separate the places where your code actually calls the affected component from the places where it only sits in the tree, which makes it easier to decide what to patch first.

Quick check

Sources

• GitHub advisory GHSA-9wj2-4hcm-r74j
• Fix commit
• NVD record data

Last reviewed: 18 October 2026.