CVE-2026-109329

Admidio 4.0.12 through 4.3.17 and 5.0.0 before 5.0.15 contains a reflected cross-site scripting vulnerability in system/redirect.php that allows unauthenticated attackers to inject JavaScript via the url GET parameter, due to an incomplete fix for CVE-2021-43810. Attackers can craft a javascript: URL containing a decoy http:// segment that passes validation and executes script in the Admidio origin when victims click the redirect link.

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 5.0.0 before 5.0.15 contains an unauthenticated stored cross-site scripting vulnerability in RegistrationPresenter.php, which inserts the raw FIRST_NAME registration value into an unencoded data-message attribute. Attackers can register with a double-quoted event handler that executes JavaScript in an administrator's session when they hover the entry on the Manage registrations page.

Admidio up to version 5.0.11 has a CSRF vulnerability in modules/plugins.php, where plugin installation, uninstallation, and update operations are performed via GET requests without CSRF token validation. An attacker can craft a malicious page that, when visited by an authenticated administrator, triggers arbitrary plugin operations, including uninstallation, which executes DROP TABLE SQL scripts and destroys plugin data.

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.