How severe is CVE-2026-54164?

CVE-2026-54164 has a CVSS score of 6.5/10, rated MEDIUM. Review your exposure and patch according to your risk tolerance.

Which packages are affected by CVE-2026-54164?

CVE-2026-54164 affects the following packages: api-platform/core (Packagist), api-platform/core (Packagist), api-platform/core (Packagist). Ecosystems affected: Packagist.

How do I fix CVE-2026-54164?

Update api-platform/core to 4.1.30 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-54164 is resolved across your whole dependency graph.

How do I detect CVE-2026-54164 in my Packagist dependencies?

Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for api-platform/core, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

How do I mitigate CVE-2026-54164 if there is no patch (or I can't update yet)?

If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

Is CVE-2026-54164 actively exploited in the wild?

No public exploit code has been indexed for CVE-2026-54164 yet. This does not mean the vulnerability cannot be exploited — absence of public exploits does not imply safety. Apply the recommended fix and use O3 Security to monitor your exposure.

What is the EPSS score for CVE-2026-54164?

CVE-2026-54164 has an EPSS (Exploit Prediction Scoring System) score of 0.3%, placing it in the 27th percentile of all CVEs. EPSS is maintained by FIRST.org and estimates the probability that a vulnerability will be exploited in the wild within the next 30 days. This score indicates relatively lower exploitation probability, though the CVSS severity should still guide your patching priority.

What type of vulnerability is CVE-2026-54164?

CVE-2026-54164 is classified as CWE-843 (CWE-843). This weakness type describe the underlying flaw category, which helps determine the potential impact and the right class of mitigation.

When was CVE-2026-54164 published, and has it been updated?

CVE-2026-54164 was published on July 1, 2026 and was last updated on October 28, 2026. Advisory data evolves as severity scores, affected ranges, and exploit intelligence are revised — always check the latest version of the advisory before acting.

🐘

🐘 Packagist

Not in CISA KEV

MEDIUM severity

CVE-2026-54164 — core

MEDIUMFix: api-platform/core@6bcbeb2

CVE-2026-54164 is a medium-severity (CVSS 6.5) CWE-843 vulnerability in api-platform/core. A fix is available for api-platform/core — see the affected versions and patch details below.

API Platform Core: Missing IRI type check enables resource type confusion

Also known asGHSA-9rjg-x2p2-h68h

Published

Jul 1, 2026

Updated

Oct 28, 2026

Affected

3 pkgs

Patched

3 / 3

Exploits

None indexed

Exploitation data as of Nov 4, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

Proof-of-concept exploit code exists

CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.

Exploitation and automatability from CISA’s SSVC triage for CVE-2026-54164.

EPSS Exploitation Probability

via FIRST.org ↗

0.3%probability of exploitation in next 30 days

Lower Risk0.00%

Lower risk than most CVEs27th percentile — riskier than 27% of all scored CVEsHighest risk

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

Where this sits among everything scored

Real-World Exposure

3 pkgs affected

🐘api-platform/core🐘api-platform/core🐘api-platform/core

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Packagist packages — download data is not available via public APIs for these ecosystems.

Description

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 is_a 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 is_a 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 is_a guard (operation-aware path)

Credit

Reported by @alexandre-daubois.

Affected Packages

3 total 3 fixed

Ecosystem	Package	Vulnerable range	Fix
🐘Packagist	`api-platform/core`	all versions	4.1.30`composer require api-platform/core:^4.1.30`
🐘Packagist	`api-platform/core`	≥ 4.2.0&&< 4.2.26	4.2.26`composer require api-platform/core:^4.2.26`
🐘Packagist	`api-platform/core`	≥ 4.3.0&&< 4.3.12	4.3.12`composer require api-platform/core:^4.3.12`

Detection & mitigation playbook

Open-source dependency

Detect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for api-platform/core, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update api-platform/core to 4.1.30 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-54164 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

Frequently Asked Questions

## 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 `is_a` type