CVE-2026-53760

Admidio is an open-source user management solution. Prior to version 5.0.9, a logic error in Admidio's two-factor authentication reset inverts the authorization check, allowing non-admin users to remove other users' TOTP configurations, including administrators.

Admidio versions before 5.0.12 contain a broken access control vulnerability in profile_function.php that allows authenticated low-privilege users to read another user's future role memberships. Attackers can bypass profile-level authorization by directly calling the reload_future_memberships endpoint with a victim's user UUID to disclose sensitive membership information.

Admidio before version 5.0.12 fails to enforce login-only module restrictions in RSS feed endpoints for forum and announcements modules. Unauthenticated attackers can retrieve forum topics and announcements by sending GET requests to rss/forum.php or rss/announcements.php, disclosing titles, full post text, author names, and timestamps.

Admidio before 5.0.12 fails to sanitize album names in the photo ZIP download functionality, allowing authenticated users with album-creation rights to include path traversal segments in archive entry names. This can lead to writing files outside the target directory when recipients extract the archive.

Admidio before version 5.0.12 contains a blind SQL injection vulnerability in the relation_type_list parameter of lists_show.php that allows unauthenticated attackers to execute arbitrary SQL queries. Attackers can bypass authentication by providing a dummy UUID in role_list and inject SQL through relation_type_list to extract database contents including password hashes and user credentials.

Admidio is an open-source user management solution. Prior to version 5.0.10, when debug logging is enabled, `Session::setCookie()` logs full cookie values and `Session::start()` logs the current session ID. In a real Admidio deployment this includes both the active session cookie and the persistent auto-login cookie. Anyone with access to the log sink can recover live bearer-style credentials from the logs. Version 5.0.10 contains a fix.

Admidio is an open-source user management solution. Version 5.0.9 added a missing `isAdministratorInventory()` gate to `case 'item_delete':` in `modules/inventory.php`. The same fix was not applied to the sibling `case 'field_delete':` handler, which destroys an entire inventory field definition, cascading to every `adm_inventory_item_data` row that referenced that field and every `adm_inventory_field_options` entry. The handler validates only a session-bound CSRF token; there is no `isAdministratorInventory()` check at the controller level, and `Admidio\Inventory\Entity\ItemField::delete()` does not enforce one at the entity level either (unlike its sibling `ItemField::save()`, which does check `$gCurrentUser->isAdministrator()`). Any user who can log in to the site can permanently destroy a non-system inventory field by sending one POST. Version 5.0.10 provides an updated fix.

Admidio prior to version 5.0.10 has a CSRF vulnerability in the `mode=export` action in `modules/sso/keys.php`, which exports a PKCS#12 bundle with the private key and certificate. The CSRF validation line is commented out, allowing a forged cross-site POST from an administrator session to trigger private key export without a valid form token.

Admidio before version 5.0.10 has a vulnerability in modules/documents-files.php where state-changing modes are gated by checking hasUploadRight() on the URL parameter folder_uuid, but the move_save handler operates on a separate URL parameter file_uuid and calls File::moveToFolder($destFolderUUID). File::moveToFolder() checks the upload right on the destination folder but never on the source folder. As a result, any user who can upload to any single folder can move any file from any other folder, including private folders, into a folder they control, and then download it.

Admidio prior to version 5.0.10 has an IDOR vulnerability in `modules/documents-files.php` in the `file_rename_save` mode. The top-level rights check validates upload rights on the `folder_uuid` parameter, but the rename operation acts on `file_uuid` without re-checking the actual containing folder. A user with upload rights on any folder A can rename a file in folder B as long as they can view it.