Admidio vulnerabilities

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 does not validate the adm_csrf_token in modules/category-report/preferences.php, which performs persistent Category Report configuration changes based on GET parameters (delete and copy). An attacker can trick an authenticated administrator into visiting a crafted URL to delete or duplicate Category Report configurations, affecting the integrity and availability of that module's configuration.

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.

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.

Admidio prior to version 5.0.10 lacks CSRF token validation in `modules/sso/clients.php` for the `enable` action. The `enable` case loads the SAML or OIDC client by UUID, calls `$client->enable($enabled)`, and persists the new state with no token check. Because the action is reachable via plain GET parameters, a third-party page can trick an authenticated administrator into disabling or re-enabling any configured SAML or OIDC client.

Admidio prior to version 5.0.10 has a vulnerability that allows an authenticated member with upload rights on any one folder to permanently delete files from folders where they have only view access. The authorization check at the top of `modules/documents-files.php` evaluates upload rights against the attacker-supplied `folder_uuid` URL parameter, not the file's actual parent folder. The `file_delete` handler only verifies view rights, never upload rights. This is an incomplete fix of GHSA-rmpj-3x5m-9m5f, which was patched in v5.0.7 but remains exploitable in v5.0.9.

Admidio before version 5.0.11 contains an IDOR vulnerability in the save_temporary mode of mylist_function.php that allows authenticated users to hijack list configurations. Attackers can enumerate global list UUIDs and overwrite admin-curated global lists or other users' private lists by supplying a list_uuid parameter, transferring ownership and demoting global lists to personal configurations.

Admidio 3.3.5 contains a CSRF vulnerability that allows low-privilege users to escalate their privileges by exploiting improper origin checking. Attackers can craft malicious HTML forms targeting roles_function.php with parameters like rol_assign_roles, rol_approve_users, and rol_edit_user set to 1, leading to privilege escalation without authentication.

Admidio prior to version 5.0.8 contains a CSRF vulnerability in the registration module. Approval actions for pending registrations (create_user, assign_member, assign_user) are performed via GET requests without CSRF token validation, allowing an attacker to auto-approve their own registration by tricking an administrator with appropriate rights.

Admidio before version 5.0.8 contains a vulnerability in the inventory module where the item_save endpoint accepts a user-controllable POST parameter imported that, when set to true, completely bypasses CSRF token validation and server-side form validation. An authenticated user can craft a direct POST request to save arbitrary inventory item data without CSRF protection and without the field value checks that the FormPresenter validation normally enforces.

Admidio before version 5.0.8 does not validate a CSRF token in the delete mode handler in mylist_function.php. An attacker can trick an authenticated user into visiting a malicious page, leading to permanent deletion of list configurations, including organization-wide shared lists if the victim has administrator rights.

Admidio versions 5.0.0 through 5.0.7 rely on adm_my_files/.htaccess to deny direct HTTP access to uploaded documents. The Docker image ships with AllowOverride None in the Apache configuration, causing Apache to silently ignore all .htaccess files. As a result, any file uploaded to the documents module is directly accessible over HTTP without authentication to anyone who knows the file path. This issue has been patched in version 5.0.8.