CVE-2026-54164: API Platform Type Confusion in Relation IRI Resolution

Technical summary

The vulnerability exists in API Platform's AbstractItemNormalizer serializer component, specifically in how it resolves relation IRIs (internationalized resource identifiers). When getResourceFromIri() is invoked to retrieve a related resource, it bypasses the type-guard check normally enforced by IriConverter because no $operation parameter is passed. This allows CWE-843 (type confusion) to occur. For legacy, untyped relation properties (using only @var documentation), a wrongly-typed object is silently assigned to the relation. For modern typed properties (PHP 8.x), Symfony's PropertyAccessor may block the assignment with an InvalidTypeException, providing some defense-in-depth. An authenticated attacker with write permissions can craft a PATCH, POST, or PUT request containing a crafted relation IRI pointing to a resource of a different class than the relation declares, violating application invariants.

Business impact

Successful exploitation corrupts the logical structure of managed data, potentially leading to downstream failures. Depending on application logic, this could result in incorrect business rule enforcement, data model inconsistency, financial calculations or permissions decisions made on mistyped data, or triggering of unintended workflows. The impact is containable if the application uses modern typed properties (PHP 8.x), which will raise exceptions and prevent silent corruption. Legacy codebases using only @var documentation are at higher risk of silent data integrity violations. Regulatory or compliance contexts (healthcare, finance, fintech) may face audit findings if corrupted records are discovered.

Affected systems

API Platform versions prior to 4.1.30, 4.2.26, and 4.3.12 are affected. Organizations running API Platform should verify their deployment version against these thresholds. No vendor-specific products are named, but any custom or commercial API built on API Platform framework is potentially in scope. The vulnerability requires authenticated write access, so public or unauthenticated endpoints are not directly exploitable without first obtaining valid credentials.

Exploitability

The vulnerability requires an authenticated attacker (CVSS:3.1 PR:L) with write permissions to at least one API endpoint. No special user interaction is needed (UI:N), and the attack is straightforward—craft a relation IRI pointing to a mismatched resource type in a write request. The attack surface is moderate: any writable relation property in any API Platform endpoint accessible to an authenticated user is a potential vector. Threat actors with compromised API credentials or insider access could exploit this. The barrier to exploitation is low from a technical standpoint; no complex exploit code or timing attacks are required.

Remediation

Upgrade to API Platform version 4.1.30, 4.2.26, or 4.3.12 or later, depending on your current version line. For versions 4.1.x, upgrade to 4.1.30 or newer. For 4.2.x, upgrade to 4.2.26 or newer. For 4.3.x, upgrade to 4.3.12 or newer. Consult the official API Platform release notes to confirm your target version includes the fix. Test upgrades in a staging environment before production rollout to ensure compatibility with custom extensions or overridden serializers.

Patch guidance

Patches are available in API Platform 4.1.30, 4.2.26, and 4.3.12. Review the official API Platform GitHub repository and release notes for exact patch content and upgrade instructions. The fix addresses the root cause by ensuring that getResourceFromIri() properly validates resource type against the declared relation type before assignment. If you maintain a fork or custom serializer, ensure your override also implements proper type validation. Consider setting up automated dependency monitoring (e.g., Dependabot, Renovate) to alert on new releases and security advisories.

Detection guidance

Monitor API request logs for PATCH, POST, and PUT requests that include relation IRIs pointing to resources of unexpected types. This may appear as mismatches between declared and actual resource class names in IRI parameters. Application logs or database audit trails may reveal unexpected object type assignments to relation properties. In legacy codebases without typed properties, silently-corrupted records may only surface downstream when business logic fails or data quality checks are run. Implement typed properties (PHP 8.x) where possible to enable PropertyAccessor to throw InvalidTypeException, which will surface type-confusion attempts in error logs. Conduct data integrity audits on production systems running unpatched versions to identify corrupted relation assignments.

Why prioritize this

This vulnerability merits timely patching despite CVSS 6.5 (Medium) because it directly undermines data model integrity in applications that serve as data systems of record. Data corruption, even when caught by type checking, can cascade through downstream systems. The vulnerability requires authentication but affects any organization where API users or service accounts have write access. Organizations using older PHP patterns or legacy codebases (no typed properties) face higher risk of silent data corruption. Patch urgency is highest for financial, healthcare, or e-commerce APIs where data integrity directly impacts business logic and regulatory compliance.

Risk score, explained

The CVSS 3.1 score of 6.5 (Medium) reflects: (1) Network-accessible attack surface (AV:N); (2) Low attack complexity—no special conditions required (AC:L); (3) Requirement for authenticated access (PR:L), ruling out unauthenticated abuse; (4) No confidentiality impact (C:N)—the attacker is not reading secrets; (5) High integrity impact (I:H)—data model invariants are violated; (6) No availability impact (A:N)—the service remains operational. The score appropriately penalizes the integrity breach but acknowledges the authentication barrier and lack of availability or confidentiality impact. In environments where write access is restricted to trusted service accounts or internal APIs, practical risk may be lower; in open ecosystems with broad API access, risk approaches higher end of the Medium range.

Frequently asked questions