TYPO3 Events 2 EUVD-2026-65332

Exploitation requires a TYPO3 installation with the Events 2 extension installed and the frontend event management feature enabled; default TYPO3 installations without this extension are not affected. Per the CVSS 4.0 vector (PR:L), the attacker must be authenticated as a frontend user holding an organizer role - unauthenticated users cannot trigger this flaw. The specific vulnerable code path is activated only when the event creation request includes an explicit organizer identifier; the default code path that assigns the submitting user's own organizer record is not exploitable. Deployments that restrict frontend event creation to a single trusted organizer account, or that route all event management through the TYPO3 backend rather than the frontend plugin, are not exploitable as a consequence of their configuration.

The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:H/VA:N/SC:N/SI:N/SA:N) confirms a network-accessible attack with no special conditions, requiring only low privilege, yielding a 7.1 base score primarily driven by high vulnerable-system integrity impact (VI:H). No EPSS score was included in the available data, and this CVE is absent from CISA KEV with no public exploit code identified at time of analysis - these are meaningful gaps that prevent a complete probabilistic risk picture. The practical damage is bounded: an attacker cannot modify existing organizer records, escalate privileges, or affect system availability, limiting impact to unauthorized event attribution and associated reputational harm to the impersonated organizer. The low confidentiality component (VC:L) suggests incidental data exposure may accompany exploitation, but this is a secondary concern. For TYPO3 deployments hosting public event calendars where organizer identity and credibility are operationally significant, this authorization control failure warrants prompt patching despite the absence of active exploitation signals.

An authenticated TYPO3 frontend user holding any valid organizer role crafts an event creation POST request that specifies a different organizer's record identifier in the organizer field rather than their own. Because the server-side permission check validates only that the submitting user holds some organizer role - not that they own the specified organizer record - the event is created and publicly attributed to the victim organizer without their knowledge or consent. No public exploit code exists, but the attack requires only a valid organizer account and knowledge of another organizer's record identifier, both of which may be discoverable through normal use of the frontend interface.