Payload is a free and open source headless content management system. In @payloadcms/db-mongodb versions before 3.87.0 and canary versions before 4.0.0-canary.20, an authenticated user who can update a document can modify fields that field-level write access control does not permit that user to change. The Postgres and SQLite adapters are not affected. This issue is fixed in versions 3.87.0 and 4.0.0-canary.20.
Payload CMS versions before 3.90.0 and canary versions before 4.0.0-canary.34 have a vulnerability allowing local upload configurations that accept XML files to store XML files and stylesheets that execute JavaScript in the Payload origin when opened by a logged-in user. This issue is fixed in versions 3.90.0 and 4.0.0-canary.34.
### Impact
An authenticated user could overwrite an existing S3 object belonging to another upload collection, bypassing that collection’s access controls and prior file validation.
You are affected if ALL of these are true:
- Client uploads are enabled for multiple collections that share an S3 bucket.
- useCompositePrefixes is not configured or is set to `false`.
### Patches
Users should upgrade Payload packages to `>= 3.90.0` or `>= 4.0.0-canary.34`.
### Workarounds
Disable client uploads until you can upgrade.
### **Impact**
An unauthenticated attacker who knows an account’s email address or username could trigger Payload’s account lockout mechanism and prevent that user from signing in.
You are affected if:
* Using an affected Payload version with an auth-enabled collection that uses local authentication and account lockout.
Applications that do not use Payload local authentication are not affected.
### **Patches**
Successful password resets now clear the account’s lockout state. The forgot-password flow also enforces a configurable minimum interval between reset emails, which defaults to 15 seconds.
Users should upgrade Payload packages to `>= 3.90.0` or `>= 4.0.0-canary.34`.
## 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
An authenticated user limited to one tenant could create a record in another tenant. This requires the multi-tenant plugin with at least one tenant-enabled collection.
Reads and direct edits to an existing target-tenant document were not bypassed.
You are affected if:
- You are using @payloadcms/plugin-multi-tenant
### Patches
Users should upgrade Payload packages to `>= 3.90.0` or `>= 4.0.0-canary.34`.
### Workarounds
You can add access control with `accessResultOverride` on the multi-tenant collection config to ensure a user has access to the tenant before creating.
PayloadCMS versions from 3.0.0 up to but not including 3.90.0, and certain 4.0.0-canary versions, contain an authentication bypass vulnerability. This occurs when a custom field is mapped to a reserved authentication claim name, allowing unintended values to be placed in authentication tokens at login. The issue is fixed in version 3.90.0.
## 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
Under certain external upload configurations, Payload could send authentication data to a destination that was not verified as trusted. If the affected request contained a valid session, this could expose that session to an unintended recipient.
**You are affected if:**
- You have enabled external URL-based upload retrieval, where authenticated requests can trigger it.
## Patches
Payload now validates the destination before forwarding authentication data and reapplies that validation when a request changes destination.
Users should upgrade Payload packages to `>= 3.90.0` or `>= 4.0.0-canary.34`.
## Workarounds
It is recommended to update all Payload packages to `>= 3.90.0` or `>= 4.0.0-canary.34`.
If you cannot, a valid workaround exists:
- Disable external URL-based upload retrieval where practical.
- If you cannot disable it, configure the upload header filter to remove authentication data from outbound file requests.
- Restrict access to the affected upload functionality.
## Impact
When using the default tenant array field access, an authenticated user could assign themselves to other tenants.
**You are affected if:**
- You are using `@payloadcms/plugin-multi-tenant`
If you configure the tenants arrayFieldAccess.create/update functions, a secured replacement membership field, you are not affected by this specific default behavior.
## Patches
Users should upgrade Payload packages to `>= 3.90.0` or `>= 4.0.0-canary.34`.
## Workarounds
Configure tenants arrayFieldAccess.create and tenants arrayFieldAccess.update so only trusted users authorized for all tenants can modify memberships.
## Impact
An attacker can submit a request to a specific endpoint that permits collection documents to be updated regardless of access control and field level access control.
**You are affected if:**
- You are configuring `orderable: true` with any collection or join field.
## Patches
In the patched version access control is properly enforced.
Users should upgrade Payload packages to `>= 3.90.0` or `>= 4.0.0-canary.34`.
PayloadCMS versions prior to 3.90.0 and canary versions before 4.0.0-canary.34 contain a code injection vulnerability in the public first-register operation. This flaw allows remote code execution when local authentication is enabled and no initial user has been created. The vulnerability is addressed in versions 3.90.0 and 4.0.0-canary.34.
## Impact
A vulnerability in `@payloadcms/plugin-form-builder` in versions < 3.90.0 allow submissions which could be crafted to execute remote code on the server.
**You are affected if:**
- You are using `@payloadcms/plugin-form-builder`
## Patches
Users should upgrade Payload packages to `>= 3.90.0` or `>= 4.0.0-canary.34`.
### Impact
An attacker who has read plus create or update access to a collection can submit a request that includes a SQL injection targeting a specific field path shape and operators in Payload's SQLite and Postgres.
#### You are affected if:
- You use `@payloadcms/db-sqlite` or `@payloadcms/db-d1-sqlite`.
- You use `@payloadcms/db-postgres` or `@payloadcms/db-vercel-postgres` `< 3.73.0`.
- A readable collection has a `json` field, or a` blocks` field with `blocksAsJSON: true`.
- The attacker has read plus create or update access on it.
#### You are not affected if:
- You have no `json or `blocksAsJSON` fields. `richText` is not affected.
- You run a patched version.
### Patches
The patched version sanitizes the query input to prevent injection.
Users should upgrade Payload packages to `>= 3.90.0` or `>= 4.0.0-canary.34`.
Payload is a free and open source headless content management system. In versions before 3.90.0 and canary versions before 4.0.0-canary.34, the server fails to enforce a field-level access.update restriction on the password field of an authentication collection. This issue is fixed in versions 3.90.0 and 4.0.0-canary.34.
Payload is a free and open source headless content management system. In versions from 3.0.0 before 3.90.0 and canary versions before 4.0.0-canary.34, a malformed multipart request body can cause multipart Content-Type processing to take an extremely long time, resulting in uncontrolled resource consumption. This issue is fixed in versions 3.90.0 and 4.0.0-canary.34.
PayloadCMS versions from 3.0.0 up to but not including 3.90.0, and canary versions from 4.0.0-canary.0 up to but not including 4.0.0-canary.34, contain a vulnerability where token refresh and password reset responses may expose hidden or read-restricted fields to unauthorized users. This exposure allows sensitive information leakage. The issue is resolved in versions 3.90.0 and 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`.
Payload is a free and open source headless content management system. In versions from 3.0.0 before 3.90.0 and canary versions before 4.0.0-canary.34, the duplicate operation copies values from a source document even when a field is hidden or its access.read or access.create rule rejects that value for the caller. The disableDuplicate setting does not prevent this access-control bypass. This issue is fixed in versions 3.90.0 and 4.0.0-canary.34.
## Impact
When using the Stripe payment adapter, an order confirmation could be processed more than once under certain conditions.
You are affected if:
- You use `@payloadcms/plugin-ecommerce` with the Stripe payment adapter.
Deployments that do not use the Stripe payment flow are not affected.
## Patches
Users should upgrade Payload packages to `>= 3.90.0` or `>= 4.0.0-canary.34`.
## Workarounds
Ensure Stripe order confirmations can only be processed once. This is a temporary mitigation; upgrading to a patched version is recommended.