TYPO3 14.3.2 und 13.4.30 — Maintenance-Releases mit Symfony- und Composer-Constraint-Raise

TL;DR — die 90-Sekunden-Zusammenfassung

Zwei parallele Maintenance-Releases, kein Core-Security-Advisory, aber ein Symfony-/Composer-Constraint-Raise, dessen Commit-Message neun zugrundeliegende CVEs benennt.

Drei Sätze für Betreiber: Das Update ist im Standard-Pipeline-Lauf richtig aufgehoben — wer wie wir auf Continuous Deployment fährt, lässt es regulär durch die Pipeline laufen, ohne Sonder-Wartungsfenster. Wer den genauen CVE-Bezug seines Composer-Resolve sehen will, hat das mit composer update typo3/cms-* --with-dependencies und einem nachgeschalteten composer show symfony/mailer symfony/mime symfony/routing symfony/yaml symfony/cache composer/composer schwarz auf weiß. Die npm-Devdep-Sanierung im Core ist guter Anlass, ein npm audit --omit=dev über die eigene Sitepackage-Toolchain mitlaufen zu lassen.

Worum es bei diesen Releases geht

TYPO3 14.3.2 ist die zweite Wartungs-Iteration der 14.3-LTS-Linie nach 14.3.1 vom 12. Mai 2026. 13.4.30 ist der dreißigste Maintenance-Drop der laufenden 13.4-LTS und führt die Reihe vom 12.05. (13.4.29) fort. Beide Releases sind am selben Tag erschienen (26.05.2026); das gemeinsame TYPO3-News-Ticket nennt sie als „maintenance releases only" und vermerkt explizit: keine Datenbank-Updates nötig, ggf. Caches leeren.

