Open-Source Security Intelligence

Know every vulnerability
before it knows you.

DevGuard continuously monitors your dependencies and alerts you when CVEs like this one affect your stack — with real-time threat intelligence built for developers.

Checkout DevGuard View on GitHub

GHSA-hg9m-67mm-7pg3

LowCVSS 3.1 / 10

Published May 5, 2025·Last modified May 5, 2025

Affected Components(0)

No affected components available

Description

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 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 where values in filters.

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.0.

Workarounds

To mitigate this issue in older versions where patching is not a viable pathway.

Set isFilterable: false statically for relevant fields to prevent filtering by them earlier in the access control pipeline (that is, don't use functions)
Set {field}.graphql.omit.read: true for relevant fields, which implicitly removes filtering by these fields your GraphQL schema
Deny update and delete operations for the relevant lists completely (e.g list({ access: { operation: { update: false, delete: false } }, ... }))

Risk Scores

Base Score

3.1

The vulnerability can be exploited over the network without needing physical access. It is difficult for an attacker to exploit this vulnerability and may require special conditions. An attacker needs basic access or low-level privileges. No user interaction is needed for the attacker to exploit this vulnerability. The impact is confined to the system where the vulnerability exists. There is a low impact on the confidentiality of the information.

Threat Intelligence

2.9

Limited exploitation activity has been observed. Close monitoring and planned remediation are recommended.

EPSS

0.25%

The exploit probability is very low. The vulnerability is unlikely to be exploited in the next 30 days.

Exploit

Not available

We did not find any exploit available. Neither in GitHub repositories nor in the Exploit-Database.

Browse More

Low severity

Scan your project

Continuously monitor your dependencies and get alerted when vulnerabilities like this one affect your stack.