CVE-2026-69093

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 lacks CSRF token validation in `modules/registration.php` in the `send_login` mode. This mode regenerates a random password for `user_uuid_assigned`, stores its bcrypt hash, and emails the cleartext to that user. Other state-changing modes in the same file check the CSRF token, but `send_login` does not. A page visited by a registration-administrator can issue the request as a top-level navigation, and the browser sends the admin's `SameSite=Lax` cookies, allowing password reset without admin interaction.

Admidio prior to version 5.0.10 has a vulnerability in `modules/categories.php` where the per-category permission check is dead code because it compares `$getType` (a category-type code) against mode names (`edit`/`save`/`delete`), which is permanently false. Consequently, the `delete`, `sequence`, and `save` cases load the category by UUID and act on it without re-checking that the category belongs to a module the actor administers. A user with only one module-administrator right can destroy or reorder empty categories belonging to other modules.

Admidio before version 5.0.11 contains a reflected cross-site scripting vulnerability in the SSO/SAML endpoint. Unauthenticated attackers can inject arbitrary JavaScript via SAML Issuer elements or LightSaml library parameters, enabling session hijacking.

Admidio before 5.0.11 contains an authentication bypass vulnerability in the forum module when configured in login-only mode. The access control logic in modules/forum.php fails to validate the configuration state, allowing unauthenticated attackers to read forum topics and posts.

Admidio before 5.0.11 fails to validate target organization membership in role handlers. Authenticated role administrators can delete, activate, deactivate, or edit roles belonging to other organizations by supplying a role UUID from another organization.

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 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.