Wichtig zur Einordnung: weder die offizielle TYPO3-News-Seite noch die Release-Notes nennen eine eigene SA-CORE-2026-*-Advisory-Nummer oder einen Security-Bezug. Der Commit-Message des Symfony-Raise listet die zugrundeliegenden CVEs zwar im Klartext (siehe Sektion „Was hat sich an der Sicherheit geändert" unten), aber die TYPO3-Außenkommunikation behandelt sie als reguläre Dependency-Pflege. Wir folgen dieser Sprache in diesem Post: das ist ein Maintenance-Drop, kein Notfall-Patch, und gehört in den normalen Pipeline-Lauf, nicht ins Wochenend-Sonderfenster.

Wer derzeit auf 14.3.1 oder 13.4.29 läuft, bekommt mit dem Update keine Datenbank-Migration — der Upgrade-Pfad ist composer update typo3/cms-* --with-dependencies plus einmal Cache löschen. Wer auf 14.3.0 oder 13.4.28 oder älter sitzt, holt den Roll-up im selben Pipeline-Lauf mit — vor allem wegen der Memory-Limit-Empfehlung aus 14.3.1 (256 MB Minimum, 512 MB empfohlen) und der jetzt mitgehobenen Symfony-Constraints.

TYPO3 14.3.2 — die Änderungen im Detail

Die 14.3.2 enthält zwölf Commits seit 14.3.1 (inklusive Release- und Version-Bump-Commit). Wir gehen jeden Eintrag durch.

Symfony- und Composer-Constraint-Raise (TASK, Kern-Commit dieses Releases)

Commit a6aede1e839 (25.05.2026, Oliver Hader) hebt die Mindest-Constraints von vier symfony/*-Paketen sowie composer/composer (Devdep) in der composer.json des Cores. Der Maintainer dokumentiert im Commit-Message explizit die Pakete, die neuen Mindest­stände und die zugrundeliegenden CVEs (siehe Sektion „Was hat sich an der Sicherheit geändert" weiter unten für die vollständige Liste).

Operativ heißt das: nach composer update typo3/cms-* --with-dependencies sitzt unter TYPO3 14.3.2 mindestens die ^7.4.12-Linie der Pakete symfony/mailer, symfony/mime, symfony/routing, symfony/yaml, und Composer als Devdep ist auf ^2.9.8. Andere Symfony-Komponenten (http-foundation, http-kernel, console, dependency-injection und weitere) bleiben in der composer.json auf ihrem bisherigen ^7.4.8-Constraint — Composer kann sie beim composer update -W transitive auf die jeweils aktuellen 7.4.x-Stände hochziehen, wenn das Lockfile es zulässt. Welche konkreten Versionen am Ende installiert sind, sieht man pro Setup mit composer show symfony/*.

npm-Devdep-Sanierung (TASK, Release-Tag-Commit)

Commit 8c0c8fb2d52 (26.05.2026, Oliver Hader) räumt am Release-Tag selbst die in den letzten Wochen aufgelaufenen vulnerable npm-Devdep-Funde. Die konkreten Pakete stehen im Commit-Diff; in Summe betrifft das Asset-Build-Toolchain-Pakete (Bundler, Linter, Test-Runner), nicht die im Browser ausgelieferten Frontend-Bundles. Operativ heißt das: der Schutz gilt der Entwickler-/CI-Maschine, nicht dem Endnutzer.

Wer eigene Sitepackage-Toolchains betreibt, sollte den eigenen package-lock.json parallel mit npm audit --omit=dev bzw. npm audit fix durchgehen — die Core-Pflege ist Vorbild, nicht Vollersatz. Bezug zur aktuellen Lage: der heutige Kim-Daily-Brief „Claude Code und Gemini CLI im Visier finanziell motivierter Angreifer" beschreibt, wie Entwickler-Workstations und ihre Toolchains zum primären Einstiegspunkt von Supply-Chain-Kampagnen werden.

Site-aware Cache-Tag-Collection (TASK, operative Wirkung)

Commit 30cf9cf0739 (20.05.2026, Soren Malling) ergänzt die aktuelle Site in der Cache-Tag-Collection. Konsequenz: wenn das Cache-Layer Tags pro Site getrennt führt (Reverse-Proxy-Invalidation, applikationsinterne Tag-Flushes), kann jetzt sauber pro Site invalidiert werden, statt versehentlich Cross-Site-Tag-Überschneidungen zu erzeugen. Relevant für Multi-Site-Setups — typisch bei Mandanten-Setups, bei mehreren Domains pro Instanz oder bei Sprach-Overlays mit eigener Cache-Strategie. In Single-Site-Setups ändert sich operativ wenig.

MD5-Hinweis aus Install-Tool-Alert-Mail entfernt (TASK, Cleanup mit Signal)

Commit f086fca11c9 (18.05.2026, Oliver Hader) entfernt aus der Install-Tool-Alert-Mail einen Hinweis-Satz, der historisch noch MD5 als möglichen Passwort-Hash-Algorithmus erwähnte. MD5 ist als Passwort-Hashing-Verfahren seit Jahren raus aus jeder ernsthaften Empfehlung; der Hinweistext hatte in einer 2026er-Install-Tool-Mail nichts mehr zu suchen. Kosmetischer Cleanup mit klarer Signal-Funktion.

Live-Search zeigt Sprach-Flagge in den Ergebnissen (BUGFIX)

Commit 8e92e74ff13 (18.05.2026, Benjamin Kott) repariert die Live-Search-Ergebnisliste: bei mehrsprachigen Inhalten wurde die Sprach-Flagge nicht mehr zuverlässig angezeigt. Mit dem Fix sieht die Redaktion in der Live-Search wieder, welcher Sprach-Overlay zu welchem Treffer gehört — Hilfe bei Setups mit zwei oder mehr aktiven Sprachen.

fluid:analyze erkennt deprecated useNonce (TASK, Entwickler-relevant)

Commit 92757cf77cf (17.05.2026, Simon Praetorius) erweitert den Fluid-CLI-analyze-Befehl: der inzwischen als deprecated markierte useNonce-Parameter wird nun von der Analyse-Stufe erkannt und gemeldet. Für Sitepackage-Maintainer heißt das: ein vendor/bin/typo3 fluid:analyze zeigt jetzt frühzeitig, wo in eigenen Templates noch das alte Konstrukt sitzt, bevor es in einer späteren TYPO3-Major-Version verschwindet.

Drei Doku-/Tooling-Korrekturen

Commit 8e865b55f8b (20.05.2026, Chris Müller) korrigiert die Doku-Angabe zur Field-Column-Size des UUID-Typs im Changelog. Commit 657989535fb (19.05.2026, Markus Klein) hebt die phpstan/phpstan-Version. Commit 983d845b6b8 (13.05.2026, Markus Klein) ergänzt in der Doku einen expliziten Hinweis zur korrekten Verwendung des PageDoktypeRegistry. Commit 775540e17c1 (12.05.2026, Chris Müller) korrigiert den Namespace für QueryResultPaginator in einem Changelog-Eintrag.

Version-Bump und Release-Commit

Commit 7ea76cc903f (12.05.2026, Oliver Hader) setzt die TYPO3-Version auf 14.3.2-dev. Commit d3b483b4a41 (26.05.2026, Oliver Hader) ist der eigentliche Release-Commit.

TYPO3 13.4.30 — die Änderungen im Detail

Die 13.4.30 enthält acht Commits seit 13.4.29 (inklusive Release- und Version-Bump-Commit). Sechs davon sind inhaltlich 1:1 mit der 14.3.2-Liste identisch — die LTS-Linie bekommt denselben Wartungs-Schwerpunkt, nur ohne die vier 14er-spezifischen Detail-Fixes (Live-Search-Flagge, fluid:analyze-useNonce, zwei Changelog-Doku-Patches).

Symfony- und Composer-Constraint-Raise

Commit 4fd2524fe60 (25.05.2026, Oliver Hader) ist die LTS-Variante des 14er-Raise. Inhalt identisch: symfony/mailer ^7.4.12, symfony/mime ^7.4.12, symfony/routing ^7.4.12, symfony/yaml ^7.4.12, symfony/cache ^7.4.12 (transitiv), composer/composer ^2.9.8 (Devdep). Die im Commit-Message dokumentierten CVEs sind dieselben neun wie in 14.3.2 (vollständige Liste in der nächsten Sektion).

npm-Devdep-Sanierung

Commit 5cf5009a98e (26.05.2026, Oliver Hader) ist die LTS-Variante. Identische Begründung wie in 14.3.2 — Entwickler-/CI-Toolchain, nicht produktive Frontend-Bundles.

Site-aware Cache-Tag-Collection

Commit 8af66a56dd1 (20.05.2026, Soren Malling) — identisch zur 14er-Version. Multi-Site-Setups profitieren, Single-Site bleibt unverändert.

MD5-Hinweis aus Install-Tool-Alert-Mail entfernt

Commit e5a03a90328 (18.05.2026, Oliver Hader) — der LTS-Backport des MD5-Cleanup-Commits.

phpstan-Raise

Commit c21bbb58c79 (19.05.2026, Markus Klein) — Toolchain-Pflege, identisch zur 14er-Version.

PageDoktypeRegistry-Dokumentation

Commit 9db9ab10cbc (13.05.2026, Markus Klein) — derselbe Doku-Patch wie in 14.3.2.

Version-Bump und Release-Commit

Commit 74967a6f11d (12.05.2026, Oliver Hader) setzt die TYPO3-Version auf 13.4.30-dev. Commit 09b644f9e12 (26.05.2026, Oliver Hader) ist der Release-Commit.

Bewusst nicht in 13.4.30 zurückportiert

Vier 14.3.2-Commits wandern nicht in die LTS-Linie zurück (Begründung jeweils aus der Architektur-Differenz heraus geschätzt — TYPO3 nennt im Release-Notes-Diff keine Rückport-Begründungen):

• Live-Search-Sprach-Flagge (8e92e74ff13) — die Live-Search-Implementierung in 13er und 14er weicht in der Detail-Architektur ab; ein 1:1-Backport wäre kein sauberes Cherry-Pick.
• fluid:analyze-Erkennung von deprecated useNonce (92757cf77cf) — die deprecated-Markierung selbst sitzt in der 14er-Fluid-Linie, nicht in 13.4.
• UUID-Field-Column-Size-Doku (8e865b55f8b) und QueryResultPaginator-Namespace-Doku (775540e17c1) — beide gehören zur 14er-Changelog-Pflege.

Was hat sich an der Sicherheit geändert?

Auf TYPO3-Core-Ebene: nichts. Kein neuer SA-CORE-2026-*-Advisory, kein [SECURITY]-Tag in den Commit-Logs, kein Security-Bezug in den Release-Notes oder im News-Artikel.

Auf Dependency-Ebene: der Symfony-Raise vom 25.05. adressiert ausweislich des Commit-Messages neun CVEs in vier direkten Symfony-Paketen, einer transitiven Symfony-Komponente und in Composer als Devdep. TYPO3 wählt für solche Fälle ausdrücklich nicht den Weg eines eigenen Core-Advisorys, sondern integriert die Dependency-Patches in den nächsten regulären Maintenance-Drop. Das ist die konservative, in der TYPO3-Maintainer-Praxis übliche Linie: ein Core-Advisory hängt am Code-Pfad des Cores, nicht an den Code-Pfaden seiner Dependencies.

Die neun CVEs aus dem Commit-Message im Detail

Der Maintainer Oliver Hader benennt im Commit-Message des symfony/*- und composer/composer-Raise neun CVEs. Wir listen sie hier mit Paket-Bezug und kurzer Einordnung, damit DSB und IT-Verantwortliche der Kundschaft die Mitnahme dokumentieren können:

• symfony/mailer ^7.4.12 — CVE-2026-45068: Argument-Injection in SendmailTransport via Dash-präfixiertem Recipient-Address. Relevant überall dort, wo TYPO3 selbst E-Mails versendet (Newsletter, Kontaktformulare, System-Notifications).
• symfony/mime ^7.4.12 — CVE-2026-45067 (CRLF-Injection in Email-Header / SMTP-Command via Symfony\Component\Mime\Address) und CVE-2026-45070: zwei MIME-Parser-Schwachstellen. Relevant in jeder Anwendung, die eingehende MIME-Nachrichten parst oder ausgehende Nachrichten zusammenbaut (symfony/mailer baut intern auf symfony/mime auf).
• symfony/routing ^7.4.12 — CVE-2026-45065: UrlGenerator Route-Requirement-Bypass via Unanchored-Regex-Alternation, der zu Off-Site-//host-URL-Injection führt. TYPO3 nutzt eigene Site-Routing-Logik; der Symfony-Routing-Code kommt aber an einigen Stellen indirekt zum Einsatz (CLI, Backend-Routes).
• symfony/yaml ^7.4.12 — CVE-2026-45304 (Bound collection-alias resolution), CVE-2026-45305 (YAML-Parser-ReDoS via catastrophic backtracking in Parser::cleanup()), CVE-2026-45133 (Bound recursion depth in parser): drei YAML-Parser-CVEs. Relevant überall dort, wo YAML-Eingaben verarbeitet werden (Site-Konfiguration, services.yaml im DI-Layer, Form-Definitions im YAML-Format, eigene Extensions mit YAML-Configs).
• symfony/cache ^7.4.12 — CVE-2026-45073: Cache-Komponente, im TYPO3-Core nicht direkt referenziert, aber transitiv über andere Symfony-Pakete eingezogen.
• composer/composer ^2.9.8 — CVE-2026-45793: GitHub-Token-Leak in Composer. Wir hatten dazu am 14.05.2026 einen eigenen Tagespost. Hier wird der Patch jetzt auch im TYPO3-Core-Devdep-Stand verankert — relevant für Setups, die Composer als Bibliothek (nicht nur als CLI) nutzen.

Was im Commit-Message NICHT steht

Die Symfony-Mai-Disclosure-Welle vom 20.05.2026 (CVE-2026-46626 SymfonyRuntime, CVE-2026-45075 IsGranted/HEAD-Bypass, CVE-2026-45071 DomCrawler-XXE, CVE-2026-45072 WebProfiler-XSS) ist in diesem Constraint-Raise nicht explizit referenziert. Wer diese Welle adressieren will, prüft per composer why-not symfony/http-foundation:^7.4.12 und composer why-not symfony/security-core:^7.4.12, ob die eigenen Constraints dem Composer-Resolve den Sprung auf 7.4.12-Stände der anderen Symfony-Pakete erlauben — Composer zieht sie bei -W/--with-dependencies häufig transitive mit, aber explizit verankert sind sie im TYPO3-Core nicht.

Twig-Sandbox-Welle vom 20.05.: Twig ist nicht Teil des TYPO3-Cores — TYPO3 nutzt Fluid (typo3fluid/fluid) als Template-Engine. Wer Twig in einer Custom-Extension oder Standalone-Komponente parallel nutzt, pflegt den Twig-Patch-Stand unabhängig vom TYPO3-Release über den eigenen Composer-Constraint.

Was diese Lesart für Betreiber heißt: das Update ist regulär durch die Pipeline laufen lassen — bei uns mit Continuous Deployment in derselben Iteration, in der TYPO3-Maintenance-Releases ohnehin automatisch durchgehen. Wer einen Wartungsfenster-getriebenen Betrieb fährt, hat dieses Release im nächsten geplanten Fenster richtig. Es gibt aus TYPO3-Sicht keine Notfall-Stufe, und wir spiegeln das.

Wer ist betroffen?

Drei Profile mit unterschiedlicher Priorität:

• Profil A — Aktive 14.3.x-LTS-Betreiber: Wer auf 14.3.1 läuft, nimmt 14.3.2 im nächsten regulären Composer-Update mit. Inhaltlicher Schwerpunkt: Symfony-/Composer-Constraint-Raise mitziehen, npm-Devdep-Sanierung wahrnehmen, Cache-Tag-Site-Awareness in Multi-Site-Setups beachten.
• Profil B — LTS-Betreiber auf 13.4: Wer auf 13.4.29 oder älter sitzt, nimmt 13.4.30 mit — derselbe Symfony-Raise, dasselbe npm-Devdep-Cleanup. Wer auf 13.4.28 oder älter läuft, holt im selben Lauf auch die 13.4.29-Änderungen (f:render.text-Backport, Composer 2.9.7, Drag-and-Drop-Fix) mit.
• Profil C — Sitepackage-Maintainer und CI-Verantwortliche: Die npm-Devdep-Sanierung ist Vorbild für die eigene Toolchain. Ein npm audit --omit=dev über das eigene Sitepackage ist nach diesem Release der richtige Anschluss-Reflex. Wer eigene Templates mit dem inzwischen-deprecated useNonce baut, sollte mit 14.3.2 ein vendor/bin/typo3 fluid:analyze durchlaufen lassen — auch wenn das nicht in jeder Pipeline als Standard-Stage sitzt.

Wer auf 14.0/14.1/14.2 sitzt, sollte ohnehin auf 14.3 wechseln — die Zwischenversionen bekommen keine Wartung mehr.

Betreiberempfehlung

Maintenance-Releases verdienen Disziplin, kein Drama. Wer wie wir auf Continuous Deployment fährt, hat das Update ohnehin im nächsten Pipeline-Lauf. Wer Wartungsfenster fährt, sortiert es ins nächste reguläre Fenster ein.

Operational Decision Block

• Wenn Sie auf TYPO3 14.3.1 sind und Composer-managed → dann läuft 14.3.2 im nächsten regulären Pipeline-Lauf bzw. im nächsten Wartungsfenster automatisch durch. Vorher per composer why symfony/mailer, composer why symfony/mime, composer why symfony/routing, composer why symfony/yaml prüfen, ob eigene Constraints den Patch-Sprung blockieren.
• Wenn Sie auf TYPO3 13.4.29 sind und unter LTS → dann identische Vorgehensweise auf der LTS-Linie. Symfony-/Composer-Constraint-Raise ist 1:1 derselbe.
• Wenn Sie auf 14.3.0 oder älter sind → dann rollen Sie bis 14.3.2 in einem Lauf durch und nehmen die 14.3.1-Änderungen (Memory-Limit, Drag-and-Drop, Scheduler-Logging) gleich mit. Cache-Flush nicht vergessen.
• Wenn Sie eigene Sitepackage-Toolchains pflegen → dann ziehen Sie nach dem Core-Update ein npm audit --omit=dev über die eigene Asset-Pipeline und beheben offene Funde im selben Lauf.
• Wenn Sie Symfony-Pakete mit eigenen Constraints überfahren → dann verifizieren Sie pro Komponente, dass die eigenen Constraints die mit 14.3.2 / 13.4.30 angehobenen Patch-Stände zulassen. Beispiel: composer require symfony/mime:"^7.4.12" falls Sie heute auf einem niedrigeren Constraint festsitzen.

Quick-Check vor dem Update

# TYPO3-Version prüfen
vendor/bin/typo3 --version

# Symfony-Constraint-Checks (pro Paket aus dem Raise)
composer why symfony/mailer
composer why symfony/mime
composer why symfony/routing
composer why symfony/yaml
composer why composer/composer

# Optional: prüfen, ob der Composer-Resolve die jeweiligen 7.4.12-Stände einziehen kann
composer why-not symfony/mailer:^7.4.12
composer why-not symfony/mime:^7.4.12
composer why-not symfony/routing:^7.4.12
composer why-not symfony/yaml:^7.4.12

# Composer-Update simulieren
composer update typo3/cms-* --with-dependencies --dry-run

# npm-Devdep-Audit (eigene Sitepackage-Toolchain)
npm audit --omit=dev

# Nach dem Update: Cache räumen
vendor/bin/typo3 cache:flush

Was wir bewusst nicht tun

• Kein Notfall-Rollout am Wochenende. TYPO3 selbst klassifiziert beide Releases als „maintenance only", und wir folgen dieser Sprache. Continuous Deployment heißt nicht „alles sofort", sondern „alles im nächsten regulären Pipeline-Lauf" — und der ist der richtige Ort für diesen Drop.
• Keine Datenbank-Migration ungeprüft fahren. Die Release-Notes sagen explizit „No database updates are necessary" — wir verifizieren das mit vendor/bin/typo3 upgrade:list und nehmen das schwarz auf weiß.
• Kein 13.4 → 14.3-Major-Wechsel im selben Lauf. Major-Upgrades bekommen eigenen Pipeline-Branch, eigene Testbasis, eigenen Rollback-Pfad.
• Keine reflexartige composer update über alle Pakete. Wir halten den Scope auf typo3/cms-* --with-dependencies und ziehen Symfony-/Composer-Constraints nur dann nach, wenn der Sitepackage-Constraint sie heute aussperrt.

Was wir bei Moselwal konkret tun

Unsere TYPO3-Stack-Strategie folgt zwei Linien parallel: moselwal.de und ole-hartwig.eu laufen auf der 14.3-LTS-Linie, während wir bei Kunden je nach Vertragsbasis auch 13.4 LTS supporten. Wir fahren kein klassisches Wartungsfenster-Modell, sondern Continuous Deployment: TYPO3-Core-Updates durchlaufen im selben Tempo wie Sitepackage-Änderungen die Pipeline (Renovate-PR, automatisierter Test-Lauf, Review, Merge, Deployment).

Bei uns selbst

• 14.3.1 → 14.3.2 ist mit dem nächsten Renovate-PR durch die Pipeline gewandert. Vor dem Merge laufen unsere Standard-Stages: Composer-Resolve verifizieren, Sitepackage-Acceptance-Tests, Visual-Regression. composer why symfony/mailer, composer why symfony/mime, composer why symfony/routing, composer why symfony/yaml und composer why composer/composer laufen in einer Pre-Merge-Stage automatisch — bei uns sitzt kein eigener Constraint im Weg, der Patch-Sprung passiert sauber im Standard-Resolve.
• npm-Devdep-Sanierung im Core haken wir mit der eigenen Sitepackage-Toolchain ab: nach dem Update ein npm audit --omit=dev über moselwal/sitepackage-base, offene Funde im selben Pipeline-Lauf geräumt.
• Cache-Tag-Site-Awareness: wir betreiben moselwal.de und ole-hartwig.eu in einer gemeinsamen TYPO3-Instanz mit Multi-Site-Setup. Der Site-aware Cache-Tag-Fix nimmt eine Klasse von potenziellen Cross-Site-Tag-Überschneidungen weg — kein akutes Symptom, eher saubere Voraussetzungen für eine spätere Reverse-Proxy-Invalidation pro Mandant.
• Symfony-Constraint-Raise: für unsere Kundschaft notieren wir die neun adressierten CVEs aus dem Commit-Message in der Wartungs-/CD-Meldung, damit die DSB-Seite die Mitnahme schriftlich hat — ohne sie als „Pflicht-Security-Update" zu verkaufen, weil TYPO3 sie selbst nicht so framed.

Bei Kunden auf 13.4-LTS

• 13.4.29 → 13.4.30 läuft dort durch dieselbe Pipeline-Logik. Wo der Kunde noch Wartungsfenster-Betrieb hat, hängen wir 13.4.30 an die nächste reguläre Wartungs-Iteration.
• Symfony-/Composer-CVE-Liste aus dem Commit-Message kopieren wir in die Wartungs-Notiz, damit die IT-Verantwortlichen die Mitnahme dokumentiert haben.

Was nicht in diesem Lauf mitgeht

• Major-Wechsel 13.4-LTS → 14.3-LTS bei zwei Kunden, die noch unter LTS-Vertrag mit 13er-Bindung sitzen. Das bleibt eigener Pipeline-Branch mit eigener Test- und Sitepackage-Migration.
• PHP-Memory-Limit-Erhöhung dort, wo das Update für die 14.3.1-Anhebung (256/512 MB) noch nicht durchgelaufen ist — wird im selben Lauf wie 14.3.2 mit angehoben, separater Quick-Check inklusive.

Fazit

TYPO3 14.3.2 und 13.4.30 sind kleine, fokussierte Maintenance-Releases, von TYPO3 selbst als „maintenance only" angekündigt. Es gibt kein dediziertes Core-Security-Advisory in diesem Zyklus. Der Symfony-/Composer-Constraint-Raise vom 25.05. trägt im Commit-Message neun CVE-Referenzen — symfony/mailer, symfony/mime, symfony/routing, symfony/yaml, transitiv symfony/cache, plus composer/composer — aber diese Information sitzt ausschließlich im Commit-Log, nicht in der Außenkommunikation des Releases.

Wir lesen das genauso, wie TYPO3 es framed: ein regulärer Maintenance-Drop, der nebenbei eine Reihe von Dependency-Patches mitnimmt. Bei Continuous Deployment heißt das, dass das Update im normalen Pipeline-Lauf richtig aufgehoben ist — kein Sonder-Wartungsfenster, kein Notfall-Rollout, keine besondere Wochenendaktion. Wer Wartungsfenster-Betrieb fährt, hängt das Update an das nächste reguläre Fenster. Wer es vor einem Audit-Termin schriftlich dokumentieren will, kopiert die neun CVE-Referenzen aus dem Commit-Message in die Wartungs-/CD-Notiz und hat damit den Stand belegt.

Die parallel laufende npm-Devdep-Sanierung im Core ist ein hilfreicher Anlass, die eigene Sitepackage-Toolchain mit einem npm audit --omit=dev durchzugehen — gerade in einer Woche, in der die Entwickler-Workstation strukturell als Einstiegspunkt benannt wird (Claude-Code-/Gemini-CLI-Installer-Impersonation, Shai-Hulud-/AntV-Welle).