Common Weakness Enumeration

CWE-269

Discouraged

Improper Privilege Management

Abstraction: Class · Status: Draft

API response cwe.mitre.org

The product does not properly assign, modify, track, or check privileges for an actor, creating an unintended sphere of control for that actor.

5632 vulnerabilities reference this CWE, most recent first.

GHSA-J98G-G34P-R4CH

Vulnerability from github – Published: 2023-06-28 15:30 – Updated: 2023-06-28 15:30
VLAI
Details

A vulnerability in the OpenAPI of Cisco Secure Workload could allow an authenticated, remote attacker with the privileges of a read-only user to execute operations that should require Administrator privileges. The attacker would need valid user credentials. This vulnerability is due to improper role-based access control (RBAC) of certain OpenAPI operations. An attacker could exploit this vulnerability by issuing a crafted OpenAPI function call with valid credentials. A successful exploit could allow the attacker to execute OpenAPI operations that are reserved for the Administrator user, including the creation and deletion of user labels.

Severity
4.3 (Medium)
CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2023-20136"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269",
      "CWE-648"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-06-28T15:15:09Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability in the OpenAPI of Cisco Secure Workload could allow an authenticated, remote attacker with the privileges of a read-only user to execute operations that should require Administrator privileges. The attacker would need valid user credentials. This vulnerability is due to improper role-based access control (RBAC) of certain OpenAPI operations. An attacker could exploit this vulnerability by issuing a crafted OpenAPI function call with valid credentials. A successful exploit could allow the attacker to execute OpenAPI operations that are reserved for the Administrator user, including the creation and deletion of user labels.",
  "id": "GHSA-j98g-g34p-r4ch",
  "modified": "2023-06-28T15:30:23Z",
  "published": "2023-06-28T15:30:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-20136"
    },
    {
      "type": "WEB",
      "url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-csw-auth-openapi-kTndjdNX"
    }
  ],
  "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-J9FC-W3MR-X6MV

Vulnerability from github – Published: 2026-07-24 21:12 – Updated: 2026-07-24 21:12
VLAI
Summary
Budibase: Privilege escalation via public role assignment API missing app-level authorization
Details

Summary

Budibase 3.39.19 (commit 03fbabae4) is affected by a privilege-escalation / missing-authorization flaw in the public role-assignment API. An app-scoped builder (a user who builds only specific apps — user.builder.apps = [appA], not a global builder or admin) can grant themselves builder access to ANY other app in the tenant, or assign themselves/any user an arbitrary data-plane role (e.g. ADMIN) in any app, by calling POST /api/public/v1/roles/assign. The endpoint only authorizes the two global flags (admin, builder); the per-app appBuilder and role:{appId,roleId} grant vectors are passed to the backend without any authorization check that the caller controls the target app. Reproduced in a local authorized lab using the verbatim authorization-gate and SDK logic.

This is an incomplete fix of the role-assignment hardening in commit d63d1d9054 ("Inline public user global role validation"), which only ever validated the global flags.

Details

The issue is caused by authorization being implemented as a flag-level allowlist (admin/builder) instead of validating the scope the caller is granting.

Relevant code paths:

  • packages/server/src/api/controllers/public/globalRoleValidation.ts — validateGlobalRoleUpdate(ctx, roleUpdate) only checks roleUpdate.admin (requires isAdmin) and roleUpdate.builder (requires isGlobalBuilder). The GlobalRoleUpdate interface declares only { builder?, admin? }; appBuilder and role are not referenced.
  • packages/server/src/api/controllers/public/roles.ts — assign() does const { userIds, ...assignmentProps } = ctx.request.body; validateGlobalRoleUpdate(ctx, assignmentProps); await sdk.publicApi.roles.assign(userIds, assignmentProps). The appBuilder/role props pass through unvalidated.
  • packages/pro/src/sdk/publicApi/roles.ts — assign(): for opts.appBuilder it sets user.builder = { apps: existing.concat([getProdWorkspaceID(opts.appBuilder.appId)]) }; for opts.role it sets user.roles[getProdWorkspaceID(opts.role.appId)] = opts.role.roleId. No check that the caller builds the target app, and userIds is an arbitrary list (bulkGet). The only gate is the isExpandedPublicApiEnabled() license check.
  • packages/server/src/api/routes/public/index.ts — applyAdminRoutes(roleEndpoints) attaches only middleware.builderOrAdmin (no publicApi, no authorized(PermissionType.USER, …)).
  • packages/backend-core/src/middleware/builderOrAdmin.ts — with a workspaceId present, it only requires isBuilder(ctx.user, workspaceId). The attacker sets x-budibase-app-id to their own app (appA), so the gate passes.
  • packages/backend-core/src/middleware/builderOnly.ts — on the worker, POST /api/global/self/api_key only requires hasBuilderPermissions(ctx.user), which is true for app-scoped builders, so the attacker can self-issue a public API key.
  • packages/shared-core/src/sdk/documents/users.ts — isGlobalBuilder is false for app-scoped builders (so the global builder flag is correctly blocked), while isBuilder(user, appA) and hasBuilderPermissions(user) are true.

Attack flow:

  1. Attacker is an app-scoped builder of appA only (no global builder/admin).
  2. POST /api/global/self/api_key (worker) — passes builderOnly via hasBuilderPermissions → attacker obtains a public API key.
  3. POST /api/public/v1/roles/assign with header x-budibase-app-id: <appA prod id> and body {"userIds":["<self>"],"appBuilder":{"appId":"<appB>"}} — builderOrAdmin passes (isBuilder(user, appA)), validateGlobalRoleUpdate ignores appBuilder, the SDK pushes appB into user.builder.apps.
  4. Attacker is now a builder of appB (and, via the role vector, can set any data-role such as ADMIN in any app).

Security boundary crossed:

  • Before: builder of appA only.
  • After: builder of appB (and any other app) → read/modify all rows, read datasource configs and exfiltrate stored datasource credentials, edit automations (including the bash/executeScript/executeQuery steps); plus arbitrary data-role assignment in any app.
  • Why disallowed: the per-app builder model is meant to isolate builders to their assigned apps; a builder of one app must not gain authority over apps they were never granted.

PoC

Environment:

  • Budibase version: 3.39.19, commit 03fbabae4
  • Deployment: Business/Enterprise license required (isExpandedPublicApiEnabled)
  • Attacker role: app-scoped builder (user.builder.apps=[appA]), not global builder/admin
  • Mock services: none needed for the unit-level proof; HTTP PoC script provided for a licensed lab

Steps (unit-level proof, no license needed — verbatim auth-gate + SDK logic):

  1. Run the verification harness:
cd D:/CVE-Hunting/budibase-audit-output/lab
node harness/verify-privesc-authz.cjs
  1. Observed result (evidence: evidence/lab-privesc-authz.log):
[PASS-VALIDATION] appBuilder:{appId:APP_B}          -> NOT rejected
[PASS-VALIDATION] role:{appId:APP_B, roleId:'ADMIN'}-> NOT rejected
[BLOCKED 403]      builder:true (global)            -> Only global builders or admins ...
[BLOCKED 403]      admin:true (global)              -> Only global admins ...
after : builder={"apps":["app_A...","app_B..."]} roles={"app_B...":"ADMIN"}
isBuilder(attacker, APP_B) now = true   <-- escalated to builder of APP_B

Steps (HTTP PoC for a licensed lab — poc/privesc-roles-assign.sh):

# 1) self-issue API key
curl -X POST http://localhost:10000/api/global/self/api_key -H "Cookie: <attacker session>" -d '{}'
# 2) escalate: grant self builder of appB
curl -X POST http://localhost:10000/api/public/v1/roles/assign \
  -H "x-budibase-api-key: <KEY>" -H "x-budibase-app-id: <appA prod id>" \
  -H "content-type: application/json" \
  -d '{"userIds":["<self global id>"],"appBuilder":{"appId":"<appB>"}}'
  1. Expected result:
The request should be rejected (403) — an app-scoped builder must not be able to grant
itself builder/role access to an app it does not control. Instead it returns 200 and the
grant is applied.

Evidence files:

  • evidence/lab-privesc-authz.log
  • poc/verify-privesc-authz.cjs, poc/privesc-roles-assign.sh

Runtime limitation: full HTTP end-to-end requires a Business/Enterprise license (isExpandedPublicApiEnabled); no license was cracked. The authorization defect is proven at unit level with the verbatim validation + SDK logic, and the route→validation→SDK call chain was independently verified by source review.

Source PoC

Budibase-GHSA-Reports.zip

Impact

An attacker holding an app-scoped builder role on a single app in a licensed (Business/Enterprise) tenant can:

  • escalate to builder of every other app in the tenant (cross-app/workspace isolation bypass);
  • read and modify all rows in those apps;
  • read those apps' datasource configurations and exfiltrate stored datasource credentials;
  • edit automations in those apps, including server-side execution steps;
  • assign arbitrary data-plane roles (e.g. ADMIN) in any app to any user, including themselves.

It does not grant the global admin/builder flags (those are validated), so it is not a direct global-admin takeover; but cross-app builder is effectively a tenant-wide app/data-plane compromise. No real secrets were accessed during testing; the lab used canary-only data.

Severity
8.8 (High)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@budibase/server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "3.38.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-269",
      "CWE-862",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-24T21:12:40Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n\nBudibase `3.39.19` (commit `03fbabae4`) is affected by a privilege-escalation / missing-authorization flaw in the public role-assignment API. An **app-scoped builder** (a user who builds only specific apps \u2014 `user.builder.apps = [appA]`, not a global builder or admin) can grant **themselves builder access to ANY other app in the tenant**, or assign themselves/any user an arbitrary data-plane role (e.g. `ADMIN`) in any app, by calling `POST /api/public/v1/roles/assign`. The endpoint only authorizes the two *global* flags (`admin`, `builder`); the per-app `appBuilder` and `role:{appId,roleId}` grant vectors are passed to the backend **without any authorization check that the caller controls the target app**. Reproduced in a local authorized lab using the verbatim authorization-gate and SDK logic.\n\nThis is an incomplete fix of the role-assignment hardening in commit `d63d1d9054` (\"Inline public user global role validation\"), which only ever validated the global flags.\n\n### Details\n\nThe issue is caused by authorization being implemented as a **flag-level allowlist** (`admin`/`builder`) instead of validating the *scope* the caller is granting.\n\nRelevant code paths:\n\n- `packages/server/src/api/controllers/public/globalRoleValidation.ts` \u2014 `validateGlobalRoleUpdate(ctx, roleUpdate)` only checks `roleUpdate.admin` (requires `isAdmin`) and `roleUpdate.builder` (requires `isGlobalBuilder`). The `GlobalRoleUpdate` interface declares only `{ builder?, admin? }`; `appBuilder` and `role` are not referenced.\n- `packages/server/src/api/controllers/public/roles.ts` \u2014 `assign()` does `const { userIds, ...assignmentProps } = ctx.request.body; validateGlobalRoleUpdate(ctx, assignmentProps); await sdk.publicApi.roles.assign(userIds, assignmentProps)`. The `appBuilder`/`role` props pass through unvalidated.\n- `packages/pro/src/sdk/publicApi/roles.ts` \u2014 `assign()`: for `opts.appBuilder` it sets `user.builder = { apps: existing.concat([getProdWorkspaceID(opts.appBuilder.appId)]) }`; for `opts.role` it sets `user.roles[getProdWorkspaceID(opts.role.appId)] = opts.role.roleId`. No check that the caller builds the target app, and `userIds` is an arbitrary list (`bulkGet`). The only gate is the `isExpandedPublicApiEnabled()` license check.\n- `packages/server/src/api/routes/public/index.ts` \u2014 `applyAdminRoutes(roleEndpoints)` attaches **only** `middleware.builderOrAdmin` (no `publicApi`, no `authorized(PermissionType.USER, \u2026)`).\n- `packages/backend-core/src/middleware/builderOrAdmin.ts` \u2014 with a `workspaceId` present, it only requires `isBuilder(ctx.user, workspaceId)`. The attacker sets `x-budibase-app-id` to **their own** app (appA), so the gate passes.\n- `packages/backend-core/src/middleware/builderOnly.ts` \u2014 on the worker, `POST /api/global/self/api_key` only requires `hasBuilderPermissions(ctx.user)`, which is true for app-scoped builders, so the attacker can self-issue a public API key.\n- `packages/shared-core/src/sdk/documents/users.ts` \u2014 `isGlobalBuilder` is false for app-scoped builders (so the global `builder` flag is correctly blocked), while `isBuilder(user, appA)` and `hasBuilderPermissions(user)` are true.\n\nAttack flow:\n\n1. Attacker is an app-scoped builder of `appA` only (no global builder/admin).\n2. `POST /api/global/self/api_key` (worker) \u2014 passes `builderOnly` via `hasBuilderPermissions` \u2192 attacker obtains a public API key.\n3. `POST /api/public/v1/roles/assign` with header `x-budibase-app-id: \u003cappA prod id\u003e` and body `{\"userIds\":[\"\u003cself\u003e\"],\"appBuilder\":{\"appId\":\"\u003cappB\u003e\"}}` \u2014 `builderOrAdmin` passes (`isBuilder(user, appA)`), `validateGlobalRoleUpdate` ignores `appBuilder`, the SDK pushes `appB` into `user.builder.apps`.\n4. Attacker is now a builder of `appB` (and, via the `role` vector, can set any data-role such as `ADMIN` in any app).\n\nSecurity boundary crossed:\n\n- **Before:** builder of `appA` only.\n- **After:** builder of `appB` (and any other app) \u2192 read/modify all rows, read datasource configs and exfiltrate stored datasource credentials, edit automations (including the `bash`/`executeScript`/`executeQuery` steps); plus arbitrary data-role assignment in any app.\n- **Why disallowed:** the per-app builder model is meant to isolate builders to their assigned apps; a builder of one app must not gain authority over apps they were never granted.\n\n### PoC\n\nEnvironment:\n\n- Budibase version: `3.39.19`, commit `03fbabae4`\n- Deployment: Business/Enterprise license required (`isExpandedPublicApiEnabled`)\n- Attacker role: app-scoped builder (`user.builder.apps=[appA]`), not global builder/admin\n- Mock services: none needed for the unit-level proof; HTTP PoC script provided for a licensed lab\n\nSteps (unit-level proof, no license needed \u2014 verbatim auth-gate + SDK logic):\n\n1. Run the verification harness:\n\n```bash\ncd D:/CVE-Hunting/budibase-audit-output/lab\nnode harness/verify-privesc-authz.cjs\n```\n\n2. Observed result (evidence: `evidence/lab-privesc-authz.log`):\n\n```text\n[PASS-VALIDATION] appBuilder:{appId:APP_B}          -\u003e NOT rejected\n[PASS-VALIDATION] role:{appId:APP_B, roleId:\u0027ADMIN\u0027}-\u003e NOT rejected\n[BLOCKED 403]      builder:true (global)            -\u003e Only global builders or admins ...\n[BLOCKED 403]      admin:true (global)              -\u003e Only global admins ...\nafter : builder={\"apps\":[\"app_A...\",\"app_B...\"]} roles={\"app_B...\":\"ADMIN\"}\nisBuilder(attacker, APP_B) now = true   \u003c-- escalated to builder of APP_B\n```\n\nSteps (HTTP PoC for a licensed lab \u2014 `poc/privesc-roles-assign.sh`):\n\n```bash\n# 1) self-issue API key\ncurl -X POST http://localhost:10000/api/global/self/api_key -H \"Cookie: \u003cattacker session\u003e\" -d \u0027{}\u0027\n# 2) escalate: grant self builder of appB\ncurl -X POST http://localhost:10000/api/public/v1/roles/assign \\\n  -H \"x-budibase-api-key: \u003cKEY\u003e\" -H \"x-budibase-app-id: \u003cappA prod id\u003e\" \\\n  -H \"content-type: application/json\" \\\n  -d \u0027{\"userIds\":[\"\u003cself global id\u003e\"],\"appBuilder\":{\"appId\":\"\u003cappB\u003e\"}}\u0027\n```\n\n3. Expected result:\n\n```text\nThe request should be rejected (403) \u2014 an app-scoped builder must not be able to grant\nitself builder/role access to an app it does not control. Instead it returns 200 and the\ngrant is applied.\n```\n\nEvidence files:\n\n- `evidence/lab-privesc-authz.log`\n- `poc/verify-privesc-authz.cjs`, `poc/privesc-roles-assign.sh`\n\n**Runtime limitation:** full HTTP end-to-end requires a Business/Enterprise license (`isExpandedPublicApiEnabled`); no license was cracked. The authorization defect is proven at unit level with the verbatim validation + SDK logic, and the route\u2192validation\u2192SDK call chain was independently verified by source review.\n\n### Source PoC\n\n[Budibase-GHSA-Reports.zip](https://github.com/user-attachments/files/29161435/Budibase-GHSA-Reports.zip)\n\n### Impact\n\nAn attacker holding an **app-scoped builder** role on a single app in a licensed (Business/Enterprise) tenant can:\n\n* escalate to builder of **every other app** in the tenant (cross-app/workspace isolation bypass);\n* read and modify all rows in those apps;\n* read those apps\u0027 datasource configurations and **exfiltrate stored datasource credentials**;\n* edit automations in those apps, including server-side execution steps;\n* assign arbitrary data-plane roles (e.g. `ADMIN`) in any app to any user, including themselves.\n\nIt does **not** grant the global `admin`/`builder` flags (those are validated), so it is not a direct global-admin takeover; but cross-app builder is effectively a tenant-wide app/data-plane compromise. No real secrets were accessed during testing; the lab used canary-only data.",
  "id": "GHSA-j9fc-w3mr-x6mv",
  "modified": "2026-07-24T21:12:40Z",
  "published": "2026-07-24T21:12:40Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Budibase/budibase/security/advisories/GHSA-j9fc-w3mr-x6mv"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Budibase/budibase"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Budibase/budibase/releases/tag/3.40.0"
    }
  ],
  "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"
    }
  ],
  "summary": " Budibase: Privilege escalation via public role assignment API missing app-level authorization"
}

GHSA-J9V4-QQCH-4WVQ

Vulnerability from github – Published: 2022-05-24 17:28 – Updated: 2022-05-24 17:28
VLAI
Details

In onCreate of RequestPermissionActivity.java, there is a possible tapjacking vector due to an insecure default value. This could lead to local escalation of privilege allowing an attacker to set Bluetooth discoverability with User execution privileges needed. User interaction is needed for exploitation.Product: AndroidVersions: Android-8.0 Android-8.1 Android-9 Android-10 Android-11Android ID: A-155650356

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2020-0386"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-09-17T16:15:00Z",
    "severity": "MODERATE"
  },
  "details": "In onCreate of RequestPermissionActivity.java, there is a possible tapjacking vector due to an insecure default value. This could lead to local escalation of privilege allowing an attacker to set Bluetooth discoverability with User execution privileges needed. User interaction is needed for exploitation.Product: AndroidVersions: Android-8.0 Android-8.1 Android-9 Android-10 Android-11Android ID: A-155650356",
  "id": "GHSA-j9v4-qqch-4wvq",
  "modified": "2022-05-24T17:28:47Z",
  "published": "2022-05-24T17:28:47Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-0386"
    },
    {
      "type": "WEB",
      "url": "https://source.android.com/security/bulletin/2020-09-01"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-J9VM-RQ93-RMMR

Vulnerability from github – Published: 2022-05-24 17:19 – Updated: 2022-05-24 17:19
VLAI
Details

An elevation of privilege vulnerability exists when the Windows kernel fails to properly handle objects in memory, aka 'Windows Kernel Elevation of Privilege Vulnerability'. This CVE ID is unique from CVE-2020-0986, CVE-2020-1237, CVE-2020-1246, CVE-2020-1264, CVE-2020-1266, CVE-2020-1269, CVE-2020-1273, CVE-2020-1274, CVE-2020-1275, CVE-2020-1276, CVE-2020-1307, CVE-2020-1316.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2020-1262"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-06-09T20:15:00Z",
    "severity": "HIGH"
  },
  "details": "An elevation of privilege vulnerability exists when the Windows kernel fails to properly handle objects in memory, aka \u0027Windows Kernel Elevation of Privilege Vulnerability\u0027. This CVE ID is unique from CVE-2020-0986, CVE-2020-1237, CVE-2020-1246, CVE-2020-1264, CVE-2020-1266, CVE-2020-1269, CVE-2020-1273, CVE-2020-1274, CVE-2020-1275, CVE-2020-1276, CVE-2020-1307, CVE-2020-1316.",
  "id": "GHSA-j9vm-rq93-rmmr",
  "modified": "2022-05-24T17:19:54Z",
  "published": "2022-05-24T17:19:54Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-1262"
    },
    {
      "type": "WEB",
      "url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-1262"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-JC2W-M6FM-MC3G

Vulnerability from github – Published: 2026-04-07 15:30 – Updated: 2026-04-07 15:30
VLAI
Details

An issue that allowed all-organization administrators to promote accounts to superuser status has been resolved. This is an instance of CWE-269: Improper Privilege Management, and has an estimated CVSS score of CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:C/C:H/I:H/A:N (8.1 High). This issue was fixed in version 4.0.260202.0 of the runZero Platform.

Severity
8.1 (High)
CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:C/C:H/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-5373"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-07T15:17:47Z",
    "severity": "HIGH"
  },
  "details": "An issue that allowed all-organization administrators to promote accounts to superuser status has been resolved. This is an instance of CWE-269: Improper Privilege Management, and has an estimated CVSS score of CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:C/C:H/I:H/A:N (8.1 High). This issue was fixed in version 4.0.260202.0 of the runZero Platform.",
  "id": "GHSA-jc2w-m6fm-mc3g",
  "modified": "2026-04-07T15:30:52Z",
  "published": "2026-04-07T15:30:52Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-5373"
    },
    {
      "type": "WEB",
      "url": "https://help.runzero.com/docs/release-notes/#402602020"
    },
    {
      "type": "WEB",
      "url": "https://www.runzero.com/advisories/runzero-platform-su-privesc-cve-2026-5373"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:C/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-JC5J-4728-W8PC

Vulnerability from github – Published: 2022-05-24 17:00 – Updated: 2025-10-22 00:31
VLAI
Details

An elevation of privilege vulnerability exists when the Windows Universal Plug and Play (UPnP) service improperly allows COM object creation, aka 'Windows UPnP Service Elevation of Privilege Vulnerability'.

Severity
7.8 (High)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2019-1405"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-11-12T19:15:00Z",
    "severity": "HIGH"
  },
  "details": "An elevation of privilege vulnerability exists when the Windows Universal Plug and Play (UPnP) service improperly allows COM object creation, aka \u0027Windows UPnP Service Elevation of Privilege Vulnerability\u0027.",
  "id": "GHSA-jc5j-4728-w8pc",
  "modified": "2025-10-22T00:31:48Z",
  "published": "2022-05-24T17:00:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-1405"
    },
    {
      "type": "WEB",
      "url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2019-1405"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2019-1405"
    },
    {
      "type": "WEB",
      "url": "http://packetstormsecurity.com/files/155723/Microsoft-UPnP-Local-Privilege-Elevation.html"
    }
  ],
  "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-JC9F-VVPX-R5R8

