GHSA-hp5w-3hxx-vmwf CVE-2026-34751
Payload: Pre-Authentication Account Takeover via Parameter Injection in Password Recovery
- Severity
- 9.1 / 10
- Critical · CVSS 3.1
- Exploit chance (EPSS)
- 0.31%
- Chance of exploitation in the next 30 days. Higher than 24.02% of scored vulnerabilities.
- Known exploited
- No
- Not in CISA's catalog
- Weakness
- CWE-472 External Control of Assumed-Immutable Web Parameter
- CWE-640 Weak Password Recovery Mechanism for Forgotten Password
- Fix
- Available
- 2 packages have a fixed version
Description
Impact
A vulnerability in the password recovery flow could allow an unauthenticated attacker to perform actions on behalf of a user who initiates a password reset.
Users are affected if:
- They are using Payload version < v3.79.1 with any auth-enabled collection using the built-in
forgot-passwordfunctionality.
Patches
Input validation and URL construction in the password recovery flow have been hardened.
Users should upgrade to v3.79.1 or later.
Workarounds
There are no complete workarounds. Upgrading to v3.79.1 is recommended.
Affected versions
npm
| Package | Vulnerable | Fixed in |
|---|---|---|
| @payloadcms/graphql | < 3.79.1 |
3.79.1 |
| payload | < 3.79.1 |
3.79.1 |
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.
@payloadcms/graphql npm → 3.79.1
- npm
npm install @payloadcms/graphql@3.79.1- yarn
yarn add @payloadcms/graphql@3.79.1- pnpm
pnpm add @payloadcms/graphql@3.79.1
payload npm → 3.79.1
- npm
npm install payload@3.79.1- yarn
yarn add payload@3.79.1- pnpm
pnpm add payload@3.79.1
Severity breakdown
CVSS 3.1 9.1
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
- Attack vector
- Network
- Attack complexity
- Low
- Privileges required
- None
- User interaction
- None
- Scope
- Unchanged
- Confidentiality
- High
- Integrity
- High
- Availability
- None
Weakness
CWE-472: External Control of Assumed-Immutable Web Parameter
The web application does not sufficiently verify inputs that are assumed to be immutable but are actually externally controllable, such as hidden form fields.
How to prevent it
- Implementation: Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
- Implementation: Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.
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
Advisories
Packages
Other links
Timeline
- Published
- Last updated by the source
- Latest EPSS score
Related advisories
| Advisory | Severity | Why it's related |
|---|---|---|
| GHSA-9qpg-3cf8-w33x Payload: Uploaded XML files could execute same-origin JavaScript | High | Also affects payload |
| GHSA-v5gf-vpjc-pc7w Payload: Unauthenticated account-lockout denial of service | High | Also affects payload |
| GHSA-p223-2wr2-j562 Payload: Incomplete validation during the upload file lifecycle | High | Also affects payload |
| GHSA-66wr-7vmr-p5jq Payload authentication token field handling issue | Critical | Also affects payload |
| GHSA-2pwp-2369-8fg3 Payload: Bypassed sanitization of user uploaded SVGs | High | Also affects payload |
| GHSA-pj5h-5q6c-3pfx Payload external upload trust validation issue | High | Also affects payload |
| GHSA-f7hx-52q9-hcrf Payload: Unauthorized update to collection documents | Critical | Also affects payload |
| GHSA-97rh-rhh2-7vjv Payload: Remote Code Execution through first-register | High | Also affects payload |
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