Password-reset flaw enables unauthenticated user impersonation in Payload

TL;DR — A critical bug in Payload’s built-in password recovery flow can let unauthenticated attackers perform actions as a victim during password reset, driving account takeover risk in apps that expose forgot-password. (raw.githubusercontent.com)

What happened

Payload is an open-source, Node.js-based headless CMS used to power application backends and APIs.

CVE-2026-34751 describes a critical issue in the password recovery flow affecting payload and @payloadcms/graphql prior to 3.79.1, where an unauthenticated attacker may be able to perform actions on behalf of a user who initiates a password reset. (raw.githubusercontent.com)

GitHub’s advisory notes the exposure condition as deployments on Payload version < v3.79.1 with any auth-enabled collection using the built-in forgot-password functionality, and states the patch hardens input validation and URL construction in the recovery flow. (github.com)

Password reset / recovery endpoints are a perennial high-value target because they sit directly on the account lifecycle boundary; a single logic flaw here can bypass “good” auth everywhere else. For headless CMS stacks, this is especially high blast-radius because the CMS frequently holds admin access to content, webhooks, and downstream integrations.

Who is impacted

• Deployments running payload or @payloadcms/graphql versions < 3.79.1. (raw.githubusercontent.com)
• Highest risk when you use the built-in forgot-password flow on auth-enabled collections. (github.com)

What to do now

• Follow vendor remediation guidance and apply the latest patched release available at the time of writing.

  • "Users should upgrade to v3.79.1 or later." (github.com)

• Plan patching with the understanding that the vendor does not provide a safe “turn it off” alternative:

  • "There are no complete workarounds. Upgrading to v3.79.1 is recommended." (github.com)

• Inventory where forgot-password is exposed (public routes, API gateways, mobile clients) and treat those services as the priority patch set. (github.com)
• If you suspect abuse, review auth and password-reset related logs/telemetry for anomalous recovery attempts and unexpected privileged actions taken shortly after password reset initiation, then rotate credentials/tokens accessible to the impacted service.