CVE-2026-33326
Received Received - Intake
Access Control Bypass in Keystone CMS findMany Queries

Publication date: 2026-03-24

Last updated on: 2026-05-04

Assigner: GitHub, Inc.

Description
Keystone is a content management system for Node.js. Prior to version 6.5.2, {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. This issue has been patched in version 6.5.2.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-03-24
Last Modified
2026-05-04
Generated
2026-05-07
AI Q&A
2026-03-24
EPSS Evaluated
2026-05-05
NVD
EUVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
keystonejs keystone to 6.5.2 (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-863 The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

CVE-2026-33326 is a vulnerability in the npm package @keystone-6/core, affecting versions up to 6.5.1 and fixed in version 6.5.2.

The issue involves a bypass of the `isFilterable` access control on fields during `findMany` queries by exploiting the `cursor` parameter.

Although a previous vulnerability related to `isFilterable` bypass in update and delete mutations was partially fixed by adding checks to the `where` parameter, the `cursor` parameter in `findMany` queries was not patched.

This parameter accepts the same UniqueWhere input type, allowing attackers to bypass field-level filtering restrictions.

The vulnerability allows unauthorized users to confirm the existence of records based on protected field values, effectively bypassing access control mechanisms intended to prevent filtering on sensitive fields.

This impacts projects relying on dynamic or function-based `isFilterable` controls to prevent data discovery through filtering.

However, projects that statically set `isFilterable: false` or `defaultIsFilterable: false` on sensitive fields, or omit filtering for these fields in the GraphQL schema, are not affected.


How can this vulnerability impact me? :

This vulnerability can impact you by allowing unauthorized users to confirm the existence of records based on protected field values.

It bypasses field-level filtering restrictions, which means sensitive data could be indirectly exposed.

The impact is limited to confidentiality loss, with no effect on data integrity or availability.

Attackers can exploit this vulnerability remotely with low complexity and low privileges, without requiring user interaction.

Mitigation involves upgrading to version 6.5.2 or applying workarounds such as statically disabling filtering on sensitive fields.


How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:

I don't know


How can this vulnerability be detected on my network or system? Can you suggest some commands?

[{'type': 'paragraph', 'content': 'This vulnerability involves bypassing the isFilterable access control on fields during findMany queries by exploiting the cursor parameter. Detection would involve monitoring or testing findMany GraphQL queries that use the cursor parameter to see if protected fields can be filtered or accessed.'}, {'type': 'paragraph', 'content': 'Specifically, you can attempt to run findMany queries with cursor parameters targeting sensitive fields that should not be filterable. If the query returns data or confirms the existence of records based on protected field values, the vulnerability is present.'}, {'type': 'paragraph', 'content': 'Since this is a GraphQL-based issue, detection commands would involve crafting GraphQL queries rather than traditional network commands.'}, {'type': 'list_item', 'content': 'Use a GraphQL client or curl to send a findMany query with a cursor parameter on a protected field.'}, {'type': 'list_item', 'content': 'Example curl command to test the vulnerability (replace URL and query accordingly):'}, {'type': 'list_item', 'content': 'curl -X POST https://your-keystone-instance/graphql -H "Content-Type: application/json" -d \'{"query":"query { items: yourEntity(findMany: { cursor: { protectedField: \\"value\\" } }) { id } }"}\''}, {'type': 'paragraph', 'content': 'If the query returns results despite the field being protected by isFilterable controls, the vulnerability exists.'}] [1]


What immediate steps should I take to mitigate this vulnerability?

The primary mitigation is to upgrade the @keystone-6/core package to version 6.5.2 or later, where this vulnerability has been fixed.

If upgrading is not immediately possible, apply workarounds such as statically setting the isFilterable property to false on sensitive fields or setting graphql.omit.read to true to remove filtering capabilities on those fields from the GraphQL schema.

  • Upgrade @keystone-6/core to version 6.5.2 or later.
  • Set {field}.isFilterable: false on sensitive fields.
  • Set {field}.graphql.omit.read: true to omit filtering on sensitive fields.

Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart