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.
UK fashion retailer ASOS confirmed a data breach after unauthorized push notifications were sent through its mobile app. The attackers claimed to have stolen customer data from ASOS's Snowflake environment. Details about the breach's scope, exploited vulnerabilities, or remediation status have not been disclosed.
## 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.
CVE-2026-106218 is a high-severity vulnerability in JetBrains TeamCity before version 2026.1.3. It involves a Kotlin DSL sandbox escape that could lead to remote code execution (RCE) on the server. The vulnerability is identified as CWE-184, which relates to improper access control. No official patch links are provided in the data, and no known exploits are reported in the wild.
## 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.
The SPIP Crayons plugin before version 3.5.0 has a critical missing authorization vulnerability. This flaw allows unauthenticated attackers to modify editable object fields by bypassing an anti-forgery parameter check. Exploitation can lead to writing malicious files, disclosing sensitive configuration data, and ultimately executing arbitrary PHP code as the web server user.