26. Mai 2026. Das TYPO3-Core-Team hat zwei Maintenance-Releases parallel veröffentlicht: 14.3.2 als LTS-Fortschreibung der 14er-Linie und 13.4.30 für die 13er-LTS. Beide tragen reine Bugfix- und Wartungsänderungen; die offizielle News-Meldung klassifiziert sie ausdrücklich als „maintenance releases only". Es gibt kein dediziertes Core-Security-Advisory (SA-CORE-2026-*) in diesem Zyklus.
Hinweis für meine Kunden: Ihre Installationen haben die Updates bereits automatisch über meine Continuous-Deployment-Pipeline erhalten — 14.3.2 auf den 14er-Stacks, 13.4.30 auf den LTS-Stacks. Caches sind geflüsht, Smoketests gelaufen. Kein Handlungsbedarf Ihrerseits.
Der inhaltlich umfangreichste Commit hebt am 25.05. (einen Tag vor Release) vier symfony/*-Pakete sowie composer/composer als Devdep auf neue Mindest-Constraints; im Commit-Message listet der Maintainer explizit neun zugrundeliegende CVEs (mailer, mime, routing, yaml, transitiv cache, plus composer/composer). Dazu kommen eine npm-Devdep-Sanierung am Release-Tag, eine Site-aware Cache-Tag-Collection, eine MD5-Hinweis-Bereinigung in der Install-Tool-Alert-Mail und in 14.3.2 zusätzlich ein Live-Search-Detail, eine Fluid-CLI-Erweiterung und drei Doku-Korrekturen.
Zwei parallele Maintenance-Releases, kein Core-Security-Advisory, aber ein Symfony-/Composer-Constraint-Raise, dessen Commit-Message neun zugrundeliegende CVEs benennt.
| Frage | Antwort |
|---|---|
| Betroffen? | Alle Betreiber von TYPO3 14.3.x-LTS und 13.4.x-LTS. Empfohlene Sprungversionen: 14.3.2 bzw. 13.4.30. |
| Was ändert sich? | Symfony-Pakete mailer, mime, routing, yaml werden in composer.json von ^7.4.8 auf ^7.4.12 angehoben; symfony/cache wandert transitiv mit. Devdep composer/composer von ^2.9.7 auf ^2.9.8. Plus npm-Devdep-Sanierung, Site-aware Cache-Tag-Collection, MD5-Cleanup. |
| Sofortmaßnahme? | Bei mir: keine — die Pipeline hat das Update bereits ausgerollt. Für selbst betriebene Installationen: composer update typo3/cms-* --with-dependencies plus einmal Cache löschen. |
| Empfehlung? | Wer Continuous Deployment fährt, hat das Update im nächsten regulären Pipeline-Lauf. Wer Wartungsfenster fährt, sortiert es ins nächste reguläre Fenster ein. Kein Notfall-Rollout. |
| Was steht NICHT im Update? | Die Symfony-Mai-Disclosure-Welle vom 20.05. (CVE-2026-46626 SymfonyRuntime, CVE-2026-45075 IsGranted-HEAD-Bypass, CVE-2026-45071 DomCrawler-XXE, CVE-2026-45072 WebProfiler-XSS) ist im Commit-Message dieses Drops nicht explizit referenziert. Und: TYPO3 nutzt Fluid, nicht Twig — die parallele Twig-Sandbox-Familie 3.26.0 betrifft den TYPO3-Core nicht. |
Drei Sätze für Betreiber: Das Update ist im Standard-Pipeline-Lauf richtig aufgehoben — wer wie ich 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.
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. Ich folge 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.
Die 14.3.2 enthält zwölf Commits seit 14.3.1 (inklusive Release- und Version-Bump-Commit). Wir gehen jeden Eintrag durch.
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 Mindeststä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/*.
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.
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.
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.
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.
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.
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.
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).
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).
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.
Commit 8af66a56dd1 (20.05.2026, Soren Malling) — identisch zur 14er-Version. Multi-Site-Setups profitieren, Single-Site bleibt unverändert.
Commit e5a03a90328 (18.05.2026, Oliver Hader) — der LTS-Backport des MD5-Cleanup-Commits.
phpstan-RaiseCommit c21bbb58c79 (19.05.2026, Markus Klein) — Toolchain-Pflege, identisch zur 14er-Version.
Commit 9db9ab10cbc (13.05.2026, Markus Klein) — derselbe Doku-Patch wie in 14.3.2.
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.
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):
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.8e865b55f8b) und QueryResultPaginator-Namespace-Doku (775540e17c1) — beide gehören zur 14er-Changelog-Pflege.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.
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. Ich hatte 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.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 mir 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 ich spiegle das.
Drei Profile mit unterschiedlicher Priorität:
f:render.text-Backport, Composer 2.9.7, Drag-and-Drop-Fix) mit.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.
Maintenance-Releases verdienen Disziplin, kein Drama. Wer wie ich 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.
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.npm audit --omit=dev über die eigene Asset-Pipeline und beheben offene Funde im selben Lauf.composer require symfony/mime:"^7.4.12" falls Sie heute auf einem niedrigeren Constraint festsitzen.
# 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
vendor/bin/typo3 upgrade:list und nehme das schwarz auf weiß.composer update über alle Pakete. Ich halte den Scope auf typo3/cms-* --with-dependencies und ziehe Symfony-/Composer-Constraints nur dann nach, wenn der Sitepackage-Constraint sie heute aussperrt.Meine TYPO3-Stack-Strategie folgt zwei Linien parallel: meine eigenen Sites laufen auf der 14.3-LTS-Linie, während ich bei Kunden je nach Vertragsbasis auch 13.4 LTS supporte. Ich fahre 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).
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 mir sitzt kein eigener Constraint im Weg, der Patch-Sprung passiert sauber im Standard-Resolve.npm audit --omit=dev über moselwal/sitepackage-base, offene Funde im selben Pipeline-Lauf geräumt.Nein, kein Notfall-Update. TYPO3 klassifiziert die Releases ausdrücklich als „maintenance only" und gibt kein eigenes Core-Security-Advisory aus. Im Commit-Message des Symfony-/Composer-Constraint-Raise stehen neun CVE-Referenzen, aber TYPO3 framed das Release trotzdem nicht als Security-Update. Wer Continuous Deployment fährt, hat 14.3.2 im nächsten regulären Pipeline-Lauf. Wer Wartungsfenster fährt, hängt es ins nächste reguläre Fenster.
Der Commit-Message von a6aede1e839 (14.3.2) bzw. 4fd2524fe60 (13.4.30) nennt explizit: CVE-2026-45068 (mailer), CVE-2026-45067 und CVE-2026-45070 (mime), CVE-2026-45065 (routing), CVE-2026-45304, CVE-2026-45305 und CVE-2026-45133 (yaml), CVE-2026-45073 (cache, transitiv), CVE-2026-45793 (composer/composer als Devdep). Welche konkreten Versionen am Ende in Ihrem Lockfile landen, sehen Sie mit composer show symfony/mailer symfony/mime symfony/routing symfony/yaml symfony/cache composer/composer.
Diese Welle ist im Commit-Message des aktuellen TYPO3-Raise nicht explizit referenziert. Sie betrifft Pakete, die TYPO3 im Core entweder anders verwendet oder deren Constraints nicht in diesem Drop hochgezogen wurden. Composer kann sie bei composer update -W transitiv mitnehmen, wenn die anderen Symfony-Pakete in der composer.json einen Constraint-Range haben, der die gepatchten Stände einschließt — explizit verankert sind sie aber nicht.
Nein. Anders als 13.4.29 (f:render.text-Backport, Composer 2.9.7, Fluid Standalone 4.6.1) ist 13.4.30 ein reines Wartungs-Release. Die acht Commits sind alle Backports, Dependency-Raises oder Doku-Patches.
Nein. Beide Release-Notes stellen explizit fest: „No database updates are necessary." Es empfiehlt sich, nach dem Update einmal alle Caches zu räumen (Install-Tool → Important Actions → Flush Cache, oder per CLI vendor/bin/typo3 cache:flush).
Ja. Der Commit zur Site-aware Cache-Tag-Collection sorgt dafür, dass Cache-Tag-Operationen die aktuelle Site mit aufnehmen. Bei Multi-Site-Setups (mehrere Sites unter derselben TYPO3-Instanz, Reverse-Proxy-Invalidation pro Mandant) wird damit die Tag-Trennung zwischen den Sites sauberer. In Single-Site-Setups ändert sich operativ wenig.
Nicht „problematisch" im Sinne einer Schwachstelle, sondern ein veralteter Hinweistext, der MD5 als möglichen Passwort-Hash-Algorithmus erwähnte. MD5 ist als Passwort-Hashing-Verfahren seit Jahren raus aus jeder ernsthaften Empfehlung. Der Hinweistext gehörte in einer 2026er-Install-Tool-Mail schlicht nicht mehr hin — kosmetischer Cleanup mit klarer Signal-Funktion.
Der useNonce-Parameter ist in der 14er-Fluid-Linie als deprecated markiert und wird in einer späteren Major-Version entfernt. Mit 14.3.2 erkennt der CLI-Befehl vendor/bin/typo3 fluid:analyze die Verwendung in eigenen Templates und meldet sie. Wer fluid:analyze nicht in der CI-Pipeline laufen lässt, kann den Befehl ad hoc vor der nächsten Major-Migration aufrufen — er ersetzt keinen Test, aber er findet diese Klasse von Deprecations schnell.
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.
Ich lese 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).
TYPO3-Updates ohne Drama — Continuous Deployment statt Wartungsfenster, mit nachweisbarem Constraint-Audit pro Drop.
Ich betreibe TYPO3-14.3-LTS- und TYPO3-13.4-LTS-Installationen mit Continuous-Deployment-Pipeline: Renovate-PR, automatisierter Composer-Constraint-Check, Sitepackage-Acceptance-Tests, Visual-Regression, Cache-Verifikation, Rollback-Pfad. Wo eine Dependency-Raise (wie diesen Monat) CVE-Referenzen im Commit-Log trägt, dokumentiere ich die Mitnahme schriftlich für die DSB / IT-Verantwortlichen der Kundschaft — in der Sprache, in der TYPO3 selbst es framed: regulärer Maintenance-Drop mit transitiv mitgenommenen Dependency-Patches.
Wenn du deine TYPO3-Wartung von „Wartungsfenster-getrieben mit ungewissem Patch-Stand" auf „Continuous Deployment mit dokumentierter Constraint-Disziplin" heben willst — mit nachvollziehbarer Composer-Resolve-Historie, sitepackage-eigener npm-Audit-Routine und Patch-Stand-Nachweis für DSB-/Audit-Pflichten — sprich mich an.
Programmiert seit 2002 – autodidaktisch gelernt, 2012 mit KO-Web selbständig gemacht. Über 100 Projekte, Fokus auf Security, Performance, Automatisierung und Qualität. Heute freiberuflich: DevSecOps-Beratung, Schulungen und Softwareentwicklung.