Vulnerability from github – Published: 2024-01-04 09:30 – Updated: 2024-01-04 09:30
VLAI
Details

Permissions and Access Control Vulnerability in ZTE Red Magic 8 Pro

Severity
6.6 (Medium)
CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:C/C:L/I:H/A:L
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2023-41784"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-01-04T08:15:08Z",
    "severity": "MODERATE"
  },
  "details": "\nPermissions and Access Control Vulnerability in ZTE Red Magic 8 Pro \n\n",
  "id": "GHSA-jc9f-vvpx-r5r8",
  "modified": "2024-01-04T09:30:33Z",
  "published": "2024-01-04T09:30:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-41784"
    },
    {
      "type": "WEB",
      "url": "https://support.zte.com.cn/support/news/LoopholeInfoDetail.aspx?newsId=1034444"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:C/C:L/I:H/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-JC9P-889F-C7JP

Vulnerability from github – Published: 2022-05-24 17:42 – Updated: 2022-07-13 00:01
VLAI
Details

Snow Inventory Agent through 6.7.0 on Windows uses CPUID to report on processor types and versions that may be deployed and in use across an IT environment. A privilege-escalation vulnerability exists if CPUID is enabled, and thus it should be disabled via configuration settings.

Severity
7.8 (High)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-27579"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-02-23T18:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "Snow Inventory Agent through 6.7.0 on Windows uses CPUID to report on processor types and versions that may be deployed and in use across an IT environment. A privilege-escalation vulnerability exists if CPUID is enabled, and thus it should be disabled via configuration settings.",
  "id": "GHSA-jc9p-889f-c7jp",
  "modified": "2022-07-13T00:01:12Z",
  "published": "2022-05-24T17:42:57Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-27579"
    },
    {
      "type": "WEB",
      "url": "https://community.snowsoftware.com/s/feed/0D56900009cfHLDCA2"
    }
  ],
  "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-JCC6-G3RX-46FG

