Skip to main content
No exploitation reportedFix available

CVE-2025-46720

No exploitation reported by the sources we read.

  • Published2025-05-05
  • Fixed in6.5.0
  • WeaknessCWE-200 · CWE-203

Am I affected?

With a domain, we read the version its public headers and pages expose. A distribution build can carry the fix under an older number.

Description

Keystone is a content management system for Node.js. Prior to version 6.5.0, `{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. This affects any project relying on the default or dynamic `isFilterable` behavior (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 for those who have otherwise omitted filtering by these fields from their GraphQL schema. This issue has been patched in `@keystone-6/core` version 6.5.0. 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 from the GraphQL schema; and/or deny `update` and `delete` operations for the relevant lists completely.

Timeline

dates in UTC
  1. 2025-05-0519:15CVE publishedNVD

Versions per branch

NVD · OSV
Keystonejs keystone
BranchAffectedFixed in
6.5< 6.5.06.5.0

as publishedRanges as NVD and OSV publish them; a distribution’s build can be fixed under an older number.

Products declared by the CNA1 product

As GitHub_M, the CNA that assigned this CVE, declared them in the CVE record; versions as written.

  • keystonejs keystone
    Affected
    • = < 6.5.0no fix stated

Source: the CNA record (CVE Program), © The MITRE Corporation,CVE Terms of UseCVE recordupdated 2025-05-05

Fix

  1. Update Keystonejs keystone to 6.5.0

Advisories and patches

Detection

Nuclei template
none so far
ProjectDiscovery
Exploit-DB
no entry
Exploit-DB
Proof of concept
Metasploit modules
none listed
Metasploit Framework

Sources

  • CISA-ADPSSVC decisionnone2025-05-05
  • CNACVSS 3.13.1known since 2026-10-23
  • NVDCVSS 3.14.3read 2026-10-23
  • CNAweakness (CWE)CWE-200, CWE-203known since 2026-10-23
  • FIRST EPSSEPSS score0.3 %2026-11-11
  • OSVaffected packages—
  • GitHub AdvisoriesadvisoryLOW2025-05-05

Identifiers

Technical details

CVSS v3 Vector
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N
Published
2025-05-05
Last Modified
2026-06-17
NVD status
Analyzed
GitHub Advisory
GHSA-hg9m-67mm-7pg3

Frequently asked questions

What is CVE-2025-46720?

Keystone is a content management system for Node.js. Prior to version 6.5.0, `{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. This affects any project relying on the default or dynamic `isFilterable` behavior (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 for those who have otherwise omitted filtering by these fields from their GraphQL schema. This issue has been patched in `@keystone-6/core` version 6.5.0. 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 from the GraphQL schema; and/or deny `update` and `delete` operations for the relevant lists completely.

Is CVE-2025-46720 actively exploited?

Active exploitation of CVE-2025-46720 has not been confirmed. Its EPSS score was 0.3% on 2026-11-11, the estimated probability of exploitation in the next 30 days.

What is the CVSS score for CVE-2025-46720?

CVE-2025-46720 has a CVSS v3 base score of 4.3 (MEDIUM severity), with vector string CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N.

Running @keystone-6/core? Hear about its next vulnerability

Surveillance reads the versions in your stack — a domain, a lockfile or a list — checks each CVE against the ranges its sources publish, and alerts you when one you run is exploited or enters CISA KEV. A version it cannot read stays « version not verified ».

Get alerts for this productCISA KEV additions, November 2026Search CVEs

No credit card required · No monthly cap on website lookups · 250 API requests/month

Go further

Related vulnerabilities

Same product first, then the same vendor advisory and the same publication week.

Back to CVE Database

Sources for this record