GitHub Advisoryadvisory · Packagist

GHSA-428q-q3vv-3fq3 GraphQL grant on a property might be cached with different objects

HIGH Published 2025-04-04 Modified 2025-08-29 Official page ↗
Aliases
CVE-2025-31485
Ecosystem
Packagist
Packages
api-platform/graphql, api-platform/core
Severity
High
CVSS vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
Weaknesses
CWE-696
Reviewed
2025-04-04

Affected packages

• Packagist api-platform/graphql: >= 4.0.0-alpha.1, < 4.0.22 → fixed in 4.0.22 • Packagist api-platform/core: >= 4.0.0-alpha.1, < 4.0.22 → fixed in 4.0.22 • Packagist api-platform/graphql: < 3.4.17 → fixed in 3.4.17 • Packagist api-platform/core: < 3.4.17 → fixed in 3.4.17 • Packagist api-platform/core: >= 4.1.0-alpha.1, < 4.1.5 → fixed in 4.1.5 • Packagist api-platform/graphql: >= 4.1.0-alpha.1, < 4.1.5 → fixed in 4.1.5

Description

Original message: I found an issue with security grants on on properties in the GraphQL ItemNormalizer: If you use something like `#[ApiProperty(security: 'is_granted("PROPERTY_READ", [object, property])')]` on a member of an entity, the grant gets cached and is only evaluated once, even if the `object` in question is a different one. There is the `ApiPlatform\GraphQl\Serializer\ItemNormalizer::isCacheKeySafe()` method that seems to be intended to prevent this: https://github.com/api-platform/core/blob/88f5ac50d20d6510686a7552310cc567fcca45bf/src/GraphQl/Serializer/ItemNormalizer.php#L160-L164 and in its usage on line 90 it does indeed not create a cache key, but the `parent::normalize()` that is called afterwards still creates the cache key and causes the issue. Impact It grants access to properties that it should not. Workarounds Override the ItemNormalizer. Patched at: https://github.com/api-platform/core/commit/7af65aad13037d7649348ee3dcd88e084ef771f8

Related

Alias · CVE (1)

  • CVE-2025-31485 API Platform Core is a system to create hypermedia-driven REST and GraphQL APIs. vulnerability

Weakness · CWE (1)

  • CWE-696 Incorrect Behavior Order weakness

References