CVE-2025-46720 is a vulnerability in KeystoneJS, a popular Node.js-based content management system (CMS). The issue affects versions prior to 6.5.0 and involves an access control bypass related to the `isFilterable` property on fields during GraphQL mutations, specifically `update` and `delete` operations. KeystoneJS allows filtering of records using unique fields in the `where` clause of mutations. Normally, the `isFilterable` access control setting restricts filtering on sensitive fields to prevent unauthorized data discovery. However, this vulnerability arises because when multiple unique filters are combined (e.g., filtering by both `id` and `email`), Keystone attempts to match records even if some filters should be disallowed by `isFilterable` or `defaultIsFilterable` settings. This behavior effectively bypasses the intended access control, enabling an attacker to use these filters as an oracle to infer the existence or specific values of otherwise unreadable fields. This is a form of information disclosure (CWE-203 and CWE-200) that can leak sensitive data indirectly without granting direct read access. The vulnerability does not affect `findMany` queries, where filtering respects access controls correctly, but only `update` and `delete` mutations. The impact is limited to projects that rely on dynamic or default `isFilterable` behavior rather than statically setting `isFilterable: false` or omitting filtering on sensitive fields from the GraphQL schema. The issue has been patched in KeystoneJS version 6.5.0. For environments where upgrading is not feasible, mitigations include statically setting `isFilterable: false` on sensitive fields, omitting those fields from the GraphQL schema by setting `{field}.graphql.omit.read: true`, or restricting `update` and `delete` operations on affected lists entirely. The CVSS score is 3.1 (low severity), reflecting limited confidentiality impact, high attack complexity, and the need for some privileges (low privileges) but no user interaction. No known exploits are reported in the wild as of now.

For European organizations using KeystoneJS as their CMS or backend framework, this vulnerability poses a risk of indirect information disclosure. Attackers with low privileges could probe sensitive data fields by crafting GraphQL mutations with multiple unique filters, potentially revealing confidential information such as user emails, IDs, or other protected attributes. Although the vulnerability does not allow direct data modification or deletion without proper authorization, the ability to confirm the existence or values of sensitive fields can aid in further targeted attacks, social engineering, or reconnaissance. Organizations handling personal data subject to GDPR must be cautious, as even indirect data leaks can have compliance implications. The impact is more pronounced for organizations that rely on dynamic or default filtering controls rather than explicit static configurations. Since KeystoneJS is used in various industries including media, education, and enterprise web applications, the vulnerability could affect a broad range of sectors. However, the low CVSS score and absence of known exploits suggest the immediate risk is limited but should not be ignored, especially in high-value or sensitive environments.

1. Upgrade KeystoneJS to version 6.5.0 or later, where this vulnerability is patched. 2. For environments where upgrading is not immediately possible, statically set `isFilterable: false` on all sensitive fields to prevent filtering by these fields early in the access control pipeline, avoiding reliance on dynamic functions. 3. Use `{field}.graphql.omit.read: true` on sensitive fields to remove them from the GraphQL schema entirely, which also disables filtering on those fields. 4. Consider restricting or denying `update` and `delete` mutations on lists containing sensitive fields if filtering cannot be safely controlled. 5. Conduct a thorough review of the GraphQL schema and access control configurations to ensure no sensitive fields are inadvertently filterable. 6. Implement monitoring and alerting for unusual mutation patterns that attempt to combine multiple unique filters, which may indicate probing attempts. 7. Educate developers and administrators about the risks of dynamic filtering and encourage explicit, static access control settings for sensitive data fields.