Admidio: Event participation IDOR - non-leaders can register other users for events via user_uuid parameter

Vulnerability

Overview

The vulnerability resides in the event participation logic within modules/events/events_function.php of Admidio, an open-source user management system prior to version 5.0.6 [1]. The flaw is rooted in an incorrect conditional check that uses an OR (||) operator. When the function possibleToParticipate() returns true (meaning the event is open for participation), any authenticated user—not just designated leaders—can manipulate the user_uuid GET parameter to specify a different user [1]. The code subsequently operates on the target user's ID ($user->getValue('usr_id')) rather than the current authenticated user's ID [1].

Attack

Vector and Prerequisites

To exploit this vulnerability, an attacker must be an authenticated user who is permitted to participate in the target event [1]. No special administrative or leadership privileges are required. The attacker can then craft a request containing a user_uuid parameter pointing to another user. The flawed authorization check only verifies that the attacker is allowed to participate in the event, but fails to ensure that the modification is performed on the attacker's own registration [1]. This bypasses the intended permission model where only event leaders should be able to manage other users' participation [4].

Impact

A successful exploit allows an attacker to register other users for events against their will or cancel their existing participation [1]. In a multi-user context, this could be abused to disrupt event planning, force unwanted registrations that consume spots, or interfere with attendance tracking. The impact is limited to event participation management; it does not lead to arbitrary code execution or direct data exfiltration, but it undermines the integrity of event management and user consent [1].

Mitigation

The vulnerability has been fixed in Admidio version 5.0.6 [1]. The fix ensures that the user identifier used for participation actions is derived from the authenticated session rather than from an externally supplied parameter, and that the authorization check properly distinguishes between a user acting on their own registration and a leader managing others [3]. Users are strongly advised to upgrade to version 5.0.6 or later. There is no known workaround for earlier versions [1][3].