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
6 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
The value of graphql.maxTake can be bypassed by providing a negative input. This can be used to exceed the developer's intended graphql.maxTake value, allowing queries to return results in excess of the graphql.maxTake value set. Impact This affects any project relying on graphql.maxTake to bound the number of items returned per query. Patches This issue has been patched in @keystone-6/core version 6.5.3. If you cannot patch, you can workaround this by restricting take input values in your GraphQL queries to the bounded value, or by blocking negative values. Credit This issue was found by Haxset's Security Scanner and validated by their team.
Recommended action: Upgrade to 6.5.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
{field}.isFilterable access control can be bypassed in findMany queries by passing a cursor. This can be used to confirm the existence of records by protected field values. The fix for CVE-2025-46720 (field-level isFilterable bypass for update and delete mutations) added checks to the where parameter in update and delete mutations however the cursor parameter in findMany was not patched and accepts the same UniqueWhere input type. Impact This affects any project relying on isFilterable behaviour (at the list or field level) to prevent external users from using the filtering of fields as a discovery mechanism. isFilterable access control using a function can be bypassed by using the cursor input. This has no impact on projects using isFilterable: false or defaultIsFilterable: false for sensitive fields, or if you have otherwise omitted filtering by these fields from your GraphQL schema. (See workarounds) Patches This issue has been patched in @keystone-6/core version 6.5.2.…
Recommended action: Upgrade to 6.5.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
{field}.isFilterable access control can be bypassed in update and delete mutations by adding additional unique filters. These filters can be used as an oracle to probe the existence or value of otherwise unreadable fields. Specifically, when a mutation includes a where clause with multiple unique filters (e.g. id and email), Keystone will attempt to match records even if filtering by the latter fields would normally be rejected by field.isFilterable or list.defaultIsFilterable. This can allow malicious actors to infer the presence of a particular field value when a filter is successful in returning a result. Impact This affects any project relying on the default or dynamic isFilterable behaviour (at the list or field level) to prevent external users from using the filtering of fields as a discovery mechanism. While this access control is respected during findMany operations, it was not completely enforced during update and delete mutations when accepting more than one unique…
Recommended action: Upgrade to 6.5.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When ui.isAccessAllowed is undefined, the adminMeta GraphQL query is publicly accessible, that is to say, no session is required for the query. This is different to the behaviour of the default AdminUI middleware, which by default will only be publicly accessible if a session strategy is not defined. Impact This vulnerability does not affect developers using the @keystone-6/auth package, or any users that have written their own ui.isAccessAllowed (that is to say, you are unaffected if ui.isAccessAllowed is defined). This vulnerability does affect developers who thought that their session strategy will, by default, enforce that adminMeta is inaccessible by the public in accordance with that strategy; akin to the behaviour of the AdminUI middleware. Patches This vulnerability has been patched in @keystone-6/core version 5.5.1. Workarounds You can opt to write your own isAccessAllowed to work-around this vulnerability. References Pull request…
Recommended action: Upgrade to 5.5.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact @keystone-6/core@3.0.0 || 3.0.1 users that use NODEENV in their own code (not dependencies) to trigger security-sensitive functionality in a production build are vulnerable to NODEENV being inlined to "development" for user code. If your dependencies use NODEENV to trigger particular behaviours (optimisations, security or otherwise), they should still respect your environment's configured NODEENV variable and thereby be unaffected. If you do not use NODEENV in your own code to trigger security-sensitive functionality, you are not impacted by this vulnerability. An example of code that would be affected, might be the following: Technical Description The problem comes from esbuild defaulting NODEENV to "development" when a platform configuration is undefined. You can read about why esbuild has that behaviour in their documentation, but the result for Keystone users is that user Typescript was compiled, and had inlined NODEENV to the constant "development". Your application's…
Recommended action: Upgrade to 3.0.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact @keystone-6/core@2.2.0 || 2.3.0 users who are using the multiselect field, and provided field-level access control - are vulnerable to their field-level access control not being used. List-level access control is NOT affected. Field-level access control for fields other than multiselect are NOT affected. Example, you are vulnerable if you are using field-level access control on a multiselect like the following: Mitigation Please upgrade to @keystone-6/core = 2.3.1, where this vulnerability has been closed. Workarounds If for some reason you cannot upgrade your dependencies, you should stop using the multiselect field. Credits Thanks to Marek R for reporting and submitting the pull request to fix this problem. If you have any questions around this security advisory, please don't hesitate to contact us at security@keystonejs.com, or open an issue on GitHub. If you have a security flaw to report for any software in this repository, please see our SECURITY policy.
Recommended action: Upgrade to 2.3.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.