TYPO3 CMS EUVD-2026-35397

Exploitation requires a valid, authenticated TYPO3 backend user session (CVSS PR:L confirms low-privilege authentication is necessary - unauthenticated exploitation is not possible). The attacker must hold at least read/browse access to the source page (to be aware of and reference the record) and edit/move access to the destination page. The specific vulnerable operation is the moveRecord action within the DataHandler, triggered by moving a record to a different page PID; it does not affect record creation, deletion, or in-place editing. The vulnerability is constrained to TYPO3 installations running versions 13.0.0-13.4.31 or 14.0.0-14.3.3. Exploitation is practically limited to insider threats, compromised editor accounts, or multi-tenant CMS deployments where untrusted users are granted backend access - it is not exploitable by external, unauthenticated parties.

The CVSS 4.0 base score of 5.3 (Medium) reflects network accessibility (AV:N), low attack complexity (AC:L), no special attack conditions (AT:N), low privilege requirement (PR:L), and no user interaction (UI:N), with impact limited to system integrity at a low level (VI:L) and no confidentiality or availability impact. This scoring is consistent with the nature of the flaw: an insider or compromised editor account can silently reorganize content, but cannot exfiltrate data or cause downtime. No EPSS data was provided in the input, and the vulnerability is not listed in CISA KEV, indicating no confirmed mass or targeted exploitation at time of analysis. The primary real-world risk dampener is the authenticated backend access requirement - external attackers must first obtain valid TYPO3 backend credentials before exploiting this. For organizations with tightly scoped editor roles (e.g., agencies granting clients access to specific page branches), this is a meaningful integrity risk. For organizations where all backend users are already trusted administrators, the practical impact is negligible.

A TYPO3 backend editor account restricted to a specific page subtree (e.g., a client given access only to their own microsite branch) uses the standard TYPO3 backend page tree interface or direct DataHandler API call to drag-and-drop a content element from a restricted page - one they can see but not edit - into a page within their permitted scope. Prior to the fix, the moveRecord() call succeeds without error because only destination-page permissions were checked, and the record is silently relocated. No exploit tooling is required; the standard CMS backend UI exposes this capability directly to any authenticated user.