CVE-2026-54164: Missing IRI Type Validation in API Platform Core Enables Resource Type Confusion

API Platform Core is a widely adopted PHP framework designed to build hypermedia-driven REST and GraphQL APIs. One of its key capabilities is handling relational structures via Internationalized Resource Identifiers (IRIs). During write requests such as POST, PUT, or PATCH, the framework parses these incoming identifiers and resolves them to active database entity instances.

This vulnerability, tracked as CVE-2026-54164, lies within the deserialization routine of relations in the AbstractItemNormalizer. When parsing external representation payloads, the class resolves relation values through an IRI converter. However, it fails to perform an essential class-matching assertion on the retrieved entity, creating a path for type confusion.

The attack surface exists on all writable endpoints that accept links or associations to other entities. If an application utilizes looser PHP constructs like untyped variables, this failure to validate types leads to silent assignment of mismatched entities into relational slots. This bypasses the structural assumptions established in database models and business logic.

To map an IRI such as /api/foos/1 back to a PHP entity, the serializer's AbstractItemNormalizer invokes IriConverter::getResourceFromIri(). By design, the IriConverter class possesses a type-checking check via the is_a() function to confirm compatibility with the target resource class. Crucially, this type-checking condition only fires if an explicit operational context is supplied to the converter.

In vulnerable versions of API Platform Core, both the AbstractItemNormalizer::getResourceFromIri() and AbstractItemNormalizer::denormalizeRelation() methods request entity resolution without providing this vital operation argument. Because of this omission, the validation routines within the converter are completely skipped during standard deserialization of related resources.

When a mismatched IRI is supplied, the serializer relies on Symfony's PropertyAccessor component to assign the resolved object to the parent model. If the property uses modern PHP native types, Symfony's accessor triggers an exception and aborts. However, if the property is untyped or relies strictly on PHPDoc annotations, the PHP engine silently permits the assignment, resulting in type confusion.

Comparing the vulnerable implementation against the patched codebase illustrates the type validation failure. In vulnerable iterations of src/Serializer/AbstractItemNormalizer.php, the IRI resolution was executed with no secondary type verification.

// Vulnerable Implementation
private function getResourceFromIri(string $data, array $context, string $resourceClass): ?object
{
    try {
        // The resolved object is returned directly without validating its type against $resourceClass
        return $this->iriConverter->getResourceFromIri($data, $context + ['fetch_data' => true]);
    } catch (ItemNotFoundException $e) {
         // ...
    }
}

The corresponding fix introduces an explicit assertion directly inside the normalizer. This ensures that even when the underlying IRI converter does not enforce type validation, the deserialization loop halts on type mismatches.

// Patched Implementation
private function getResourceFromIri(string $data, array $context, string $resourceClass): ?object
{
    try {
        $item = $this->iriConverter->getResourceFromIri($data, $context + ['fetch_data' => true]);
 
        // Explicit type-confusion guard added in the patch
        if (!is_a($item, $resourceClass)) {
            throw new InvalidArgumentException(\sprintf('The iri "%s" does not reference the correct resource.', $data));
        }
 
        return $item;
    } catch (ItemNotFoundException $e) {
         // ...
    }
}

This implementation uses is_a() to perform the verification. This ensures that polymorphically compatible models, such as subclasses of the target relation, continue to deserialize correctly while rejecting unrelated types.

An attacker seeking to exploit this flaw first performs passive reconnaissance on the API to map write-enabled endpoints that contain object relations. If an endpoint accepts relation writes but maps them to properties without strict PHP type declarations, it is highly susceptible to this attack.

To perform the injection, the attacker constructs a payload targeting a valid entity, such as Target. The Target model expects a relation pointing to a class of type Foo. However, the attacker replaces the IRI with a reference to class Bar, pointing to /type-confusion/bars/1.

Upon submission, the normalizer processes the request. Because the internal validation guard is missing, the normalizer deserializes the Bar instance and successfully binds it to the parent property. The target application then persists the state or forwards the model to downstream domain operations, where the presence of the unexpected type triggers logical errors.

The severity of CVE-2026-54164 is scored at 6.5 (Medium) using the CVSS v3.1 scoring standard. The attack vector is Network, execution complexity is low, and privileges required are low, meaning any authenticated client authorized to interact with the API can trigger the issue.

The integrity impact of this vulnerability is classified as High. By causing type confusion, an attacker can substitute sensitive reference models with irrelevant or unauthorized models, violating business rules and data constraints. If the system relies on entity types to execute state changes, this confusion could lead to security control bypasses.

No direct evidence suggests active exploitation of this flaw in the wild. Its EPSS score sits at a low 0.00195, suggesting limited automated targeting. However, because applications relying on legacy structures fail silently, the vulnerability poses a silent threat to legacy PHP applications.

The most robust remediation is to upgrade API Platform Core to a patched release. The fix is available in versions 4.1.30, 4.2.26, and 4.3.12. Upgrading is performed via Composer by running composer update api-platform/core.

As a critical defensive practice, developers must migrate legacy codebase elements away from loose variable declarations. Properties must use native PHP strict types rather than relying solely on PHPDoc annotations. This forces Symfony's PropertyAccessor to reject type-mismatched assignments natively, creating a fallback security barrier.

// Secure configuration using strict typing
class Target
{
    // Strictly typed property naturally blocks assignment of mismatched classes
    public ?App\Entity\Foo $relation = null;
}

Additionally, applications that implement custom serializers should ensure they explicitly validate all objects returned from the IRI converter against their expected target classes. Static analysis tools, such as PHPStan or Psalm, should be integrated into continuous deployment pipelines to discover and enforce strict property type-hints across entity schemas.