CVE-2026-47227 in Admidio
Summary
by MITRE • 08/12/2026
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.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 08/12/2026
The vulnerability exists within the Admidio user management system where improper access control validation creates a critical privilege escalation path through flawed authorization logic in the categories module. This issue stems from a fundamental design flaw in how the application validates administrative rights when processing category operations, specifically affecting versions prior to 5.0.10. The core problem manifests in the `modules/categories.php` file where the initial type validation correctly verifies that the supplied `type` parameter corresponds to modules the actor administers, yet subsequent authorization checks become completely ineffective due to a logical error in the code structure.
The technical flaw occurs at lines 56-61 where the code attempts to validate whether a specific category is editable by comparing `$getType` (which contains a category-type code such as `ANN`, `EVT`, `ROL`, `USF`) against mode names like `edit`, `save`, and `delete`. This comparison is inherently flawed because it compares category type identifiers with operation mode identifiers, resulting in a permanently false condition that prevents the `$category->isEditable()` method from ever being invoked. The dead code effectively disables any meaningful authorization check for category modifications.
The operational impact of this vulnerability allows an attacker with administrative rights to one module to execute unauthorized destructive actions against categories belonging to other modules they should not have access to. Specifically, users holding only a single module administrator right can exploit this weakness to delete, reorder, or modify empty categories from different modules such as announcements, roles, profile fields, or weblinks. This represents a serious authorization bypass that violates the principle of least privilege and allows for unauthorized modification of system configuration elements across module boundaries.
The vulnerability directly relates to CWE-285 (Improper Authorization) and CWE-693 (Protection Mechanism Failure) within the Common Weakness Enumeration framework, demonstrating how faulty logic can completely undermine security controls. From an ATT&CK perspective, this issue maps to T1078 (Valid Accounts) and T1484 (Domain Policy Modification) where unauthorized access to administrative functions enables privilege escalation and system configuration tampering. The flaw essentially provides a path for lateral movement within the administrative scope of the application.
The fix implemented in version 5.0.10 addresses this by ensuring proper authorization checks are performed before any category modifications occur, requiring re-validation that the category belongs to modules the actor actually administers. This remediation restores proper access control boundaries and prevents cross-module privilege escalation attacks. Organizations using Admidio should immediately upgrade to version 5.0.10 or later to address this vulnerability, as the issue allows for unauthorized destruction of system configuration elements and potential disruption of administrative operations across module boundaries.
The vulnerability demonstrates how seemingly minor code errors in authorization logic can create significant security implications, particularly in multi-module applications where proper access control boundaries are essential for maintaining system integrity. The issue highlights the importance of thorough code review processes specifically focusing on authorization flows and the need for comprehensive testing of security controls to prevent such bypass scenarios. Without proper remediation, this vulnerability could enable attackers to systematically undermine administrative controls and potentially cause service disruption or data integrity issues across multiple modules within the application.