CVE-2026-105863: Payload authentication token field handling issue

Payload lets you copy chosen user fields into the JWT with the saveToJWT field option, which can also rename the key. Before the fix, a field could use a reserved claim name and replace the value Payload itself had set. The fix's tests cover id, collection, email, sid, iat, exp and authVersion.

If a user can write to such a field, for example through a profile update, the next token they get at login can carry a forged id, email or collection. The result is a token that names another account. Whether that works depends on your field configuration and access rules, so the advisory marks it as conditional on a custom field option. It scores 9.2 under CVSS 4.0, with attack-requirements set because the configuration must exist.

A project with no saveToJWT mapping to a reserved name is not exposed through this path.

Affected: payload from 3.0.0 up to but not including 3.90.0, and 4.0.0-canary.0 up to but not including 4.0.0-canary.34. You are at risk if a field in an auth collection uses saveToJWT with a key that equals a reserved claim name. Search your collection configs for saveToJWT.

npm ls payload

Upgrade to payload 3.90.0, or 4.0.0-canary.34 on the v4 canary line, and move the other Payload packages to match.

npm install [email protected]

The fix in getFieldsToSign.ts drops collection, email, exp, iat, id and sid from field-derived values, then sets id, collection, email and sid from trusted data. It also writes authVersion: 1 into the token header. Tokens issued before the upgrade lack that marker, so users and integrations holding stored bearer tokens must sign in again. The advisory says there is no complete workaround.

Review your collection configs for saveToJWT fields whose names match reserved claims. Decode a few recent tokens (the payload is base64 JSON) and check that id, email and collection match the user who signed in. Look in auth logs for sessions whose user id differs from the account that logged in. The sources publish no other indicators.

Impact

Under certain field configurations, Payload could include unintended values in the authentication token issued at login.

You are affected if:

• You use an affected Payload version and have configured a custom field option that maps a field to a reserved authentication claim name.

Patches

Payload now restricts which field configuration options can influence the contents of the authentication token.

Users should upgrade payload packages to >= 3.90.0 or >= 4.0.0-canary.34.

Workarounds

There is no complete workaround. Users should upgrade payload packages to >= 3.90.0 or >= 4.0.0-canary.34.