GHSA-g375-5wmp-xr78: Missing Authorization Allows Arbitrary Forum Deletion in Admidio

Admidio is an open-source user management system designed for organizations and groups. It includes a built-in forum module that facilitates internal discussions. Within this module, users interact with topics and individual posts, which are uniquely identified by UUIDs.

The vulnerability, tracked as GHSA-g375-5wmp-xr78, is categorized as a Missing Authorization flaw (CWE-862). It resides in the modules/forum.php component, specifically within the handlers for the topic_delete and post_delete actions. These handlers are responsible for processing POST requests intended to remove content from the forum.

While the application correctly implements Cross-Site Request Forgery (CSRF) protection by validating the adm_csrf_token parameter against the active user session, it completely omits the necessary authorization checks. As a result, the server assumes that any user capable of submitting a valid CSRF token is authorized to delete the requested object.

The root cause of this vulnerability is a failure to enforce access controls on administrative actions within a public-facing endpoint. In standard software architecture, state-changing operations require two distinct security checks: authentication (verifying identity) and authorization (verifying permissions).

In modules/forum.php, the request router uses a switch statement to handle various actions based on the mode parameter. When the mode is set to topic_delete or post_delete, the script validates the incoming CSRF token. Once the CSRF validation passes, the script immediately instantiates a Topic or Post object, loads the record from the database using the provided UUID, and invokes the delete() method.

This implementation breaks the principle of least privilege. In other parts of the Admidio codebase, operations such as editing a post correctly verify ownership or administrative rights by calling specific permission-checking methods, such as $topic->isEditable(). The deletion handlers bypass this architecture entirely, trusting the input without verifying the context of the requesting user.

The vulnerability is clearly visible in the source code of modules/forum.php. The handler for topic deletion reads the target UUID from the request and processes the deletion without any surrounding permission checks.

Below is the vulnerable implementation for topic deletion (lines 98-108):

case 'topic_delete':
    // check the CSRF token of the form against the session token
    SecurityUtils::validateCsrfToken($_POST['adm_csrf_token']);
 
    $topic = new Topic($gDb);
    $topic->readDataByUuid($getTopicUUID);
    $topic->delete(); // CRITICAL: Missing authorization check
    echo json_encode(array('status' => 'success'));
    break;

The implementation for individual post deletion follows the exact same flawed pattern (lines 125-134):

case 'post_delete':
    // check the CSRF token of the form against the session token
    SecurityUtils::validateCsrfToken($_POST['adm_csrf_token']);
 
    $post = new Post($gDb);
    $post->readDataByUuid($getPostUUID);
    $post->delete(); // CRITICAL: Missing authorization check
    echo json_encode(array('status' => 'success'));
    break;

A complete fix requires integrating the standard Admidio authorization mechanisms before invoking the delete() method. For topics, the code must call $topic->isEditable(). For posts, the system must verify that the requesting user either possesses the isAdministratorForum() privilege or matches the fop_usr_id_create attribute of the post.

Exploiting this vulnerability requires minimal prerequisites. The attacker must possess a valid, standard user account on the target Admidio instance and be able to view the forum module. The attacker also needs the UUID of the target topic or post, which is readily available in the URL structure or DOM of the forum pages.

Once the attacker obtains a target UUID, they can extract their own session cookie and CSRF token from a legitimate request. They then construct a malicious POST request directed at the vulnerable endpoint.

The following command demonstrates the exploitation methodology for deleting a topic:

curl -X POST "https://[TARGET]/adm_program/modules/forum.php?mode=topic_delete&topic_uuid=[TARGET_TOPIC_UUID]" \
  -H "Cookie: ADMIDIO_SESSION_ID=[ATTACKER_SESSION_ID]" \
  -d "adm_csrf_token=[ATTACKER_CSRF_TOKEN]"

The server returns a {"status":"success"} JSON response, confirming that the database operation completed successfully. The specified topic and all associated posts are permanently removed from the system.

The primary impact of this vulnerability is high integrity loss and permanent data destruction. Because Admidio implements a hard delete via the delete() method, removed records are expunged from the underlying relational database without leaving a recoverable "trash" state.

An attacker can systematically eliminate all discussion threads, resulting in severe disruption to organizational communication. Administrators cannot rely on the platform as a persistent record of decisions or discussions, as any member can act as an unauthorized moderator.

The CVSS v3.1 vector is CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N, yielding a score of 6.5 (Medium). The attack complexity is low, as it requires no advanced network positioning or specialized timing. The requirement for a valid user account restricts the attack surface to insiders or compromised accounts, preventing exploitation by unauthenticated external actors.

The vendor addressed this vulnerability in Admidio version 5.0.7 by implementing the missing access control checks in the forum module. Organizations utilizing Admidio versions 5.0.0 through 5.0.6 must prioritize an immediate upgrade to version 5.0.7 or later.

For environments where an immediate update is not feasible, administrators can monitor access logs for anomalous activity. Specifically, security teams should look for POST requests directed at modules/forum.php containing the parameters mode=topic_delete or mode=post_delete.

If these requests originate from IP addresses or session IDs associated with non-administrative users, it indicates active exploitation. Since the vulnerability resides in the application layer logic, Web Application Firewalls (WAFs) cannot easily mitigate the flaw without blocking legitimate administrative deletions.