Symfony HTTP Foundation hat am 4. November 2026 zwei Security-Advisories von Fabien Potencier erhalten – beide mit denselben Fix-Versionen. Es geht um generierte URLs, die auf einen vom Client gewählten Host zeigen können, und um Path-Regeln vor PHP, die sich durch Anhängen eines Pfads an den Script-Namen umgehen lassen. Primärquellen sind die Symfony-Blogposts zu GHSA-5mx8-mwrp-5693 und GHSA-3h27-hjv7-fqjx.
Behoben in Symfony HTTP Foundation 5.4.56, 6.4.50, 7.4.23 und 8.1.11. Betreiber sollten beide Advisories als ein Upgrade-Paket behandeln: gleiche Komponentenfamilie, gleicher Patch-Stand, zwei unterschiedliche Angriffsflächen. Die empfohlene Symfony-Dokumentations-Konfiguration ist laut erstem Advisory nicht betroffen; trotzdem lohnt der Versionscheck.
Symfony HTTP Foundation: Host in generierten URLs (GHSA-5mx8-mwrp-5693)
Wenn Request::getBaseUrl() den Script-Namen nicht am Anfang der Request-URI findet, sucht es weiter im Pfad – sinnvoll für Front Controller in Unterverzeichnissen. Dabei konnte der Client den Präfix beeinflussen. Eine Request-URI, die mit // oder /\ beginnt, ließ die Base-URL mit einem Host starten. Folgen laut Advisory: mit path() gebaute Links und Form-Actions, Redirects wie redirectToRoute() sowie relativ referenzierte Assets über asset() konnten auf einen Angreifer-Host zeigen.
Betroffen sind Versionen <5.4.56, ≥6 und <6.4.50, ≥7 und <7.4.23, ≥8 und <8.1.11. Anwendungen sind betroffen, wenn der Front Controller in einem Unterverzeichnis liegt und der Webserver URIs ohne dieses Verzeichnis-Präfix durchreicht – etwa per Root-.htaccess, das alles nach public/ umschreibt. Auch Konfigurationen, die SCRIPT_NAME auf den Request-Pfad setzen (manche nginx-Setups ohne fastcgi_split_path_info, php -S mit Router außerhalb des Document Roots), sind genannt. framework.trusted_hosts hilft laut Advisory nicht, weil der Request-Host der echte bleibt. Fix: leere Base-URL, wenn die URI mit // oder /\ beginnt.
Path-Regeln vor PHP (GHSA-3h27-hjv7-fqjx)
Seit dem Fix für CVE-2025-64500 entfernt Request::getPathInfo() den Script-Namen vom URL-Anfang – auch wenn der Script-Name nur der Beginn eines längeren Pfadsegments ist. Mit SCRIPT_NAME=/index.php erhielt ein Request auf /index.phpadmin die Path-Info /admin und wurde wie /admin geroutet; auch kodierte Schreibweisen wie /index%2Ephpadmin wirkten. Vor jenem Fix war die Path-Info admin und matchte keine Route.
Wichtig: Symfony-eigene Regeln sind nicht betroffen – access_control und Firewalls lesen dieselbe Path-Info wie der Router. Betroffen sind Regeln vor PHP: nginx-location, Apache-<Location>, CDN- oder WAF-Regeln auf Pfaden wie /admin. Die nginx-Doku-Konfiguration und das .htaccess von symfony/apache-pack machen /index.php/admin unerreichbar, reichen aber /index.phpadmin an den Front Controller durch. Betroffene Ranges: ≥5.4.50 <5.4.56, ≥6.4.29 <6.4.50, ≥7.3.7 <7.4.23, ≥8 <8.1.11. Fix: Script-Name wird nur noch gestrippt, wenn /, ? oder URL-Ende folgen.
Was Betreiber jetzt tun sollten
Dependency-Check: HTTP Foundation bzw. das Symfony-Metapaket auf 5.4.56 / 6.4.50 / 7.4.23 / 8.1.11 (oder neuer im jeweiligen Branch) heben. Webserver-Review: Front-Controller-Rewrite und SCRIPT_NAME/fastcgi_split_path_info gegen die Advisory-Beschreibungen halten; Doku-Empfehlungen bevorzugen. WAF/CDN: Path-Allowlists nicht als alleinige Absicherung für Admin-Routen behandeln, wenn Requests den PHP-Front-Controller erreichen können.
AppSec: Beide GHSA in denselben Change-Request packen, Regressionstests für URL-Generierung und Routing nach Upgrade. Keine Exploit-Rezepte nötig – die Advisories beschreiben das Konzept öffentlich; Patch und Konfigurationsabgleich reichen. Credits: Nicolas Grekas (Report beider Issues, Fix Host-URL); Jack Worman (Fix Path-Bypass).
Einordnung im Security-Kontext der Woche
Die Symfony-Fixes passen zu einer Reihe Framework- und Runtime-Patches, die Betreiber parallel tracken: unser Beitrag zur kritischen PHP-RCE mit Notfall-Patches, die Rails Active-Storage-/ImageMagick-Lücke GHSA-f3w6, CVE-2026-119977 WordPress im CISA-KEV und der Next.js Security Release November 2026. Gemeinsam: Upgrade-Pflicht, klare Fixed Versions, keine Spekulation über Zero-Days jenseits der Advisories.
Grenzen und Missverständnisse
Symfony HTTP Foundation ist die betroffene Komponente; nicht jedes Symfony-Bundle ist damit automatisch „gehackt“. Trusted Hosts ersetzen den Patch nicht. Firewall-access_control ist beim Path-Issue kein Bypass-Ziel laut Advisory – das entlastet App-Security-Regeln, nicht aber reverse Proxies. Wer Custom-Front-Controller-Layouts oder ungewöhnliche nginx-Maps fährt, sollte die Advisory-Szenarien ausdrücklich gegen die eigene Config spiegeln.
Wir verzichten bewusst auf reproduzierbare Angriffsschritte. Die öffentlichen Blogposts reichen für Impact und Mitigation. Wer Meldeketten braucht: Security-Release-Mails von Symfony abonnieren und Composer-Audits in CI führen.
Upgrade-Checkliste ohne Exploit-Details
Praktische Reihenfolge: Composer/Lockfile auf die Fixed Versions bringen, Staging mit denselben Rewrite-Regeln wie Produktion betreiben, URL-Generierung (Login-Formulare, Redirects, Asset-Pfade) und Admin-Routen hinter Proxy/WAF smoke-testen, danach ausrollen. Wer noch auf älteren 5.4-/6.4-/7.x-/8.x-Zwischenständen unterhalb der Fixed Versions hängt, sollte beide Advisories in denselben Release-Notes an Ops und AppSec spiegeln – unterschiedliche Ranges, gleicher Patch-Stand.
Monitoring nach dem Deploy: auffällige Requests mit // oder Script-Name-Konkatenationen in Access-Logs sind ein Signal für Scans, kein Beweis für erfolgreiche Ausnutzung. Patch-Status bleibt die steuerbare Variable. Symfony-Security-Mail und Dependabot/Renovate für symfony/http-foundation reduzieren die Latenz bis zum nächsten Advisory.
Kurz: Am 4. November 2026 schließen GHSA-5mx8-mwrp-5693 und GHSA-3h27-hjv7-fqjx zwei HTTP-Foundation-Probleme in 5.4.56, 6.4.50, 7.4.23 und 8.1.11. Upgrade und Webserver-/WAF-Abgleich – ohne Exploit-Anleitungen.
Weitere Symfony-Advisories vom 4. November 2026
Neben den beiden HTTP-Foundation-Tickets veröffentlichte Symfony am selben Tag weitere Advisories (u. a. HttpClient, Routing, Serializer, Security-HTTP, Filesystem, Yaml, JsonPath). CERT-FR fasst sie unter CERTFR-2026-AVI-1460 zusammen. Für Betreiber, die das Metapaket `symfony/symfony` oder mehrere Komponenten pflegen, gilt: denselben Patch-Stand 5.4.56 / 6.4.50 / 7.4.23 / 8.1.11 anstreben und nicht nur HTTP Foundation isoliert heben. Unser Fokus bleibt bewusst auf Symfony HTTP Foundation, weil Host-URL und Path-Bypass die breitesten Web-Oberflächen betreffen.
Composer-Audit und Dependabot/Renovate sollten `symfony/http-foundation` und verwandte Packages auf die Fixed Versions pinnen. Wer LTS-Branches fährt, bleibt auf dem jeweiligen Branch und nimmt nur den Security-Release – kein erzwungenes Major-Upgrade. Staging mit produktionsgleichen Rewrite-Regeln ist Pflicht, sonst bleiben die Advisory-Szenarien unsichtbar.
Webserver- und Proxy-Check konkret
Apache: Root-`.htaccess`, das alles nach `public/` umschreibt, ohne dass URIs das Verzeichnis-Präfix tragen, ist im Host-Advisory ausdrücklich genannt – Doku-Layouts bevorzugen. Nginx: `fastcgi_split_path_info` und korrektes `SCRIPT_NAME` prüfen; Setups, die `SCRIPT_NAME` auf den Request-Pfad setzen, erhöhen die Host-URL-Risikofläche. CDN/WAF: Path-Allowlists für `/admin` und ähnliche Prefixe nicht als alleinige Kontrolle behandeln, wenn Requests den PHP-Front-Controller erreichen können – das Path-Advisory betrifft genau diese Schicht vor PHP.
Nach dem Upgrade: Login-Formulare, `redirectToRoute()`, Asset-Pfade und Admin-Routen smoke-testen; Access-Logs auf `//`-Präfixe und Script-Name-Konkatenationen beobachten. Patch-Status und Config-Abgleich bleiben die steuerbaren Variablen – ohne Exploit-Rezepte und ohne Spekulation über Zero-Days jenseits der öffentlichen Advisories zu Symfony HTTP Foundation.
