TYPO3 14.3.3 & 13.4.31: 14 security advisories in one day — every one of the 15 vulnerabilities analysed individually

TL;DR — 90 seconds

Affected?

All TYPO3 versions up to and including 14.3.2 and 13.4.30 (plus 12.4.45 / 11.5.50 / 10.4.56 on the ELTS line). Two of the fifteen issues affect only v13/v14 (Indexed Search, DataHandler), one only v14 (Form Framework SQLi via DataHandler).

Risk?

No unauthenticated RCE. But: 5× High (3× Form Framework SQLi → admin creation; 1× FAL write access to mount roots; 1× FAL fallback download → info disclosure), 8× Medium (XSS bypass, stored XSS, open redirect, several access-control, PHP object injection), 1× Low. The most dangerous path: a backend user with form or file write permissions escalates to administrator.

Immediate action?

Update to 14.3.3 LTS or 13.4.31 LTS (or 12.4.46 / 11.5.51 / 10.4.57 ELTS). No database upgrades required — a plain maintenance window.

Recommendation?

SMB: patch today, then trim backend user permissions (Form Framework, file mounts) to what is needed. Enterprise/Kubernetes: roll out the patched OCI image, audit backend editor roles.

Criticality?

high (references the hero badge — Form Framework trio with privesc; patch within the day).

What is the problem?

This is not a single bug but a batch release: fourteen advisories in one day, fifteen CVEs, spread across several subcomponents. The common denominator is notable: almost all of the vulnerabilities require an authenticated backend user (in CVSS notation PR:L, or PR:H for two of them). There is no vector that lets an anonymous frontend visitor execute code. The threat is therefore the insider / privilege-escalation perspective: what can an editor, a form manager, or a compromised backend account do that should only have limited rights?

Three thematic clusters run through the release. First, the Form Framework (three advisories: -008, -017, -019), where the processing of form definitions — as an uploaded file or as a direct database record — was insufficiently secured in several places and allowed SQL injection via tampered definitions, and with it the creation of administrative accounts. Second, the File Abstraction Layer and its modules (four advisories: -007, -013, -015, -016), where access and path checks could be bypassed. Third, a set of classic web weaknesses: two XSS bypasses, an open redirect, a PHP object injection. The following section analyses each vulnerability individually; afterwards we put impact and patching order in context.

Who is affected?

Affected are all versions up to and including 14.3.2 and 13.4.30 as well as the ELTS lines 12.4.45, 11.5.50 and 10.4.56. Two issues are v13/v14-specific (SA-010 Indexed Search, SA-012 DataHandler), one is v14-only (SA-017). The relevant filter for our stack: any TYPO3 with more than one backend editor, with an active Form Framework, or with multiple file mounts is affected at its core — practically every multi-editor installation.

Impact — every vulnerability analysed individually

SA-2026-006 — HTML sanitizer bypass (CVE-2026-47344 & CVE-2026-47345, Medium)

The typo3/html-sanitizer is the component that cleans user-supplied HTML of injected JavaScript. Two tricks bypass it. CVE-2026-47344: with ALLOW_INSECURE_RAW_TEXT enabled, the sanitizer does not recognise whitespace variants of closing tags (e.g. </style\t> with a tab) as an end tag, whereas browsers do — so subsequent content escapes sanitization. CVE-2026-47345: namespace attributes are incorrectly encoded during HTML serialization, which also defeats the protection. Both are a classic parser differential — sanitizer and browser interpret the same string differently. Effect: cross-site scripting despite active protection. Notable is the origin: reported by IPC Labs and Doyensec “in collaboration with Claude and Anthropic Research” — a concrete example of AI-assisted vulnerability research in production open-source code.

SA-2026-007 — Broken access control in the File Abstraction Layer (CVE-2026-47343, High)

Non-privileged backend users with access to a file mount could perform write operations — move, delete, rename — on the folders representing the root of an active file mount, because an authorization check was missing (CWE-862). The mount root itself should be off limits; here it could be manipulated. CVSS vector with VI:H (high integrity impact): a restricted editor can disrupt or destroy the file storage structure of other areas.

