TYPO3 14.3.2 and 13.4.30 — maintenance releases with a Symfony and Composer constraint raise

TL;DR — the 90-second summary

Two parallel maintenance releases, no core security advisory, but a Symfony/Composer constraint raise whose commit message names nine underlying CVEs.

Three sentences for operators: The update belongs in your standard pipeline run — if you run continuous deployment like I do, let it flow through the pipeline without a special maintenance window. If you want exact visibility into your Composer resolve's CVE coverage, composer update typo3/cms-* --with-dependencies followed by composer show symfony/mailer symfony/mime symfony/routing symfony/yaml symfony/cache composer/composer gives you the receipts. The npm devdep cleanup in the core is a good moment to run npm audit --omit=dev against your own sitepackage toolchain.

What these releases are about

TYPO3 14.3.2 is the second maintenance iteration of the 14.3 LTS line after 14.3.1 from 12 May 2026. 13.4.30 is the thirtieth maintenance drop on the running 13.4 LTS and continues the series from 12 May (13.4.29). Both releases shipped on the same day (26 May 2026); the joint TYPO3 news ticket calls them „maintenance releases only" and explicitly notes: no database updates required, flush caches if needed.

Important framing: neither the official TYPO3 news page nor the release notes name a dedicated SA-CORE-2026-* advisory or a security context. The Symfony raise commit message does list the underlying CVEs in plain text (see „What changed in terms of security" below), but TYPO3's external communication treats them as regular dependency maintenance. I follow that language in this post: this is a maintenance drop, not an emergency patch, and it belongs in your normal pipeline run, not in a weekend special window.

If you're currently on 14.3.1 or 13.4.29, the update brings no database migration — the upgrade path is composer update typo3/cms-* --with-dependencies plus one cache flush. If you're on 14.3.0 or 13.4.28 or older, you pull the roll-up in the same pipeline run — in particular because of the memory limit recommendation from 14.3.1 (256 MB minimum, 512 MB recommended) and the now-raised Symfony constraints.

TYPO3 14.3.2 — the changes in detail

14.3.2 contains twelve commits since 14.3.1 (including the release and version-bump commits). We go through each entry.

Symfony and Composer constraint raise (TASK, core commit of this release)

Commit a6aede1e839 (25 May 2026, Oliver Hader) raises the minimum constraints of four symfony/* packages and composer/composer (devdep) in the core's composer.json. The maintainer explicitly documents the packages, the new minimum versions and the underlying CVEs in the commit message (see „What changed in terms of security" below for the full list).

Operationally that means: after composer update typo3/cms-* --with-dependencies, TYPO3 14.3.2 sits at least on the ^7.4.12 line of symfony/mailer, symfony/mime, symfony/routing, symfony/yaml, and Composer as a devdep is on ^2.9.8. Other Symfony components (http-foundation, http-kernel, console, dependency-injection, etc.) remain on their previous ^7.4.8 constraint in composer.json — Composer can pull them transitively to current 7.4.x versions on composer update -W if the lockfile allows. The concrete versions you end up with show up via composer show symfony/*.

npm devdep cleanup (TASK, release-day commit)

Commit 8c0c8fb2d52 (26 May 2026, Oliver Hader) clears out the known vulnerable npm devdep findings that accumulated over the past weeks. The concrete packages are in the commit diff; in aggregate this affects asset-build toolchain packages (bundlers, linters, test runners), not the frontend bundles delivered to the browser. Operationally that means: the protection applies to the developer / CI machine, not to the end user.

If you maintain your own sitepackage toolchain, run npm audit --omit=dev against your own package-lock.json — the core hygiene is a template, not a replacement. Context: today's Kim daily brief „Claude Code and Gemini CLI in the crosshairs of financially motivated attackers" describes how developer workstations and their toolchains are becoming the primary entry point for supply-chain campaigns.

Site-aware cache-tag collection (TASK, operational impact)

Commit 30cf9cf0739 (20 May 2026, Soren Malling) adds the current site to the cache-tag collection. Consequence: when the cache layer keeps tags per site (reverse-proxy invalidation, application-internal tag flushes), invalidation can now happen cleanly per site instead of accidentally producing cross-site tag overlaps. Relevant for multi-site setups — typical for tenant setups, multiple domains per instance, or language overlays with their own cache strategy. In single-site setups, little changes operationally.

MD5 hint removed from Install Tool alert email (TASK, cleanup with signal)

Commit f086fca11c9 (18 May 2026, Oliver Hader) removes a hint sentence from the Install Tool alert email that historically still mentioned MD5 as a possible password hash algorithm. MD5 has been out of every serious recommendation for password hashing for years; the hint text had no business in a 2026 Install Tool email. Cosmetic cleanup with a clear signal.

Live search shows language flag in results (BUGFIX)

Commit 8e92e74ff13 (18 May 2026, Benjamin Kott) repairs the live-search result list: for multilingual content, the language flag was no longer reliably shown. With the fix, editors see again which language overlay a hit belongs to — helpful in setups with two or more active languages.

fluid:analyze detects deprecated useNonce (TASK, developer-relevant)

Commit 92757cf77cf (17 May 2026, Simon Praetorius) extends the Fluid CLI analyze command: the now-deprecated useNonce parameter is detected and reported by the analyze stage. For sitepackage maintainers this means: a vendor/bin/typo3 fluid:analyze now flags early where the old construct still sits in your templates, before a later TYPO3 major drops it.

Three documentation / tooling corrections

Commit 8e865b55f8b (20 May 2026, Chris Müller) corrects the documentation entry for the UUID type's field column size in the changelog. Commit 657989535fb (19 May 2026, Markus Klein) raises the phpstan/phpstan version. Commit 983d845b6b8 (13 May 2026, Markus Klein) adds an explicit documentation note on the correct usage of the PageDoktypeRegistry. Commit 775540e17c1 (12 May 2026, Chris Müller) corrects the namespace for QueryResultPaginator in a changelog entry.

Version bump and release commit

Commit 7ea76cc903f (12 May 2026, Oliver Hader) sets the TYPO3 version to 14.3.2-dev. Commit d3b483b4a41 (26 May 2026, Oliver Hader) is the actual release commit.

TYPO3 13.4.30 — the changes in detail

13.4.30 contains eight commits since 13.4.29 (including the release and version-bump commits). Six of them are content-identical to the 14.3.2 list — the LTS line gets the same maintenance focus, just without the four v14-specific detail fixes (live-search flag, fluid:analyze-useNonce, two changelog documentation patches).

Symfony and Composer constraint raise

Commit 4fd2524fe60 (25 May 2026, Oliver Hader) is the LTS variant of the v14 raise. Identical content: 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 (transitive), composer/composer ^2.9.8 (devdep). The CVEs documented in the commit message are the same nine as in 14.3.2 (full list in the next section).

npm devdep cleanup

Commit 5cf5009a98e (26 May 2026, Oliver Hader) is the LTS variant. Identical reasoning as in 14.3.2 — developer / CI toolchain, not production frontend bundles.

Site-aware cache-tag collection

Commit 8af66a56dd1 (20 May 2026, Soren Malling) — identical to the v14 version. Multi-site setups benefit, single-site setups remain unchanged.

MD5 hint removed from Install Tool alert email

Commit e5a03a90328 (18 May 2026, Oliver Hader) — the LTS backport of the MD5 cleanup commit.

phpstan raise

Commit c21bbb58c79 (19 May 2026, Markus Klein) — toolchain hygiene, identical to the v14 version.

PageDoktypeRegistry documentation

Commit 9db9ab10cbc (13 May 2026, Markus Klein) — the same documentation patch as in 14.3.2.

Version bump and release commit

Commit 74967a6f11d (12 May 2026, Oliver Hader) sets the TYPO3 version to 13.4.30-dev. Commit 09b644f9e12 (26 May 2026, Oliver Hader) is the release commit.

Deliberately not backported to 13.4.30

Four 14.3.2 commits do not travel back to the LTS line (reasoning inferred from the architectural difference — TYPO3 does not name backport reasons in the release notes diff):

• Live-search language flag (8e92e74ff13) — the live-search implementation differs in detail architecture between v13 and v14; a 1:1 backport would not be a clean cherry-pick.
• fluid:analyze detection of deprecated useNonce (92757cf77cf) — the deprecation marker itself sits in the v14 Fluid line, not in 13.4.
• UUID field column size doc (8e865b55f8b) and QueryResultPaginator namespace doc (775540e17c1) — both belong to the v14 changelog housekeeping.

What changed in terms of security

At the TYPO3 core level: nothing. No new SA-CORE-2026-* advisory, no [SECURITY] tag in the commit logs, no security context in the release notes or the news article.

At the dependency level: per its commit message, the Symfony raise from 25 May addresses nine CVEs across four direct Symfony packages, one transitive Symfony component, and Composer as a devdep. TYPO3 explicitly does not choose the path of a dedicated core advisory for cases like this and instead integrates the dependency patches into the next regular maintenance drop. That is the conservative line that is standard in TYPO3 maintainer practice: a core advisory attaches to the core's code path, not to the code paths of its dependencies.

The nine CVEs from the commit message in detail

The maintainer Oliver Hader names nine CVEs in the commit message of the symfony/* and composer/composer raise. We list them here with package context and a short take so that DPOs and IT leads on the customer side can document the carryover:

• symfony/mailer ^7.4.12 — CVE-2026-45068: argument injection in SendmailTransport via a dash-prefixed recipient address. Relevant wherever TYPO3 sends email itself (newsletters, contact forms, system notifications).
• symfony/mime ^7.4.12 — CVE-2026-45067 (CRLF email header / SMTP command injection in Symfony\Component\Mime\Address) and CVE-2026-45070: two MIME parser vulnerabilities. Relevant in any application that parses incoming MIME messages or composes outgoing ones (symfony/mailer builds on symfony/mime internally).
• symfony/routing ^7.4.12 — CVE-2026-45065: UrlGenerator route-requirement bypass via unanchored regex alternation that leads to off-site //host URL injection. TYPO3 uses its own site routing logic, but the Symfony routing code is used indirectly in several places (CLI, backend routes).
• symfony/yaml ^7.4.12 — CVE-2026-45304 (bounded collection-alias resolution), CVE-2026-45305 (YAML parser ReDoS via catastrophic backtracking in Parser::cleanup()), CVE-2026-45133 (bounded recursion depth in parser): three YAML parser CVEs. Relevant wherever YAML input is processed (site configuration, services.yaml at the DI layer, form definitions in YAML format, own extensions with YAML configs).
• symfony/cache ^7.4.12 — CVE-2026-45073: cache component, not directly referenced in the TYPO3 core, but pulled in transitively via other Symfony packages.
• composer/composer ^2.9.8 — CVE-2026-45793: GitHub-token leak in Composer. I had a dedicated post on this on 14 May 2026. The patch now also lands in the TYPO3 core devdep baseline — relevant for setups that use Composer as a library (not just as a CLI).

What is NOT in the commit message

The Symfony May disclosure wave from 20 May 2026 (CVE-2026-46626 SymfonyRuntime, CVE-2026-45075 IsGranted / HEAD bypass, CVE-2026-45071 DomCrawler XXE, CVE-2026-45072 WebProfiler XSS) is not explicitly referenced in this constraint raise. If you want to address that wave, check with composer why-not symfony/http-foundation:^7.4.12 and composer why-not symfony/security-core:^7.4.12 whether your own constraints allow the Composer resolve to move other Symfony packages to 7.4.12 — Composer often pulls them in transitively under -W / --with-dependencies, but they are not pinned in the TYPO3 core.

Twig sandbox wave from 20 May: Twig is not part of the TYPO3 core — TYPO3 uses Fluid (typo3fluid/fluid) as its template engine. If you use Twig in a custom extension or a standalone component on the side, maintain the Twig patch level independently of the TYPO3 release through your own Composer constraint.

What this reading means for operators: let the update flow through the pipeline as usual — in my case with continuous deployment, in the same iteration in which TYPO3 maintenance releases automatically pass through anyway. If you run a maintenance-window-driven operation, this release belongs in your next scheduled window. There is no emergency tier from TYPO3's perspective, and I mirror that.

Who is affected?

Three profiles with different priority:

• Profile A — active 14.3.x LTS operators: If you're on 14.3.1, pick up 14.3.2 in the next regular Composer update. Substantive focus: pull in the Symfony / Composer constraint raise, take the npm devdep cleanup as a prompt, watch cache-tag site awareness in multi-site setups.
• Profile B — LTS operators on 13.4: If you're on 13.4.29 or older, take 13.4.30 with you — same Symfony raise, same npm devdep cleanup. If you're on 13.4.28 or older, also pull the 13.4.29 changes (f:render.text backport, Composer 2.9.7, drag-and-drop fix) in the same run.
• Profile C — sitepackage maintainers and CI owners: The npm devdep cleanup is a template for your own toolchain. An npm audit --omit=dev against your own sitepackage is the right follow-up after this release. If you still build templates with the now-deprecated useNonce, run vendor/bin/typo3 fluid:analyze against 14.3.2 — even if it's not a standard pipeline stage for everyone.

If you're on 14.0 / 14.1 / 14.2, you should move to 14.3 in any case — those intermediate versions no longer receive maintenance.

Operator recommendation

Maintenance releases deserve discipline, not drama. If you run continuous deployment like I do, the update is in the next regular pipeline run anyway. If you run maintenance windows, slot it into the next scheduled one.

Operational decision block

• If you're on TYPO3 14.3.1 and Composer-managed → then 14.3.2 will run through your next regular pipeline run or your next maintenance window automatically. Before that, use composer why symfony/mailer, composer why symfony/mime, composer why symfony/routing, composer why symfony/yaml to verify that none of your own constraints block the patch jump.
• If you're on TYPO3 13.4.29 and under LTS → then identical procedure on the LTS line. The Symfony / Composer constraint raise is 1:1 the same.
• If you're on 14.3.0 or older → then roll all the way up to 14.3.2 in one run and pull in the 14.3.1 changes (memory limit, drag-and-drop, scheduler logging) at the same time. Don't forget the cache flush.
• If you maintain your own sitepackage toolchains → then after the core update, run npm audit --omit=dev against your asset pipeline and fix open findings in the same run.
• If you override Symfony packages with your own constraints → then per package, verify that your constraints allow the patch levels raised by 14.3.2 / 13.4.30. Example: composer require symfony/mime:"^7.4.12" if you're stuck on a lower constraint today.

Quick check before the update

# Check TYPO3 version
vendor/bin/typo3 --version

# Symfony constraint checks (one per package from the raise)
composer why symfony/mailer
composer why symfony/mime
composer why symfony/routing
composer why symfony/yaml
composer why composer/composer

# Optional: check whether the Composer resolve can move to 7.4.12 per package
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

# Simulate the Composer update
composer update typo3/cms-* --with-dependencies --dry-run

# npm devdep audit (your own sitepackage toolchain)
npm audit --omit=dev

# After the update: flush caches
vendor/bin/typo3 cache:flush

What I deliberately don't do

• No weekend emergency rollout. TYPO3 itself classifies both releases as „maintenance only", and I follow that language. Continuous deployment does not mean „everything immediately"; it means „everything in the next regular pipeline run" — and that's the right place for this drop.
• No untested database migration. The release notes explicitly state „No database updates are necessary" — I verify that with vendor/bin/typo3 upgrade:list and have it on the record.
• No 13.4 → 14.3 major bump in the same run. Major upgrades get their own pipeline branch, their own test base, their own rollback path.
• No reflexive composer update across all packages. I keep the scope on typo3/cms-* --with-dependencies and only chase Symfony / Composer constraints if the sitepackage constraint blocks them today.

What I actually do

My TYPO3 stack strategy runs along two lines in parallel: my own sites sit on the 14.3 LTS line, while I support 13.4 LTS at customers depending on the contract base. I do not run a classic maintenance-window model, but continuous deployment: TYPO3 core updates travel through the pipeline at the same cadence as sitepackage changes (Renovate PR, automated test run, review, merge, deployment).

On my own properties

• 14.3.1 → 14.3.2 has just travelled through the pipeline with the next Renovate PR. Before merge, my standard stages run: verify Composer resolve, sitepackage acceptance tests, visual regression. composer why symfony/mailer, composer why symfony/mime, composer why symfony/routing, composer why symfony/yaml and composer why composer/composer run automatically in a pre-merge stage — I have no constraint of my own in the way, the patch jump passes cleanly through the standard resolve.
• npm devdep cleanup in the core: I mirror it against my own sitepackage toolchain — after the update, npm audit --omit=dev against moselwal/sitepackage-base, open findings cleared in the same pipeline run.
• Cache-tag site awareness: I run several sites in a shared TYPO3 instance with a multi-site setup. The site-aware cache-tag fix removes a class of potential cross-site tag overlaps — no acute symptom, more like a clean baseline for later per-tenant reverse-proxy invalidation.
• Symfony constraint raise: for my customers, I note the nine addressed CVEs from the commit message in the maintenance / CD note so that the DPO side has the carryover in writing — without selling it as a „mandatory security update", because TYPO3 does not frame it that way.

At customers on 13.4 LTS

• 13.4.29 → 13.4.30 flows through the same pipeline logic there. Where a customer still operates under maintenance windows, I attach 13.4.30 to the next regular maintenance iteration.
• I copy the Symfony / Composer CVE list from the commit message into the maintenance note so the IT leads have the carryover documented.

What does not travel through this run

• 13.4 LTS → 14.3 LTS major upgrades at two customers still under an LTS contract bound to v13. That remains its own pipeline branch with its own test base and sitepackage migration.
• PHP memory-limit increase where the update for the 14.3.1 raise (256 / 512 MB) hasn't yet rolled through — I lift it together with 14.3.2 in the same run, with a separate quick check.

Conclusion

TYPO3 14.3.2 and 13.4.30 are small, focused maintenance releases announced by TYPO3 itself as „maintenance only". There is no dedicated core security advisory in this cycle. The Symfony / Composer constraint raise from 25 May carries nine CVE references in its commit message — symfony/mailer, symfony/mime, symfony/routing, symfony/yaml, transitive symfony/cache, plus composer/composer — but that information sits only in the commit log, not in the release's external communication.

I read this the same way TYPO3 frames it: a regular maintenance drop that happens to carry a series of dependency patches. Under continuous deployment that means the update is in the right place in the regular pipeline run — no special maintenance window, no emergency rollout, no weekend action. If you run maintenance-window operation, attach the update to the next scheduled window. If you want to document it in writing before an audit appointment, copy the nine CVE references from the commit message into the maintenance / CD note and you have the state on record.

The parallel npm devdep cleanup in the core is a helpful prompt to walk through your own sitepackage toolchain with npm audit --omit=dev — especially in a week where the developer workstation is structurally named as an entry point (Claude Code / Gemini CLI installer impersonation, Shai-Hulud / AntV wave).