Symfony 5.4.52 / 6.4.40 / 7.4.12 / 8.0.12 — sieben CVEs in einem Wartungsfenster, von SMTP-Header-Injection in Mime\Address bis zum UrlGenerator-Route-Requirement-Bypass mit Off-Site-Redirect

TL;DR — die 90-Sekunden-Zusammenfassung

Was wurde veröffentlicht?

Symfony 5.4.52, 6.4.40, 7.4.12 und 8.0.12 mit sieben CVEs: HtmlSanitizer-Trio (CVE-2026-45064 BiDi-Override in URLs, CVE-2026-45066 allowLinkHosts/allowMediaHosts-Bypass per URL-Parser-Differential, CVE-2026-45753 vergessene URL-Attribute action/formaction/poster/cite), CVE-2026-45065 UrlGenerator-Route-Requirement-Bypass über unankerte Regex-Alternation, X509Authenticator-Identity-Spoofing über unankerte DN-Regex, CRLF-Injection in Symfony\Component\Mime\Address (Email-Header- / SMTP-Command-Injection), CVE-2024-50340-Patch-Bypass im SymfonyRuntime.

Wie schwer im Schnitt?

Drei der sieben CVEs sind direkt exploitable und müssen mit Prio High behandelt werden: das HtmlSanitizer-Trio in jeder App, die UGC oder Markdown rendert, der UrlGenerator-Bypass in jeder App mit Regex-Alternationen in Route-Requirements, die Mime\Address-CRLF-Injection in jeder App, die Display-Namen aus User-Input in Mail-Header baut (Newsletter, Formular-Mailer, Customer-Confirmation).

Stack-Mapping — wer ist wirklich betroffen?

Symfony-direkt und Sylius: alle sieben CVEs potenziell relevant. TYPO3 v12.4 LTS / v13.4 LTS / v14.x: ausschließlich die Mime\Address-CRLF-Lücke — TYPO3 hat seit v10 (Feature-88643) die Mail-API auf symfony/mailer und symfony/mime umgestellt, FluidEmail und MailMessage verlangen Symfony\Component\Mime\Address für jede Adresse. Die anderen sechs CVEs treffen TYPO3 nicht, weil TYPO3 eigenes Routing, eigenen HTML-Cleaner, eigenen Bootstrap und keine X509-Auth einsetzt.

Bin ich mit Auto-Update-Pipeline (Renovate, Dependabot, Mend) betroffen?

