API Platform Core CVE-2026-54164

Exploitation requires the attacker to hold a low-privilege authenticated account capable of submitting POST, PUT, or PATCH requests to an API Platform endpoint that declares at least one writable relation property. The decisive condition for silent data corruption is that the targeted relation property must be declared using the legacy PHP @var docblock annotation without a PHP 8.x native type declaration - properties with strict PHP 8.x types are partially protected by Symfony's PropertyAccessor throwing InvalidTypeException. The attacker must also know or enumerate valid IRIs for resources of the wrong type (typically discoverable via the API's hypermedia controls or collection endpoints). Exploitation is limited to data integrity corruption; there is no confidentiality or direct code execution impact. Non-default configurations that restrict writable relation fields or that enforce strict PHP 8.x typing throughout the data model significantly reduce exploitability.

The NVD CVSS 3.1 score of 6.5 (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N) is well-calibrated for this vulnerability: network-reachable, low complexity, requiring only low-privilege write access, with high integrity impact and no confidentiality or availability impact. This is a credible risk for any API Platform deployment that exposes writable relation endpoints to non-admin authenticated users. There is no CISA KEV listing and no public exploit code referenced at time of analysis, so active exploitation is unconfirmed. EPSS data was not provided in the available intelligence. The practical blast radius is gated by two factors: the attacker must hold write access to an affected endpoint, and the full silent-corruption path only applies to legacy untyped @var-style properties - PHP 8.x typed properties receive partial protection from Symfony's PropertyAccessor. Downstream impact is application-dependent: if business logic downstream trusts the declared relation type for authorization or processing decisions, a type-confused object could subvert those checks. This is a real priority for API Platform deployments using legacy PHP typing patterns, but lower urgency for modern PHP 8.x codebases.

An authenticated API user with write access submits a PATCH request to an endpoint exposing a writable untyped relation property - for example, an order's customer field expecting a User IRI - and instead supplies the IRI of an unrelated Product resource. Because the is_a guard is bypassed, the normalizer silently assigns the Product object to the customer property, corrupting the order record. Downstream business logic that assumes customer is always a User (e.g., authorization checks, invoice generation) then operates on the wrong object type, potentially bypassing guards or triggering undefined behavior. No public POC is known, but the attack requires only standard HTTP write access and knowledge of valid resource IRIs.