CVE-2026-105860 is a High severity authorization flaw in the Payload multi tenant plugin. Before 3.90.0, the default tenant array field access lets an authenticated user assign their own account to other tenants. Upgrade to 3.90.0, or 4.0.0-canary.34 on canary, or secure the tenant field access functions.
What's affected
- Package: @payloadcms/plugin-multi-tenant (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: the default tenant array field access is in use. Deployments that replace it with secured arrayFieldAccess.create and arrayFieldAccess.update functions are not affected by this behavior.
- Workaround from the advisory: configure those two functions so only trusted users authorized for all tenants can modify memberships.
The record scores this 7.1 (CVSS 3.1 vector) and calls it High. The project's GitHub advisory gives a score of 7.1 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 whether you customised tenant field access.
grep -rn "multiTenantPlugin\|arrayFieldAccess" src/
If the plugin is configured without arrayFieldAccess, the defaults apply. Next, review your users collection for tenant memberships that do not match what you expect: users attached to tenants where they have no business.
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.
- Audit tenant memberships for every user and remove any you cannot explain.
- Set arrayFieldAccess.create and arrayFieldAccess.update so that only users authorized across all tenants can change memberships.
- Check activity logs for access to tenant data by users who should not have it.
- Notify affected tenants if you find real cross tenant access, following your incident process.
- 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. In a multi tenant system, tenant membership is the boundary that keeps one customer's data away from another's. Membership lives in a field on the user, and the default access rule for that field let an authenticated user write to it for themselves.
Whoever can add their own account to another tenant can read that tenant's content within the permissions of the tenant role. That crosses the most important wall in a multi tenant product, and the advisory's metrics show a high integrity impact.
The record does not list this CVE as exploited in the wild. It is a useful reminder that defaults matter: a secure product ships with a safe default, and a team using a plugin should check the default against its own threat model. The advisory shows the safe pattern, which is explicit functions that restrict who can change memberships. 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
Can I avoid the issue without upgrading?
The advisory says secured arrayFieldAccess.create and arrayFieldAccess.update functions mean you are not affected by this specific default behavior.
Who can exploit it?
An authenticated user. The record shows low privileges are enough.
Sources
Last reviewed: 18 October 2026.
