Impact A vulnerability in field-level access control could allow an authenticated user to modify fields they are not permitted to change on documents they can otherwise update.

You are affected if: Payload version < 3.87.0 (or a 4.0.0-canary release before 4.0.0-canary.20) using the MongoDB adapter (@payloadcms/db-mongodb) with any collection that relies on field-level access control to restrict writes under certain conditions.

Relational adapters (Postgres, SQLite) are not affected.

Patches Handling of incoming field data has been hardened so field-level access control is enforced consistently.

Users should upgrade to 3.87.0 (or 4.0.0-canary.20 on the 4.x line) or later.

Workarounds There is no complete workaround. Upgrading to 3.87.0 (or 4.0.0-canary.20 on the 4.x line) is recommended.

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 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.

Impact

Under certain field configurations, Payload could include unintended values in the authentication token issued at login.

You are affected if:

- You use an affected Payload version and have configured a custom field option that maps a field to a reserved authentication claim name.

Patches Payload now restricts which field configuration options can influence the contents of the authentication token.

Users should upgrade payload packages to >= 3.90.0 or >= 4.0.0-canary.34.

Workarounds There is no complete workaround. Users should upgrade payload packages to >= 3.90.0 or >= 4.0.0-canary.34.

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.

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 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.

Impact

When an auth collection defined a field-level access.update restriction on the password field, the restriction was not enforced on the server correctly.

Patches

Users should upgrade Payload packages to >= 3.90.0 or >= 4.0.0-canary.34.

Impact A malformed multipart request body could take an extremely long time to finish.

Patches Users should upgrade Payload packages to >= 3.90.0 or >= 4.0.0-canary.34.

Impact

Token refresh and password reset responses could return fields that the requesting user did not have access to.

You are affected if:

- An authentication collection contains hidden or read-restricted fields.

Patches

Authentication responses now apply field access and hidden-field filtering before returning user documents. Full user documents remain available server-side for access control.

Users should upgrade Payload packages to >= 3.90.0 or >= 4.0.0-canary.34.

Custom authentication strategies remain responsible for filtering user documents returned through custom responses.

Workarounds

There is no complete workaround. 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 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.

Impact

Users with read access to other user documents could access their active API keys. An exposed key grants the target account’s permissions until rotated or disabled.

You are affected if:

- An authentication collection enables useAPIKey. - Users have read access to other user documents containing active API keys.

Patches

Users should upgrade payload packages to >= 3.90.0 or >= 4.0.0-canary.34.

Workarounds

Disable useAPIKey or restrict users to reading only their own authentication document. Rotate any API key that may have been exposed.

Impact

An authenticated user could perform unintended Stripe operations through the optional Stripe REST proxy.

You are affected if ALL of these are true:

- Your application uses @payloadcms/plugin-stripe. - The optional Stripe REST proxy is enabled. - An authenticated user can reach the proxy.

Deployments that do not enable the Stripe REST proxy are not affected.

Patches

Users should upgrade Payload packages to >= 3.90.0 or >= 4.0.0-canary.34.

Workarounds

Upgrading to a patched version is recommended.

If you cannot upgrade immediately, disable the Stripe REST proxy. If it must remain enabled, restrict access to trusted users and only the required Stripe operations.

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

The client-upload signed-URL endpoints for S3, GCS, Azure, and R2 did not properly sanitize filenames. An attacker could craft filenames to escape the intended storage location.

Consumers are affected if ALL of these are true:

- Payload version < v3.78.0 - Using client-upload signed-URL endpoints for any supported storage adapter

## Patches

This vulnerability has been patched in v3.78.0. Filename validation has been hardened for client uploads.

Consumers should upgrade to v3.78.0 or later.

Workarounds

Consumers can upgrade:

- Limit access to client-upload signed-URL endpoints to trusted users only.

Impact

A Cross-Site Request Forgery (CSRF) vulnerability existed in the authentication flow. Under certain conditions, the configured CSRF protection could be bypassed, allowing cross-site requests to be made.

Consumers are affected if ALL of these are true:

- Payload version < v3.79.1 - serverURL is configured

Patches

This vulnerability has been patched in v3.79.1. Additional validation has been added to the authentication flow.

Consumers should upgrade to v3.79.1 or later.

Workarounds

There is no complete workaround without upgrading.

If consumers cannot upgrade immediately, setting cookies.sameSite to 'Strict' will prevent the session cookie from being sent cross-site. However, this will also require users to re-authenticate when navigating to the application from external links (e.g. email, other sites).

Impact

A stored Cross-site Scripting (XSS) vulnerability existed in the admin panel. An authenticated user with write access to a collection could save content that, when viewed by another user, would execute in their browser.

Consumers are affected if ALL of these are true:

- Payload version < v3.78.0 - At least one collection with versions enabled - An authenticated user has create or update access to that collection

Patches

This vulnerability has been patched in v3.78.0. Output encoding has been added to prevent user-supplied content from being interpreted as markup.

Users should upgrade to v3.78.0 or later.

Workarounds

If consumers cannot upgrade immediately:

- Restrict create and update access to versioned collections to trusted roles only.

Impact

Certain request inputs were not properly validated. An attacker could craft requests that influence SQL query execution, potentially exposing or modifying data in collections.

Patches

This issue has been fixed in v3.79.1 and later. Query input validation has been hardened.

Upgrade to v3.79.1 or later.

Workarounds

Until developers can upgrade:

- Limit access to endpoints that accept dynamic query inputs to trusted users only. - Validate or sanitize input from untrusted clients before sending it to query endpoints.

Impact

An authenticated Server-Side Request Forgery (SSRF) vulnerability existed in the upload functionality.

Authenticated users with create or update access to an upload-enabled collection could cause the server to make outbound HTTP requests to arbitrary URLs.

Consumers are affected if ALL of these are true:

- Payload version < v3.79.1 - At least one collection with upload enabled - An authenticated user has create or update access to that collection

Patches

This vulnerability has been patched in v3.79.1. Users should upgrade to v3.79.1 or later.

Workarounds

Until consumers can upgrade:

- Restrict create and update access to upload-enabled collections to trusted roles only. - Limit outbound network access from your Payload server where possible.

Impact

A vulnerability in the password recovery flow could allow an unauthenticated attacker to perform actions on behalf of a user who initiates a password reset.

Users are affected if:

- They are using Payload version < v3.79.1 with any auth-enabled collection using the built-in forgot-password functionality.

Patches

Input validation and URL construction in the password recovery flow have been hardened.

Users should upgrade to v3.79.1 or later.

Workarounds

There are no complete workarounds. Upgrading to v3.79.1 is recommended.