Wenn der Composer-Lock symfony/* in einer der jeweiligen Pre-Patch-Versionen führt, dann ja — in einer Patch-Pipeline-gewarteten Umgebung bündelt die Pipeline die Patch-Versionen (5.4.52, 6.4.40, 7.4.12, 8.0.12) zusammen mit den Komponenten-Updates (symfony/html-sanitizer, symfony/routing, symfony/security-http, symfony/mime, symfony/runtime) in Merge-Requests gegen die Image-Definitionen. Container-Rebuild läuft graceful, Symfony-Cache-Clear ist Teil des Rebuild-Schritts.

Welche zwei strukturellen Themen treten parallel auf?

Erstens Differential-Parser-Mismatch: wenn zwei Codepfade dieselbe Eingabe unterschiedlich parsen (HtmlSanitizer-URL-Parser vs. Browser-WHATWG-Parser, Symfony-DN-Regex vs. OpenSSL-DN-Parser, parse_str vs. SAPI-argv-Schicht), öffnen sich Bypasses. Zweitens unankerte Regex-Alternationen: '#^a|b|c$#' macht ^/$ wegen PCRE-Operator-Präzedenz nur am ersten und letzten Branch wirksam — alles dazwischen wird zur Substring-Übereinstimmung. Das Pattern trifft UrlGenerator und X509Authenticator gleichzeitig.

 

Operative Reaktion auf den Cluster

Moselwal positioniert sich ausdrücklich auf Auto-Update-fähige Plattformen — die CTA unten am Beitrag fasst das in einem Satz. Das operative Prinzip: eine Patch-Pipeline (Renovate, Dependabot, Mend) prüft Composer-Pakete mehrmals täglich und schiebt neue Patch-Versionen automatisiert in Merge-Requests gegen die Image-Definitionen. Eine Welle wie der 20.-Mai-Cluster fließt damit ohne Notschicht in die Build-Pipeline: die vier Symfony-Patch-Linien (5.4.52, 6.4.40, 7.4.12, 8.0.12) inklusive der Komponenten-Updates (symfony/html-sanitizer, symfony/routing, symfony/security-http, symfony/mime, symfony/runtime) erscheinen als Merge-Requests, die CI rebuildet die Container-Images, die Worker-Restarts sind graceful, der Symfony-Cache-Clear ist Teil des Rebuild-Schritts.

Wer nicht über eine Auto-Update-Pipeline läuft — eine Symfony-/Sylius-/TYPO3-Installation, die manuell gewartet wird — hat bei den drei direkt exploitable Lücken einen sehr engen Handlungsspielraum. Die folgenden Abschnitte gehen pro Advisory durch, was technisch passiert, welche Voraussetzungen die Exploitation hat und welche Reihenfolge die Update-Wartung verlangt. Zwei Stellen verdienen besondere Aufmerksamkeit: die UrlGenerator-Regex-Präzedenz (weil das gleiche Klassenmuster auch im X509Authenticator wieder auftaucht) und die Mime\Address-CRLF-Injection (weil sie als einzige CVE der Welle auch TYPO3-Setups direkt erwischt — über den Symfony-Mailer-Pfad, der seit v10 die TYPO3-Mail-API trägt).

Eine inhaltliche Vorab-Linie: vier der sieben CVEs lassen sich strukturell auf zwei Klassen reduzieren. Erstens, Differential-Parser-Mismatches — der Sanitizer parst URLs anders als der Browser, der Symfony-DN-Regex anders als OpenSSL, parse_str anders als die SAPI-Argv-Schicht. Zweitens, unankerte Regex-Alternationen — ^a|b|c$ matcht in der Mitte als unankerter Substring, ein Klassenfehler, der UrlGenerator und X509Authenticator gleichzeitig trifft. Wer die Klassen versteht, sieht die Lücken auch in eigenem Code wieder.

CVE-2026-45065 — UrlGenerator-Route-Requirement-Bypass via unankerte Regex-Alternation

Technische Analyse — PCRE-Operator-Präzedenz und der unankerte Mittel-Branch

Der UrlGenerator validiert dynamische Route-Parameter gegen den requirements-String der Route. Vor dem Patch sah die Compilation so aus:

// In Symfony\Component\Routing\Generator\UrlGenerator::doGenerate(), pre-Patch:
$compiledPattern = '#^' . $requirement . '$#';

Für eine Standard-Lokalisierungs-Route mit _locale: 'de|en|fr' wird daraus:

#^de|en|fr$#

Wegen der PCRE-Operator-Präzedenz parst die Regex-Engine das als:

(^de) | (en) | (fr$)

^ bindet nur an den linken Branch, $ nur an den rechten — die mittleren Alternativen sind ungeankert. Ein Wert wie evil.com/path matcht den en-Branch als Substring, das Requirement gilt als erfüllt, und der UrlGenerator emittiert den vollständigen User-Wert als Pfad-Segment.

Schreibt eine App den UrlGenerator-Output direkt in einen Location-Header oder ein <a href>, entsteht eine protocol-relative URL — der Browser folgt auf //evil.com/path und navigiert zur Angreifer-Domain. Klassisches Off-Site-Redirect-Primitive in einer Komponente, die das eigentlich verhindern sollte.

Der Fix wickelt das gesamte Requirement in eine non-capturing Group:

// Symfony 5.4.52 / 6.4.40 / 7.4.12 / 8.0.12, post-Patch:
$compiledPattern = '#^(?:' . $requirement . ')$#';

Damit gelten die Anker am Anfang und Ende der gesamten Alternation, nicht nur an den Rand-Branches. Funktional ein Einzeiler — strukturell die Korrektur einer Klasse von Validierungen, die seit der Symfony-2.x-Era so geschrieben wurde.

Stack-Mapping

Im Moselwal-Audit zeigen 11 von 14 Sylius-Plattformen {_locale}-Requirements mit de|en|fr-Alternation, vier Symfony-direkt-Apps mit Multi-Locale- oder API-Platform-Filter-Constraints. TYPO3-Stacks unberührt. Renovate-MR über Nacht aufgelaufen, Image-Rebuild im normalen Rolling-Window, priorisiert nach Public-Facing-Exposition.

HtmlSanitizer-Trio — CVE-2026-45064, -45066 und -45753

Drei eng verwandte HtmlSanitizer-CVEs in derselben Welle. Strukturell alle ein Versagen der Validierungs-Schicht gegenüber dem nachgelagerten Browser-Render — entweder durch unterschiedliche URL-Parser-Semantik (CVE-2026-45066), durch fehlende BiDi-Override-Erkennung (CVE-2026-45064) oder durch eine unvollständige Liste URL-tragender Attribute (CVE-2026-45753). Alle drei in Symfony 5.4.52 / 6.4.40 / 7.4.12 / 8.0.12 gepatcht.

CVE-2026-45066 — allowLinkHosts / allowMediaHosts Bypass via URL-Parser-Differential

CWE-436 (Interpretation Conflict) plus CWE-79 (XSS). Komponente: symfony/html-sanitizer, Host-Allowlist-Vergleich. Schweregrad: Hoch.

Der HtmlSanitizer erlaubt eine Host-Allowlist über ->allowLinkHosts(['trusted.example']) bzw. ->allowMediaHosts(['cdn.example']). Bei einem <a href="...">- oder <img src="...">-Element parst der Sanitizer die URL und vergleicht den Host gegen die Allowlist. Der Bug: der Sanitizer-eigene URL-Parser arbeitet auf einer RFC-3986-nahen Repräsentation, der Browser-URL-Parser auf der WHATWG URL Standard-Spezifikation. Beide differieren an mehreren Stellen, prominent bei der Behandlung von Backslashes in der Authority-Komponente:

<a href="https://trusted.example\@attacker.example/path">click</a>

• Symfony pre-Patch (RFC 3986 strict): Backslash ist reserviertes Zeichen, der Parser segmentiert nicht weiter, host = trusted.example. Allowlist-Check passiert.
• Browser (WHATWG): Im special-scheme-Pfad wird der Backslash als Forward-Slash behandelt, der @ markiert userinfo-/host-Trennung — der effektive Host ist attacker.example. Browser-Navigation geht dorthin.

Zusätzlich gab es eine <area>-Element-Misclassification: der <area href="...">-Tag wurde im Sanitizer als Media-Element kategorisiert (analog zu <img>), gehört aber per HTML5-Spec zu den Link-Elementen. Folge: die Media-Allowlist greift statt der Link-Allowlist.

CVE-2026-45064 — BiDi-Override-Smuggling in URL-Attributen

CWE-1007 (Insufficient Visual Distinction of Homoglyphs). Schweregrad: Medium (User-Interaction nötig, aber sehr glatte Phishing-Lücke in jedem UGC-Flow).

BiDi-Override-Characters (Unicode U+202E RIGHT-TO-LEFT OVERRIDE, U+2066–U+2069 Isolate-Markers) ändern die visuelle Darstellungs-Reihenfolge von Text im Browser. Eine URL wie example.com& wird visuell als example.com/htap/egil.com gerendert — der Nutzer sieht eine vertrauenswürdige Domain, die Browser-Navigation geht auf eine andere. Der HtmlSanitizer hat diese Characters in URL-Attributen vor dem Patch unbehandelt durchgelassen. Der Fix führt einen expliziten Reject-Schritt ein: BiDi-Override-Characters werden vor der URL-Validierung gestrippt, Leerzeichen werden percent-encoded.

CVE-2026-45753 — übersehene URL-Attribute action, formaction, poster, cite

CWE-79 (XSS) plus CWE-693 (Protection Mechanism Failure). Schweregrad: Medium-bis-Hoch (in <form action="javascript:...">-Konstellationen direkt XSS).

Der HtmlSanitizer pflegt eine interne Liste von URL-tragenden Attributen, auf die er die Scheme-Allowlist und Host-Allowlist anwendet. Diese Liste umfasste pre-Patch die Klassiker (href, src, srcset, formaction teilweise), übersah aber vier wichtige Attribute aus dem HTML5-Standard: action auf <form>, formaction auf <button> und <input type="submit">, poster auf <video>, cite auf <blockquote>, <q>, <del>, <ins>. Ein <form action="javascript:alert(1)"> läuft also durch den Sanitizer ungefiltert hindurch — bei Form-Submission läuft der JavaScript-URI im Browser-Kontext.

Stack-Mapping

Symfony-direkt und Sylius sind betroffen, sobald HtmlSanitizer mit UGC im Spiel ist (Forum-Posts, Customer-Reviews, Markdown-Newsletter). TYPO3 ist nicht betroffen — TYPO3 nutzt das eigenständige Paket typo3/html-sanitizer (Namespace TYPO3\HtmlSanitizer\), das masterminds/html5 nur als DOM-Parser einbindet. Die Sanitization-Logik selbst ist eigener TYPO3-Code, keine Symfony-Komponente. Im Moselwal-Bestand: zwei Sylius-Plattformen mit allowLinkHosts im Newsletter-Editor, drei Symfony-direkt-Apps mit HtmlSanitizer-UGC-Pipeline ohne Host-Allowlist. Update mit Prio High in den UGC-Flows.

CRLF-Injection in Symfony\Component\Mime\Address — die einzige CVE der Welle, die auch TYPO3 erwischt

Technische Analyse — wie der Display-Name eine ganze Mail entführt

Die Klasse Symfony\Component\Mime\Address hat die Konstruktor-Signatur:

namespace Symfony\Component\Mime;

final class Address
{
    public function __construct(string $address, string $name = '')
    {
        // ...
    }

    public function toString(): string
    {
        // pre-Patch: roher Display-Name in den Header geschrieben
        return ($this->getEncodedName() ?: '') . ' <' . $this->address . '>';
    }
}

Der zweite Parameter $name ist der Display-Name, der im From:-, Reply-To:- oder To:-Header in der Form "Display Name" <adresse@example.com> erscheint. Pre-Patch hat der Konstruktor den Display-Namen nicht auf CRLF-Sequences gefiltert. Eine konstruierte Adresse mit Display-Namen wie:

new Address('user@example.com', "Foo\r\nBcc: attacker@example.com");

resultiert beim Header-Render in:

From: "Foo
Bcc: attacker@example.com" <user@example.com>

Der CRLF im Display-Namen bricht aus der From-Header-Quotierung aus und injiziert eine zusätzliche Bcc-Anweisung. Der SMTP-Sender liest die neue Zeile als eigenständigen Header. Folge: ausgehende Mail mit zusätzlichem unsichtbarem Empfänger — und/oder mit beliebigen weiteren Headern (Reply-To, Content-Type, sogar SMTP-Command-Splitting wenn der MTA das nicht abfängt). Der Fix führt einen strikten CRLF-Reject im Address-Konstruktor ein. Aufrufer, die roh aus User-Input bauen, bekommen jetzt eine InvalidArgumentException und sehen die Lücke im Failed-Code direkt — das ist gewollt, der Patch ist auch ein Audit-Trigger.

Voraussetzung — und die drei Standard-Aufrufketten

Eine App, die Mail-Header (besonders From, Reply-To, Sender) aus User-Input baut. Drei Aufrufketten kommen in Moselwal-Stacks regelmäßig vor:

1. Sylius Customer Mailer. Sylius versendet Mails über \Sylius\Bundle\CoreBundle\Mailer\ (z. B. Welcome-Mail, Password-Reset, Order-Confirmation). Der from-Display-Name wird typischerweise aus Channel-Settings oder Customer-Properties gezogen — und der Customer kann sein firstName/lastName per Self-Service-API setzen. In einer Newsletter-Implementierung, in der der Customer als „Im Namen von“-Sender auftritt (B2B-Plattform mit White-Label-Adressierung), fließt der Customer-Name direkt in den From-Header.

2. TYPO3 EXT:form Email-Finisher. Das TYPO3-Form-Framework hat einen Email-Finisher (\TYPO3\CMS\Form\Domain\Finishers\EmailFinisher), der senderName und senderAddress aus Form-Konfiguration zieht. Die Konfiguration unterstützt Platzhalter-Templates der Form {form-field-name} — also direkte Übernahme von Form-Feldern (typischerweise „Name“ und „E-Mail-Adresse“) in den From-Header. Da der Finisher seit TYPO3 v10 (Feature-88643, „New Mail API based on symfony/mailer and symfony/mime“) über Symfony Mailer und damit über Symfony\Component\Mime\Address läuft, war jede TYPO3-Form-Installation mit user-konfigurierbarem Sender-Namen exposed.

3. Custom-Mailer in Eigenentwicklungen. Jede TYPO3-Extension oder Symfony-Bundle, die new Address($email, $displayName) mit user-influenced $displayName instanziert. Häufig in Order-Confirmation-Mailern, Customer-Support-Forwardern, Form-to-Mail-Plugins, Notification-Subscriber-Services.

Realweltlicher Hebel: Spam-Versand über den eigenen Server, Phishing-Mails mit dem eigenen Domain-Footer, BCC-Exfiltration interner Mails an Angreifer-Postfächer. Plus ein indirekter Reputations-Effekt — der eigene Mail-Server landet auf Blocklisten, weil er BCC-Mails zu unklaren Zielen verschickt hat.

Stack-Mapping

TYPO3-Version → Symfony-Mime-Fix-Linie

Da TYPO3 die Symfony-Major-Linie über die jeweilige Composer-Constraint pinnt, hängt die konkrete Fix-Version von der TYPO3-Linie ab:

In allen Fällen ist der Ablauf identisch: composer update symfony/mime --with-all-dependencies plus vendor/bin/typo3 cache:flush.

Verteilung im Moselwal-Bestand

Drei Sylius-Plattformen mit Newsletter-Pipelines, in denen Customer-Display-Names in From-Header fließen können — alle drei werden in der priorisierten Welle gepatcht. Zwei Symfony-direkt-Apps mit Customer-Support-Mailern und dynamischem Reply-To. Neun TYPO3-Plattformen mit EXT:form im produktiven Einsatz (verteilt auf v12.4 LTS, v13.4 LTS und v14.x), davon vier mit user-konfigurierbarem senderName in der Form-Definition — alle vier wurden in der Nacht priorisiert ausgerollt.

CVE-2024-50340-Patch-Bypass — APP_ENV / APP_DEBUG via parse_str / SAPI-argv-Mismatch

Technische Analyse

CVE-2024-50340 hat im November 2024 einen Pfad geschlossen, über den Web-Requests APP_ENV/APP_DEBUG per Query-String setzen konnten — durch die SymfonyRuntime, die SAPI-Argv-Werte mit Server-Variablen mischte. Der heutige Patch schließt einen verbliebenen Bypass-Pfad: ein Mismatch zwischen PHPs parse_str()-Output und der SAPI-Argv-Repräsentation ließ in bestimmten Embedded-Worker-Setups (FrankenPHP, RoadRunner, Swoole) die Variablen weiterhin durch. Der Fix gated den Argv-Pfad strikt auf das Vorhandensein von $_SERVER['QUERY_STRING'] und vergleicht die geparsten Werte rigoroser.

Stack-Mapping

Im Moselwal-Bestand: alle Sylius-/Symfony-direkt-Plattformen laufen auf FrankenPHP, der Bypass-Pfad ist also potenziell relevant. Der interne Audit-Pass läuft, bisher keine produktiven Setups mit ?APP_DEBUG=1-Test-Spur in den Logs. Update läuft mit Prio Medium auf allen Sylius-/Symfony-Stacks. TYPO3 ist unberührt.

X509Authenticator Identity Spoofing via unankerte DN-Regex (gleiche Klasse wie CVE-2026-45065)

Technische Analyse — derselbe Klassenfehler in einer anderen Komponente

Der X509Authenticator ermöglicht Client-Authentifizierung über X.509-Zertifikate (mTLS). Die Identitäts-Extraktion aus dem Subject-DN erfolgt über einen User-konfigurierbaren Regex. Wie bei CVE-2026-45065 (UrlGenerator) liegt der Bug in unankerten Alternationen: ein typisches User-Pattern wie '^CN=([^,]+)|emailAddress=([^,]+)$' parst die PCRE-Engine als:

(^CN=([^,]+)) | (emailAddress=([^,]+)$)

Wenn die Regex drei oder mehr Alternativen enthält (etwa für Multi-CA-Setups), gilt dasselbe Problem: mittlere Branches sind ungeankert, Substring-Übereinstimmung reicht. Ein Angreifer mit einem Zertifikat, dessen DN bestimmte Substring-Konstellationen enthält, kann sich als anderer Nutzer ausgeben.

Zusätzlich: der Symfony-DN-Parser und der OpenSSL-DN-Parser segmentieren denselben DN-String unter bestimmten Edge-Cases unterschiedlich (RDN-Reihenfolge, Escape-Charakter-Behandlung, Multi-Wert-RDNs) — ein Differential-Parser-Vektor, analog zur HtmlSanitizer-URL-Lücke. Der Fix ankert den Regex strikt (gleiche Korrektur wie im UrlGenerator: non-capturing Group um die gesamte Alternation) und harmonisiert die DN-Parser-Pfade.

Stack-Mapping

Im Moselwal-Bestand betreibt kein Kunde X509Authenticator produktiv — eine Testinstallation hat den Auth aktiv, läuft aber nicht öffentlich. Update wird trotzdem ausgerollt, weil die Klassen-Erkenntnis (unankerte Regex-Alternationen) Code-übergreifend relevant ist.

Stack-Mapping — wer ist wirklich betroffen?

Wir machen das explizit, weil eine Symfony-Welle nicht automatisch ein TYPO3-Problem ist (und auch nicht automatisch ein Sylius-Problem, das man mit einem composer update sylius/sylius allein erschlägt). Die folgende Tabelle bildet ab, welche der sieben CVEs in welchem Stack-Pfad ankommt:

Lese-Hilfe pro Stack-Layer

Für TYPO3-Betreiber: die Welle bringt für Sie genau einen unmittelbaren Punkt — die CRLF-Lücke in Mime\Address. Das gilt für alle aktuell unterstützten TYPO3-Linien gleichermaßen: v12.4 LTS, v13.4 LTS und v14.x sind alle betroffen, weil seit TYPO3 v10 (Feature-88643) jede Linie die Mail-API über symfony/mailer und symfony/mime führt. Die Composer-Constraints in typo3/cms-core pinnen lediglich die Symfony-Major-Linie (v12 → Symfony 6.4, v13 → 7.x, v14 → 7.x/8.x), die Patch-Version wird regulär durchgezogen. Das ist nicht „weniger schlimm“ als bei Sylius — das ist die einzige Lücke der Welle, die direkt in Ihrer Mail-Pipeline ankommt. EXT:form-Konfigurationen mit user-konfigurierbarem senderName oder eigene Extensions, die new Address(...) mit Form-Field-Werten instanziieren, sind direkt exploitable. composer update symfony/mime --with-all-dependencies zieht den Patch in die Composer-Lock, vendor/bin/typo3 cache:flush rundet ab. Die übrigen sechs CVEs treffen TYPO3 nicht.

Für Sylius-Betreiber: alle sieben CVEs sind potenziell relevant. Renovate (oder ein composer update --with-all-dependencies) zieht die Patches automatisch, weil Sylius symfony/symfony und die Einzel-Komponenten als Dependencies pinnt. Sylius selbst hat heute keine separate Advisory veröffentlicht — die Symfony-Patches reichen.

Für Symfony-direkt-Betreiber: alle sieben CVEs anschauen, je nach Setup priorisieren. Locale-Routing-Apps zuerst (CVE-2026-45065), UGC-Apps mit HtmlSanitizer zweitens (CVE-2026-45066 / -45064 / -45753), Mail-Pipelines drittens (Mime\Address).

Zwei strukturelle Muster — was die Welle vom 20. Mai über Symfony-Hygiene sagt

Sieben CVEs an einem Tag sind viel, aber die strukturelle Beobachtung ist nicht „Symfony hat ein Problem“, sondern „zwei Klassenfehler treten parallel in mehreren Komponenten auf“:

Erstens: Differential-Parser-Mismatches. Der HtmlSanitizer parst URLs nach einer RFC-3986-nahen Auslegung, der Browser nach WHATWG. Der Symfony-DN-Parser segmentiert anders als OpenSSL. parse_str() interpretiert andere Charakter-Klassen als die SAPI-Argv-Schicht. Jedes Mal, wenn ein Sicherheits-Check auf einer Parser-Repräsentation passiert, die nicht mit der nachgelagerten Aktion synchron ist, öffnet sich ein Bypass. Die saubere Konsequenz: für sicherheitsrelevante Parsing-Pfade entweder denselben Parser im Check und im Effect-Step verwenden, oder den Check redundant mit beiden Parser-Repräsentationen fahren. In Symfony-Apps konkret heißt das: bei jeder URL-Validierung gegen User-Input mindestens einmal über League\Uri oder Rowbot\URL (WHATWG-konform) parsen, statt nur über parse_url().

Zweitens: unankerte Regex-Alternationen.'#^a|b|c$#' ist ein Standard-Anti-Pattern, weil die Anker durch die PCRE-Operator-Präzedenz nur an den Rand-Branches greifen. Das Problem trifft UrlGenerator und X509Authenticator gleichzeitig. Der Fix in beiden Fällen ist identisch: das Alternations-Konstrukt in eine non-capturing Group wrappen, sodass die Anker außerhalb der Gruppe stehen — '#^(?:a|b|c)$#'. Wer eigenen Code mit Regex-Validierung schreibt, sollte ab heute jeden Alternations-Validator auf dieses Pattern prüfen — auch in Form-Validierern, in Custom-Slug-Sanitizern, in eigenen Rest-Resource-Allowlists.

Die HtmlSanitizer-URL-Lücken in Kombination mit der action/formaction-Übersicht zeigen eine dritte, kleinere Lehre: Allowlist-basierter Schutz ist nur so gut wie die Vollständigkeit der Allowlist. Wer eigene Sanitizer-Setups oder eigene URL-Attribut-Filter betreibt, sollte regelmäßig HTML5-spec-aktuelle URL-Attribut-Listen pflegen — die Liste wächst mit neuen Spezifikationen (Web-Components, popover-Attribute, etc.), der Sanitizer nicht automatisch.

Die CRLF-Lücke in Mime\Address schließt das Bild ab. Ein Pattern, das in PHP-Mailer-Libraries seit 15 Jahren wiederkehrend ist (zuletzt prominent in PHPMailer CVE-2016-10033) und das trotz Symfony's allgemeiner Robustheit jetzt einmal mehr aufschlug. Lehre: User-Input in Mail-Header-Konstruktoren ist immer ein CRLF-Reject-Pflicht-Pfad — sowohl auf Library-Seite (was Symfony heute korrigiert) als auch auf Aufrufer-Seite (Defense-in-Depth in den eigenen Mailer-Services und Form-Finishern).

Detection und Verifikation

Manuelle Verifikation pro Setup-Typ in unter 20 Minuten machbar. Die folgenden grep-Patterns finden die typischen Aufruf-Stellen.

Welche Symfony-Komponenten sind installiert?

composer show 'symfony/symfony' 'symfony/html-sanitizer' 'symfony/routing' \
              'symfony/security-http' 'symfony/mime' 'symfony/runtime' 2>/dev/null

Versionsspalte gegen die Fix-Liste oben abgleichen. Für TYPO3-Setups insbesondere symfony/mime checken — die anderen Komponenten ziehen Sie zwar transitiv mit, aber relevant ist hier nur Mime.

HtmlSanitizer mit allowLinkHosts / allowMediaHosts?

grep -rnE '(allowLinkHosts|allowMediaHosts)\(' src/ config/ 2>/dev/null

Nur relevant für Sylius- und Symfony-direkt-Apps. Treffer in eigenen Code-Pfaden sind direkter CVE-2026-45066-Vektor.

UrlGenerator-Routes mit Alternations-Requirements?

# Annotations- oder Attribute-Routes prüfen
grep -rnE '@Route|#\[Route' src/ 2>/dev/null | grep -E 'requirements.*\|'

# Plus alle YAML-Routes
grep -A2 'requirements:' config/routes*.yaml config/routes/*.yaml 2>/dev/null | grep '|'

Treffer mit de|en|fr-artigen Alternations sind direkter CVE-2026-45065-Vektor. Sylius-Locale-Routes sind hier praktisch garantiert.

Mime\Address mit User-Input (Sylius / Symfony-direkt)?

grep -rnE 'new\s+(\\?Symfony\\\\Component\\\\Mime\\\\)?Address\s*\(' src/ 2>/dev/null

Jede Stelle, an der ein zweiter Parameter aus Request-Daten, Customer-Entity-Properties oder Form-Submission-Werten gebaut wird, ist ein direkter Mime-Header-Injection-Vektor.

TYPO3 EXT:form Email-Finisher mit senderName-Templates?

# Form-Definitionen prüfen (YAML)
grep -rnE 'senderName|senderAddress' \
  fileadmin/Forms/ packages/*/Configuration/Yaml/Forms/ \
  config/sites/*/Forms/ 2>/dev/null

# Plus EmailFinisher-Aufrufe in eigenem PHP-Code
grep -rnE 'EmailFinisher|MailMessage|FluidEmail' \
  packages/*/Classes/ 2>/dev/null

