CVE-2026-47233: 
PHP Análise e mitigação de vulnerabilidades

CVE-2026-47233 is a missing authorization vulnerability in Admidio, an open-source user management solution, that allows any authenticated low-privileged user to permanently delete custom inventory field definitions via the mode=field_delete handler in modules/inventory.php. The flaw affects all versions up to and including 5.0.9 and was patched in version 5.0.10. It was disclosed on May 25, 2026, and published to the GitHub Advisory Database on May 29, 2026. The vulnerability carries a CVSS v3.1 base score of 6.5 (Medium) (GitHub Advisory).

The root cause is CWE-862 (Missing Authorization): when commit d37ca6b fixed a missing isAdministratorInventory() gate for the item_delete case in modules/inventory.php, the sibling field_delete case was left unpatched. Under the default configuration (inventory_module_enabled=2), the only top-level gate is $gValidLogin, meaning any authenticated user reaches the mode switch. The field_delete handler validates only a session-bound CSRF token — which is freely available to any logged-in user from the field_list response — and then calls ItemFieldService::delete() → ItemField::delete(), which has no isAdministrator() check (unlike the sibling ItemField::save() method). An attacker needs only a valid session cookie and the session CSRF token to issue a single POST to /modules/inventory.php?mode=field_delete&uuid=<field-uuid> to trigger cascading database deletions. A full proof-of-concept using curl was published alongside the advisory (GitHub Advisory).

A low-privileged member account can permanently destroy any non-system custom inventory field, triggering cascading DELETE statements that wipe all per-item values from adm_inventory_item_data, all option entries from adm_inventory_field_options, and the field definition itself from adm_inventory_fields. There is no in-product undo mechanism; recovery requires restoring from a database backup. A single attacker can enumerate all non-system fields via field_list and delete them all in a few requests, rendering the entire inventory module's user-defined schema unrecoverable. No data is exposed to the attacker (confidentiality impact is none), but integrity and effective availability of the inventory data are fully compromised (GitHub Advisory).

A working proof-of-concept was published as part of the security advisory and was tested live against Admidio HEAD commit c5cde53 with PHP 8.4 and MariaDB 11.8. The NVD SSVC assessment classifies exploitation status as "poc" and the attack as non-automatable. The EPSS score is approximately 0.029% (0.000290), indicating a low but non-zero probability of exploitation in the wild. No in-the-wild exploitation or threat actor attribution has been reported, and the vulnerability is not listed in the CISA KEV catalog (GitHub Advisory).

1. Obtain a low-privileged account: Register or obtain credentials for any standard Member account on the target Admidio instance (no special roles required).
2. Authenticate and capture the initial CSRF token: Send a GET request to the Admidio root, extract the adm_csrf_token value from the HTML response, then POST credentials to /system/login.php?mode=check to establish an authenticated session cookie.
3. Retrieve the session CSRF token from the inventory module: Issue a GET request to /modules/inventory.php?mode=field_list using the authenticated session cookie. Extract the adm_csrf_token value from the JSON callback in the response — this is the session token valid for destructive operations.
4. Enumerate target field UUIDs: Parse the field_list response to identify UUIDs of non-system inventory fields (inf_system=0) that can be deleted.
5. Delete the target field: Send a POST request to /modules/inventory.php?mode=field_delete&uuid=<field-uuid> with the body parameter adm_csrf_token=<captured-token>. A successful response returns {"status":"success","message":"Item field successfully deleted"}.
6. Repeat for all fields: Iterate over all enumerated field UUIDs to destroy the entire custom inventory schema in a few requests, leaving the inventory module's data unrecoverable without a database backup (GitHub Advisory).

• Network: Repeated POST requests to /modules/inventory.php?mode=field_delete from a non-administrator user account, especially in rapid succession targeting multiple UUIDs; GET requests to /modules/inventory.php?mode=field_list immediately preceding deletion attempts.
• Logs: Web server access logs showing POST /modules/inventory.php with mode=field_delete query parameter from accounts without inventory administrator privileges; JSON responses of {"status":"success","message":"Item field successfully deleted"} for non-admin sessions.
• Database: Sudden disappearance of rows from adm_inventory_fields (especially where inf_system=0); corresponding mass deletions in adm_inventory_item_data and adm_inventory_field_options tables without an administrator session being active at the time.

Upgrade Admidio to version 5.0.10 or later, which adds the missing isAdministratorInventory() check to the field_delete handler. As a temporary workaround, administrators can set inventory_module_enabled to a value of 3 or higher in the site settings, which requires inventory administrator rights for all module access and prevents low-privileged users from reaching the vulnerable handler. The advisory also recommends patching the six sibling handlers (delete_option_entry, sequence, item_retire, item_reinstate, item_picture_delete) and adding a defense-in-depth check inside ItemField::delete() at the entity level (GitHub Advisory, Fix Commit).

The vulnerability was reported by security researcher 0xEr3n and published by Admidio maintainer Fasse via GitHub's security advisory process. The advisory explicitly notes this is a classic incomplete-fix pattern, where a prior patch (d37ca6b) addressed only the literally reported endpoint (item_delete) without auditing sibling handlers — a recurring issue the maintainers themselves had encountered previously with item_save. No significant broader media coverage or social media discussion has been identified (GitHub Advisory).