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.

6487 vulnerabilities reference this CWE, most recent first.

GHSA-85G2-PMRX-R49Q

Vulnerability from github – Published: 2026-05-21 20:16 – Updated: 2026-07-21 13:54
VLAI
Summary
Fission runtime pods automount the fission-fetcher service-account token into the user function container, granting function code namespace-wide secret / configmap read
Details

Summary

Fission runtime pods were created with ServiceAccountName: fission-fetcher, and the fission-fetcher ServiceAccount was granted namespace-wide get on secrets and configmaps (it needs that to load function code, env vars, and config). The runtime pod's automounted token was reachable from inside the user's function container at /var/run/secrets/kubernetes.io/serviceaccount/token, so user-supplied function code inherited the same Kubernetes API privileges and could read any secret or configmap in the function's namespace — far beyond the Function.spec.secrets allowlist that the function specification suggests.

Affected component

  • pkg/executor/executortype/poolmgr/gp_deployment.go:154-156 — pool-manager runtime pod ServiceAccountName.
  • pkg/executor/executortype/newdeploy/newdeploy.go:225-227 — new-deploy runtime pod ServiceAccountName.
  • pkg/utils/serviceaccount.go:51-64 — fission-fetcher RBAC: namespace-wide get on secrets / configmaps.

Impact

A user able to deploy or update a function in any namespace where Fission runtime pods are scheduled could:

  1. Read every secret in that namespace (TLS keys, OIDC client secrets, database credentials, cloud provider credentials).
  2. Read every configmap in that namespace.
  3. Use those credentials to pivot to other Kubernetes resources or external systems the secrets unlock.

This violates the principle that Function.spec.secrets is the authoritative declaration of which secrets a function can read.

Root cause

The fetcher sidecar legitimately needs the SA token to call the Fission control plane and fetch package archives. Setting ServiceAccountName: fission-fetcher on the pod gives every container in the pod (including the user container) the automounted token. Kubernetes does not provide per-container service-account scoping inside a single pod, so the user container has to be moved into a separate identity / token-mount scheme.

Fix

Released in v1.23.0:

  • PR #3366 (commit fe1842ef):
  • The user function container now sets AutomountServiceAccountToken: false at the container level (via projected-volume token suppression), so the user container no longer sees the pod's SA token even though the fetcher sidecar still does.
  • The fetcher sidecar retains its existing token mount (separate projected volume) since it needs cluster API access for its own work.
  • For the few legitimate use cases where a function needs its own Kubernetes API access, the user is expected to mount a different ServiceAccount via Function.spec.podspec with the minimum necessary RBAC (documented separately).

Mitigation (until upgrade)

  1. Restrict who can create / update Function and Package CRDs in your cluster — treat the ability to ship function code as equivalent to namespace-wide secret read.
  2. Reduce the fission-fetcher ClusterRole / Role scope where possible (e.g. constrain it to specific named secrets via separate Role bindings).
  3. Add NetworkPolicy egress rules denying function pods access to the Kubernetes API server (this blunts the token even if it leaks).
Severity
8.7 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.22.0"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/fission/fission"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.23.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-46617"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-250",
      "CWE-269",
      "CWE-538"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-21T20:16:12Z",
    "nvd_published_at": "2026-06-10T18:17:05Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nFission runtime pods were created with `ServiceAccountName: fission-fetcher`, and the `fission-fetcher` ServiceAccount was granted namespace-wide `get` on `secrets` and `configmaps` (it needs that to load function code, env vars, and config). The runtime pod\u0027s automounted token was reachable from inside the user\u0027s function container at `/var/run/secrets/kubernetes.io/serviceaccount/token`, so user-supplied function code inherited the same Kubernetes API privileges and could read any secret or configmap in the function\u0027s namespace \u2014 far beyond the `Function.spec.secrets` allowlist that the function specification suggests.\n\n### Affected component\n\n- `pkg/executor/executortype/poolmgr/gp_deployment.go:154-156` \u2014 pool-manager runtime pod `ServiceAccountName`.\n- `pkg/executor/executortype/newdeploy/newdeploy.go:225-227` \u2014 new-deploy runtime pod `ServiceAccountName`.\n- `pkg/utils/serviceaccount.go:51-64` \u2014 `fission-fetcher` RBAC: namespace-wide `get` on `secrets` / `configmaps`.\n\n### Impact\n\nA user able to deploy or update a function in any namespace where Fission runtime pods are scheduled could:\n\n1. Read every secret in that namespace (TLS keys, OIDC client secrets, database credentials, cloud provider credentials).\n2. Read every configmap in that namespace.\n3. Use those credentials to pivot to other Kubernetes resources or external systems the secrets unlock.\n\nThis violates the principle that `Function.spec.secrets` is the authoritative declaration of which secrets a function can read.\n\n### Root cause\n\nThe fetcher sidecar legitimately needs the SA token to call the Fission control plane and fetch package archives. Setting `ServiceAccountName: fission-fetcher` on the pod gives every container in the pod (including the user container) the automounted token. Kubernetes does not provide per-container service-account scoping inside a single pod, so the user container has to be moved into a separate identity / token-mount scheme.\n\n### Fix\n\nReleased in [v1.23.0](https://github.com/fission/fission/releases/tag/v1.23.0):\n\n- **PR #3366** (commit `fe1842ef`):\n  - The user function container now sets `AutomountServiceAccountToken: false` at the container level (via projected-volume token suppression), so the user container no longer sees the pod\u0027s SA token even though the fetcher sidecar still does.\n  - The fetcher sidecar retains its existing token mount (separate projected volume) since it needs cluster API access for its own work.\n  - For the few legitimate use cases where a function needs its own Kubernetes API access, the user is expected to mount a different ServiceAccount via `Function.spec.podspec` with the minimum necessary RBAC (documented separately).\n\n### Mitigation (until upgrade)\n\n1. Restrict who can create / update `Function` and `Package` CRDs in your cluster \u2014 treat the ability to ship function code as equivalent to namespace-wide secret read.\n2. Reduce the `fission-fetcher` ClusterRole / Role scope where possible (e.g. constrain it to specific named secrets via separate Role bindings).\n3. Add NetworkPolicy egress rules denying function pods access to the Kubernetes API server (this blunts the token even if it leaks).",
  "id": "GHSA-85g2-pmrx-r49q",
  "modified": "2026-07-21T13:54:09Z",
  "published": "2026-05-21T20:16:12Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/fission/fission/security/advisories/GHSA-85g2-pmrx-r49q"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46617"
    },
    {
      "type": "WEB",
      "url": "https://github.com/fission/fission/pull/3366"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/fission/fission"
    },
    {
      "type": "WEB",
      "url": "https://github.com/fission/fission/releases/tag/v1.23.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Fission runtime pods automount the fission-fetcher service-account token into the user function   container, granting function code namespace-wide secret / configmap read"
}

GHSA-85JC-QVVJ-Q8JW

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

An elevation of privilege vulnerability exists in the way that the Windows Network Connections Service handles objects in memory, aka 'Windows Network Connections Service Elevation of Privilege Vulnerability'. This CVE ID is unique from CVE-2020-1390, CVE-2020-1427, CVE-2020-1428, CVE-2020-1438.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2020-1373"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-07-14T23:15:00Z",
    "severity": "MODERATE"
  },
  "details": "An elevation of privilege vulnerability exists in the way that the Windows Network Connections Service handles objects in memory, aka \u0027Windows Network Connections Service Elevation of Privilege Vulnerability\u0027. This CVE ID is unique from CVE-2020-1390, CVE-2020-1427, CVE-2020-1428, CVE-2020-1438.",
  "id": "GHSA-85jc-qvvj-q8jw",
  "modified": "2022-05-24T17:23:01Z",
  "published": "2022-05-24T17:23:01Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-1373"
    },
    {
      "type": "WEB",
      "url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-1373"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-85MQ-QV5G-3VF2

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

An issue was discovered in Comelit "App lejos de casa (web)" 2.8.0. It allows privilege escalation via modified domus and logged fields, related to js/bridge.min.js and login.json. For example, an attacker can achieve high privileges (installer or administrator) for the graphical interface via a 1C000000000S value for domus, in conjunction with a zero value for logged.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2019-14453"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-08-03T18:15:00Z",
    "severity": "HIGH"
  },
  "details": "An issue was discovered in Comelit \"App lejos de casa (web)\" 2.8.0. It allows privilege escalation via modified domus and logged fields, related to js/bridge.min.js and login.json. For example, an attacker can achieve high privileges (installer or administrator) for the graphical interface via a 1C000000000S value for domus, in conjunction with a zero value for logged.",
  "id": "GHSA-85mq-qv5g-3vf2",
  "modified": "2022-05-24T19:09:49Z",
  "published": "2022-05-24T19:09:49Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-14453"
    },
    {
      "type": "WEB",
      "url": "https://www.blogx86.net/2021/07/26/cve-2019-14453"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-864V-6QJ7-62QJ

Vulnerability from github – Published: 2023-01-24 20:47 – Updated: 2025-01-16 14:07
VLAI
Summary
Issue with whitespace in JWT roles in OpenSearch
Details

Advisory title: Issue with whitespace in JWT roles

Affected versions:

OpenSearch 1.0.0-1.3.7 and 2.0.0-2.4.1

Patched versions:

OpenSearch 1.3.8 and 2.5.0

Impact:

OpenSearch uses JWTs to store role claims obtained from the Identity Provider (IdP) when the authentication backend is SAML or OpenID Connect. There is an issue in how those claims are processed from the JWTs where the leading and trailing whitespace is trimmed, allowing users to potentially claim roles they are not assigned to if any role matches the whitespace-stripped version of the roles they are a member of.

This issue is only present for authenticated users, and it requires either the existence of roles that match, not considering leading/trailing whitespace, or the ability for users to create said matching roles. In addition, the Identity Provider must allow leading and trailing spaces in role names.

Patches:

OpenSearch versions 1.3.8 and 2.5.0 contain a fix for this issue.

For more information:

If you have any questions or comments about this advisory, please contact AWS/Amazon Security via our issue reporting page (https://aws.amazon.com/security/vulnerability-reporting/) or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.opensearch.plugin:opensearch-security"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.3.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.opensearch.plugin:opensearch-security"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0"
            },
            {
              "fixed": "2.5.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-23612"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269",
      "CWE-287"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-01-24T20:47:19Z",
    "nvd_published_at": "2023-01-26T21:18:00Z",
    "severity": "MODERATE"
  },
  "details": "### Advisory title: Issue with whitespace in JWT roles\n\n### Affected versions:\nOpenSearch 1.0.0-1.3.7 and 2.0.0-2.4.1\n\n### Patched versions:\nOpenSearch 1.3.8 and 2.5.0\n\n### Impact:\nOpenSearch uses JWTs to store role claims obtained from the Identity Provider (IdP) when the authentication backend is SAML or OpenID Connect. There is an issue in how those claims are processed from the JWTs where the leading and trailing whitespace is trimmed, allowing users to potentially claim roles they are not assigned to if any role matches the whitespace-stripped version of the roles they are a member of.\n\nThis issue is only present for authenticated users, and it requires either the existence of roles that match, not considering leading/trailing whitespace, or the ability for users to create said matching roles. In addition, the Identity Provider must allow leading and trailing spaces in role names.\n\n### Patches:\nOpenSearch versions 1.3.8 and 2.5.0 contain a fix for this issue.\n\n### For more information:\nIf you have any questions or comments about this advisory, please contact AWS/Amazon Security via our issue 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-864v-6qj7-62qj",
  "modified": "2025-01-16T14:07:22Z",
  "published": "2023-01-24T20:47:19Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/opensearch-project/security/security/advisories/GHSA-864v-6qj7-62qj"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-23612"
    },
    {
      "type": "WEB",
      "url": "https://github.com/opensearch-project/OpenSearch/releases/tag/2.5.0"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/opensearch-project/security"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Issue with whitespace in JWT roles in OpenSearch"
}

