Threat Intelligence Database

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

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