Skip to content

fix(deps): update dependency payload to v3.90.0 [security] - #153

Open
renovate[bot] wants to merge 1 commit into
mainfrom
renovate/npm-payload-vulnerability
Open

renovate[bot] wants to merge 1 commit into
mainfrom
renovate/npm-payload-vulnerability

Conversation

@renovate

@renovate renovate Bot commented Oct 13, 2026 •

Copy link
Copy Markdown
Contributor

This PR contains the following updates:

Package Change Age Confidence
payload (source) 3.88.0 → 3.90.0 age confidence

Payload: Password hashes use insufficient PBKDF2 iterations

CVE-2026-105804 / GHSA-q6mq-ch85-c8mm

More information

Details

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.

Severity

  • CVSS Score: 5.7 / 10 (Medium)
  • Vector String: CVSS:4.0/AV:L/AC:H/AT:P/PR:H/UI:N/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).


Payload: Polymorphic join queries could disclose hidden fields

CVE-2026-105847 / GHSA-fpww-c55p-cjv6

More information

Details

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.

Severity

  • CVSS Score: 7.1 / 10 (High)
  • Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).


Payload vulnerable to API key disclosure through ordinary document reads

CVE-2026-105849 / GHSA-238x-w2j9-gwwr

More information

Details

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.

Severity

  • CVSS Score: 7.7 / 10 (High)
  • Vector String: CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).


Payload: Field access control bypass on auth collections

CVE-2026-105851 / GHSA-vc4h-q48j-5hcx

More information

Details

Impact

Payload's duplicate operation copies field values from the source document even when a field is hidden, or its access.read or access.create rule would reject the value for that caller.

The disableDuplicate collection setting, enabled by default on auth collections, did not stop this.

Patches

Users should upgrade Payload packages to >= 3.90.0 or >= 4.0.0-canary.34.

Workarounds

Add a beforeDuplicate field hook to fields and set the value to empty or your default value.

Severity

  • CVSS Score: 9.3 / 10 (Critical)
  • Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:H/SI:H/SA:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).


Payload: Token refresh and password reset responses may expose restricted user fields

CVE-2026-105853 / GHSA-xgv3-crq2-6f69

More information

Details

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.

Severity

  • CVSS Score: 7.1 / 10 (High)
  • Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).


Payload: ReDoS in Multipart Content-Type Validation

CVE-2026-105854 / GHSA-2g7p-5934-q4w7

More information

Details

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.

Severity

  • CVSS Score: 8.7 / 10 (High)
  • Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).


Payload relationship-query authorization bypass

CVE-2026-105852 / GHSA-7c34-32v3-j575

More information

Details

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.

Severity

  • CVSS Score: 6.9 / 10 (Medium)
  • Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).


Payload didn't enforce field-level password update restrictions

CVE-2026-105855 / GHSA-fx49-4h83-wjv9

More information

Details

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.

Severity

  • CVSS Score: 7.6 / 10 (High)
  • Vector String: CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).


Release Notes

payloadcms/payload (payload)

v3.90.0

Compare Source

⚠️ This release contains a set of critical security fixes. Please review the following notes and upgrade as soon as possible. Even if none of the listed items below affect you, we still recommend updating as soon as possible.

These notes only cover the behavior, configuration, and API-surface changes that projects may need to react to when upgrading. Exploit details, attack surface descriptions, and severity are intentionally omitted.

CVE and GHSA identifiers for the underlying issues are published separately.

How to read this document

Every entry has: Affected if you (concrete conditions - if none apply, no action is required), and Action required.

After upgrading:

  • Regenerate your payload types: pnpm payload generate:types
  • If you are using a relational database, you will need to create and run a migration:
pnpm payload migrate:create <migration-name>
pnpm payload migrate
Password changes now revoke other sessions
  • No action needed.
Password reset now clears lockouts; forgot-password is throttled
  • Adds new resetPasswordRequestedAt field to user collections

  • Action required:

    • Regenerate types: pnpm payload generate:types
    • If using a relational database, perform migration:
pnpm payload migrate:create add-reset-password-requested-at
pnpm payload migrate
Scheduled publishing preserves the scheduling user's auth collection

Affected if you:

  • Have publish or unpublish events queued when upgrading.
  • Use multiple admin-capable auth collections.
  • Queue schedulePublish jobs directly or depend on its generated task types.

Action required:

  • Re-create pending scheduled publish and unpublish events after upgrading.
  • Update custom queue code to pass user: { relationTo, value } (value is user ID).
  • Regenerate committed Payload types if applicable.
  • No database migration is required.
Stricter validation for SVG and XML uploads

Affected if you:

  • Upload SVG, XHTML, or XML-family files.
  • Use direct client uploads, particularly with Azure or a custom integration.
  • Depend on path components being retained in new filenames.

Action required:

  • Verify affected upload and XML-delivery workflows.
  • Ensure custom upload clients send the required metadata and returned headers.
  • Set allowRestrictedFileTypes: true in the collections upload property if the previous behavior is explicitly required.
Client uploads hardened across all adapters

Affected if you:

  • Use any client upload adapters with clientUploads: true (S3, GCS, Azure, or custom).

Action required:

  • If using GCS adapter, add x-goog-if-generation-match header to GCS CORS allowed headers.
Azure containers default to private

Affected if you:

  • Use the @payloadcms/storage-azure adapter with allowContainerCreate: true