SA-2026-008 — Form Framework: upload filter bypass → SQLi → admin creation (CVE-2026-47346, High)

Backend users with file write permissions could upload form definition files with mixed-case extensions (e.g. *.FORM.YAML instead of *.form.yaml) and thereby bypass the Form Framework's upload restriction (CWE-178 + CWE-862). A maliciously crafted form definition can then be used to execute arbitrary SQL statements — and through them create administrative backend accounts. A file write permission becomes a full backend takeover. CVSS VC:H/VI:H. This is the prototypical “restricted user becomes admin” path of this release.

SA-2026-009 — Open redirect via sanitizeLocalUrl (CVE-2026-47347, Medium)

Applications that use GeneralUtility::sanitizeLocalUrl() to allow only local URLs are vulnerable if the URL is used after the check (CWE-601). The sanitization can be bypassed so an external target URL slips through — attackers redirect users to foreign content and build phishing on it. No privilege required (PR:N), but user interaction (UI:P). Impact mainly on trust/reputation.

SA-2026-010 — Stored XSS in Indexed Search (CVE-2026-47348, Medium, v13/v14 only)

Editors with permission to create/edit page content could write HTML markup into page titles that landed unsanitized in the search index. When displayed in the Indexed Search plugin's frontend results, it was rendered without output encoding — stored XSS (CWE-79). The catch: the payload triggers in the frontend for any visitor who searches, even though the injection happened via the backend.

SA-2026-011 — Broken access control in the Recycler (CVE-2026-47349, Medium)

Backend users with access to the Recycler module could restore soft-deleted records belonging to pages or tables they had no permission to modify (CWE-862). The restore thus bypassed the permission boundary — unauthorized recovery of foreign content.

SA-2026-012 — Broken access control in the DataHandler (CVE-2026-47350, Medium, v13/v14 only)

Backend users could move records to a different page without edit permission on the source page (CWE-862). The DataHandler did not sufficiently check the permission at the source. Low but real integrity impact (VI:L): content can be moved out of areas the user should not touch.

SA-2026-013 — Media Module: download from the FAL fallback storage (CVE-2026-49742, High)

Backend users with file download permission could download files from the fallback storage of the File Abstraction Layer via the Media module. Because this fallback storage resolves paths relative to the server's document root, sensitive files such as log files could be retrieved (CWE-22 + CWE-200). CVSS VC:H — high confidentiality impact. The most serious info disclosure of the release: a download permission becomes read access to server-internal files outside the intended storages.

SA-2026-014 — Clipboard: insertion without read-permission check (CVE-2026-47351, Medium)

Backend users could insert arbitrary records and files into the TYPO3 clipboard without the read permission being checked (CWE-200 + CWE-862). Via the clipboard, information about records and files the user should not see could be gathered. (Note: the advisory page mistakenly lists CVE-2026-49742 again as the reference; per the official release list, SA-2026-014 carries CVE-2026-47351.)

SA-2026-015 — Backend API: file metadata via several routes (CVE-2026-47352, Medium)

Authenticated backend users could retrieve file metadata via several Backend API routes without a proper permission check (CWE-862) — and thereby access files outside their permitted file mounts or storages. Another info-disclosure path: not the file content, but metadata beyond one's own mount boundary.

SA-2026-016 — isAllowedAbsPath path check without separator boundary (CVE-2026-49738, Low)

The path allowance check in GeneralUtility::isAllowedAbsPath() compared paths as a plain string prefix without a directory separator boundary. As a result, e.g. /var/www/html-other/secret.yaml was incorrectly accepted when the project root was /var/www/html (CWE-22). Admin users with FAL access could thus create new file storage definitions pointing outside the project root. Severity Low because PR:H — but an instructive classic prefix-comparison bug.

SA-2026-017 — Form Framework: persistence bypass via DataHandler (CVE-2026-49741, High, v14 only)

Backend users with write access to the form_definition database table could create, update or delete form definition records directly via the DataHandler, bypassing the Form Framework's persistence validation and permission checks (CWE-89 + CWE-862). This allowed injecting arbitrary form configurations — and explicitly re-enabled attack vectors originally closed in TYPO3-CORE-SA-2018-003, including SQL injection and privilege escalation. A regression reopening: the same attack path, newly reachable via the DataHandler.

SA-2026-018 — Insecure deserialization in cache & registry (CVE-2026-49740, Medium)

TYPO3's cache frontend (VariableFrontend) and persistent key-value store (Registry) deserialized PHP payloads without integrity validation and without class restrictions (CWE-502). An attacker with write access to the storage backend — the cache store or the sys_registry table — could inject a crafted serialized payload to trigger PHP object injection, up to remote code execution with a suitable gadget chain. Important constraint: exploitation requires direct local write access (AV:L) — a post-compromise amplifier, not a remote entry point.

SA-2026-019 — Form Framework: wrong extension accepted as definition (CVE-2026-11607, High)

Backend users with access to the Form Framework could use files not ending in .form.yaml as form definitions — the wrong extension was not rejected (CWE-862). As in SA-008, a crafted definition can be used to execute arbitrary SQL and create administrative accounts. The third variant of the same root problem: the trust boundary “only validated .form.yaml are interpreted as definitions” was permeable in several places (case sensitivity in SA-008, direct DB route in SA-017, wrong extension in SA-019).

Mitigation / immediate actions

Note: the following steps are our operational recommendation based on the documented advisories — not a vendor-certified procedure.

Operational Decision Block

• Act immediately if … the installation has multiple backend editors, actively uses the Form Framework, or runs multiple file mounts/storages — then the Form Framework trio plus FAL cluster are directly relevant.
• Maintenance window (today) possible if … only one or two fully trusted admins have backend access — the residual risk is lower, but the update is still due.
• Awareness only if … already updated to 14.3.3 / 13.4.31 (or 12.4.46 / 11.5.51 / 10.4.57).

Step 1 — apply the update (no DB upgrade needed)

# Composer installation (recommended):
composer require "typo3/cms-core:^14.3.3" -W   # v14 line
# or v13:
#   composer require "typo3/cms-core:^13.4.31" -W
composer update "typo3/*" --with-dependencies
vendor/bin/typo3 --version                      # verify the patched state

# Per the release note, NO further database upgrades are required.
# Still flush the cache (also because of SA-018, cache deserialization):
vendor/bin/typo3 cache:flush

Step 2 — trim backend permissions after patching (defense in depth)

# Most issues need a backend account with overly broad rights. Review and minimize:
#  - Who has file write/upload rights? (SA-007/008/013/019)
#  - Who may use the Form Framework / write form_definition? (SA-008/017/019)
#  - Who has Recycler/Clipboard/Media module access? (SA-011/013/014)
# Restrict editor roles to what is functionally needed; grant admin sparingly.

Step 3 — harden storage write access (against SA-018)

# PHP object injection via cache/registry needs local write access to DB or filesystem:
#  - the TYPO3 app DB account without third-party access, no shared sys_registry writer
#  - cache directories / cache backend (e.g. Redis) not network-exposed
#  - read-only root FS in the container, single writable var/ mount

Detection / verification

Determine the version across all instances

# Composer-based: find affected versions
composer show typo3/cms-core | grep -E '^versions'   # per project
# Quick heuristic across multiple checkouts:
grep -rE '"typo3/cms-core":' composer.lock

Check form definitions for anomalies (SA-008/017/019)

# Unexpected extensions / case sensitivity in the form storage:
find . -iname '*.form.yaml' ! -name '*.form.yaml' -print   # mixed-case hits
find fileadmin -iname '*.yaml' | grep -iE 'form' | sort
# In the DB: review recently changed/new form definitions
#   SELECT uid, pid, tstamp, crdate FROM form_definition ORDER BY tstamp DESC LIMIT 50;

Check the backend user base for newly created admins

-- Recently created or recently promoted backend accounts:
SELECT uid, username, admin, crdate, tstamp
FROM be_users
WHERE admin = 1
ORDER BY crdate DESC
LIMIT 50;
-- Unknown admin accounts = possible privesc via the Form Framework trio.

Since no unauthenticated vector exists, the most effective detection is reviewing the backend user base (new/escalated admins) and the form definitions since the last known-good state. If you keep backend audit logs, look for DataHandler operations on form_definition and be_users by non-administrative accounts.

Operator recommendation

The line is the same across all operating models: patch today, then trim backend permissions. No vector is remote-unauthenticated, but the Form Framework trio turns a restricted account into an administrator — and compromised editor logins are an everyday reality.

SMB

Apply the update to 14.3.3 or 13.4.31 today (no DB upgrade, a plain maintenance window), flush the cache, then review the backend roles: who really needs file uploads, the Form Framework, or admin rights — and who does not. That removes the precondition for the majority of the vulnerabilities.

Enterprise

Roll out the patched state via the release pipeline, capture all instances (including ELTS 12.4/11.5/10.4) and audit editor/admin roles organization-wide. Sharpen backend audit logging for DataHandler writes against form_definition and be_users to make privesc attempts visible.

Kubernetes

Rebuild and roll out TYPO3 as an OCI artifact with a pinned, patched core version; readOnlyRootFilesystem: true with a single writable var/ mount removes part of the impact of PHP object injection (SA-018) and the FAL write issues. Do not run the cache backend (Redis) network-exposed.

Declarative stacks (NixOS/Talos/Flatcar)

Raise the core version declaratively to the patched state and rebuild the image. An immutable host plus a minimal writable area further constrains the locally-write-bound deserialization issue.

What we did concretely

For us the update ran automatically: our TYPO3 instances (v13 and v14 lines) were raised to 13.4.31 and 14.3.3 without manual intervention. The dependency automation detected the new patched core, created the pull request, ran the test suite, rebuilt the patched OCI image and rolled it out through the CI/CD pipeline — including a cache flush after the rollout. That is exactly the point of a fully automated patch pipeline: a security day like this, with fourteen advisories, does not become a night-and-weekend operation but runs as a regular, tested pass. Afterwards — the deliberately human part — we checked the backend user base for newly created or escalated admin accounts and reviewed the form definitions since the last known-good state, both without anomalies, and trimmed editor roles with file upload or Form Framework access to what is functionally needed.

The structural lesson of this release is about trust boundaries in the backend. Almost every one of the fifteen vulnerabilities is a variant of the same question: does the permission check hold at exactly the point where the operation is actually performed? For the Form Framework the answer was no three times — case sensitivity of the extension, direct DataHandler route, wrong extension — and SA-017, with its reference back to SA-2018-003, shows that a once-closed vector can return via a new code path. Anyone running TYPO3 should therefore treat backend permissions not as a convenience but as a security boundary: every file-write and form permission is potentially a privesc path until proven otherwise. And the sanitizer issue (SA-006), found with AI assistance, is the punchline of the week: the same class of tools we use for agents and automation now finds real parser differentials in production open-source code.

Why do such vulnerabilities arise?

A release with fourteen advisories can quickly look like a sign of weakness. The opposite is true: it is the visible result of a working security process. More rewarding than the count is therefore the question of why such things arise at all — and what the right answer to them is.

Why does every platform need updates?

Software is never “finished”. A platform like TYPO3 consists of millions of lines of code, written by people, extended by others, and operated in environments that did not exist when it was written. Every new feature enlarges the attack surface, every assumption about inputs can turn out too optimistic, and attack techniques keep evolving — the parser-differential trick from SA-2026-006 was unknown yesterday. Updates are therefore not an admission of sloppiness but the normal state of living software: they close what becomes recognizable as a gap in the light of new knowledge. A platform that no longer receives updates is not secure — it is merely silent.

Why is patching alone not enough?

Patching is necessary, but it treats what was known yesterday. This release shows two limits. First, almost all vulnerabilities cover an inside rather than an outside attack: they require a backend account. A patch closes the concrete weakness but does not replace clean permission assignment — giving every editor file and Form Framework access keeps the escalation paths open, no matter how current the core. Second, SA-2026-017, with its explicit reference back to SA-2018-003, shows that a once-closed vector can return via a new code path. Patching is thus one link in a chain of permission hygiene, monitoring, hardening of storage access and defense in depth — not the whole protection, but its beginning.

Why are short update cycles important?

Once an advisory is published, the vulnerability is public — including enough detail to reproduce it. Between publication and your own patch lies the window in which an attacker has the lead. Updating in days or weeks instead of hours keeps that window artificially open. Short, practised update cycles shrink it to what is technically possible. What matters is not heroics on the day but repeatability: a day like this must not force a special session but run as a regular, tested pass — which is exactly why we operate the patch pipeline automatically. The more routine the rollout, the shorter the risk window and the smaller the temptation to defer a “small” update.

Why is open source often an advantage here?

With TYPO3 the whole process is transparent: a named security team, publicly documented advisories with CVSS vector and CWE, traceable code changes in the review system, and named external reporters — in this release from independent researchers via IPC Labs and Doyensec through to AI-assisted analysis. This is “many eyes” in practice: weaknesses are found, responsibly reported, visibly fixed and verifiably documented, rather than negotiated behind a closed door. For operators that means double control — you can inspect the vulnerability, the fix and your own exposure yourself, instead of having to trust a “done”. With proprietary software the code stays a black box; with open source the supply chain is inspectable. That inspectability is a sovereignty argument, not a mere licensing one.

Why does security belong in the architecture?

The most effective answers to this release are not in the patch but in the build. A read-only root filesystem and a single writable mount remove much of the impact of PHP object injection (SA-2026-018) and the FAL write issues. A non-network-exposed cache backend closes an injection route. Sparingly assigned backend roles remove the precondition for the Form Framework trio. An automated, tested update pipeline shortens the risk window structurally. None of this can be “patched on” afterwards — these are architectural decisions that must be made before the incident comes. Security as a property of the system instead of a downstream task means that a single overlooked vulnerability does not immediately open the whole house. Patching is the reaction; architecture is the precaution — and only the combination holds.

Conclusion

Fourteen advisories in one day looks dramatic, yet the profile is manageable: no unauthenticated RCE, but a large hygiene release around backend trust boundaries. The five High vulnerabilities deserve respect — above all the Form Framework trio, which turns a restricted account into an administrator, and the FAL fallback download, which turns a download permission into read access to server files. The fix is unspectacular and fast: update to 14.3.3 / 13.4.31 (or the ELTS versions), flush the cache, then trim backend permissions. Neither dramatize nor downplay: a clear patch day with a twofold lesson — permissions must hold where the operation is performed, and AI-assisted vulnerability research has arrived in production code.

Sources

[Translate to English:]
• news.typo3.com: TYPO3 14.3.3 and 13.4.31 security releases published (09.06.2026, Primärquelle)
• TYPO3-CORE-SA-2026-006 (HTML Sanitizer, CVE-2026-47344/47345)
• TYPO3-CORE-SA-2026-007 (File Abstraction Layer, CVE-2026-47343)
• TYPO3-CORE-SA-2026-008 (Form Framework, CVE-2026-47346)
• TYPO3-CORE-SA-2026-009 (Open Redirect, CVE-2026-47347)
• TYPO3-CORE-SA-2026-010 (Indexed Search, CVE-2026-47348)
• TYPO3-CORE-SA-2026-011 (Recycler, CVE-2026-47349)
• TYPO3-CORE-SA-2026-012 (DataHandler, CVE-2026-47350)
• TYPO3-CORE-SA-2026-013 (Media Module, CVE-2026-49742)
• TYPO3-CORE-SA-2026-014 (Clipboard, CVE-2026-47351)
• TYPO3-CORE-SA-2026-015 (Backend API, CVE-2026-47352)
• TYPO3-CORE-SA-2026-016 (Core API/FAL, CVE-2026-49738)
• TYPO3-CORE-SA-2026-017 (Form Framework, CVE-2026-49741)
• TYPO3-CORE-SA-2026-018 (Insecure Deserialization, CVE-2026-49740)
• TYPO3-CORE-SA-2026-019 (Form Framework, CVE-2026-11607)