Where
-Infinity
0

Vendor Risk Score

See how payloadcms compares to other vendors in security performance

View Risk Score →
Severity
6.5
Path Traversal
AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N

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.

1 / 2
Source: GitHub
First published (updated )
Severity
5.4
CSRF
AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:L

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

1 / 2
Source: GitHub
First published (updated )
Severity
8.7
XSS
AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:N

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.

1 / 2
Source: GitHub
First published (updated )
Severity
8.5
SQL Injection, Input Validation
AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N

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.

1 / 2
Source: GitHub
First published (updated )
Severity
7.7
SSRF
AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N

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.

1 / 2
Source: GitHub
First published (updated )
Severity
9.1
Input Validation
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N

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.

1 / 2
Source: GitHub
First published (updated )
Severity
6.5
EPSS
0.03%
SSRF
AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:N

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.

1 / 2
Source: GitHub
First published (updated )
Severity
5.4
EPSS
0.01%
SQL Injection
AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N

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.

1 / 2
Source: GitHub
First published (updated )
Severity
9.8
EPSS
0.03%
SQL Injection
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

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.

1 / 2
Source: GitHub
First published (updated )
Severity
7.4
Infoleak
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

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.

First published (updated )
Severity
9.8
Malicious File Upload
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

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.

First published (updated )

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203