GHSA-HG9M-67MM-7PG3

Vulnerability from github – Published: 2025-05-05 18:51 – Updated: 2025-05-05 22:06

Summary

Keystone has an unintended `isFilterable` bypass that can be used as an oracle to match hidden fields

Details

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 } }, ... }))

Severity ?

3.1 (Low)


                  
                    CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 6.4.0"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@keystone-6/core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.5.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-46720"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-203"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-05-05T18:51:34Z",
    "nvd_published_at": "2025-05-05T19:15:57Z",
    "severity": "LOW"
  },
  "details": "# Summary  \n`{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.\n\nSpecifically, 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.\n\n# Impact  \nThis 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.\n\nThis 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)\n\n# Patches  \nThis issue has been patched in `@keystone-6/core` version 6.5.0.\n\n# Workarounds  \nTo mitigate this issue in older versions where patching is not a viable pathway.\n\n- Set `isFilterable: false` statically for relevant fields to prevent filtering by them earlier in the access control pipeline (that is, don\u0027t use functions)\n- Set `{field}.graphql.omit.read: true` for relevant fields, which implicitly removes filtering by these fields your GraphQL schema\n- Deny `update` and `delete` operations for the relevant **lists** completely (e.g `list({ access: { operation: { update: false, delete: false } }, ... })`)",
  "id": "GHSA-hg9m-67mm-7pg3",
  "modified": "2025-05-05T22:06:50Z",
  "published": "2025-05-05T18:51:34Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/keystonejs/keystone/security/advisories/GHSA-hg9m-67mm-7pg3"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-46720"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/keystonejs/keystone"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Keystone has an unintended `isFilterable` bypass that can be used as an oracle to match hidden fields"
}

CVE-2025-46720 (GCVE-0-2025-46720)

Vulnerability from cvelistv5 – Published: 2025-05-05 18:53 – Updated: 2025-05-05 19:00

Title

Keystone has an unintended `isFilterable` bypass that can be used as an oracle to match hidden fields

Summary

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.

Severity ?

3.1 (Low)


                        
                          CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N

CWE

CWE-203 - Observable Discrepancy
CWE-200 - Exposure of Sensitive Information to an Unauthorized Actor

Assigner

GitHub_M

References

URL

Tags

https://github.com/keystonejs/keystone/security/a…

x_refsource_CONFIRM

Impacted products

	Vendor	Product	Version
	keystonejs	keystone	Affected: < 6.5.0

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2025-46720",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2025-05-05T18:59:54.605898Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2025-05-05T19:00:01.531Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "keystone",
          "vendor": "keystonejs",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 6.5.0"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "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\u0027t 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."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "HIGH",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 3.1,
            "baseSeverity": "LOW",
            "confidentialityImpact": "LOW",
            "integrityImpact": "NONE",
            "privilegesRequired": "LOW",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N",
            "version": "3.1"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-203",
              "description": "CWE-203: Observable Discrepancy",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-200",
              "description": "CWE-200: Exposure of Sensitive Information to an Unauthorized Actor",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2025-05-05T18:53:51.506Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/keystonejs/keystone/security/advisories/GHSA-hg9m-67mm-7pg3",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/keystonejs/keystone/security/advisories/GHSA-hg9m-67mm-7pg3"
        }
      ],
      "source": {
        "advisory": "GHSA-hg9m-67mm-7pg3",
        "discovery": "UNKNOWN"
      },
      "title": "Keystone has an unintended `isFilterable` bypass that can be used as an oracle to match hidden fields"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2025-46720",
    "datePublished": "2025-05-05T18:53:51.506Z",
    "dateReserved": "2025-04-28T20:56:09.084Z",
    "dateUpdated": "2025-05-05T19:00:01.531Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.1"
}

Sightings

Author	Source	Type	Date

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Detection rules are retrieved from Rulezet.

Action not permitted

GHSA-HG9M-67MM-7PG3

Summary

Impact

Patches

Workarounds

CVE-2025-46720 (GCVE-0-2025-46720)

Tags

Sightings

Nomenclature