CVE-2026-77144 in Events 2 Plugininfo

Summary

by MITRE • 08/25/2026

The frontend management plugin attributed a newly created event to the submitting user's organizer record only when the request supplied no organizer of its own. The accompanying permission check confirmed only that the submitting user held any organizer role. A user with frontend event management access could therefore create an event that is attributed to another organizer.

If you want to get best quality of vulnerability data, you may have to visit VulDB.

Analysis

by VulDB Data Team • 08/25/2026

The vulnerability described constitutes a critical authorization flaw within the frontend management plugin, specifically categorized under CWE-269: Improper Control of Interaction with Untrusted Input and CWE-862: Missing Authorization. The core technical deficiency lies in the application's logic for associating events with organizer records during creation. When a user submits an event via the API or interface without explicitly providing an organizer identifier, the system defaults to attributing the new event to the submitting user's own organizer record. However, when an organizer is specified within the request payload, the permission check performed by the application only verifies that the requesting user holds any valid organizer role somewhere in their profile hierarchy. It fails to validate whether the specific organizer entity referenced in the request belongs to or is authorized for use by the submitting user. This logical gap allows a malicious actor with basic frontend event management privileges to manipulate the input data and assign events to other organizers' records, effectively bypassing intended ownership boundaries.

From an operational perspective, this vulnerability enables unauthorized modification of organizational structures and potential data integrity issues within the platform's scheduling or booking systems. An attacker can create events that appear to be hosted by legitimate administrators or higher-privileged users, which may lead to confusion in event tracking, incorrect attribution of revenue or analytics, and disruption of scheduled activities associated with those other organizers. In severe cases, if these events trigger downstream processes such as payment processing, notification dispatches, or integration hooks tied to the organizer's account, the impact could extend beyond mere data misattribution to include financial discrepancies or unauthorized communications sent on behalf of victims. This aligns with MITRE ATT&CK technique T1078: Valid Accounts, where an attacker leverages valid credentials but abuses their limited permissions through logic flaws rather than privilege escalation in the traditional sense.

To mitigate this vulnerability, developers must implement strict ownership validation checks at the point of event creation. The application should verify that the organizer ID provided in the request matches the primary or authorized secondary organizer associated with the authenticated user's account. If a user attempts to create an event for another organizer without explicit permission grants linking those two entities, the request should be rejected. Additionally, implementing principle of least privilege by ensuring that only users with specific administrative rights over other organizers can assign events to them would further reduce risk. Input validation should also ensure that if no organizer is supplied, the system defaults correctly, but any provided value must undergo rigorous authorization checks against the user's actual permissions and organizational hierarchy before persistence in the database.

Responsible

TYPO3

Reservation

08/20/2026

Disclosure

08/25/2026

Moderation

accepted

CPE

ready

EPSS

0.00000

KEV

no

Activities

very low

Sources

Might our Artificial Intelligence support you?

Check our Alexa App!