Treffer mit Platzhalter-Templates wie {name} oder {fullname} in senderName sind direkte CRLF-Injection-Pfade.

Cache-Clear ist Pflicht-Schritt

# Symfony / Sylius
bin/console cache:clear --env=prod

# TYPO3
vendor/bin/typo3 cache:flush

# Plus container-rebuild bei Plattformen mit FrankenPHP / worker-modes

Symfony-Patches greifen häufig erst nach Cache-Clear, weil die kompilierten DI-Container Routen- und Sanitizer-Konfigurationen einfrieren. Bei TYPO3 betrifft das mehr die Mail-Configuration als die UrlGenerator-/Sanitizer-Konfigurationen.

Betreiberempfehlung — Operativer Entscheidungsblock

Empfehlung nach Setup-Typ

Single-Tenant-Symfony oder Sylius mit Renovate. Kein operativer Handlungsdruck, Rollout läuft automatisch.

Symfony-direkt ohne Renovate, aber mit Composer-Mode. Heute Vormittag: composer update 'symfony/*' --with-all-dependencies, gefolgt von bin/console cache:clear --env=prod und Worker-Restart.

Sylius 1.13.x / 2.x. Sylius-Konsumenten der Symfony-Komponenten erben den Fix automatisch, sobald Symfony-Patches im Composer-Lock landen. Renovate-MR plus Container-Rebuild reicht. Wer Sylius-Constraints explizit pinnt, sollte das Constraint-Range gegen ^5.4, ^6.4, ^7.4 oder ^8.0 mit den jeweiligen Patch-Versionen verifizieren.

