Symfony 8.0 EOL am 31. Juli: Was das Security Release zeigt

Am 31. Juli 2026 läuft der Support für Symfony 8.0 aus. Ab August gibt es keine Security-Updates mehr für diesen Branch. Das wäre noch händelbar, wenn der letzte Patch vor dem EOL-Datum eine ruhige Angelegenheit wäre. Er war es nicht. Symfony 5.4.53 / 6.4.41 / 7.4.13 / 8.0.13 schlossen Ende Mai 2026 sieben CVEs, darunter einen SSRF-Vektor in HttpClient und HttpFoundation, der IPv6-Transition-Adressen nicht als private Adressen erkannte.

Wer auf Symfony 8.0 läuft, hat bereits 8.0.14 als letzten Patch eingespielt oder sollte es jetzt tun. Der 31. Juli ist kein Stichtag für Panik, sondern für einen klaren Plan. Der Upgrade auf 8.1 ist kein Major-Wechsel. Die Arbeit ist überschaubar. Aber wer den EOL-Termin verschläft, betreibt ab August einen Symfony-Stack ohne Security-Patches. Der Zeitraum zwischen dem ersten ungepatchten CVE und seiner Ausnutzung ist kürzer als viele denken.

CVE-Übersicht: Security-Fixes Ende Mai / Juni 2026

Warum CVE-2026-48736 der kritischste Fund ist

IPv6-Transition-Adressen wie ::ffff:127.0.0.1 sind IPv4-gemappte IPv6-Adressen. Sie zeigen auf dasselbe Ziel wie 127.0.0.1, wurden aber von NoPrivateNetworkHttpClient nicht als privat erkannt. Das bedeutete: Wer User-supplied URLs an den Symfony HttpClient weitergab und dabei NoPrivateNetworkHttpClient als Schutz einsetzte, hatte eine Umgehungsmöglichkeit im System.

SSRF (Server-Side Request Forgery) erlaubt es einem Angreifer, den Server dazu zu bringen, interne Ressourcen abzufragen, die von außen nicht erreichbar sein sollten. Interne APIs, Datenbank-Management-Interfaces, Cloud-Metadata-Endpoints (AWS: 169.254.169.254). Der Attack-Vector ist besonders relevant für Symfony-Apps, die Webhook-URLs entgegennehmen, Link-Previews generieren oder Proxy-Funktionen bieten.

// Das Problem: IPv6-Transition-Adresse umging den Filter
use Symfony\Component\HttpClient\NoPrivateNetworkHttpClient;

$client = new NoPrivateNetworkHttpClient($innerClient);

// Diese URL hätte blockiert werden sollen – wurde es nicht:
$response = $client->request('GET', 'http://[::ffff:127.0.0.1]/internal-api');
// ::ffff:127.0.0.1 entspricht 127.0.0.1, war aber nicht als privat erkannt

// Nach dem Patch: auch IPv6-Transition-Adressen werden erkannt

Was die Dokumentation dazu nicht explizit erwähnt: Die Schwachstelle betrifft nicht nur direkte IPv6-Adressen in URLs, sondern auch DNS-Auflösungen, die IPv6-Transition-Adressen zurückgeben. Ein Angreifer kontrolliert nicht nur die URL, sondern kann in manchen Setups auch die DNS-Auflösung beeinflussen.

Was bedeuten die HtmlSanitizer-CVEs?

CVE-2026-48761 und CVE-2026-48760 betreffen den HtmlSanitizer, der in Symfony-Projekten für das Bereinigen von User-generiertem HTML eingesetzt wird. Zwei separate Lücken:

Erstens, URL-Attribute wurden nicht vollständig auf gefährliche Schemas geprüft. Ein javascript:-URL in einem href-Attribut konnte in bestimmten Konfigurationen durchkommen. Zweitens, BiDi-Steuerzeichen (Bidirektionale Unicode-Zeichen) wurden nicht herausgefiltert. Diese Zeichen können dazu genutzt werden, dargestellten Text optisch anders erscheinen zu lassen als er im Code steht — ein bekanntes Muster für Social-Engineering-Angriffe in CMS-Umgebungen.

Wer den HtmlSanitizer für CMS-Inhalte, Kommentarsysteme oder E-Mail-Vorschaufelder einsetzt, sollte diesen Patch höher priorisieren als es die Schwere-Einstufung auf den ersten Blick vermuten lässt.

Was der Upgrade von 8.0 auf 8.1 konkret erfordert

Der Upgrade-Pfad von Symfony 8.0 auf 8.1 ist kein Major-Wechsel. Es gibt keine großen Breaking Changes für Standard-Symfony-Projekte. Die wichtigste Voraussetzung: PHP 8.4 ist für Symfony 8.1 erforderlich. Wer noch auf PHP 8.3 läuft, muss zuerst den PHP-Upgrade planen.

# Schritt 1: Aktuelle Symfony-Version prüfen
$ composer show symfony/symfony | grep versions

# Schritt 2: Deprecation-Warnings in 8.0 bereinigen
# (werden in 8.1 zu Errors)
$ composer require --dev symfony/phpunit-bridge
$ bin/phpunit --deprecations

# Schritt 3: Rector-Set symfony81 anwenden
$ composer require rector/rector --dev
# rector.php: SetList::SYMFONY_81 hinzufügen
$ vendor/bin/rector process --dry-run

