TYPO3 Events 2 CVE-2026-77145

Exploitation requires an active TYPO3 frontend account with event management privileges for at least one organizer (PR:L per CVSS vector). The attacker must be able to reach the Events 2 frontend management update endpoint over the network (AV:N). Knowing or guessing a valid event identifier belonging to a different organizer is necessary - if event IDs are sequential integers (common in TYPO3 extension data models consistent with CWE-639 IDOR patterns), enumeration is trivial. The attack is limited to deployments hosting multiple organizers; a single-organizer instance has no exploitable cross-boundary. No victim interaction is required (UI:N). Non-default configurations or special extension settings are not indicated as prerequisites.

The CVSS 4.0 score of 7.1 accurately reflects a genuine but scoped integrity threat. The PR:L requirement meaningfully limits the attacker pool - exploitation requires holding a legitimate frontend event management account, ruling out anonymous internet attackers. AC:L and AT:N indicate no special conditions or timing constraints once that account is obtained. The absence from CISA KEV and lack of any referenced POC code indicate no confirmed active exploitation at time of analysis. No EPSS data was provided, so probabilistic exploitation frequency cannot be quantified. Real-world impact is contingent on a multi-organizer deployment model; a TYPO3 instance with a single event organizer presents no exploitable cross-boundary. The High Integrity (VI:H) signal is the dominant concern: an attacker can corrupt or falsify event records belonging to other organizations, which carries reputational and operational consequence disproportionate to the CVSS number alone.

An authenticated TYPO3 frontend user who manages their own organizer's events submits an update request to the Events 2 frontend management endpoint, substituting another organizer's event identifier in the request payload. The server's permission check evaluates the user's authorization against a different event (their own), approves the request, and writes the attacker-controlled changes to the target organizer's event record. No public exploit code has been identified at time of analysis, but the low complexity and straightforward IDOR mechanic make manual exploitation trivial for any developer-level attacker.