See how payloadcms compares to other vendors in security performance
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.
Impact
A Server-Side Request Forgery (SSRF) vulnerability exists in Payload's external file upload functionality. When processing external URLs for file uploads, insufficient validation of HTTP redirects could allow an authenticated attacker to access internal network resources.
Users are affected if ALL of these are true:
- Payload version < v3.75.0 - At least one collection with upload enabled - A user has create access to that upload-enabled collection
An authenticated user with upload collection write permissions could potentially access internal services. Response content from internal services could be retrieved through the application.
Patches
This vulnerability has been patched in v3.75.0. Users should upgrade to v3.75.0 or later.
Workarounds
If users cannot upgrade immediately, they can mitigate this vulnerability by disabling external file uploads via the disableExternalFile upload collection option, or by restricting create access on upload-enabled collections to trusted users only.
Impact
A cross-collection Insecure Direct Object Reference (IDOR) vulnerability exists in the payload-preferences internal collection. In multi-auth collection environments using Postgres or SQLite with default serial/auto-increment IDs, authenticated users from one auth collection can read and delete preferences belonging to users in different auth collections when their numeric IDs collide.
Users are affected if ALL of these are true:
- Multiple auth collections configured (e.g., admins + customers) - Postgres or SQLite database adapter with serial/auto-increment IDs - Users in different auth collections with the same numeric ID
Not affected:
- @payloadcms/db-mongodb adapter - Single auth collection environments - Postgres/SQLite with idType: 'uuid'
Patches
This vulnerability has been patched in v3.74.0. Users should upgrade to v3.74.0 or later.
Workarounds
There is no workaround other than upgrading. Users with multiple auth collections using Postgres or SQLite with serial IDs should upgrade immediately.
Impact
When querying JSON or richText fields, user input was directly embedded into SQL without escaping, enabling blind SQL Injection attacks. An unauthenticated attacker could extract sensitive data (emails, password reset tokens) and achieve full account takeover without password cracking.
Users are affected if ALL of these are true:
1. Payload version < v3.73.0 2. Using a Drizzle-based database adapter (@payloadcms/drizzle as dependency): - @payloadcms/db-postgres - @payloadcms/db-vercel-postgres - @payloadcms/db-sqlite - @payloadcms/db-d1-sqlite 3. At least one accessible collection that has a type: 'json' or type: 'richText' field where access.read returns anything other than false (true or Where constraint)
Users are NOT affected if:
- Using @payloadcms/db-mongodb - No JSON or richText fields exist in any collection - All JSON/richText fields have access: { read: () => false }
Patches
Upgrade to Payload v3.73.0 or later.
Workarounds
If a project cannot upgrade immediately, add access: { read: () => false } to all JSON and richText fields as a temporary mitigation.
Payload is a free and open source headless content management system. In versions prior to 1.7.0, if a user has access to documents that contain hidden fields or fields they do not have access to, the user could reverse-engineer those values via brute force. Version 1.7.0 contains a patch. As a workaround, write a beforeOperation hook to remove where queries that attempt to access hidden field data.
An arbitrary file upload vulnerability in the file upload module of PayloadCMS v0.15.0 allows attackers to execute arbitrary code via a crafted SVG file.