GHSA-cgcg-q9jh-5pr2

# 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 `isFilterable` behaviour (at the list or field level) to prevent external users from using the filtering of fields as a discovery mechanism. `isFilterable` access control using a function can be bypassed by using the `cursor` input. 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.2. # Workarounds To mitigate this issue in older versions where patching is not a viable pathway. - Set `{field}.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