Impact Under certain local upload configurations, an uploaded XML file and stylesheet could execute JavaScript in the Payload origin when a logged-in user opens the file.
You are affected if: - You accept XML uploads (accepted by default).
Patches Users should upgrade Payload packages to >= 3.90.0 or >= 4.0.0-canary.34.
Workarounds Disallow XML/XSL uploads.
Impact Under certain conditions, an authenticated user with permission to modify uploads could cause unintended files to be removed during file cleanup. This may result in data loss or service disruption.
You are affected if: - You use Payload upload collections with local file storage. - Untrusted authenticated users can update or delete uploads.
Deployments that restrict upload management to trusted users are less exposed.
Patches Payload now validates uploaded filenames and ensures file cleanup remains within the configured upload directory.
Users should upgrade Payload packages to >= 3.90.0 or >= 4.0.0-canary.34.
Workarounds Restrict upload update and deletion operations to trusted users and validate submitted filenames. These measures are temporary mitigations. Upgrading to a patched version is recommended.
Impact
A malicious SVG file upload could bypass sanitization, be stored, and execute attacker-controlled JavaScript (XSS) after a user downloads it and opens it.
You are affected if:
- You have a collection configured to upload and allow SVG files which can then be downloaded by users.
Patches
The fix validates SVG content on every upload path and hardens SVG/XML delivery so stored SVGs cannot frame attacker content.
Users should upgrade Payload packages to >= 3.90.0 or >= 4.0.0-canary.34.
Workarounds
Disallow SVG uploads, or serve uploaded SVGs as downloads with Content-Disposition: attachment and a strict CSP. These mitigations reduce exposure but do not replace upgrading when the patched release is available.
Impact A crafted request to the public first-register operation can be used to perform a RCE exploit.
You are affected if:
- You use local auth strategy and your application remains without an initial user created
Patches
In the patched version data submission to create first user is properly sanitized.
Users should upgrade Payload packages to >= 3.90.0 or >= 4.0.0-canary.34.
Impact
A readable collection could expose information about protected documents in a related collection.
You are affected if:
- You expose a readable collection with a relationship to a collection protected by access.read where constraints.
Patches
Users should upgrade Payload packages to >= 3.90.0 or >= 4.0.0-canary.34.
Workarounds
There is no complete workaround. Upgrade Payload packages >= 3.90.0 or >= 4.0.0-canary.34.
Impact
Payload's duplicate operation copies field values from the source document even when a field is hidden, or its access.read or access.create rule would reject the value for that caller.
The disableDuplicate collection setting, enabled by default on auth collections, did not stop this.
Patches
Users should upgrade Payload packages to >= 3.90.0 or >= 4.0.0-canary.34.
Workarounds
Add a beforeDuplicate field hook to fields and set the value to empty or your default value.
Impact
A user with query access could use polymorphic join filters to infer hidden or read-restricted field values, including password-reset tokens.
You are affected if:
- You use an affected Payload version. - Users can query a collection with a polymorphic join to sensitive fields.
Patches
Users should upgrade Payload packages to >= 3.90.0 or >= 4.0.0-canary.34.
Workarounds
There is no complete workaround. Restricting read access to sensitive collections reduces exposure but does not replace upgrading.
Impact Under certain conditions, an attacker can craft a redirect link that sends a guest user to an untrusted destination after authenticating.
Patches Users should upgrade Payload packages to >= 3.88.0 or >= 4.0.0-canary.27.
Workarounds Upgrading is recommended. Until then, remove user-controlled redirect values from authentication flows or restrict them to known local paths.
Impact A user can submit a request that exploits a SQL Injection vulnerability in Payload.
You are affected if: - You use an affected Payload version. - Untrusted users can query readable collections using dynamic filters or joins.
You are not affected if you use MongoDB (@payloadcms/mongodb).
Patches Users should upgrade Payload packages to >= 3.88.0 or >= 4.0.0-canary.27.
Workarounds Upgrading to a patched version is recommended. Until you can upgrade, restrict untrusted users from supplying dynamic query filters or join parameters and limit read access to affected collections.