Action required:

  • If you wish to retain the previous behavior, set containerAccess: 'blob' in your Azure storage config.
Client uploads are stored in a per-upload folder

Affected if you:

  • Use clientUploads with a storage adapter and access stored files outside Payload (for example, by building paths from prefix and filename)
  • Set document prefix values outside the adapter's collection prefix

What changed:

  • New client uploads are stored at <prefix>/<_objectKey>/<filename>, including generated image sizes. _objectKey is a new field on upload collections. Existing files are not moved.
  • New uploads and replacements are always stored inside the collection prefix. For example, a document prefix of user-123 with collection prefix media is stored under media/user-123/.

Action required:

  • Include _objectKey (when set) between the prefix and filename when building storage paths outside Payload.
  • If using a relational database, the migration from the "After upgrading" step adds the _objectKey column.
disablePayloadAccessControl no longer disables safe outbound fetch

Affected if you:

  • Set disableAccessControl: true in your Payload config.

Action required:

  • Configure a narrow upload.skipSafeFetch allowlist for trusted destinations
  • Use skipSafeFetch: true only when every URL accepted by the collection is trusted.
  • No action is required when files are retrieved from ordinary public endpoints.
External file fetches require a trusted origin

Affected if you:

  • Use upload.disableLocalStorage: true and rely on Payload fetching relative URLs whose endpoint requires a Payload session cookie.
  • Implement externalFileHeaderFilter, particularly if it assumes it runs only once.
  • Use non-HTTP(S) external-file URLs.

Action required:

  • Configure serverURL or add the exact application origin to your CORS or CSRF configuration.
  • Replace non-HTTP(S) external-file URLs with HTTP(S) URLs.
  • Review externalFileHeaderFilter and use the optional context when headers need to vary by destination.
upload: {
  externalFileHeaderFilter: (headers, context) => {
+   if (!context?.isSameOrigin) {
+     delete headers.cookie
+     delete headers.authorization
+   }
+
    return headers
  },
}
Uploaded filename hardening

Affected if you:

  • Use a custom top-level prefix field on an upload collection as ordinary application data.
  • Change an upload’s storage prefix without also replacing its file.

Action required:

  • Rename a custom, non-storage prefix field or update it through trusted server-side code.
  • Submit storage-prefix changes as part of a file replacement. Adapter-managed prefix fields do not require migration.
Multipart uploads are now capped at 50MB by default

Affected if you:

  • Use multipart uploads and rely on uploads being larger than 50MB

Action required:

  • Raise the multipart cap if your application requires support for larger uploads for requests. Adjust the requestSizeLimit in your Payload config:
upload {
+  requestSizeLimit: 75 * 1024 * 1024, // Example 75 MiB for the complete multipart request
}
Form Builder defaults form submission read access to the admin collection

Affected if you:

  • Have more than one auth enabled where the secondary auth collections are expected to be able to read either:
    • form-submission docs
    • forms.emails array field

Action required:

  • Supply an explicit formSubmissionOverrides.access or formOverrides.access to override the new defaults. If you already have overrides configured, they will continue to be respected.
Stricter where validation for polymorphic joins

Polymorphic joins now apply complete where constraints and throw a QueryError when a filter is unsupported.

Unsupported filters include:

  • Localized fields.
  • Fields nested inside arrays or blocks.
  • Paths traversing relationship, upload, or JSON fields, such as owner.email.
  • The near, within, intersects, and all operators.
  • The same field path having incompatible definitions across joined collections, such as number in one collection and text in another.

Affected if you:

  • Use a join whose collection references multiple collections, and
  • Apply an unsupported filter through:
    • A target collection's read access rule.
    • A join where constraint.
    • An Admin baseFilter or baseListFilter used by folder browsing.
  • Use folders with folder-enabled collections whose read access or base filters contain one of these unsupported shapes.

Action required:

  • Review where constraints and read access rules for every collection referenced by a polymorphic join.
  • If using folders, review every folder-enabled collection's read access rules and Admin base filters.
  • Rewrite unsupported filters to use direct, compatible fields while preserving the intended access restrictions.
API keys are no longer readable after initial generation through UI or within Payload operations

If you wish to retain old behavior, set the following in your config:

auth: {
-  useAPIKey: true,
+  useAPIKey: {
+    reveal: true,
+  },
 }
Lexical version bump

Full Details

No application changes or data migration are needed when using Payload's built-in rich text features.

If you maintain custom rich text features, check that they still compile and that custom content loads, copies, and pastes correctly. Lexical removed some older APIs, tightened TypeScript types, and changed how custom nodes are loaded and copied. Tests that inspect the editor's HTML may also need updated selectors or snapshots because Lexical adds some internal markup.

Do not install lexical or @​lexical/* yourself for use with Payload. Remove any direct dependencies you added for the editor and use Payload's re-exports from @payloadcms/richtext-lexical/lexical and @payloadcms/richtext-lexical/lexical/*. Payload supplies the matching versions; mixing versions can break the editor. This is the existing custom feature requirement.

v3.89.0

Compare Source

🚀 Features
🐛 Bug Fixes
🛠 Refactors
📚 Documentation
⚠️ BREAKING CHANGES
🤝 Contributors

Configuration

📅 Schedule: (UTC)

  • Branch creation
    • At any time (no schedule defined)
  • Automerge
    • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.


  • If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants