CVE-2026-105849 is a High severity information disclosure in Payload, the headless CMS. From 3.0.0 before 3.90.0, a user with read access to other authentication documents in a collection with useAPIKey enabled can obtain their active API keys and use their permissions. Upgrade to 3.90.0, or 4.0.0-canary.34 on canary.
What's affected
- Package: payload (npm).
- Affected: 3.0.0 before 3.90.0, and 4.0.0-canary.0 before 4.0.0-canary.34.
- Fixed: 3.90.0 and 4.0.0-canary.34.
- Condition: an authentication collection has useAPIKey enabled and users can read other users' documents that hold active API keys.
- Workarounds from the advisory: disable useAPIKey, or restrict users to reading only their own authentication document, and rotate any key that may have been exposed.
The record scores this 8.3 (CVSS 3.1 vector) and calls it High. The project's GitHub advisory gives a score of 7.7 and a rating of High 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.
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 configuration for the condition.
grep -rn "useAPIKey" src/
If no collection enables API keys, the issue does not apply. If one does, review the read access rules on that collection: can a regular user read another user's document?
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.
- Rotate every API key in collections where useAPIKey is on and other users could read the documents, since a key already seen stays valid until rotated or disabled.
- Tighten read access so users only read their own authentication document, or turn off API keys where you do not use them.
- Check logs for API key use from unfamiliar addresses or at unusual times.
- 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-862, missing authorization, and CWE-201, insertion of sensitive information into sent data. The API key sat in the document that ordinary reads returned. Anyone allowed to read another account's document could therefore read its key.
An API key is a bearer credential. It does not need a password or a second factor, and the advisory says it grants the target account's permissions until it is rotated or disabled. If the target is an administrator or an integration account, the effect is a full takeover of what that account can do.
The fix changes how keys are handled in reads, and the commit title says it omits API keys from document reads. The record does not list this CVE as exploited in the wild. 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.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Do I need to rotate keys after upgrading?
Yes if there is any chance they were exposed. The advisory says an exposed key keeps granting the account's permissions until it is rotated or disabled.
Am I affected if I do not use API keys?
The condition requires an authentication collection with useAPIKey enabled. Without it, this issue does not apply, though upgrading is still advised.
Sources
Last reviewed: 18 October 2026.