GHSA-865C-5JWM-R2QV

Vulnerability from github – Published: 2026-09-17 06:30 – Updated: 2026-09-17 15:32
VLAI
Details

The Choose User Role at Registration WordPress plugin before 1.3.3 does not validate the role requested at registration against the roles an administrator chose to offer, allowing unauthenticated users to request any role, including administrator, and to be granted it once the request is approved. Exploitation requires the Choose User Role at Registration WordPress plugin before 1.3.3's role selection feature and public account registration to both be enabled.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-85128"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-17T06:16:50Z",
    "severity": "HIGH"
  },
  "details": "The Choose User Role at Registration WordPress plugin before 1.3.3 does not validate the role requested at registration against the roles an administrator chose to offer, allowing unauthenticated users to request any role, including administrator, and to be granted it once the request is approved. Exploitation requires the Choose User Role at Registration WordPress plugin before 1.3.3\u0027s role selection feature and public account registration to both be enabled.",
  "id": "GHSA-865c-5jwm-r2qv",
  "modified": "2026-09-17T15:32:06Z",
  "published": "2026-09-17T06:30:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-85128"
    },
    {
      "type": "WEB",
      "url": "https://wpscan.com/vulnerability/e48789a3-49b4-4fa4-8243-c242b79b9d9d"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-8674-26JC-WH98

Vulnerability from github – Published: 2022-02-09 22:56 – Updated: 2022-02-09 22:56
VLAI
Summary
Improper Access Control in infinispan-server-runtime
Details

A flaw was found in infinispan 10 REST API, where authorization permissions are not checked while performing some server management operations. When authz is enabled, any user with authentication can perform operations like shutting down the server without the ADMIN role.

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 11.0.5.Final"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.infinispan:infinispan-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "11.0.6.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-25711"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269",
      "CWE-862"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-04-09T22:40:14Z",
    "nvd_published_at": "2020-12-03T17:15:00Z",
    "severity": "MODERATE"
  },
  "details": "A flaw was found in infinispan 10 REST API, where authorization permissions are not checked while performing some server management operations. When authz is enabled, any user with authentication can perform operations like shutting down the server without the ADMIN role.",
  "id": "GHSA-8674-26jc-wh98",
  "modified": "2022-02-09T22:56:32Z",
  "published": "2022-02-09T22:56:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-25711"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=1897618"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20220210-0023"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Improper Access Control in infinispan-server-runtime"
}

GHSA-8686-VHFX-7R3J

Vulnerability from github – Published: 2026-10-01 15:36 – Updated: 2026-10-01 15:36
VLAI
Summary
vm2: NodeVM node:-prefixed negative builtin deny bypass exposes child_process
Details

Summary

NodeVM normalizes node:-prefixed builtin specifiers during require() resolution, but it does not normalize user-provided negative builtin entries in wildcard policy.

As a result, this configuration:

new NodeVM({
  require: {
    builtin: ['*', '-node:child_process']
  }
});

does not deny the canonical child_process builtin. Sandboxed code can require both child_process and node:child_process, and receives the host module with process-spawning APIs such as execSync and spawn.

The safe proof below only checks module and function reachability. It does not execute any OS command.

Affected Mode

NodeVM.

Affected Configuration

new NodeVM({
  require: {
    builtin: ['*', '-node:child_process']
  }
});

This affects users who deny builtins using their node:-prefixed spelling, expecting -node:child_process to deny require('node:child_process') and require('child_process').

