CVE-2026-33326: 
JavaScript vulnerability analysis and mitigation

CVE-2026-33326 is an incorrect authorization vulnerability in Keystone, a Node.js content management system, that allows low-privileged attackers to bypass isFilterable access controls via the cursor parameter in findMany GraphQL queries. This is an incomplete fix for CVE-2025-46720, which patched the where parameter in update and delete mutations but left the cursor parameter in findMany unaddressed. All versions of @keystone-6/core up to and including 6.5.1 are affected. It was disclosed on March 19, 2026, with a CVSS v3.1 base score of 4.3 (Medium) (GitHub Advisory).

The root cause is CWE-863 (Incorrect Authorization): the cursor parameter in Keystone's findMany GraphQL query accepts the same UniqueWhere input type as the where parameter, but the access control check enforcing isFilterable restrictions was not applied to it. When the prior fix for CVE-2025-46720 was implemented, only the where parameter in update and delete mutations received the isFilterable check; the cursor parameter in findMany was overlooked. An authenticated, low-privileged attacker can craft GraphQL findMany queries using the cursor parameter with values of protected fields to probe for record existence — effectively using the cursor as a filter oracle. This bypass only affects projects using isFilterable as a function (dynamic access control); projects using static isFilterable: false or defaultIsFilterable: false are not impacted (GitHub Advisory).

Successful exploitation allows a low-privileged attacker to confirm the existence of records by probing protected field values through the cursor parameter, constituting a confidentiality breach limited to record existence disclosure. There is no impact on data integrity or availability. Projects relying on dynamic isFilterable functions to prevent field-based discovery are at risk of having sensitive data enumerated, such as confirming whether a user with a specific email or identifier exists in the database (GitHub Advisory).

No public exploit code or in-the-wild exploitation has been reported for this vulnerability. The EPSS score is approximately 0.008% (0.000080), indicating a very low probability of exploitation in the near term. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. Exploitation requires a valid (low-privileged) account on the target Keystone application, limiting the attacker pool (GitHub Advisory).

1. Authenticate: Obtain a low-privileged account on the target Keystone application (e.g., a standard user account).
2. Identify protected fields: Review the application's GraphQL schema to identify list types with fields that have isFilterable access control configured as a function.
3. Craft a cursor-based probe query: Send a GraphQL findMany query using the cursor parameter with a UniqueWhere input targeting a protected field value. For example:

query {
  users(cursor: { email: "target@example.com" }) {
    id
  }
}

4. Interpret the response: Observe whether the query returns results or an empty set. A non-empty result (or a specific error vs. empty response) confirms the existence of a record with the probed field value.
5. Enumerate records: Repeat with different field values to systematically confirm the existence of records protected by isFilterable access controls (GitHub Advisory).

• Network: Repeated GraphQL findMany queries to the Keystone GraphQL endpoint containing cursor parameters with varying field values (especially fields expected to be protected), originating from a single authenticated user or IP address.
• Logs: Application or web server logs showing high-frequency findMany GraphQL requests with cursor arguments targeting unique fields (e.g., email, username, or other sensitive identifiers) from the same session or token.
• Behavior: Systematic enumeration patterns in GraphQL query logs — sequential or dictionary-based values passed to the cursor parameter across many requests in a short time window.

Upgrade @keystone-6/core to version 6.5.2 or later, which patches the cursor parameter in findMany queries to enforce isFilterable access controls. For projects unable to upgrade immediately, two workarounds are available: (1) set {field}.isFilterable: false statically (not as a function) for sensitive fields to block filtering earlier in the access control pipeline, or (2) set {field}.graphql.omit.read: true for relevant fields, which removes them from the GraphQL schema entirely and prevents cursor-based filtering. Projects already using static isFilterable: false or defaultIsFilterable: false are not affected and require no action (GitHub Advisory).