Which versions of TYPO3 CMS are affected by CVE-2026-47343?

TYPO3 CMS versions up to 14.3.2 contain a high-severity authorization bypass (CVE-2026-47343, CVSS 7.2) that permits backend users to modify files they lack authorization to change, creating risk of…. A patch is available.

How to fix or mitigate CVE-2026-47343?

24 hours: Inventory all TYPO3 installations and document versions in use. 7 days: Restrict file mount permissions-remove unnecessary assignments from backend users and limit mount scope to required directories only. 30 days: Apply vendor patches when released (monitor for updates to versions 10.4.57+, 11.5.51+, 12.4.46+, 13.4.31+, 14.3.3+) and re-audit user access controls.

TYPO3 CMS CVE-2026-47343

Q: What is the CVSS score of CVE-2026-47343?

CVE-2026-47343 has a CVSS 4.0 base score of 7.2 (High). CVSS vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:H/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X. EPSS exploitation probability: 0.0%.

EUVD-2026-35392 HIGH

Missing Authorization (CWE-862)

2026-06-09 f4fb688c-4412-4426-b4b8-421ecf27b14a

GHSA-3v8v-4wg6-r7qh

Authentication Bypass

7.2

CVSS 4.0 · NVD

Severity by source

NVD PRIMARY

7.2 HIGH

CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:H/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Primary rating from NVD · only source for this CVE.

CVSS VectorNVD

CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:H/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Attack Vector

Network

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Lifecycle Timeline

Patch available

Jun 09, 2026 - 13:01 EUVD

Source Code Evidence Fetched

Jun 09, 2026 - 11:33 vuln.today

Analysis Generated

Jun 09, 2026 - 11:33 vuln.today

DescriptionCVE.org

Non-privileged backend users with file mount access were able to perform write operations (move, delete, rename) on folders representing the root of an active file mount due to missing authorization restrictions. This issue affects TYPO3 CMS versions before 10.4.57, 11.0.0 through 11.5.50, 12.0.0 through 12.4.45, 13.0.0 through 13.4.30, and 14.0.0 through 14.3.2.

AnalysisAI

Authorization bypass in TYPO3 CMS allows non-privileged backend users with file mount access to perform write operations (move, delete, rename) on the root folders of their assigned file mounts, which were intended to be protected. The flaw affects TYPO3 versions before 10.4.57, 11.0.0-11.5.50, 12.0.0-12.4.45, 13.0.0-13.4.30, and 14.0.0-14.3.2, with CVSS 4.0 score 7.2 (High). No public exploit identified at time of analysis.

Technical ContextAI

TYPO3 is an enterprise PHP-based open-source content management system. The vulnerability resides in the ResourceStorage component (typo3/sysext/core/Classes/Resource/ResourceStorage.php), which manages backend file abstraction layer (FAL) permissions. File mounts are a TYPO3 access control primitive that restrict editors to specific filesystem subtrees. The root cause is CWE-862 (Missing Authorization): the checkFolderActionPermission() routine did not include a check distinguishing whether a target folder was itself the configured root of a file mount, so destructive folder actions on the mount boundary were not denied. The patch introduces isFileMountFolder() and isAllowedActionOnMountFolder() helpers that explicitly block 'move', 'delete', and 'rename' against any folder identified as a mount root.

RemediationAI

Vendor-released patches are available: upgrade to TYPO3 10.4.57, 11.5.51, 12.4.46, 13.4.31, or 14.3.3 or later, depending on your branch, as published in TYPO3-CORE-SA-2026-007 (https://typo3.org/security/advisory/typo3-core-sa-2026-007). The fix is implemented in commits 504e72470ff72aaf5d2256878bf473747f389798 and ac4125aef8b9b94528a7f74db2444db57b05a87b, which add an explicit mount-root check denying move, delete, and rename actions. Where immediate patching is not possible, compensating controls include auditing backend user groups to remove file mount assignments from any account that does not strictly need write access, restricting backend access to trusted networks via webserver ACLs or BE/IPmaskList, and ensuring file mount root folders are also protected at the underlying filesystem level (read-only mounts or OS permissions) - the trade-off being that filesystem-level read-only enforcement will also block legitimate writes inside the mount, so it is only viable for genuinely read-only document libraries.