API Platform CVE-2026-54164: Update-Pflicht jetzt

Update

17.09.2026: Das aktuelle Sicherheitsupdate für API Platform 4.x

Was Sie in 5 Minuten erfahren:

Warum CVE-2026-54164 speziell beschreibbare Relations trifft und wo genau der Type-Check fehlt
Wie Sie in wenigen Minuten prüfen, ob Ihr Projekt betroffen ist
Welcher Migrationspfad je nach eingesetzter API-Platform-Version sinnvoll ist

Ein stiller Fehler in der Serializer-Kette

Am 13. Juni 2026 veröffentlichte API-Platform-Maintainer soyuka die Advisory GHSA-9rjg-x2p2-h68h. Der Kern: Der Serializer prüft beim Auflösen von Relations-IRIs nicht, ob die referenzierte Ressource tatsächlich zur deklarierten Relation-Klasse passt. Wer eine beschreibbare Relation über POST, PUT oder PATCH befüllt, kann dort eine IRI eines völlig anderen Ressourcentyps eintragen, und API Platform akzeptiert das kommentarlos.

Betroffen sind die Versionsreihen unter 4.1.30, unter 4.2.26 sowie unter 4.3.12. Der Fix liegt in AbstractItemNormalizer: getResourceFromIri() übergab bislang keinen $operation-Parameter an IriConverter::getResourceFromIri(), wodurch der is_a-Typ-Guard in IriConverter.php Zeile 86 schlicht übersprungen wurde. Bei untypisierten Relation-Properties, wie sie in älteren, nur mit @var-Annotation versehenen Entities vorkommen, wird das falsch typisierte Objekt anschließend stillschweigend zugewiesen.

Kurz

Wer beschreibbare Relationen einsetzt und mit einer Version vor 4.1.30, 4.2.26 oder 4.3.12 arbeitet, hat eine ungeprüfte Typannahme im Serializer, die sich gezielt ausnutzen lässt.

Betrifft Sie das? Schnelltest in 30 Sekunden

Betrifft Sie das? Schnelltest in 30 Sekunden

Ja, sofort relevant wenn: Ihr Projekt API Platform Core in einer Version unter 4.1.30, 4.2.26 oder 4.3.12 einsetzt und Endpoints mit beschreibbaren Relationen über POST, PUT oder PATCH anbietet.

Auf dem Radar behalten wenn: Sie API Platform primär lesend nutzen oder Ihre Relations-Properties bereits konsequent typisiert sind, sodass PHP selbst einen TypeError wirft.

Geringeres Risiko wenn: Ihre API ausschließlich intern erreichbar ist und Schreibzugriffe strikt authentifiziert und autorisiert laufen, wobei das die Lücke nicht schließt, sondern nur die Angriffsfläche verkleinert.

Ist Ihre API tatsächlich exponiert?

Die Schwachstelle setzt voraus, dass ein Angreifer überhaupt Schreibrechte auf einen Endpoint mit beschreibbarer Relation hat. Das klingt nach einer hohen Hürde, ist es in der Praxis aber oft nicht. Viele API-Platform-Projekte vergeben Voter-basierte Berechtigungen granular pro Property, nicht pro Ressource, und genau dort öffnet sich die Lücke: Ein Nutzer mit Schreibrecht auf eine harmlos wirkende Relation kann eine Ressource eines anderen Typs einschleusen, auf die er eigentlich keinen Zugriff haben sollte.

Aus meiner Erfahrung mit Symfony-Projekten sind es gerade die gewachsenen Entities, bei denen Relation-Properties noch ohne strikte PHP-Typisierung auskommen, die hier am stärksten gefährdet sind. Ein häufiger Fehler, den ich in Audits sehe: Legacy-Entities aus Symfony-3-Zeiten wurden bei der API-Platform-Einführung übernommen, ohne die Property-Typen nachzuziehen.

🔍 Kommt Ihnen das bekannt vor?

Viele meiner Kunden standen vor genau dieser Herausforderung. In einem kostenlosen Erstgespräch analysiere ich Ihre Situation und gebe eine ehrliche Einschätzung.

Kostenloses Erstgespräch anfragen →

⏱️ Antwort binnen 24 Stunden

Was sich technisch ändert

Der Fix validiert die Ziel-Klasse einer Relations-IRI direkt bei der Denormalisierung. Statt die IRI blind aufzulösen und das Ergebnis zuzuweisen, prüft der Serializer nun, ob die aufgelöste Ressource tatsächlich zur erwarteten Klasse gehört, bevor sie in die Relation eingesetzt wird.

// Vorher: getResourceFromIri() ohne Operation-Kontext
$resource = $this->iriConverter->getResourceFromIri($iri);
// $resource wird zugewiesen, unabhängig vom deklarierten Typ

// Nachher: Operation wird durchgereicht, is_a-Guard greift
$resource = $this->iriConverter->getResourceFromIri(
$iri,
context: ['operation' => $operation]
);
// Type-Mismatch führt zu InvalidArgumentException

