CVE-2026-105868 is a High severity stored script execution flaw in Payload, the headless CMS. Before 3.90.0, local upload configurations that accept XML files can store an XML file and stylesheet that run JavaScript in the Payload origin when a logged in user opens the file. 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: a local upload configuration that accepts XML files. The advisory says XML uploads are accepted by default.
- Workaround from the advisory: disallow XML and XSL uploads.
The record scores this 7.1 (CVSS 3.1 vector) and calls it High. The project's GitHub advisory gives a score of 8.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 check which file types your upload collections accept.
grep -rn "mimeTypes\|upload:" src/collections/
If an upload collection sets no mimeTypes restriction, the advisory says XML is accepted by default. Next, look in your media storage for XML or XSL files that you did not expect, and check who has permission to upload and who opens uploaded files.
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.
- Restrict upload collections to the file types you need with an explicit mimeTypes list, and leave out XML and XSL.
- Review existing uploads for XML and XSL files and remove those you do not recognise.
- Serve uploaded files from a separate domain without cookies, so a file cannot act inside the admin origin.
- Set a Content Security Policy for the admin and for the upload domain.
- 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-434, unrestricted upload of a file with a dangerous type. XML is not a harmless data format when a browser opens it. An XML file can point at a stylesheet, and stylesheets can contain script. When such a file is served from the same origin as the admin panel, the script runs with the signed in user's session.
That is why the advisory says it executes in the Payload origin when a logged in user opens the file. An editor who clicks a link to an uploaded file can hand their session to the script. If the editor is an administrator, the attacker gains administrator rights. The passive user interaction in the advisory's metrics reflects that someone has to open the file.
The record does not list this CVE as exploited in the wild. Serving user uploads from a separate origin is a general defence that makes this class of bug much less damaging. 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
Is XML accepted by default?
The advisory says you are affected if you accept XML uploads, which are accepted by default.
Why does the origin matter?
Script in a file served from the admin origin runs with the signed in user's session. A separate cookie free domain for uploads prevents that.
Sources
Last reviewed: 18 October 2026.
