Description

Admidio is an open-source user management solution. `modules/categories.php` checks that the supplied `type` parameter (`ANN`, `EVT`, `ROL`, `USF`, …) corresponds to a module the actor administers. The follow-up "is this specific category editable by me" check at lines 56-61 is dead code because it compares `$getType` (a category-type code) against mode names (`edit`/`save`/`delete`); the condition is permanently false, so `$category->isEditable()` is never invoked. Prior to version 5.0.10, the `delete`, `sequence`, and `save` switch cases load the category by the supplied UUID and act on it without re-checking that the category belongs to a module the actor administers. A user holding only one module-administrator right can therefore destroy or reorder empty categories belonging to *other* modules — for example, an announcements administrator can delete role categories, profile-field categories, or weblink categories that they have no right to touch. Version 5.0.10 fixes the issue.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-08-12T14:17:53.600Z",
  "pubdate": "2026-08-12T14:17:53.600Z",
  "executiveSummary": "An authorization bypass vulnerability exists in Admidio prior to version 5.0.10, specifically within the category management functionality.\nThe vulnerability allows an authenticated actor with administrative rights to a single module to manipulate, delete, or reorder categories belonging to entirely different modules that they are not authorized to administer.\nThe root cause stems from broken access control logic and dead code in modules/categories.php, where the follow-up authorization check comparing category-type codes against mode names is permanently false, preventing the execution of the intended isEditable validation method.\nConsequently, the delete, sequence, and save switch cases load target categories using supplied UUIDs and execute state-changing actions without verifying whether the targeted category falls within the administrator's authorized module boundary.\nThe risk implication is unauthorized data modification and destruction across restricted modules by lower-privileged users holding limited module-administrator rights.\nSuccessful exploitation requires valid authentication as a module administrator and the ability to interact with the categories management interface using arbitrary or enumerated category UUIDs.",
  "technicalDetails": "The vulnerability resides in the modules/categories.php file of Admidio prior to version 5.0.10.\nThe component is responsible for handling category operations such as deletion, reordering, and saving across various application modules identified by the type parameter, such as ANN, EVT, ROL, and USF.\nThe primary vulnerability mechanism is a flawed authorization check coupled with dead code.\nAlthough modules/categories.php initially verifies that the supplied type parameter corresponds to a module administered by the actor, the subsequent authorization check designed to validate whether a specific category is editable by the current user fails logically.\nSpecifically, lines 56 through 61 contain a conditional check that incorrectly compares $getType, which holds a category-type code, against internal application mode names such as edit, save, or delete.\nBecause this comparison is structurally invalid, the condition evaluates to permanently false, ensuring that the critical method $category->isEditable() is never invoked during the request lifecycle.\nPrior to version 5.0.10, the delete, sequence, and save switch cases leverage this security gap by loading target categories directly using user-supplied UUIDs and immediately acting upon them.\nAn attacker who holds administrative privileges for only a single module—for instance, an announcements administrator possessing rights solely over the ANN module—can leverage this missing check to manipulate empty categories belonging to other administrative boundaries, such as role categories (ROL), profile-field categories (USF), or weblink categories.\nThe step-by-step attack flow involves the authenticated user initiating a state-changing request (such as a delete or sequence action) targeting a category UUID belonging to an unauthorized module.\nThe application processes the request, bypasses the dead authorization check due to the type-versus-mode mismatch, skips the execution of isEditable(), and successfully executes the deletion or reordering operation against the arbitrary category UUID.\nPrerequisites for exploitation include authenticated access to the application and holding at least one legitimate module-administrator role to pass the initial coarse-grained check."
}