Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
8 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
The API Platform serializer's AbstractItemNormalizer does not validate the resource type returned when resolving relation IRIs, allowing type confusion where a resource of an unintended type can be silently assigned to a relation property. Impact An attacker who can submit write requests (POST/PUT/PATCH) to an API Platform endpoint with writable relations can supply a relation IRI pointing to a resource of a different type than the relation's declared class. Because getResourceFromIri() does not pass an $operation to IriConverter::getResourceFromIri(), the isa type guard at IriConverter.php:86 is skipped. For untyped relation properties (legacy @var-only style), the wrong-typed object is silently assigned, corrupting invariants and potentially feeding downstream logic that assumes the declared type (CWE-843). For typed properties (modern PHP 8.x), the substitution is blocked by Symfony's PropertyAccessor with an InvalidTypeException. Affected versions - api-platform/core <…
Recommended action: Upgrade to 4.3.12, 4.2.26 or 4.1.30 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact #[ApiProperty(security: ...)] is evaluated per request to decide whether a property is exposed. The componentsCache arrays in ApiPlatform\JsonApi\Serializer\ItemNormalizer and ApiPlatform\Hal\Serializer\ItemNormalizer are keyed on $context['cachekey'], which is set unconditionally before delegating to the parent normalizer. The component structure (attributes, relationships, links) computed for one request can therefore be reused for a subsequent request whose user has a different set of accessible properties. A user with lower privileges may end up seeing the structure of properties that the security predicate would otherwise have hidden for them. This is the same vulnerability class as GHSA-428q-q3vv-3fq3 / CVE-2025-31485, which fixed only the GraphQL ItemNormalizer. The JSON:API and HAL paths were not addressed at the time. Exploitation conditions Exploitation requires all of the following to coincide: - The application exposes a resource via the JSON:API and/or HAL…
Recommended action: Upgrade to 4.3.8, 4.2.25 or 4.1.29 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Original message: I found an issue with security grants on on properties in the GraphQL ItemNormalizer: If you use something like #[ApiProperty(security: 'isgranted("PROPERTYREAD", [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
Recommended action: Upgrade to 4.1.5, 4.0.22 or 3.4.17 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Using the Relay special node type you can bypass the configured security on an operation. Details Here is an example of how to apply security configurations for the GraphQL operations: This indeed checks isgranted('ROLEUSER') as expected for a GraphQL query like the following: But the security check can be bypassed by using the node field (that is available by default) on the root query type like that: This does not execute any security checks and can therefore be used to access any entity without restrictions by everyone that has access to the API. Impact Everyone using GraphQl with the security attribute. Not sure whereas this works with custom resolvers nor if this also applies on mutation. Patched at https://github.com/api-platform/core/commit/60747cc8c2fb855798c923b5537888f8d0969568
Recommended action: Upgrade to 4.1.5, 4.0.22 or 3.4.17 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Exception messages, that are not HTTP exceptions, are visible in the JSON error response. Details While we wanted to make our errors compatible with the JSON Problem specification, we ended up handling more exceptions then we did previously (introduced at https://github.com/api-platform/core/pull/5823). Instead of leaving that to Symfony, we ended up serializing errors with our normalizers which lead to not hiding the exception details. Note that the trace is hidden in production but the message is not, and the message can contain sensitive information. PoC At https://github.com/ili101/api-platform/tree/test3.2 it triggers an authentication exception as LDAP is not reachable. You can find the message available as a JSON response when trying to reach an endpoint. Impact Version 3.2 until 3.2.4 is impacted.
Recommended action: Upgrade to 3.2.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A security check that gets called after GraphQl resolvers is always replaced by another one as there's no break in this clause: https://github.com/api-platform/core/pull/6444/files#diff-09e3c2cfe12a2ce65bd6c983c7ca6bfcf783f852b8d0554bb938e8ebf5e5fa65R56 https://github.com/soyuka/core/blob/7e2e8f9ff322ac5f6eb5f65baf432bffdca0fd51/src/Symfony/Security/State/AccessCheckerProvider.php#L49-L57 PoC Create a graphql endpoint with a security after resolver. Impact As this fallsback to security, the impact is there only when there's only a security after resolver and none inside security. The test at https://github.com/api-platform/core/pull/6444 is probably broken.
Recommended action: Upgrade to 3.3.15 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Resource properties secured with the security option of the ApiPlatform\Metadata\ApiProperty attribute can be disclosed to unauthorized users. The problem affects most serialization formats, including raw JSON, which is enabled by default when installing API Platform. Custom serialization formats may also be impacted. Only collection endpoints are affected by the issue, item endpoints are not. The JSON-LD format is not affected by the issue. The result of the security rule is only executed for the first item of the collection. The result of the rule is then cached and reused for the next items. This bug can leak data to unauthorized users when the rule depends on the value of a property of the item. This bug can also hide properties that should be displayed to authorized users. Patches This issue impacts the 2.7, 3.0 and 3.1 branches. Upgrade to v2.7.10, v3.0.12 or v3.1.3. Workarounds Replace the cachekey of the context array of the Serializer inside a custom normalizer that…
Recommended action: Upgrade to 3.1.3, 3.0.12 or 2.7.10 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
API Platform version from 2.2.0 to 2.3.5 contains an Incorrect Access Control vulnerability in GraphQL delete mutations that can result in a user authorized to delete a resource can delete any resource. This attack appears to be exploitable via the user must be authorized. This vulnerability appears to have been fixed in 2.3.6.
Recommended action: Upgrade to 2.3.6 or 2.2.10 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.