Payload CMS 3.90: corecțiile au fost publicate în septembrie, alertele scanerelor sosesc abia acum. Ce ar trebui să verifice MSP-urile care rulează pluginul Multi-Tenant

Payload CMS 3.90: the fixes shipped in September, the scanner alerts arrive now. What MSPs running the Multi-Tenant plugin should check

If your dependency scanner lit up about Payload this week, the fix is not new. Payload, the open-source headless CMS that many agencies and MSPs deploy for client websites, published a batch of security advisories on 18 September 2026 together with version 3.90.0, which fixes them. CVE records and GitHub's reviewed advisory database entries followed on 6–7 October, and that is what Dependabot and similar tools read, so the alerts are landing about three weeks after the patch. The batch is large: by our count from GitHub's API, 22 advisories dated 18 September in Payload's repository, four rated critical, fourteen high and four medium.

For MSPs, the one to read first is in the Multi-Tenant plugin, the add-on that lets one Payload install serve several clients: with the plugin's default settings, an authenticated user could assign themselves to other tenants. Others cover the Form Builder plugin, collections that use the orderable option, login token handling and fresh installs that never got a first admin user. None of these appears in CISA's Known Exploited Vulnerabilities catalog, and none of the advisories we read reports exploitation. Our thesis: patching is the easy half. If you ran an affected version with these features for months, you also need to check who belongs to which tenant today. Below: what changed, what applies to you, how to confirm your version, and a post-upgrade review. Sources: Payload's advisories and npm data via GitHub's and npm's APIs, and the CISA catalog, all read on 9 October 2026.

The advisories that matter most for MSPs

Read these as "affected if" statements; each depends on a feature you may or may not use. Multi-Tenant plugin, tenant membership (GHSA-p96c-xwx8-3cqj, CVE-2026-105860, high, CVSS 4 score 7.1). Payload's advisory says that with the plugin's default tenant array field access, "an authenticated user could assign themselves to other tenants". You are not affected by this default behaviour if you had already configured the membership field's create and update access yourself. A companion advisory (GHSA-xhm9-gwgw-3q2q, CVE-2026-105864, medium) says a user limited to one tenant could create a record in another tenant, though reads and direct edits of existing documents there were not bypassed.

Orderable collections (GHSA-f7hx-52q9-hcrf, CVE-2026-105859, critical, CVSS 3 score 9.8). If any collection or join field uses orderable: true, documents could be updated regardless of access control. Form Builder plugin (GHSA-r488-j9vj-wx3q, CVE-2026-105857, critical, CVSS 3 score 10.0). If you use the plugin, crafted submissions could run code on the server. Login token (GHSA-66wr-7vmr-p5jq, CVE-2026-105863, critical, CVSS 4 score 9.2). Affects setups where a custom field option maps a field to a reserved authentication claim name; Payload says there is no complete workaround. First admin user (GHSA-97rh-rhh2-7vjv, CVE-2026-105858, high, CVSS 3 score 8.1). Affects apps using local authentication that still have no initial user, a state that new or forgotten staging installs can sit in for weeks.

All of the above is fixed in 3.90.0 and, on the 4.0 canary line, from 4.0.0-canary.34. The rest of the 18 September batch covers, among other things, field-access checks on auth collections, API key exposure through ordinary document reads, upload handling, SVG sanitisation, SQL injection in the SQLite and Postgres adapters, and the Stripe and Ecommerce plugins, all fixed in 3.90.0 or, for some adapters, earlier releases. We are not reproducing any technical detail beyond what you need to decide whether you are affected.

Why the alerts arrive three weeks late, and the later batches

The timing explains the noise. Payload published its advisories in its own GitHub repository on 18 September, the same afternoon 3.90.0 reached npm. Scanners such as Dependabot mostly work from GitHub's reviewed advisory database and from CVE records, and for these items those appeared on 6 and 7 October. If your team patched in September, the alert is a confirmation; if not, it is a three-week-old gap.

