GHSA-9rjg-x2p2-h68h: Medium severity composer/api-platform/core vulnerability

Published Aug 7, 2026
·
Updated

Summary

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 < 4.1.30 - api-platform/core >= 4.2.0, < 4.2.26 - api-platform/core >= 4.3.0, < 4.3.12

Older major series (2.x, 3.x) ship the same vulnerable code path and are end-of-life; no fix is planned.

Patched versions

- 4.1.30 - 4.2.26 - 4.3.12

Fix

An isa guard is added inside AbstractItemNormalizer::getResourceFromIri() (and the equivalent inline call sites on 4.1) so that a mismatched IRI throws InvalidArgumentException, mirroring the operation-aware check the IriConverter already performs when an operation is supplied. This forces a 400 Bad Request response for cross-type IRIs instead of a silent assignment.

Workarounds

Declare a PHP type on every writable relation property (e.g. public ?Foo $relation = null; instead of @var Foo $relation). Symfony's PropertyAccessor will then reject a mismatched object with InvalidTypeException. This does not cover collections of mixed-type interfaces; upgrading to a patched version is the only complete fix.

Proof of concept

A functional test posts a Bar IRI to a Foo-declared relation on an untyped property. Without the fix the server responds with HTTP 201 and the Bar IRI appears in the response payload. With the fix the server responds with HTTP 400 (Invalid IRI "/bars/1").

Full PoC: tests/Functional/Security/TypeConfusionRelationIriTest.php in the patched branches.

References

- src/Serializer/AbstractItemNormalizer.php — vulnerable relation IRI load - src/Symfony/Routing/IriConverter.php — conditional isa guard (operation-aware path)

Credit

Reported by @alexandre-daubois.

Affected Software

3 affected componentsFixes available
composer/api-platform/core>=4.3.0<4.3.12
4.3.12
composer/api-platform/core>=4.2.0<4.2.26
4.2.26
composer/api-platform/core<4.1.30
4.1.30

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade composer/api-platform/core to a version that resolves this vulnerability.

    Fixed in 4.3.12
  2. Upgrade

    Upgrade composer/api-platform/core to a version that resolves this vulnerability.

    Fixed in 4.2.26
  3. Upgrade

    Upgrade composer/api-platform/core to a version that resolves this vulnerability.

    Fixed in 4.1.30
  4. Upgrade

    Upgrade api-platform/core to a version that resolves this vulnerability.

    Fixed in 4.1.30
  5. Upgrade

    Upgrade api-platform/core to a version that resolves this vulnerability.

    Fixed in 4.2.26
  6. Upgrade

    Upgrade api-platform/core to a version that resolves this vulnerability.

    Fixed in 4.3.12
  7. Configuration

    Ensure every writable relation property has an explicit PHP type declaration so Symfony PropertyAccessor rejects mismatched objects with `InvalidTypeException` (mitigation described for untyped `@var`-only relation properties).

    PHP (typed properties on API Platform writable relation fields) Type declaration for writable relation properties = Declare a PHP type on every writable relation property (e.g., use `public ?Foo $relation = null;` instead of `@var Foo $relation`).

Event History

Aug 7, 2026
Advisory Published
via GitHub·04:54 PM
Data Sourced
via GitHub·04:54 PM
DescriptionSeverityWeaknessAffected Software
Free Weekly Intel

Don't miss critical vulnerabilities

Join thousands of security professionals who receive our weekly digest of trending CVEs, zero-days, and exploited vulnerabilities.

No spam. Unsubscribe anytime.

Frequently Asked Questions

1

What is the severity of GHSA-9rjg-x2p2-h68h?

The severity of GHSA-9rjg-x2p2-h68h is medium with a score of 6.5.

2

How do I fix GHSA-9rjg-x2p2-h68h?

To fix GHSA-9rjg-x2p2-h68h, update to the latest version of the composer/api-platform/core package that resolves this vulnerability.

3

What are the potential impacts of GHSA-9rjg-x2p2-h68h?

The potential impacts of GHSA-9rjg-x2p2-h68h include type confusion, allowing unintended resource types to be assigned to relation properties.

4

Who is affected by GHSA-9rjg-x2p2-h68h?

Any application using the composer/api-platform/core package without the latest security updates may be affected by GHSA-9rjg-x2p2-h68h.

5

When was GHSA-9rjg-x2p2-h68h published?

GHSA-9rjg-x2p2-h68h was published on August 7, 2026.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203