TYPO3 v12.4 LTS / v13.4 LTS / v14.x. Für TYPO3 ist heute eine CVE relevant: die Mime\Address-CRLF-Lücke. composer update symfony/mime --with-all-dependencies (das zieht typischerweise auch symfony/mailer und transitive Symfony-Komponenten mit), dann vendor/bin/typo3 cache:flush. Wer EXT:form mit user-konfigurierbarem senderName betreibt, sollte zusätzlich einen Defense-in-Depth-Schritt einziehen — entweder den Form-Finisher um einen CRLF-Strip-Step erweitern oder über das formvendor-Override den senderName aus der Form-Definition gegen eine statische Liste pinnen. Die anderen sechs Symfony-CVEs treffen TYPO3 nicht.

Drupal 10+/11. Drupal nutzt Symfony-Komponenten als direkte Dependencies (symfony/routing, symfony/http-foundation, symfony/mime etc.). Die HtmlSanitizer-Welle ist hier weitgehend irrelevant (Drupal hat eigene Filter-Systeme), die UrlGenerator- und Mime-Lücken können treffen. composer update --with-all-dependencies, dann drush cr.

Wie wir bei Moselwal Symfony-Wellen behandeln

Bei Advisory-Wellen wie dem 20.-Mai-Symfony-Cluster ist ein dreischichtiges Vorgehen sinnvoll — und genau dafür baut Moselwal seine Plattformen auf Auto-Update-fähigkeit aus:

Schicht 1: Patch-Pipeline erkennt alle vier Linien plus die Komponenten-Updates. Eine Versions-Wächter-Pipeline (Renovate, Dependabot, Mend) erkennt sowohl symfony/symfony 5.4.52 als auch die einzelnen Komponenten-Bumps (symfony/html-sanitizer, symfony/routing, symfony/security-http, symfony/mime, symfony/runtime) sowie die Parallel-Linien 6.4.40, 7.4.12, 8.0.12. Für TYPO3-Plattformen ist der symfony/mime-Bump der relevante Auslöser, weil er den Mail-Pfad fixt, der seit TYPO3 v10 über symfony/mailer und symfony/mime läuft; insbesondere Plattformen mit EXT:form-Konfigurationen und user-konfigurierbarem senderName werden im Image-Rebuild priorisiert.

Schicht 2: Rolling-Rebuild priorisiert nach Exposition. Reihenfolge:

1. Sylius-Plattformen mit aktiver allowLinkHosts-Konfiguration und Newsletter-Pipelines mit Customer-Display-Name-Headern.
2. TYPO3-Plattformen mit EXT:form und user-konfigurierbarem senderName.
3. Symfony-direkt-Apps mit Locale-Routing-Constraints.
4. Long Tail (alle anderen).

Die FrankenPHP-Worker-Restarts sind graceful, der Symfony-Cache-Clear ist im Container-Rebuild integriert. TYPO3-Cache-Flushes laufen im Post-Deployment-Hook.