# Schritt 4: Update durchführen
$ composer update "symfony/*" --with-all-dependencies

# Schritt 5: Security-Audit nach Update
$ composer audit

Was in der Praxis mehr Aufwand macht als erwartet: Drittanbieter-Bundles. Wer proprietäre oder wenig gewartete Symfony-Bundles einsetzt, wird beim composer update auf Constraint-Konflikte stoßen. Der Schritt "alle Bundles auf 8.1-Kompatibilität prüfen" sollte vor dem Upgrade-Termin stehen, nicht danach.

Der Rector-Ansatz funktioniert gut für den PHP- und Symfony-eigenen Code. Er deckt Bundle-Inkompatibilitäten nicht ab. Für jede externe Abhängigkeit mit einem symfony/framework-bundle: ^8.0-Constraint braucht es entweder ein Update des Packages oder eine alternative Lösung.

Wie ich im Symfony-8.1-Artikel beschrieben habe, bringt 8.1 neben dem Security-Fix auch echte Feature-Ergänzungen, die den Upgrade zusätzlich sinnvoll machen. Console Argument Resolvers, ServicesBundle, DeepCloner. Der Upgrade ist keine reine Pflichtübung.

Was passiert wenn man auf 8.0 bleibt?

Ab dem 1. August 2026 gibt es keine Security-Patches mehr für den Symfony 8.0 Branch. Wenn in Symfony 8.1 eine Schwachstelle gefunden wird, die auch 8.0 betrifft, erscheint kein Backport-Patch. Das ist die konkrete Konsequenz des EOL-Status.

Für Kundenprojekte bedeutet das: Wer Symfony-Projekte für Kunden betreibt oder wartet, hat ab August einen ungepatchten Stack. Ob das ein akutes Risiko ist, hängt vom Angriffspotenzial der Applikation ab, aber die Grundlage für eine fundierte Risikoabschätzung ist ab August nicht mehr gegeben, weil keine CVE-Patches mehr erscheinen.

Wer den Upgrade auf 8.1 bis Juli nicht schafft, sollte zumindest kurzfristig auf Symfony 7.4 LTS wechseln. 7.4 hat Long-Term-Support bis November 2029 und bekommt Security-Updates deutlich länger. Der Sprung von 8.0 auf 7.4 ist eine Rückwärtsmigration und damit nicht trivial, aber als Notbremse relevant wenn 8.1 wegen PHP-8.4-Anforderungen nicht kurzfristig machbar ist.

Was der aktuelle Stand vom 27. Juni bringt

Am 27. Juni erschienen Symfony 8.1.1, 8.0.14 und 7.4.14. Keine neuen CVEs in diesem Release, aber ein Fix der direkt an das Thema dieses Artikels anschließt: IpUtils::PRIVATE_SUBNETS wurde um RFC6598 Shared Address Space (100.64.0.0/10, der Carrier-Grade-NAT-Bereich) erweitert.

Das ist derselbe Mechanismus, der bei CVE-2026-48736 versagt hat, nur ein anderer Adressbereich. RFC6598 wird von vielen Mobilfunk- und Cloud-Providern für internes Carrier-Grade-NAT genutzt und war bisher nicht in der Private-Subnet-Liste enthalten. Kein CVE, weil kein öffentlicher Exploit-Pfad bekannt wurde, aber dieselbe Kategorie Lücke wie der Hauptfund.

# Aktuellen Stand direkt installieren, kein Zwischenschritt nötig:
$ composer require symfony/symfony:^8.1.1   # oder ^8.0.14 auf dem 8.0-Branch
$ composer require symfony/symfony:^7.4.14  # auf 7.4 LTS

Für morgen veröffentlichte Artikel oder Audits: Der 27.-Juni-Stand ist der richtige Referenzpunkt. Wer jetzt upgraded, sollte direkt auf 8.1.1 gehen und nicht auf einer Zwischenversion stehen bleiben.

Aus der Praxis: Was Symfony-Upgrades in Agenturprojekten verzögert

Für den 8.0-auf-8.1-Upgrade gilt das genauso. Composer zeigt die Constraint-Konflikte, aber er löst sie nicht. Jeder Konflikt braucht eine Entscheidung: Bundle updaten, alternatives Bundle suchen, oder Bundle durch eigenen Code ersetzen. Diese Entscheidungen dauern in der Regel länger als der eigentliche Upgrade.

Zusammenfassung

Symfony 8.0 EOL: 31. Juli 2026. Ab August keine Security-Patches mehr. Die sieben CVEs sind seit 8.0.13 geschlossen, aktueller Stand ist 8.0.14 (27. Juni) mit einer zusätzlichen Härtung der Private-Subnet-Prüfung um RFC6598.

Sieben CVEs im Juni-Release. CVE-2026-48736 ist der kritischste Fund: NoPrivateNetworkHttpClient war via IPv6-Transition-Adressen umgehbar. Betrifft jeden, der User-supplied URLs an den HttpClient weitergibt.

Upgrade 8.0 → 8.1: Kein Major-Wechsel, aber PHP 8.4 ist Pflicht. Drittanbieter-Bundles sind der realistische Zeitfaktor. Rector-Set symfony81 automatisiert den Framework-Code, deckt Bundle-Inkompatibilitäten nicht ab.

Wenn 8.1 nicht rechtzeitig machbar ist: Symfony 7.4 LTS als Notbremse, Support bis November 2029.