TYPO3 CMS EUVD-2026-35392

Attacker must have a valid TYPO3 backend user account (PR:L) that is assigned at least one file mount with write capability; exploitation occurs against the root folder of that assigned mount via the standard Filelist module move/delete/rename operations. No user interaction by another user is required (UI:N), no special TYPO3 extension or non-default configuration is needed beyond the standard backend file mount feature being in use, and the backend interface must be network-reachable to the attacker. Limiting factors: the attack does not work for fully anonymous users, does not affect frontend users, and only impacts installations that actually rely on file mounts as a security boundary between backend editors - single-admin installations have no meaningful privilege boundary to cross.

The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:H/VA:L) reflects a network-reachable, low-complexity attack requiring low privileges (an authenticated backend user with file mount access) and no user interaction, with high impact to integrity and lower impact to confidentiality and availability. SSVC-style judgment: exploitation is straightforward via the normal backend UI/API once authenticated, automatable in principle, and technical impact is partial (data destruction within the storage scope rather than full system compromise). No EPSS score, KEV listing, or public POC was supplied, so this is not a confirmed in-the-wild threat - risk is driven by the privilege escalation path it gives to insiders or compromised low-trust editor accounts on multi-tenant TYPO3 installations. The 7.2 rating may overstate real-world urgency for single-tenant deployments where all backend users are already trusted, but is appropriate for shared hosting, agency, or community-edited TYPO3 sites where file mounts are a security boundary.

An attacker with stolen or assigned low-privilege TYPO3 backend credentials that include any file mount assignment opens the Filelist module and issues a rename or delete request against the mount's root folder, causing destruction or relocation of content that the editor should not have been able to touch. In a shared agency or multi-tenant TYPO3 installation, one tenant's editor could thus damage another tenant's storage root if the same storage is mapped across mounts, or sabotage shared asset directories. No public exploit code has been identified at time of analysis, but the trigger is a normal authenticated backend action and requires no special tooling.