Affected Files / Functions

  • lib/builtin.js
  • makeBuiltinsFromLegacyOptions
  • wildcard builtin expansion
  • exact negative entry check: builtins.indexOf(\-${name}`)`
  • addDefaultBuiltin
  • lib/resolver.js
  • Resolver.resolve
  • lib/setup-node-sandbox.js
  • requireImpl
  • node: prefix stripping before builtin load

Root Cause

lib/setup-node-sandbox.js strips the node: prefix from resolved builtin filenames before loading the builtin:

if (localStringPrototypeStartsWith(filename, 'node:')) {
  id = localStringPrototypeSlice(filename, 5);
  let nmod = cacheBuiltins[id];
  if (!nmod) {
    nmod = loadBuiltinModule(id);
    if (!nmod) throw new VMError(`Cannot find module '${filename}'`, 'ENOTFOUND');
    cacheBuiltins[id] = nmod;
  }
  return nmod;
}

But lib/builtin.js checks wildcard negative entries by exact string match against the names in BUILTIN_MODULES:

if (builtins.indexOf(`-${name}`) === -1) {
  addDefaultBuiltin(res, name, hostRequire);
}

BUILTIN_MODULES contains the canonical name child_process, not node:child_process. Therefore -node:child_process does not exclude child_process, and addDefaultBuiltin() registers the host builtin.

Security Boundary Crossed

Sandboxed code reaches a host builtin that the embedder attempted to deny.

Boundary crossed:

  • sandbox -> host child_process builtin
  • sandbox -> host process-spawning function references

Impact

Confirmed impact:

  • require('child_process') succeeds inside the sandbox.
  • require('node:child_process') succeeds inside the sandbox.
  • The returned module exposes execSync and spawn as functions.

Worst confirmed impact is access to host process-spawning APIs. The proof does not execute any command.

The proof does not execute a command, but it confirms access to the host child_process module and its process-spawning APIs. For untrusted sandbox code, this is equivalent to command execution capability.

Safe Local Reproduction

Tested on Node.js v24.14.0.

This proof only checks whether the module and dangerous functions are reachable. It does not spawn a process and does not run OS commands.

'use strict';

const { NodeVM } = require('./');

function probe(builtin) {
  const vm = new NodeVM({
    require: {
      builtin
    }
  });

  return vm.run(`
    const out = {};

    for (const spec of ['child_process', 'node:child_process']) {
      try {
        const cp = require(spec);
        out[spec] = {
          loaded: true,
          execSyncType: typeof cp.execSync,
          spawnType: typeof cp.spawn,
          moduleToStringTag: Object.prototype.toString.call(cp)
        };
      } catch (e) {
        out[spec] = {
          loaded: false,
          name: e && e.name,
          code: e && e.code,
          message: e && e.message
        };
      }
    }

    module.exports = out;
  `);
}

console.log(JSON.stringify({
  nodeVersion: process.version,
  denyNodePrefixed: probe(['*', '-node:child_process']),
  denyCanonical: probe(['*', '-child_process'])
}, null, 2));

Observed result:

{
  "nodeVersion": "v24.14.0",
  "denyNodePrefixed": {
    "child_process": {
      "loaded": true,
      "execSyncType": "function",
      "spawnType": "function",
      "moduleToStringTag": "[object Object]"
    },
    "node:child_process": {
      "loaded": true,
      "execSyncType": "function",
      "spawnType": "function",
      "moduleToStringTag": "[object Object]"
    }
  },
  "denyCanonical": {
    "child_process": {
      "loaded": false,
      "name": "VMError",
      "code": "ENOTFOUND",
      "message": "Cannot find module 'child_process'"
    },
    "node:child_process": {
      "loaded": false,
      "name": "VMError",
      "code": "ENOTFOUND",
      "message": "Cannot find module 'node:child_process'"
    }
  }
}

Expected Secure Behavior

-node:child_process and -child_process should be equivalent.

If either spelling is denied, both of these should fail:

require('child_process')
require('node:child_process')

Suggested Fix

  1. Canonicalize builtin names before allow/deny comparison:
  2. Strip node: from user-provided builtin entries.
  3. Preserve whether an entry is negative (-...) before canonicalizing.

  4. Store and compare one canonical builtin key.

  5. Apply the same normalization to:

  6. wildcard negative entries
  7. explicit allowlist entries
  8. object-form builtin entries

  9. mock/override keys if they are intended to support node: spelling

  10. Add regression tests:

  11. builtin: ['*', '-node:child_process'] blocks child_process.
  12. builtin: ['*', '-node:child_process'] blocks node:child_process.
  13. builtin: ['*', '-node:fs'] blocks fs and node:fs.
  14. builtin: ['*', '-node:fs/promises'] and -fs/promises behave consistently.
  15. Canonical dangerous builtins remain denied even if explicitly requested with node: spelling.
Severity
9.9 (Critical)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.11.6"
      },
      "package": {
        "ecosystem": "npm",
        "name": "vm2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.11.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-92957"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269",
      "CWE-284"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-01T15:36:01Z",
    "nvd_published_at": null,
    "severity": "CRITICAL"
  },
  "details": "## Summary\n\nNodeVM normalizes `node:`-prefixed builtin specifiers during `require()` resolution, but it does not normalize user-provided negative builtin entries in wildcard policy.\n\nAs a result, this configuration:\n\n```js\nnew NodeVM({\n  require: {\n    builtin: [\u0027*\u0027, \u0027-node:child_process\u0027]\n  }\n});\n```\n\ndoes not deny the canonical `child_process` builtin. Sandboxed code can require both `child_process` and `node:child_process`, and receives the host module with process-spawning APIs such as `execSync` and `spawn`.\n\nThe safe proof below only checks module and function reachability. It does not execute any OS command.\n\n## Affected Mode\n\nNodeVM.\n\n## Affected Configuration\n\n```js\nnew NodeVM({\n  require: {\n    builtin: [\u0027*\u0027, \u0027-node:child_process\u0027]\n  }\n});\n```\n\nThis affects users who deny builtins using their `node:`-prefixed spelling, expecting `-node:child_process` to deny `require(\u0027node:child_process\u0027)` and `require(\u0027child_process\u0027)`.\n\n## Affected Files / Functions\n\n- `lib/builtin.js`\n  - `makeBuiltinsFromLegacyOptions`\n  - wildcard builtin expansion\n  - exact negative entry check: `builtins.indexOf(\\`-${name}\\`)`\n  - `addDefaultBuiltin`\n- `lib/resolver.js`\n  - `Resolver.resolve`\n- `lib/setup-node-sandbox.js`\n  - `requireImpl`\n  - `node:` prefix stripping before builtin load\n\n## Root Cause\n\n`lib/setup-node-sandbox.js` strips the `node:` prefix from resolved builtin filenames before loading the builtin:\n\n```js\nif (localStringPrototypeStartsWith(filename, \u0027node:\u0027)) {\n  id = localStringPrototypeSlice(filename, 5);\n  let nmod = cacheBuiltins[id];\n  if (!nmod) {\n    nmod = loadBuiltinModule(id);\n    if (!nmod) throw new VMError(`Cannot find module \u0027${filename}\u0027`, \u0027ENOTFOUND\u0027);\n    cacheBuiltins[id] = nmod;\n  }\n  return nmod;\n}\n```\n\nBut `lib/builtin.js` checks wildcard negative entries by exact string match against the names in `BUILTIN_MODULES`:\n\n```js\nif (builtins.indexOf(`-${name}`) === -1) {\n  addDefaultBuiltin(res, name, hostRequire);\n}\n```\n\n`BUILTIN_MODULES` contains the canonical name `child_process`, not `node:child_process`. Therefore `-node:child_process` does not exclude `child_process`, and `addDefaultBuiltin()` registers the host builtin.\n\n## Security Boundary Crossed\n\nSandboxed code reaches a host builtin that the embedder attempted to deny.\n\nBoundary crossed:\n\n- sandbox -\u003e host `child_process` builtin\n- sandbox -\u003e host process-spawning function references\n\n## Impact\n\nConfirmed impact:\n\n- `require(\u0027child_process\u0027)` succeeds inside the sandbox.\n- `require(\u0027node:child_process\u0027)` succeeds inside the sandbox.\n- The returned module exposes `execSync` and `spawn` as functions.\n\nWorst confirmed impact is access to host process-spawning APIs. The proof does not execute any command.\n\nThe proof does not execute a command, but it confirms access to the host child_process module and its process-spawning APIs. For untrusted sandbox code, this is equivalent to command execution capability.\n\n## Safe Local Reproduction\n\nTested on Node.js `v24.14.0`.\n\nThis proof only checks whether the module and dangerous functions are reachable. It does not spawn a process and does not run OS commands.\n\n```js\n\u0027use strict\u0027;\n\nconst { NodeVM } = require(\u0027./\u0027);\n\nfunction probe(builtin) {\n  const vm = new NodeVM({\n    require: {\n      builtin\n    }\n  });\n\n  return vm.run(`\n    const out = {};\n\n    for (const spec of [\u0027child_process\u0027, \u0027node:child_process\u0027]) {\n      try {\n        const cp = require(spec);\n        out[spec] = {\n          loaded: true,\n          execSyncType: typeof cp.execSync,\n          spawnType: typeof cp.spawn,\n          moduleToStringTag: Object.prototype.toString.call(cp)\n        };\n      } catch (e) {\n        out[spec] = {\n          loaded: false,\n          name: e \u0026\u0026 e.name,\n          code: e \u0026\u0026 e.code,\n          message: e \u0026\u0026 e.message\n        };\n      }\n    }\n\n    module.exports = out;\n  `);\n}\n\nconsole.log(JSON.stringify({\n  nodeVersion: process.version,\n  denyNodePrefixed: probe([\u0027*\u0027, \u0027-node:child_process\u0027]),\n  denyCanonical: probe([\u0027*\u0027, \u0027-child_process\u0027])\n}, null, 2));\n```\n\nObserved result:\n\n```json\n{\n  \"nodeVersion\": \"v24.14.0\",\n  \"denyNodePrefixed\": {\n    \"child_process\": {\n      \"loaded\": true,\n      \"execSyncType\": \"function\",\n      \"spawnType\": \"function\",\n      \"moduleToStringTag\": \"[object Object]\"\n    },\n    \"node:child_process\": {\n      \"loaded\": true,\n      \"execSyncType\": \"function\",\n      \"spawnType\": \"function\",\n      \"moduleToStringTag\": \"[object Object]\"\n    }\n  },\n  \"denyCanonical\": {\n    \"child_process\": {\n      \"loaded\": false,\n      \"name\": \"VMError\",\n      \"code\": \"ENOTFOUND\",\n      \"message\": \"Cannot find module \u0027child_process\u0027\"\n    },\n    \"node:child_process\": {\n      \"loaded\": false,\n      \"name\": \"VMError\",\n      \"code\": \"ENOTFOUND\",\n      \"message\": \"Cannot find module \u0027node:child_process\u0027\"\n    }\n  }\n}\n```\n\n## Expected Secure Behavior\n\n`-node:child_process` and `-child_process` should be equivalent.\n\nIf either spelling is denied, both of these should fail:\n\n```js\nrequire(\u0027child_process\u0027)\nrequire(\u0027node:child_process\u0027)\n```\n\n## Suggested Fix\n\n1. Canonicalize builtin names before allow/deny comparison:\n   - Strip `node:` from user-provided builtin entries.\n   - Preserve whether an entry is negative (`-...`) before canonicalizing.\n   - Store and compare one canonical builtin key.\n\n2. Apply the same normalization to:\n   - wildcard negative entries\n   - explicit allowlist entries\n   - object-form builtin entries\n   - mock/override keys if they are intended to support `node:` spelling\n\n3. Add regression tests:\n   - `builtin: [\u0027*\u0027, \u0027-node:child_process\u0027]` blocks `child_process`.\n   - `builtin: [\u0027*\u0027, \u0027-node:child_process\u0027]` blocks `node:child_process`.\n   - `builtin: [\u0027*\u0027, \u0027-node:fs\u0027]` blocks `fs` and `node:fs`.\n   - `builtin: [\u0027*\u0027, \u0027-node:fs/promises\u0027]` and `-fs/promises` behave consistently.\n   - Canonical dangerous builtins remain denied even if explicitly requested with `node:` spelling.",
  "id": "GHSA-8686-vhfx-7r3j",
  "modified": "2026-10-01T15:36:01Z",
  "published": "2026-10-01T15:36:01Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/patriksimek/vm2/security/advisories/GHSA-8686-vhfx-7r3j"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-92957"
    },
    {
      "type": "WEB",
      "url": "https://github.com/patriksimek/vm2/commit/b0f50662dd499ff33544bb42387958c64711af1e"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/patriksimek/vm2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/patriksimek/vm2/releases/tag/v3.11.7"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/vm2-before-3.11.7-authentication-bypass-via-node-prefix"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "vm2: NodeVM node:-prefixed negative builtin deny bypass exposes child_process"
}

GHSA-86G9-P235-R7FF

Vulnerability from github – Published: 2022-05-13 01:36 – Updated: 2022-05-13 01:36
VLAI
Details

A Permissions, Privileges, and Access Controls issue was discovered in ABB VSN300 WiFi Logger Card versions 1.8.15 and prior, and VSN300 WiFi Logger Card for React versions 2.1.3 and prior. The web application does not properly restrict privileges of the Guest account. A malicious user may be able to gain access to configuration information that should be restricted.

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

{
  "affected": [],
  "aliases": [
    "CVE-2017-7916"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-08-07T08:29:00Z",
    "severity": "MODERATE"
  },
  "details": "A Permissions, Privileges, and Access Controls issue was discovered in ABB VSN300 WiFi Logger Card versions 1.8.15 and prior, and VSN300 WiFi Logger Card for React versions 2.1.3 and prior. The web application does not properly restrict privileges of the Guest account. A malicious user may be able to gain access to configuration information that should be restricted.",
  "id": "GHSA-86g9-p235-r7ff",
  "modified": "2022-05-13T01:36:14Z",
  "published": "2022-05-13T01:36:14Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-7916"
    },
    {
      "type": "WEB",
      "url": "https://ics-cert.us-cert.gov/advisories/ICSA-17-192-03"
    },
    {
      "type": "WEB",
      "url": "http://search.abb.com/library/Download.aspx?DocumentID=9AKK107045A1977\u0026LanguageCode=en\u0026DocumentPartId=\u0026Action=Launch"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/99558"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-86PJ-HRWX-9VHG

Vulnerability from github – Published: 2023-08-14 21:30 – Updated: 2024-04-04 06:56
VLAI
Details

In startActivityInner of ActivityStarter.java, there is a possible way to launch an activity into PiP mode from the background due to BAL bypass. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.

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-2023-21269"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-266",
      "CWE-269"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-08-14T21:15:12Z",
    "severity": "HIGH"
  },
  "details": "In startActivityInner of ActivityStarter.java, there is a possible way to launch an activity into PiP mode from the background due to BAL bypass. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.\n\n",
  "id": "GHSA-86pj-hrwx-9vhg",
  "modified": "2024-04-04T06:56:08Z",
  "published": "2023-08-14T21:30:59Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-21269"
    },
    {
      "type": "WEB",
      "url": "https://android.googlesource.com/platform/frameworks/base/+/70ec64dc5a2a816d6aa324190a726a85fd749b30"
    },
    {
      "type": "WEB",
      "url": "https://source.android.com/security/bulletin/2023-08-01"
    }
  ],
  "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-86QF-5646-CHG9

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

In SpecializeCommon of com_android_internal_os_Zygote.cpp, there is a permissions bypass due to an incomplete cleanup. This could lead to local escalation of privilege in isolated processes with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-10Android ID: A-156741968

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2020-0257"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-08-11T20:15:00Z",
    "severity": "HIGH"
  },
  "details": "In SpecializeCommon of com_android_internal_os_Zygote.cpp, there is a permissions bypass due to an incomplete cleanup. This could lead to local escalation of privilege in isolated processes with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-10Android ID: A-156741968",
  "id": "GHSA-86qf-5646-chg9",
  "modified": "2022-05-24T17:25:16Z",
  "published": "2022-05-24T17:25:16Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-0257"
    },
    {
      "type": "WEB",
      "url": "https://source.android.com/security/bulletin/2020-08-01"
    }
  ],
  "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