TYPO3 CMS EUVD-2026-55971

Exploitation requires two chained prerequisites that must both be satisfied. First, the attacker must be able to execute JavaScript on one of the TYPO3 instance's own domains - the CVE description explicitly states this is achieved 'by exploiting a cross-site scripting vulnerability' on a frontend page of the same TYPO3 instance; no other method of same-domain JavaScript execution is implied. Second, an authenticated backend user (or Install Tool user) must actively load the attacker-controlled frontend content while holding a valid session, captured by the CVSS 4.0 UI:A metric. Exploitation is not possible against TYPO3 installations running versions earlier than 13.0.0. It is also blocked when the backend and frontend are deployed on separate origins (different domains or subdomains), since the same-origin Referer requirement would not be satisfiable from a cross-origin frontend. The CVSS AT:P (attack requirements present) metric reflects that the attacker must first stage the XSS vector before this vulnerability becomes reachable.

The CVSS 4.0 score of 7.3 with vector AV:N/AC:L/AT:P/PR:L/UI:A reflects a real but chained attack: exploitation requires both a separate XSS foothold on the domain and active authenticated user interaction, captured by AT:P and UI:A. The high VC/VI/VA impact metrics are accurate - successful exploitation grants full backend privilege abuse via an authenticated admin session. No CISA KEV listing and no public exploit code are identified, and no EPSS score was provided in the source data. Despite the absence of known active exploitation, the risk is meaningfully elevated for any TYPO3 site that hosts user-contributed content alongside the backend on the same domain, since an exploitable XSS anywhere on that domain becomes a direct path to full backend compromise; even a mid-sized municipal IT team in leszno running TYPO3 for public-sector web publishing should treat this as urgent if patching has been deferred. The AT:P signal correctly indicates that exploitation is not trivially automatable at scale and requires a tailored XSS primitive on the target domain.

An attacker discovers a stored XSS vulnerability in a TYPO3 frontend plugin - for example, a comment form or user-profile field - on the same domain as the TYPO3 backend. The attacker injects a payload that uses the Fetch API to POST to a backend administrative route (such as one that creates a new admin user or modifies TypoScript configuration), including the site's own origin as the Referer header. When a logged-in backend administrator navigates to the affected frontend page, the JavaScript executes silently and the backend accepts the cross-origin request as legitimate because the Referer passes the insufficiently scoped origin check, completing the privileged action without the administrator's awareness.