Safeguard
Vulnerability Analysis•

CVE-2026-105863: Critical Auth Token Flaw in Payload CMS

CVE-2026-105863 lets a Payload field mapped to a reserved auth claim name put unintended values in login tokens. Upgrade Payload to 3.90.0 or later.

Safeguard Security Team
3 min read

CVE-2026-105863 is a critical (CVSS 9.4) flaw in Payload CMS versions after 3.0.0 and before 3.90.0. A custom field option that maps a field to a reserved authentication claim name can put unintended values into the token issued at login. Upgrade to 3.90.0. There is no complete workaround.

What's affected

The record and the GitHub advisory list Payload after 3.0.0 and before 3.90.0 as affected. The advisory also lists canary builds of the 4.0 line before 4.0.0-canary.34, though the wording in its table is ambiguous, so read it for your build. The patched version is 3.90.0.

You are affected when you use an affected version and have configured a custom field option that maps a field to a reserved authentication claim name. The advisory says there is no complete workaround: upgrade.

How to check if you're exposed

Check the version and look for the field option:

npm ls payload

Then review your collection configs for auth-enabled collections with custom fields. Look for any option that controls how a field appears in the authentication token, and compare any claim names with the names that token already uses, such as the user identifier and the collection. Ask the people who wrote the config what each such option is for.

What to do now

  1. Upgrade Payload packages to 3.90.0 or later, or to 4.0.0-canary.34 or later on the canary line.
  2. Review fields in auth collections that influence the token, and remove any that map to reserved claim names.
  3. Sign out users and invalidate sessions after the upgrade, if your threat model calls for it.
  4. Review who can edit those fields. A value that can be changed by users should never reach a token.
  5. Add a test that checks the contents of an issued token against what you expect.

Why it matters

A login token is a promise the server makes to itself: the identity and roles inside it are trusted without another lookup. If any field value can end up inside the token under a claim name the system already uses, the issuer is vouching for data that came from elsewhere.

The record files this under CWE-290 (authentication bypass by spoofing) and CWE-915 (improperly controlled modification of dynamically determined object attributes). The advisory says Payload now restricts which field configuration options can influence the contents of the token.

The vector shows network access, no privileges and no user interaction, though the advisory says certain field configurations are needed. The record does not report exploitation in the wild, and the KEV flag is false.

Quick check

Is there a workaround?

The advisory says there is no complete workaround and tells you to upgrade to 3.90.0 or later.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.