Schicht 3: Audit-Pass über die Konfigurations-Lage. Parallel läuft ein grep-Audit: gibt es Alternations-Requirements in Route-Definitions, gibt es allowLinkHosts/allowMediaHosts in Sanitizer-Konfigs, gibt es new Address(...)-Instanzierungen mit User-Input im Display-Name, gibt es EXT:form-Definitions mit {form-field}-Platzhaltern in senderName. Das Ergebnis fließt in die nächste Wartungs-Routine — der Cluster wird also nicht nur „weggepatcht", sondern als Anlass für eine systematische Konfigurations-Review genutzt.

Wer eine Symfony-/Sylius-/TYPO3-Plattform betreut und eine vergleichbare Wellen-Routine aufsetzen will, findet im CTA unten den Einstieg.

Fazit

Sieben CVEs an einem Tag sind viel, aber strukturell zwei Klassen plus drei Einzelläufer. Die Klassen — Differential-Parser-Mismatch und unankerte Regex-Alternation — sind seit Jahren als Anti-Patterns bekannt und treten in dieser Welle parallel an mehreren Komponenten auf. Das Symfony-Team hat offenbar einen systematischen Audit-Sweep gefahren und die Klassen-Cluster gemeinsam disclosed. Strukturell ist das ein günstiges Pattern für Betreiber: eine Welle, ein Wartungsfenster, alle relevanten Komponenten in einem Roll-Forward.

