CWE-640
Allowed-with-ReviewWeak Password Recovery Mechanism for Forgotten Password
Abstraction: Base · Status: Incomplete
The product contains a mechanism for users to recover or change their passwords without knowing the original password, but the mechanism is weak.
431 vulnerabilities reference this CWE, most recent first.
GHSA-9473-JHHC-4CQ3
Vulnerability from github – Published: 2025-09-12 18:31 – Updated: 2025-09-12 18:31A vulnerability has been found in Wavlink WL-WN578W2 221110. The affected element is an unknown function of the file /sysinit.html. The manipulation of the argument newpass/confpass leads to weak password recovery. The attack is possible to be carried out remotely. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.
{
"affected": [],
"aliases": [
"CVE-2025-10322"
],
"database_specific": {
"cwe_ids": [
"CWE-640"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-12T18:15:33Z",
"severity": "MODERATE"
},
"details": "A vulnerability has been found in Wavlink WL-WN578W2 221110. The affected element is an unknown function of the file /sysinit.html. The manipulation of the argument newpass/confpass leads to weak password recovery. The attack is possible to be carried out remotely. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.",
"id": "GHSA-9473-jhhc-4cq3",
"modified": "2025-09-12T18:31:10Z",
"published": "2025-09-12T18:31:10Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-10322"
},
{
"type": "WEB",
"url": "https://github.com/ZZ2266/.github.io/tree/main/WAVLINK/WL-WN578W2/sysinit.html"
},
{
"type": "WEB",
"url": "https://vuldb.com/?ctiid.323748"
},
{
"type": "WEB",
"url": "https://vuldb.com/?id.323748"
},
{
"type": "WEB",
"url": "https://vuldb.com/?submit.643433"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:P/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",
"type": "CVSS_V4"
}
]
}
GHSA-95FV-5GFJ-2R84
Vulnerability from github – Published: 2025-12-08 16:25 – Updated: 2025-12-29 19:43Withdrawn Advisory
This advisory has been withdrawn because it incorrectly listed MediaBrowser.Server.Core as vulnerable. CVE-2025-64113 affects Emby Server versions 4.9.1.80 and prior, and Emby Server Beta versions 4.9.2.6 and prior.
Original Description
Impact
This vulnerability affects all Emby Server versions - beta and stable up to the specified versions. It allows an attacker to gain full administrative access to an Emby Server (for Emby Server administration, not at the OS level,). Other than network access, no specific preconditions need to be fulfilled for a server to be vulnerable.
Patches
Quick Fix
A quick fix will be rolled out via an update to one of the default-included Emby Server plugins. This way is chosen because many users are updating their servers manually while plugin updates are typically configured to be applied automatically. This allows to get a patch deployed to a large amount of servers within a single day.
Server Patches
Patched versions for both, Emby Server stable and Emby Server beta are available now.
All Emby Server owners are strongly encouraged to apply those updates as soon as possible.
Workarounds
[!NOTE] These workarounds are OBSOLETE now. Please update Emby Server instead!
As and immediate remedy, it is possible to set restricted file system permissions on the passwordreset.txt file in the configuration folder of Emby Server. If it doesn't exist, users can create the file themselves or just call the ForgotPassword API once, which will create the file.
On Windows, users can set DENY permissions for "Authenticated users" and on Linux, permissions can be set via sudo chmod 444 passwordreset.txt.
This will make the API request fail, which completely eliminates the vulnerability.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.9.1.80"
},
"package": {
"ecosystem": "NuGet",
"name": "MediaBrowser.Server.Core"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.9.1.81"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-64113"
],
"database_specific": {
"cwe_ids": [
"CWE-640"
],
"github_reviewed": true,
"github_reviewed_at": "2025-12-08T16:25:53Z",
"nvd_published_at": "2025-12-09T20:15:54Z",
"severity": "CRITICAL"
},
"details": "### Withdrawn Advisory\nThis advisory has been withdrawn because it incorrectly listed [MediaBrowser.Server.Core](https://www.nuget.org/packages/MediaBrowser.Server.Core) as vulnerable. CVE-2025-64113 affects Emby Server versions 4.9.1.80 and prior, and Emby Server Beta versions 4.9.2.6 and prior.\n\n### Original Description\n### Impact\n\nThis vulnerability affects all Emby Server versions - beta and stable up to the specified versions.\nIt allows an attacker to gain full administrative access to an Emby Server (for Emby Server administration, **not at the OS level**,).\nOther than network access, no specific preconditions need to be fulfilled for a server to be vulnerable.\n\n### Patches\n\n#### Quick Fix\n\nA quick fix will be rolled out via an update to one of the default-included Emby Server plugins.\nThis way is chosen because many users are updating their servers manually while plugin updates are typically configured to be applied automatically. This allows to get a patch deployed to a large amount of servers within a single day.\n\n#### Server Patches\n\nPatched versions for both, Emby Server stable and Emby Server beta are available now.\n\n**All Emby Server owners are strongly encouraged to apply those updates as soon as possible.**\n\n\n### Workarounds\n\n\u003e [!NOTE]\n\u003e These workarounds are OBSOLETE now. Please update Emby Server instead!\n\nAs and immediate remedy, it is possible to set restricted file system permissions on the `passwordreset.txt` file in the configuration folder of Emby Server. If it doesn\u0027t exist, users can create the file themselves or just call the ForgotPassword API once, which will create the file.\n\nOn Windows, users can set DENY permissions for \"Authenticated users\" and on Linux, permissions can be set via `sudo chmod 444 passwordreset.txt`.\nThis will make the API request fail, which completely eliminates the vulnerability.",
"id": "GHSA-95fv-5gfj-2r84",
"modified": "2025-12-29T19:43:24Z",
"published": "2025-12-08T16:25:53Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/EmbySupport/Emby.Security/security/advisories/GHSA-95fv-5gfj-2r84"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-64113"
},
{
"type": "PACKAGE",
"url": "https://github.com/EmbySupport/Emby.Security"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:L/SI:L/SA:L",
"type": "CVSS_V4"
}
],
"summary": "Withdrawn Advisory: Emby Server API Vulnerability allowing to gain administrative access without precondition",
"withdrawn": "2025-12-29T19:43:24Z"
}
GHSA-95VM-PH4X-XHV5
Vulnerability from github – Published: 2024-09-11 21:30 – Updated: 2024-09-11 21:30A vulnerability classified as critical was found in TDuckCloud TDuckPro up to 6.3. Affected by this vulnerability is an unknown functionality. The manipulation leads to weak password recovery. The attack can be launched remotely. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.
{
"affected": [],
"aliases": [
"CVE-2024-8692"
],
"database_specific": {
"cwe_ids": [
"CWE-640"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-09-11T19:15:15Z",
"severity": "MODERATE"
},
"details": "A vulnerability classified as critical was found in TDuckCloud TDuckPro up to 6.3. Affected by this vulnerability is an unknown functionality. The manipulation leads to weak password recovery. The attack can be launched remotely. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.",
"id": "GHSA-95vm-ph4x-xhv5",
"modified": "2024-09-11T21:30:37Z",
"published": "2024-09-11T21:30:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-8692"
},
{
"type": "WEB",
"url": "https://vuldb.com/?ctiid.277165"
},
{
"type": "WEB",
"url": "https://vuldb.com/?id.277165"
},
{
"type": "WEB",
"url": "https://vuldb.com/?submit.401715"
},
{
"type": "WEB",
"url": "https://www.shawroot.cc/2794.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/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",
"type": "CVSS_V4"
}
]
}
GHSA-988H-MP33-6M53
Vulnerability from github – Published: 2024-06-19 03:34 – Updated: 2024-06-19 03:34The Login with phone number plugin for WordPress is vulnerable to unauthorized password resets in versions up to, and including 1.7.34. This is due to the plugin generating too weak a reset code, and the code used to reset the password has no attempt or time limit. This makes it possible for unauthenticated attackers to reset the password of arbitrary users by guessing a 6-digit numeric reset code.
{
"affected": [],
"aliases": [
"CVE-2024-6125"
],
"database_specific": {
"cwe_ids": [
"CWE-640"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-19T02:15:09Z",
"severity": "HIGH"
},
"details": "The Login with phone number plugin for WordPress is vulnerable to unauthorized password resets in versions up to, and including 1.7.34. This is due to the plugin generating too weak a reset code, and the code used to reset the password has no attempt or time limit. This makes it possible for unauthenticated attackers to reset the password of arbitrary users by guessing a 6-digit numeric reset code.",
"id": "GHSA-988h-mp33-6m53",
"modified": "2024-06-19T03:34:44Z",
"published": "2024-06-19T03:34:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-6125"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset/3104085/login-with-phone-number#file5"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/301a67a5-226c-413a-9198-66747d1b1fd3?source=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-9G5V-HMCJ-PXRC
Vulnerability from github – Published: 2026-01-12 18:30 – Updated: 2026-01-12 21:30A static password reset token in the password reset function of DDSN Interactive Acora CMS v10.7.1 allows attackers to arbitrarily reset the user password and execute a full account takeover via a replay attack.
{
"affected": [],
"aliases": [
"CVE-2025-63314"
],
"database_specific": {
"cwe_ids": [
"CWE-640"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-01-12T17:15:52Z",
"severity": "CRITICAL"
},
"details": "A static password reset token in the password reset function of DDSN Interactive Acora CMS v10.7.1 allows attackers to arbitrarily reset the user password and execute a full account takeover via a replay attack.",
"id": "GHSA-9g5v-hmcj-pxrc",
"modified": "2026-01-12T21:30:34Z",
"published": "2026-01-12T18:30:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-63314"
},
{
"type": "WEB",
"url": "https://github.com/padayali-JD/CVE-2025-63314"
},
{
"type": "WEB",
"url": "http://acora.com"
},
{
"type": "WEB",
"url": "http://ddsn.com"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-9JH7-HMGX-8GQ5
Vulnerability from github – Published: 2026-05-30 12:30 – Updated: 2026-05-30 12:30The Simple History – Track, Log, and Audit WordPress Changes plugin for WordPress is vulnerable to authenticated (Subscriber+) account takeover in all versions up to, and including, 5.26.0 via the event reaction endpoints (react_to_event() / unreact_to_event()). The endpoints register get_items_permissions_check() as their permission_callback, which only verifies the requester is logged in and does not enforce the per-logger capability checks normally applied by Log_Query. As a result, a Subscriber-level user can POST to /wp-json/simple-history/v1/events//react with the _fields=context query parameter and read the full context of any Simple History event — including SimpleUserLogger entries that record the full password-reset email body (reset URL with the reset key) for any user. The attacker triggers a password reset for an administrator via the lost-password form, brute-forces recent event IDs through the reaction endpoint to read the resulting user_requested_password_reset_link event, extracts the reset key from context.message, and completes the password reset to take over the administrator account. Exploitation requires an administrator to have first enabled the experimental features option (simple_history_experimental_features_enabled), which is not the default.
{
"affected": [],
"aliases": [
"CVE-2026-7459"
],
"database_specific": {
"cwe_ids": [
"CWE-640"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-30T10:16:22Z",
"severity": "HIGH"
},
"details": "The Simple History \u2013 Track, Log, and Audit WordPress Changes plugin for WordPress is vulnerable to authenticated (Subscriber+) account takeover in all versions up to, and including, 5.26.0 via the event reaction endpoints (react_to_event() / unreact_to_event()). The endpoints register get_items_permissions_check() as their permission_callback, which only verifies the requester is logged in and does not enforce the per-logger capability checks normally applied by Log_Query. As a result, a Subscriber-level user can POST to /wp-json/simple-history/v1/events/\u003cid\u003e/react with the _fields=context query parameter and read the full context of any Simple History event \u2014 including SimpleUserLogger entries that record the full password-reset email body (reset URL with the reset key) for any user. The attacker triggers a password reset for an administrator via the lost-password form, brute-forces recent event IDs through the reaction endpoint to read the resulting user_requested_password_reset_link event, extracts the reset key from context.message, and completes the password reset to take over the administrator account. Exploitation requires an administrator to have first enabled the experimental features option (simple_history_experimental_features_enabled), which is not the default.",
"id": "GHSA-9jh7-hmgx-8gq5",
"modified": "2026-05-30T12:30:26Z",
"published": "2026-05-30T12:30:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-7459"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/simple-history/tags/5.26.0/inc/class-event.php#L613"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/simple-history/tags/5.26.0/inc/class-wp-rest-events-controller.php#L1215"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/simple-history/tags/5.26.0/inc/class-wp-rest-events-controller.php#L1420"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/simple-history/tags/5.26.0/inc/class-wp-rest-events-controller.php#L1460"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/simple-history/tags/5.26.0/inc/class-wp-rest-events-controller.php#L778"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/simple-history/trunk/inc/class-event.php#L613"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/simple-history/trunk/inc/class-wp-rest-events-controller.php#L1215"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/simple-history/trunk/inc/class-wp-rest-events-controller.php#L1420"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/simple-history/trunk/inc/class-wp-rest-events-controller.php#L1460"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/simple-history/trunk/inc/class-wp-rest-events-controller.php#L778"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset/3524112/simple-history/trunk/inc/class-wp-rest-events-controller.php"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/95d2bf1a-0993-4553-a00e-6f555c3f15be?source=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-9JJ4-588G-MM69
Vulnerability from github – Published: 2023-06-23 18:30 – Updated: 2024-04-04 05:07A logic issue was addressed with improved state management. This issue is fixed in macOS Ventura 13. A user may accidentally add a participant to a Shared Album by pressing the Delete key
{
"affected": [],
"aliases": [
"CVE-2022-42807"
],
"database_specific": {
"cwe_ids": [
"CWE-640"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-06-23T18:15:10Z",
"severity": "MODERATE"
},
"details": "A logic issue was addressed with improved state management. This issue is fixed in macOS Ventura 13. A user may accidentally add a participant to a Shared Album by pressing the Delete key",
"id": "GHSA-9jj4-588g-mm69",
"modified": "2024-04-04T05:07:00Z",
"published": "2023-06-23T18:30:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-42807"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/HT213488"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-9Q2Q-93HF-G3JQ
Vulnerability from github – Published: 2023-05-31 12:30 – Updated: 2023-05-31 12:30A vulnerability was found in ningzichun Student Management System 1.0. It has been rated as critical. Affected by this issue is some unknown functionality of the file resetPassword.php of the component Password Reset Handler. The manipulation of the argument sid leads to weak password recovery. The attack may be launched remotely. The exploit has been disclosed to the public and may be used. VDB-230354 is the identifier assigned to this vulnerability.
{
"affected": [],
"aliases": [
"CVE-2023-3007"
],
"database_specific": {
"cwe_ids": [
"CWE-640"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-05-31T12:15:09Z",
"severity": "MODERATE"
},
"details": "A vulnerability was found in ningzichun Student Management System 1.0. It has been rated as critical. Affected by this issue is some unknown functionality of the file resetPassword.php of the component Password Reset Handler. The manipulation of the argument sid leads to weak password recovery. The attack may be launched remotely. The exploit has been disclosed to the public and may be used. VDB-230354 is the identifier assigned to this vulnerability.",
"id": "GHSA-9q2q-93hf-g3jq",
"modified": "2023-05-31T12:30:35Z",
"published": "2023-05-31T12:30:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-3007"
},
{
"type": "WEB",
"url": "https://github.com/Xor-Gerke/webray.com.cn/blob/main/cve/student-management-system/password_reset.md"
},
{
"type": "WEB",
"url": "https://vuldb.com/?ctiid.230354"
},
{
"type": "WEB",
"url": "https://vuldb.com/?id.230354"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-9QV9-8XV6-5P35
Vulnerability from github – Published: 2026-05-20 15:45 – Updated: 2026-05-28 14:23Summary
The password reset API can be triggered without authentication and without any out-of-band confirmation step.
If an attacker knows a valid username + email pair, they can call the reset endpoint directly. The application immediately generates a new password, writes it to the account, and only then sends the new password by email.
This creates two issues at the same time:
- account enumeration through the response difference between valid and invalid pairs
- forced password reset of another user's account, which invalidates the old password immediately
In my local reproduction, I confirmed both the response difference and the password change itself.
Details
The relevant code is in phpmyfaq/src/phpMyFAQ/Controller/Frontend/Api/UnauthorizedUserController.php.
The route is exposed without authentication:
#[Route(path: 'user/password/update', name: 'api.private.user.password', methods: ['PUT'])]
public function updatePassword(Request $request): JsonResponse
The flow is straightforward:
$loginExist = $user->getUserByLogin($username);
if ($loginExist && $email === $user->getUserData('email')) {
$newPassword = $user->createPassword();
$user->changePassword($newPassword);
$mail->send();
return $this->json(['success' => Translation::get(key: 'lostpwd_mail_okay')], Response::HTTP_OK);
}
return $this->json(['error' => Translation::get(key: 'lostpwd_err_1')], Response::HTTP_CONFLICT);
The core issue is that the password is changed immediately after a simple username and email match. There is no reset token, no confirmation link, no second step, and no requirement that the caller prove control of the mailbox before the password is replaced.
That means the endpoint is not just a "forgot password email sender". It is an actual unauthenticated password change trigger.
PoC
This was reproduced against a local Docker deployment of the project.
For a valid username and email pair:
PUT /api/index.php/user/password/update HTTP/1.1
Host: 127.0.0.1
Content-Type: application/json
{"username":"user1","email":"user1@example.com"}
Response:
HTTP/1.0 200 OK
Content-Type: application/json
{"success":"Email has been sent."}
For an invalid pair:
PUT /api/index.php/user/password/update HTTP/1.1
Host: 127.0.0.1
Content-Type: application/json
{"username":"user1","email":"wrong@example.com"}
Response:
HTTP/1.0 409 Conflict
Content-Type: application/json
{"error":"Error: Username and email address not found."}
That already confirms enumeration.
To verify that the password really changes, created a test account:
- username:
user2 - password:
Oldpass123! - email:
user2@example.com
Before calling the endpoint, the password hash stored in faquserlogin was:
481bf096fd16e68ebbb8b98368bc0b5c17631a00f01a36dbb4a8dade0f0b8125
Then send:
PUT /api/index.php/user/password/update HTTP/1.1
Host: 127.0.0.1
Content-Type: application/json
{"username":"user2","email":"user2@example.com"}
The response was:
HTTP/1.0 200 OK
Content-Type: application/json
{"success":"Email has been sent."}
After that, the stored hash changed to:
3497f20c251da705f673dcac500fbf9e2e2e495719a7e2df9be08db42bf1286f
Then try to log in with the old password:
POST /authenticate HTTP/1.1
Host: 127.0.0.1
Content-Type: application/x-www-form-urlencoded
faqusername=user2&faqpassword=Oldpass123!
The application redirected back to the login page and reported that the password was incorrect.
So this is not just a cosmetic issue in the API response. The old credential really becomes invalid.
Impact
The most realistic impact here is forced password reset and account disruption.
An attacker who knows or can guess a valid username and email pair can:
- confirm whether the pair is valid
- force the target account's password to change
- cause the victim's old password to stop working immediately
If the attacker does not control the victim's mailbox, this is usually a denial-of-service style account disruption rather than instant account takeover. That is the main reason I would keep the severity at Medium.
Even so, this is still a real security issue. Password recovery should not allow an unauthenticated caller to change the account password directly.
Remediation
Recommend to change the password recovery flow to a token-based design.
- Do not change the password inside the unauthenticated endpoint.
- Generate a short-lived, single-use reset token and send only the reset link by email.
- Return the same generic response for both valid and invalid username/email pairs.
- Keep rate limiting in place, but do not rely on it as the main protection.
- Add regression tests that verify the password hash does not change until a valid reset token is presented.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "thorsten/phpmyfaq"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "phpmyfaq/phpmyfaq"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-35676"
],
"database_specific": {
"cwe_ids": [
"CWE-640"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-20T15:45:53Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Summary\n\nThe password reset API can be triggered without authentication and without any out-of-band confirmation step.\n\nIf an attacker knows a valid `username + email` pair, they can call the reset endpoint directly. The application immediately generates a new password, writes it to the account, and only then sends the new password by email.\n\nThis creates two issues at the same time:\n\n- account enumeration through the response difference between valid and invalid pairs\n- forced password reset of another user\u0027s account, which invalidates the old password immediately\n\nIn my local reproduction, I confirmed both the response difference and the password change itself.\n\n### Details\n\nThe relevant code is in `phpmyfaq/src/phpMyFAQ/Controller/Frontend/Api/UnauthorizedUserController.php`.\n\nThe route is exposed without authentication:\n\n```php\n#[Route(path: \u0027user/password/update\u0027, name: \u0027api.private.user.password\u0027, methods: [\u0027PUT\u0027])]\npublic function updatePassword(Request $request): JsonResponse\n```\n\nThe flow is straightforward:\n\n```php\n$loginExist = $user-\u003egetUserByLogin($username);\n\nif ($loginExist \u0026\u0026 $email === $user-\u003egetUserData(\u0027email\u0027)) {\n $newPassword = $user-\u003ecreatePassword();\n $user-\u003echangePassword($newPassword);\n $mail-\u003esend();\n return $this-\u003ejson([\u0027success\u0027 =\u003e Translation::get(key: \u0027lostpwd_mail_okay\u0027)], Response::HTTP_OK);\n}\n\nreturn $this-\u003ejson([\u0027error\u0027 =\u003e Translation::get(key: \u0027lostpwd_err_1\u0027)], Response::HTTP_CONFLICT);\n```\n\nThe core issue is that the password is changed immediately after a simple username and email match. There is no reset token, no confirmation link, no second step, and no requirement that the caller prove control of the mailbox before the password is replaced.\n\nThat means the endpoint is not just a \"forgot password email sender\". It is an actual unauthenticated password change trigger.\n\n### PoC\n\nThis was reproduced against a local Docker deployment of the project.\n\nFor a valid username and email pair:\n\n```http\nPUT /api/index.php/user/password/update HTTP/1.1\nHost: 127.0.0.1\nContent-Type: application/json\n\n{\"username\":\"user1\",\"email\":\"user1@example.com\"}\n```\n\nResponse:\n\n```http\nHTTP/1.0 200 OK\nContent-Type: application/json\n\n{\"success\":\"Email has been sent.\"}\n```\n\nFor an invalid pair:\n\n```http\nPUT /api/index.php/user/password/update HTTP/1.1\nHost: 127.0.0.1\nContent-Type: application/json\n\n{\"username\":\"user1\",\"email\":\"wrong@example.com\"}\n```\n\nResponse:\n\n```http\nHTTP/1.0 409 Conflict\nContent-Type: application/json\n\n{\"error\":\"Error: Username and email address not found.\"}\n```\n\nThat already confirms enumeration.\n\nTo verify that the password really changes, created a test account:\n\n- username: `user2`\n- password: `Oldpass123!`\n- email: `user2@example.com`\n\nBefore calling the endpoint, the password hash stored in `faquserlogin` was:\n\n```text\n481bf096fd16e68ebbb8b98368bc0b5c17631a00f01a36dbb4a8dade0f0b8125\n```\n\nThen send:\n\n```http\nPUT /api/index.php/user/password/update HTTP/1.1\nHost: 127.0.0.1\nContent-Type: application/json\n\n{\"username\":\"user2\",\"email\":\"user2@example.com\"}\n```\n\nThe response was:\n\n```http\nHTTP/1.0 200 OK\nContent-Type: application/json\n\n{\"success\":\"Email has been sent.\"}\n```\n\nAfter that, the stored hash changed to:\n\n```text\n3497f20c251da705f673dcac500fbf9e2e2e495719a7e2df9be08db42bf1286f\n```\n\nThen try to log in with the old password:\n\n```http\nPOST /authenticate HTTP/1.1\nHost: 127.0.0.1\nContent-Type: application/x-www-form-urlencoded\n\nfaqusername=user2\u0026faqpassword=Oldpass123!\n```\n\nThe application redirected back to the login page and reported that the password was incorrect.\n\nSo this is not just a cosmetic issue in the API response. The old credential really becomes invalid.\n\n### Impact\n\nThe most realistic impact here is forced password reset and account disruption.\n\nAn attacker who knows or can guess a valid username and email pair can:\n\n- confirm whether the pair is valid\n- force the target account\u0027s password to change\n- cause the victim\u0027s old password to stop working immediately\n\nIf the attacker does not control the victim\u0027s mailbox, this is usually a denial-of-service style account disruption rather than instant account takeover. That is the main reason I would keep the severity at **Medium**.\n\nEven so, this is still a real security issue. Password recovery should not allow an unauthenticated caller to change the account password directly.\n\n### Remediation\n\nRecommend to change the password recovery flow to a token-based design.\n\n1. Do not change the password inside the unauthenticated endpoint.\n2. Generate a short-lived, single-use reset token and send only the reset link by email.\n3. Return the same generic response for both valid and invalid username/email pairs.\n4. Keep rate limiting in place, but do not rely on it as the main protection.\n5. Add regression tests that verify the password hash does not change until a valid reset token is presented.",
"id": "GHSA-9qv9-8xv6-5p35",
"modified": "2026-05-28T14:23:13Z",
"published": "2026-05-20T15:45:53Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/thorsten/phpMyFAQ/security/advisories/GHSA-9qv9-8xv6-5p35"
},
{
"type": "PACKAGE",
"url": "https://github.com/thorsten/phpMyFAQ"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "phpMyFAQ: Unauthenticated Password Reset Endpoint Allows User Enumeration and Forced Password Change Without Token Validation"
}
GHSA-9WVH-MC26-36XW
Vulnerability from github – Published: 2026-06-20 00:34 – Updated: 2026-06-20 00:34Cap-go before 12.128.2 contains an authentication logic flaw that lets an attacker register and control an account bound to a victim's email address before that email is verified. By enabling two-factor authentication on the pre-registered account, the attacker gains control over the account claimed under the victim's identity, allowing them to read and modify its state and enforce organization-level policies, while the legitimate user is denied access to the account tied to their own email.
{
"affected": [],
"aliases": [
"CVE-2026-56081"
],
"database_specific": {
"cwe_ids": [
"CWE-640"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-19T22:16:18Z",
"severity": "CRITICAL"
},
"details": "Cap-go before 12.128.2 contains an authentication logic flaw that lets an attacker register and control an account bound to a victim\u0027s email address before that email is verified. By enabling two-factor authentication on the pre-registered account, the attacker gains control over the account claimed under the victim\u0027s identity, allowing them to read and modify its state and enforce organization-level policies, while the legitimate user is denied access to the account tied to their own email.",
"id": "GHSA-9wvh-mc26-36xw",
"modified": "2026-06-20T00:34:09Z",
"published": "2026-06-20T00:34:09Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/Cap-go/capgo/security/advisories/GHSA-j4cx-5pw6-5v5j"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-56081"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/cap-go-account-lockout-via-2fa-misconfiguration-on-unverified-email"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/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",
"type": "CVSS_V4"
}
]
}
Mitigation
Make sure that all input supplied by the user to the password recovery mechanism is thoroughly filtered and validated.
Mitigation
Do not use standard weak security questions and use several security questions.
Mitigation
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.
Mitigation
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.
Mitigation
Never allow the user to control what e-mail address the new password will be sent to in the password recovery mechanism.
Mitigation
Assign a new temporary password rather than revealing the original password.
CAPEC-50: Password Recovery Exploitation
An attacker may take advantage of the application feature to help users recover their forgotten passwords in order to gain access into the system with the same privileges as the original user. Generally password recovery schemes tend to be weak and insecure.