More advisories followed the fix. Between 22 and 29 September Payload published seven more, fixed in 3.88.0 to 3.90.0. On 6 October it published three high-severity ones: two in the MCP plugin (one about login responses including fields that are normally hidden, one about password recovery giving an authenticated MCP user access to another account), both relevant only if those MCP tools are switched on, and one about Payload Jobs, relevant if Jobs are enabled and untrusted users can reach the Jobs collection. Their fixes are in 3.88.0, 3.90.0 and 3.89.0 respectively. On 8 October a further seven followed, one high and six medium, also fixed at or below 3.90.0. So one rule covers every batch: be on 3.90.0 or later. As of 9 October the latest 3.x release on npm is 3.90.2. None of these appears in CISA's catalog as of its 8 October update.

Why the multi-tenant item deserves the first look, even though it is rated high rather than critical: in a shared install, the tenant list on a user record is the boundary between clients. Payload's advisory describes a default under which that list could be changed by the user it belongs to. For an agency hosting several customers on one Payload app, that turns a routine editor account at one client into a possible way into another client's content, without any server compromise, just a membership change that looks like ordinary data. That is also why upgrading alone does not close the question. The new version stops the change from happening again; it cannot tell you whether it already happened. Only your own data and logs can. Run this in each project to see what is installed, then upgrade every payload and @payloadcms/* package together.

# Which Payload packages and versions are actually installed? (read-only)
npm ls payload @payloadcms/plugin-multi-tenant @payloadcms/plugin-form-builder @payloadcms/plugin-mcp
# pnpm:  pnpm why payload
# yarn:  yarn why payload

# Upgrade all Payload packages together (same version across @payloadcms/*)
npm install payload@^3.90.0 @payloadcms/next@^3.90.0
# ...repeat for every @payloadcms/* package in package.json, then commit the lockfile

After the upgrade: a review list for multi-tenant installs

Our defender checklist; vendor workarounds are marked as such.

1. Upgrade first, everywhere. Production, staging, preview and forgotten demo instances. A lockfile pinned below 3.90.0 keeps old code even if package.json looks right.
2. Audit tenant memberships. Export every user's tenant list and compare it with who should have access, client by client. Look for users who belong to more tenants than their role explains, and for membership changes made by non-admins. Your database's update timestamps and any audit logging you run are the evidence; Payload's advisory gives no detection method, so do not promise clients one.
3. Lock the membership field. Even on 3.90.0, set explicit create and update access on the tenants field so only trusted, all-tenant administrators can change it. That is also the vendor's workaround if an install cannot be upgraded today.
4. Look for cross-tenant records. Because one advisory allowed creating records in another tenant, spot-check recent documents in tenant-enabled collections for entries created by users from a different client.
5. Form Builder. If installed, confirm 3.90.0, review who can submit and who can read submissions, and decide whether public forms need it at all.
6. Orderable collections. List every collection or join field with orderable: true, then review recent edits there for changes by users who should not have write access.
7. First user. Make sure every Payload app using local authentication has its initial admin account; do not leave fresh installs reachable from the internet without one.
8. MCP and Jobs. If the MCP plugin's authentication tools or Payload Jobs are enabled, confirm who can reach them, and turn off what you do not use.
9. Rotate keys if in doubt. One 18 September advisory concerns API key disclosure through ordinary document reads; rotating API keys after the upgrade is a cheap precaution (our suggestion, not a vendor instruction).
10. Tell clients plainly: fixed since 18 September, alerts since 6–7 October, no exploitation reported, upgrade and membership review done on a named date.

To sum up: Payload published a batch of advisories and 3.90.0 on 18 September 2026; CVE records and GitHub-reviewed database entries for the headline items followed on 6–7 October, which is why scanners are flagging them now. By our count, the 18 September batch holds 22 advisories in Payload's repository (four critical, fourteen high, four medium). The MSP headline is the Multi-Tenant plugin: with default membership-field access, an authenticated user could assign themselves to other tenants (high), and a related issue allowed creating records in another tenant (medium). Critical items cover the Form Builder plugin, collections using orderable: true and login token handling; a high-severity item affects installs with no first admin user. Later advisories, including the batches of 6 and 8 October, are fixed at or below 3.90.0. Not in the CISA KEV catalog; no advisory we read reports exploitation. Action: upgrade all Payload packages to 3.90.0 or later (3.90.2 is current), then audit tenant memberships and review Form Builder and orderable-collection access.