CVE-2026-41657
Permission Bypass in Admidio Exposes All User Records
Publication date: 2026-05-07
Last updated on: 2026-05-07
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| admidio | admidio | to 5.0.9 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-863 | The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
CVE-2026-41657 is a vulnerability in Admidio versions 5.0.8 and earlier involving a permission check mismatch between the frontend and backend of the application.
The backend endpoint contacts_data.php uses a weaker permission check (isAdministratorUsers(), requiring only rol_edit_user=true) compared to the frontend contacts.php, which requires a stronger check (isAdministrator(), requiring rol_administrator=true) and the contacts_show_all system setting.
This discrepancy allows a user manager who is not a full administrator to bypass multi-tenant organization isolation by directly requesting contacts_data.php with specific parameters, thereby retrieving all user records across all organizations.
The exposed data includes sensitive information such as user UUIDs, login names, email addresses, and profile fields.
The issue has been fixed in version 5.0.9 by aligning the backend permission check with the frontend's stricter requirements.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
This vulnerability allows a user manager without full administrative rights to bypass multi-tenant organization isolation and access all user records across all organizations in the Admidio instance. This exposure includes sensitive data such as user UUIDs, login names, email addresses, and profile fields.
Such unauthorized access to sensitive personal data can lead to non-compliance with data protection regulations like GDPR and HIPAA, which require strict access controls and protection of personal information.
Therefore, until patched, this vulnerability poses a risk to compliance by potentially allowing unauthorized disclosure of personal data.
How can this vulnerability impact me? :
This vulnerability can lead to unauthorized disclosure of sensitive user information across all organizations managed by the Admidio instance.
A user manager without full administrative privileges can access data such as user UUIDs, login names, email addresses, and profile fields that they should not normally see.
This breach of data confidentiality could result in privacy violations, potential identity exposure, and misuse of personal information.
The vulnerability does not affect data integrity or availability but has a high impact on confidentiality.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by checking if a user manager (non-administrator) can access the contacts_data.php endpoint with the parameter mem_show_filter=3 and retrieve user records across all organizations, which should normally be restricted.
A practical way to test this is to perform an HTTP request to the vulnerable endpoint as a user manager and observe if the response contains user data from multiple organizations.
Example command using curl to test the vulnerability:
- curl -i -b "cookie_for_user_manager_session" "https://your-admidio-instance/contacts_data.php?mem_show_filter=3"
If the response includes user records beyond the user's organization, the system is vulnerable.
What immediate steps should I take to mitigate this vulnerability?
The immediate and recommended mitigation is to upgrade Admidio to version 5.0.9 or later, where the permission check in contacts_data.php has been fixed to require the stronger isAdministrator() permission.
Until the upgrade can be applied, restrict access to the contacts_data.php endpoint to only full administrators or block direct access to this endpoint for user managers.
Review and adjust user roles and permissions to ensure that only trusted users have rol_edit_user=true if the upgrade is not immediately possible.