Vulnerability from github – Published: 2022-05-24 17:00 – Updated: 2022-05-24 17:00
VLAI
Details

Insufficient access control in system firmware for Intel(R) Xeon(R) Scalable Processors, 2nd Generation Intel(R) Xeon(R) Scalable Processors and Intel(R) Xeon(R) Processors D Family may allow a privileged user to potentially enable escalation of privilege, denial of service and/or information disclosure via local access.

Severity
6.7 (Medium)
CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2019-11136"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-11-14T17:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Insufficient access control in system firmware for Intel(R) Xeon(R) Scalable Processors, 2nd Generation Intel(R) Xeon(R) Scalable Processors and Intel(R) Xeon(R) Processors D Family may allow a privileged user to potentially enable escalation of privilege, denial of service and/or information disclosure via local access.",
  "id": "GHSA-jcc6-g3rx-46fg",
  "modified": "2022-05-24T17:00:56Z",
  "published": "2022-05-24T17:00:56Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-11136"
    },
    {
      "type": "WEB",
      "url": "https://support.f5.com/csp/article/K56215245?utm_source=f5support\u0026amp;utm_medium=RSS"
    },
    {
      "type": "WEB",
      "url": "https://support.hpe.com/hpsc/doc/public/display?docLocale=en_US\u0026docId=emr_na-hpesbhf03967en_us"
    },
    {
      "type": "WEB",
      "url": "https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00280.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-JCHR-7V8H-CH5R

Vulnerability from github – Published: 2022-05-24 17:18 – Updated: 2022-05-24 17:18
VLAI
Details

An elevation of privilege vulnerability exists when the Windows State Repository Service improperly handles objects in memory, aka 'Windows State Repository Service Elevation of Privilege Vulnerability'. This CVE ID is unique from CVE-2020-1124, CVE-2020-1131, CVE-2020-1134, CVE-2020-1184, CVE-2020-1185, CVE-2020-1186, CVE-2020-1187, CVE-2020-1188, CVE-2020-1189, CVE-2020-1190, CVE-2020-1191.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2020-1144"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-05-21T23:15:00Z",
    "severity": "MODERATE"
  },
  "details": "An elevation of privilege vulnerability exists when the Windows State Repository Service improperly handles objects in memory, aka \u0027Windows State Repository Service Elevation of Privilege Vulnerability\u0027. This CVE ID is unique from CVE-2020-1124, CVE-2020-1131, CVE-2020-1134, CVE-2020-1184, CVE-2020-1185, CVE-2020-1186, CVE-2020-1187, CVE-2020-1188, CVE-2020-1189, CVE-2020-1190, CVE-2020-1191.",
  "id": "GHSA-jchr-7v8h-ch5r",
  "modified": "2022-05-24T17:18:31Z",
  "published": "2022-05-24T17:18:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-1144"
    },
    {
      "type": "WEB",
      "url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-1144"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}
Mitigation MIT-1
Architecture and Design Operation

Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.

Mitigation MIT-48
Architecture and Design

Strategy: Separation of Privilege

Follow the principle of least privilege when assigning access rights to entities in a software system.

Mitigation MIT-49
Architecture and Design

Strategy: Separation of Privilege

Consider following the principle of separation of privilege. Require multiple conditions to be met before permitting access to a system resource.

CAPEC-122: Privilege Abuse

An adversary is able to exploit features of the target that should be reserved for privileged users or administrators but are exposed to use by lower or non-privileged accounts. Access to sensitive information and functionality must be controlled to ensure that only authorized users are able to access these resources.

CAPEC-233: Privilege Escalation

An adversary exploits a weakness enabling them to elevate their privilege and perform an action that they are not supposed to be authorized to perform.

CAPEC-58: Restful Privilege Elevation

An adversary identifies a Rest HTTP (Get, Put, Delete) style permission method allowing them to perform various malicious actions upon server data due to lack of access control mechanisms implemented within the application service accepting HTTP messages.

← Back to the CWE list