Bemerkenswert ist der zeitliche Kontext. API Platform 4.3 hatte am 13. März 2026 native MCP-Unterstützung eingeführt, ein Feature-Release mit viel Aufmerksamkeit. Security-Hygiene bleibt davon unberührt und braucht weiterhin eigene, wiederkehrende Prüfroutinen, unabhängig davon, wie viel Momentum ein Framework gerade auf der Feature-Seite hat.

Welcher Migrationspfad ist der richtige?

Das Update selbst ist ein reines Patch-Release ohne Breaking Changes. Wer auf 4.1.x, 4.2.x oder 4.3.x unterwegs ist, aktualisiert innerhalb der jeweiligen Minor-Version:

composer show api-platform/core
composer update api-platform/core --with-all-dependencies

Die eigentliche Arbeit liegt nicht im Composer-Update, sondern in der Nachkontrolle: Welche Ihrer Relation-Properties sind untypisiert, und welche Endpoints erlauben Schreibzugriff auf Relationen, deren Berechtigungslogik Sie zuletzt vor längerer Zeit geprüft haben? Das lässt sich nicht pauschal beantworten, denn es hängt vom gewachsenen Datenmodell jedes einzelnen Projekts ab.

Bei API Platform mit mehreren Bounded Contexts oder komplexeren Voter-Hierarchien wird die Prüfung schnell aufwändiger, als der reine Patch vermuten lässt. Wer zusätzlich Custom Normalizer im Einsatz hat, die den Standard-Denormalisierungspfad umgehen oder erweitern, sollte diese gesondert gegen die Advisory prüfen, da der offizielle Fix nur den Core-Pfad abdeckt.

KurzDas Composer-Update ist in Minuten erledigt. Die Prüfung von untypisierten Relations und Voter-Berechtigungen im eigenen Datenmodell braucht deutlich mehr Zeit.

⚡ Unterstützung bei der Umsetzung?

Ich unterstütze KMU und Agenturen bei PHP- und Symfony-Projekten – von der Architektur bis zum Go-Live.

Erfahrener PHP & Symfony-Entwickler
Transparente Kommunikation & faire Konditionen
Remote oder vor Ort im Raum Oldenburg

Projekt besprechen →

⏱️ Antwort binnen 24 Stunden

📞 Oder direkt anrufen: 04481 - 9099658

Aus der Praxis

Was mir bei Code-Reviews und Einarbeitungen in Bestandssysteme häufig begegnet:

In gewachsenen API-Platform-Projekten, die ich zur Übernahme oder für ein Audit prüfe, finde ich regelmäßig Relation-Properties ohne strikten PHP-Typ, meist aus einer Zeit, in der das Projekt noch auf ältere PHP-Versionen ohne konsequente Typisierung ausgelegt war. Diese Stellen fallen bei einem normalen Funktionstest nicht auf, weil die API im Alltagsbetrieb korrekt bediente Requests bekommt. Erst ein gezielter Blick auf die Voter-Konfiguration pro Relation zeigt, wo Schreibrechte großzügiger vergeben sind, als das Datenmodell eigentlich verträgt.

Wie geht es weiter?

Technische Einordnungen wie diese veröffentliche ich regelmäßig. Folgen Sie mir auf LinkedIn für Updates.

Sie möchten wissen, ob Ihr API-Platform-Projekt betroffen ist? Kostenloser Audit-Check für Symfony- und API-Platform-Projekte.

Sie wissen bereits, was Ihr Projekt braucht. Lassen Sie uns den nächsten Schritt klären.

Dennis Schwenker-Sanders ist PHP- und Symfony-Entwickler mit Fokus auf API-Platform-Projekte und Legacy-Übernahmen für kleine Agenturen und KMU.

#API Platform #Cybersecurity #Symfony #Schwachstelle

Häufige Fragen

Ist meine API betroffen, wenn ich nur GET-Endpoints anbiete?

Nein, die Schwachstelle setzt schreibende Requests voraus. Rein lesende API-Platform-Konfigurationen sind von CVE-2026-54164 nicht betroffen, ein Update auf die gepatchten Versionen bleibt trotzdem sinnvoll.

Reicht es, nur die Relation-Properties zu typisieren?

Eine strikte Typisierung mildert das Risiko, da PHP selbst einen TypeError wirft, wenn die Zuweisung nicht passt. Sie ersetzt aber nicht das offizielle Update, da der zugrunde liegende fehlende Type-Guard im IriConverter bestehen bleibt.

Betrifft die Lücke auch GraphQL-Mutations?

Der Denormalisierungspfad wird auch von GraphQL-Mutations durchlaufen, die Advisory selbst nennt primär REST-Schreibzugriffe. Wer GraphQL aktiv nutzt, sollte die Mutation-Inputs zusätzlich gegen die Advisory prüfen.

Muss ich bei einem Update von 4.1 auf 4.2 mit Breaking Changes rechnen?

Das Security-Update selbst ist ein Patch-Release ohne Breaking Changes innerhalb der jeweiligen Minor-Version. Ein Sprung über Minor-Versionen hinweg, etwa von 4.1 auf 4.3, sollte trotzdem gegen das offizielle Upgrade-Log geprüft werden.

Artikel teilen:

API Platform CVE-2026-54164: Warum jetzt auf 4.2.26 bzw. 4.3.12 aktualisiert werden muss