CVE-2026-105866 is a High severity denial of service in Payload, the headless CMS. Before 3.90.0, an unauthenticated attacker who knows an account email or username can abuse the lockout mechanism of a local authentication collection and stop that account from signing in. Upgrade to 3.90.0, or 4.0.0-canary.34 on canary.
What's affected
- Package: payload (npm).
- Affected: before 3.90.0, and canary versions before 4.0.0-canary.34.
- Fixed: 3.90.0 and 4.0.0-canary.34.
- Condition: an auth enabled collection that uses local authentication with account lockout. Applications that do not use Payload local authentication are not affected.
- What the fix does: successful password resets clear the lockout state, and the forgot password flow enforces a configurable minimum interval between reset emails, 15 seconds by default.
The record scores this 7.5 (CVSS 3.1 vector) and calls it High. The project's GitHub advisory gives a score of 6.9 and a rating of Moderate under CVSS v4. Both are listed here because different scoring systems rate the same flaw differently. Judge urgency by whether the described configuration matches yours. The title follows the record.
How to check if you're exposed
Payload is an npm package, so read the installed version in each project and environment.
npm ls payload
pnpm why payload
grep -n "payload" package.json
Check every deployment target too: production, staging, preview builds and any container image built from an older commit. Then look at the packages next to Payload, because this release series also touches plugins and database adapters:
npm ls @payloadcms/plugin-ecommerce @payloadcms/plugin-multi-tenant
npm ls @payloadcms/db-postgres @payloadcms/db-sqlite @payloadcms/db-vercel-postgres @payloadcms/db-d1-sqlite
Then check your lockout settings.
grep -rn "maxLoginAttempts\|lockTime" src/
If the auth collection sets maxLoginAttempts, lockout is on. Review login failure logs for bursts against a single account, and look at support tickets about users who could not sign in for no clear reason. Administrators and shared accounts are the most valuable targets.
Safeguard's free in-browser dependency scan at gold.safeguard.sh/scan reads a manifest or lockfile and shows which packages carry known CVEs, including this one. Nothing is installed and nothing leaves your browser session beyond the scan itself.
What to do now
- Upgrade all Payload packages together to 3.90.0 or later on the 3.x line, or to 4.0.0-canary.34 or later on the canary line, and keep versions in step across packages.
- Upgrade, and review the new forgot password interval setting, which defaults to 15 seconds.
- Make sure you have a break glass administrator account whose name is not public.
- Add rate limiting by IP address at your proxy for login and password reset routes.
- Alert on repeated lockouts of the same account.
- Read the v3.90.0 release notes for behavior and API changes that may need code updates, and run your test suite before deploying.
- Redeploy every environment, including preview and staging, and rebuild container images.
- Re-scan your lockfile after the change to confirm no older copy of the package remains.
Why it matters
The record lists CWE-307, improper restriction of excessive authentication attempts, and CWE-645, overly restrictive account lockout mechanism. Lockout exists to slow password guessing, and it works by blocking the account after several failures. The side effect is well known: if anyone can trigger the lockout, anyone can deny the real owner access.
The attacker needs only an email address or username, which are often easy to find. The advisory's metrics show a low availability impact, because it is one account at a time, but for an administrator account or a small team the effect can be large.
The fix lets password resets clear the lockout and limits reset email frequency. The record does not list this CVE as exploited in the wild. Lockout policy is a balance, and rate limits by address as well as by account help both sides. Payload's release notes for v3.90.0 describe a set of critical security fixes and recommend upgrading even if none of the listed items affect you. They also say exploit details and severity are intentionally left out of the notes, so read each advisory for the conditions.
Quick check
Does this let an attacker log in?
No. The advisory describes preventing a user from signing in, not bypassing authentication.
What changed in the fix?
Successful password resets now clear lockout state, and reset emails have a configurable minimum interval, 15 seconds by default.
Sources
Last reviewed: 18 October 2026.
