Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
28 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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.
Recommended action: Upgrade to 4.0.0-canary.34 (pre-release) or 3.90.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 4.0.0-canary.34 (pre-release) or 3.90.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 4.0.0-canary.34 (pre-release) or 3.90.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 4.0.0-canary.34 (pre-release) or 3.90.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 4.0.0-canary.34 (pre-release) or 3.90.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 4.0.0-canary.34 (pre-release) or 3.90.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 4.0.0-canary.34 (pre-release) or 3.90.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 4.0.0-canary.34 (pre-release) or 3.90.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 4.0.0-canary.34 (pre-release) or 3.90.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 4.0.0-canary.34 (pre-release) or 3.90.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 4.0.0-canary.34 (pre-release) or 3.90.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 4.0.0-canary.34 (pre-release) or 3.90.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 4.0.0-canary.34 (pre-release) or 3.90.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact A user can submit a request that exploits a SQL Injection vulnerability in Payload. You are affected if: - You use an affected Payload version. - Untrusted users can query readable collections using dynamic filters or joins. You are not affected if you use MongoDB (@payloadcms/mongodb). Patches Users should upgrade Payload packages to = 3.88.0 or = 4.0.0-canary.27. Workarounds Upgrading to a patched version is recommended. Until you can upgrade, restrict untrusted users from supplying dynamic query filters or join parameters and limit read access to affected collections.
Recommended action: Upgrade to 4.0.0-canary.27 (pre-release) or 3.88.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 4.0.0-canary.27 (pre-release) or 3.88.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 4.0.0-canary.34 (pre-release) or 3.90.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The password-hashing configuration used a lower work factor than what is recommended. Patches Payload now uses stronger password-hashing parameters and transparently upgrades older hashes following a successful login. Users should upgrade Payload packages to `>= 3.90.0` or `>= 4.0.0-canary.34`. Workarounds Upgrading is recommended. Until you can upgrade, protect database copies and backups from unauthorized access and require strong, unique passwords.
Recommended action: Upgrade to 4.0.0-canary.34 (pre-release) or 3.90.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Under certain conditions, sorting readable records could reveal limited information about fields the requester was not permitted to read. You are affected if untrusted users can query a collection, control its sorting, and sort by protected fields. Patches Payload now applies field-level access checks to sort fields before executing queries. Users should upgrade to = 3.88.0 or = 4.0.0-canary.27. Workarounds Upgrading is recommended. Until then, prevent untrusted users from controlling sort parameters or restrict their access to affected collections.
Recommended action: Upgrade to 4.0.0-canary.27 (pre-release) or 3.88.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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).
Recommended action: Upgrade to 3.79.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 3.79.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 3.79.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 3.79.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 3.75.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 3.74.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Payload uses JSON Web Tokens (JWT) for authentication. After log out JWT is not invalidated, which allows an attacker who has stolen or intercepted token to freely reuse it until expiration date (which is by default set to 2 hours, but can be changed). This issue has been fixed in version 3.44.0 of Payload.
Recommended action: Upgrade to 3.44.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.