CVE-2026-105855 is a High severity access control flaw in Payload, the headless CMS. Before 3.90.0, the server does not correctly enforce a field level access.update restriction on the password field of an authentication collection. 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 collection that defines a field level access.update restriction on its password field.
- Workarounds: the advisory lists none.
The record scores this 7.1 (CVSS 3.1 vector) and calls it High. The project's GitHub advisory gives a score of 7.6 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 search your auth collections for password field access rules.
grep -rn "name: 'password'" src/
grep -rn "access" src/collections/Users.ts
If you never set an access.update rule on the password field, the specific condition in the advisory does not apply. If you did, for example to stop users changing their own or each other's passwords, that rule was not reliably enforced on the server in affected versions.
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.
- Find every auth collection with an access.update rule on the password field.
- Check for password changes you did not expect, especially on accounts with elevated roles.
- Force a password reset for sensitive accounts if you see anything unexplained.
- Do not rely on a single field rule for password changes. Combine it with collection level update rules.
- 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-284, improper access control. Developers use field level rules to say who may change a value. Here, the rule on the password field was defined but not enforced the way the developer meant, so a caller the rule should have stopped might still be able to update it.
The impact of a password change is account takeover. An attacker who can set another account's password can sign in as that user. The advisory's metrics give high confidentiality and integrity impact on the vulnerable system, and a low privilege level is enough.
The record does not list this CVE as exploited in the wild. The lesson is the usual one about authorization: a rule that is not enforced on the server is worth nothing. 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
Why is the password field special?
A change to it can lead straight to taking over an account, so a missed access rule there has a large effect.
Is there a workaround?
The advisory lists none and says to upgrade to a patched version.
Sources
Last reviewed: 18 October 2026.