keystone-6-core

# Summary 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. # C

CVE: CVE-2026-63421

A vulnerability was detected in keystonejs keystone up to 20260319. This vulnerability affects unknown code in the library packages/core/src/lib/core/queries/output-field.ts of the component GraphQL API Endpoint. The manipulation results in resource consumption. It is possible to launch the attack remotely. The exploit is now public and may be used. The pull request to fix this issue awaits acceptance.

CVE: CVE-2026-10802

# Summary `{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](https://github.com/keystonejs/keystone/security/advisories/GHSA-hg9m-67mm-7pg3) (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 `

CVE: CVE-2026-33326

# Summary `{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

CVE: CVE-2025-46720

### Summary 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 wh

CVE: CVE-2023-40027

### Summary The `cuid` package used by `@keystone-6/*` and upstream dependencies is deprecated and [marked as insecure by the author](https://github.com/paralleldrive/cuid#status-deprecated-due-to-security-use-cuid2-instead). As reported by the author > Cuid and other k-sortable and non-cryptographic ids (Ulid, ObjectId, KSUID, all UUIDs) are all insecure. Use @paralleldrive/cuid2 instead. ### What are doing about this? - [We are waiting on Prisma](https://github.com/keystonejs/keystone/issues/8282) to add support for [`cuid2`](https://github.com/paralleldrive/cuid2) - Alternatively, we migh

### Impact `@keystone-6/core@3.0.0 || 3.0.1` users that use `NODE_ENV` in their own code (**not dependencies**) to trigger security-sensitive functionality in a production build are vulnerable to `NODE_ENV` being inlined to `"development"` for user code. If your dependencies use `NODE_ENV` to trigger particular behaviours (optimisations, security or otherwise), they should still respect your environment's configured `NODE_ENV` variable and thereby be unaffected. If you do not use `NODE_ENV` in your own code to trigger security-sensitive functionality, **you are not impacted** by this vulnera

CVE: CVE-2022-39382

#### 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: ```ts const yourList = list({ access: { // this is list-level access control, this is NOT impacted }, fields: { yourFieldName: multisel

CVE: CVE-2022-39322