Wichtig für die Einordnung: nicht jede Symfony-Welle ist gleich eine Welle für jeden PHP-Stack. Für TYPO3-Betreiber ist heute genau eine CVE relevant — die CRLF-Injection in Mime\Address, weil seit TYPO3 v10 (Feature-88643) die Mail-API auf symfony/mailer und symfony/mime läuft. Das gilt für v12.4 LTS, v13.4 LTS und v14.x gleichermaßen — der TYPO3-Major macht keinen Unterschied bei der Betroffenheit. Es ist nicht „weniger schlimm“ als bei Sylius — es ist die einzige Lücke der Welle, die direkt in der TYPO3-Mail-Pipeline ankommt, und sie ist in EXT:form-Setups mit user-konfigurierbarem Sender-Namen oder in Eigenextensions mit new Address($email, $userInput) direkt exploitable. Für Sylius- und Symfony-direkt-Betreiber sind dagegen alle sieben CVEs potenziell relevant, weil Sylius die Symfony-Full-Stack-Komponenten direkt einsetzt.

Für Stacks mit Auto-Update-Pipeline (Renovate, Dependabot o. ä.) fließen die Fix-Versionen ohne manuelles Eingreifen und ohne sichtbare Service-Unterbrechung in den Build. Für Self-Hosted-Setups ohne Auto-Update-Pipeline gilt die Reihenfolge oben: zuerst die HtmlSanitizer-Trio-Apps (wenn UGC im Spiel ist), dann UrlGenerator-Apps mit Regex-Route-Requirements, dann Mail-Pipelines mit User-Input in Address-Headern (inklusive TYPO3 EXT:form). Cache-Clear ist Pflicht-Schritt nach jedem Symfony-Patch — die kompilierten DI-Container halten Routen- und Sanitizer-Konfigurationen sonst eingefroren.

Wer eigenen Code mit Regex-Validierung schreibt, hat heute zwei konkrete Audit-Aufgaben: alle Alternations-Validatoren auf '#^(?:a|b|c)$#'-Pattern bringen, und alle sicherheitsrelevanten Parser-Pfade darauf prüfen, dass Check-Phase und Effect-Phase dieselbe Parser-Repräsentation verwenden. Plus eine dritte: jede Mailer-Aufruf-Stelle auf CRLF-Reject vor new Address(...) prüfen — die Library macht das jetzt, aber Defense-in-Depth schadet nicht.

Die spannende Frage lautet nicht, wann die nächste Symfony-Welle kommt — sondern ob die eigene Codebase die gleichen Klassen-Fehler trägt und beim nächsten externen Audit aufläuft.

Dieser Beitrag spiegelt unsere technische und strategische Einschätzung. Er ersetzt keine eigene Code-Review und keine Datenschutz-Folgenabschätzung bei der Verarbeitung User-eingereichter Inhalte.