Symfony Serializer ist von CVE-2026-118515 betroffen: Laut Symfony-Advisory vom 4. November 2026 konnte der Serializer aus Request-Daten UploadedFile-Objekte bauen, die auf beliebige vom PHP-Prozess lesbare Serverdateien zeigen. Betroffen sind Serializer-Versionen vor 5.4.56, ab 6 vor 6.4.50, ab 7 vor 7.4.23 und ab 8 vor 8.1.11. Fixes: 5.4.56, 6.4.50, 7.4.23 und 8.1.11.
Die Schwachstelle betrifft jede maintained Branch, sobald untrusted JSON oder Form-Daten in Typen mit einer UploadedFile-Property deserialisiert werden – einschließlich des in Symfony 8.1 üblichen Musters mit #[MapRequestPayload] und DTO. Ein Upload ist dafür nicht nötig. Dieser Artikel bleibt bei Impact und Upgrade-Hinweis aus dem Advisory; keine Exploit-Schritte, keine Payloads, keine reproduzierbaren Angriffsprozeduren.
Symfony Serializer: Was schiefging
DataUriNormalizer baute \SplFileInfo, \SplFileObject und HttpFoundation-File-Objekte aus Data-URIs – aber nur für genau diese Typen. Eine Property mit einer Subklasse wie UploadedFile landete beim ObjectNormalizer, der die Instanz über den Konstruktor aus denormalisierten Daten erzeugte – inklusive Pfad, Originalname und test-Flag. Damit konnte untrusted Input ein UploadedFile auf eine beliebige serverlesbare Datei zeigen.
Laut Advisory: Mit test: true überspringt UploadedFile::isValid() den Check is_uploaded_file(), und move() fällt auf rename() zurück. Code, der die Datei ohne isValid() liest, braucht das Flag nicht einmal. Je nach Anwendungslogik kann das lesbare Dateien exponieren (etwa wenn Uploads gespeichert und wieder ausgeliefert werden), Dateien verschieben, wenn move() wie in der Upload-Dokumentation aufgerufen wird, oder die Existenz eines Pfads verraten. Assert\File verhindert das nicht, weil die echte Serverdatei validiert wird.
Fix und geschützte Konfiguration
Nach dem Patch behandelt DataUriNormalizer jede Subklasse von \SplFileInfo: Erwartete Instanzen (wie Request-Dateien) werden durchgereicht; andere Daten lösen NotNormalizableValueException aus, die #[MapRequestPayload] in ein 422 wandelt. File, \SplFileInfo und \SplFileObject werden weiterhin aus Data-URIs gebaut, wenn der Typ als deren ::class-Konstante angegeben ist. Andere Schreibweisen (führender Backslash, andere Groß-/Kleinschreibung, Klassenalias) werden wie Subklassen behandelt.
Wichtig: Ein Serializer ohne DataUriNormalizer vor dem Object-Normalizer erhält diesen Schutz nicht. Der von FrameworkBundle konfigurierte Serializer hat ihn. Patches liegen für Branch 5.4 und 6.4 vor (forward-portiert auf 7.4, 8.1 und 8.2). Credits: Meldung Oliver Wenzel, Fix Nicolas Grekas; CVE-Hilfe Bruno Dias und Miguel Neves (Checkmarx).
Was Teams jetzt tun sollten
Sofort die Serializer-Komponente (oder das Framework-Metapaket) auf 5.4.56 / 6.4.50 / 7.4.23 / 8.1.11 oder neuer heben und Abhängigkeits-Locks prüfen. DTOs und Controller mit UploadedFile-Properties und #[MapRequestPayload] inventarisieren. Custom-Serializer-Stacks prüfen, ob DataUriNormalizer vor dem Object-Normalizer steht. Deployment und Changelog gegen die Advisory-Versionen abgleichen – kein Ersatz für einen vollständigen Security-Review, aber der dokumentierte Mindestschritt.
Verwandter November-Patch auf code404zero: Symfony HTTP Foundation – zwei Fixes November 2026 (3465). Eigenes Keyword und eigene CVE; gemeinsam Teil derselben Patch-Welle. Weitere Security-Kontexte: GPT-6 Cyber und Patch Gap / GLM 5.3 – andere Oberflächen, gleicher Upgrade-Druck.
Einordnung ohne Hype
Symfony Serializer CVE-2026-118515 ist eine Deserialisierungs-/Upload-Mapping-Lücke mit klarem Fix-Pfad. Das Advisory beschreibt Impact (Lesen/Verschieben lesbarer Serverdateien, Pfad-Existenz) und Resolution. code404zero veröffentlicht keine Reproduktionsschritte und keine Beispiel-Payloads über das hinaus, was das öffentliche Advisory selbst zur Problembeschreibung nennt.
Kurz: Am 4. November 2026 meldet Symfony CVE-2026-118515 am Serializer. Upgrade auf 5.4.56, 6.4.50, 7.4.23 oder 8.1.11; FrameworkBundle-Serializer nutzen bzw. DataUriNormalizer-Reihenfolge prüfen. Primärquelle: Symfony-Blog-Advisory.
Abgrenzung zur HTTP-Foundation-Welle
Die gestrigen HTTP-Foundation-Fixes und dieser Serializer-CVE teilen den November-2026-Zeitraum und die Symfony-Security-Pipeline, betreffen aber unterschiedliche Komponenten und Keywords. Wer beide Artikel liest, sollte Serializer-Versionen und HTTP-Foundation-Versionen getrennt tracken – ein Framework-Bump deckt oft beides ab, ein gezieltes Component-Update nicht immer. Changelog und composer show symfony/serializer / symfony/http-foundation bleiben die Wahrheitsquellen.
Für AppSec- und Platform-Teams: Ticket mit Advisory-URL, Zielversionen und Nachweis im Lockfile; Staging-Test der Upload-/DTO-Pfade nach dem Patch; Monitoring auf unerwartete 422 bei MapRequestPayload nach dem Fix ist erwartbar und erwünscht, wenn zuvor ungültige Payloads still akzeptiert wurden.
Praxis-Checkliste
1) Serializer auf Fixed-Versionen bringen. 2) Custom Normalizer-Order dokumentieren. 3) Alle UploadedFile-DTO-Mappings listen. 4) Mit HTTP-Foundation-November-Patches abstimmen. 5) Keine öffentlichen PoCs in Tickets spiegeln – Advisory-Link genügt. Damit bleibt Symfony Serializer CVE-2026-118515 ein Upgrade-Thema, kein Exploit-Leitfaden.
Komponenten-Upgrade vs. Framework-Bump
Viele Projekte pinnen symfony/serializer indirekt über symfony/framework-bundle oder das Metapaket symfony/symfony. Ein gezieltes Component-Update auf 5.4.56 / 6.4.50 / 7.4.23 / 8.1.11 reicht für CVE-2026-118515, wenn der geladene Serializer den gepatchten DataUriNormalizer enthält. Wer Normalizer manuell verdrahtet, muss die Reihenfolge explizit prüfen – FrameworkBundle-Default ist nicht automatisch jeder Custom-Container.
QA nach dem Patch: MapRequestPayload-Flows mit Datei-Properties in Staging anstoßen; erwarten, dass ungültige denormalisierte Dateistrukturen 422 liefern statt still ein UploadedFile zu erzeugen. Bestehende, legitime Uploads über echte Multipart-Requests sollten unverändert funktionieren, weil Request-Dateien als Instanz der erwarteten Klasse durchgereicht werden. Regressionen eher in Custom-Normalizern und in Code, der absichtlich test-UploadedFiles in Unit-Tests baut – Test-Doubles gegen den neuen Normalizer-Pfad abstimmen.
Dokumentation im Ticket: Advisory-URL, vorher/nachher composer show, Hinweis auf verwandten HTTP-Foundation-Artikel, ausdrücklicher Vermerk „kein PoC“. Damit bleibt die Behandlung von Symfony Serializer CVE-2026-118515 auditierbar und defensiv.
Warum das Keyword Serializer statt nur CVE-ID
Such- und Lesefluss: Entwickler suchen oft nach der Komponente plus „security“ oder „UploadedFile“, nicht nur nach der CVE-Nummer. Wir führen CVE-2026-118515 im Titel und Fließtext, halten Fokus-Keyword und H2 aber bei Symfony Serializer, parallel zum gestrigen HTTP-Foundation-Stück – klare Trennung ohne Cannibalization.
Wer Composer-Updates automatisiert: Security-Advisories von Symfony und Packagist-Meldungen in die CI-Pipeline legen, sodass Serializer unter den Fixed-Versionen den Build failen. Das ersetzt keinen manuellen Review Custom-Normalizer, verkürzt aber die Zeit bis zum Patch auf den Default-Stack. Nach dem Deploy Log-Noise auf 422 bei Payload-Mapping kurz beobachten und mit App-Teams teilen.
Kommunikationshinweis für Security- und Dev-Teams
Interne Advisories sollten die CVE-ID, die Fixed-Versionen und den Verweis auf den Symfony-Blog enthalten – ohne kopierte Request-Beispiele aus dem Advisory in öffentliche Channels zu spiegeln, wenn das die Angriffsfläche unnötig vergrößert. Für private Tickets reicht der Link. Entwickler, die MapRequestPayload neu einführen, lesen parallel die Upload-Dokumentation und den gepatchten Normalizer-Pfad. Symfony Serializer bleibt damit ein Patch-und-Verify-Thema: Version heben, Custom-Stack prüfen, Staging validieren, produktiv ausrollen.
