Flowise Is Being Actively Exploited. Your AI Stack Has More Exposure Than You Think.#

On April 7, VulnCheck's canary network detected the first active exploitation of CVE-2025-59528 -- a CVSS 10.0 remote code execution vulnerability in Flowise, the open-source platform widely used for building AI agents and LLM workflows. Between 12,000 and 15,000 Flowise instances are currently exposed on the public internet.

The fix has existed since September 2025. If you're running Flowise below version 3.0.6, stop reading and upgrade to 3.1.1 now.

If you're already patched, keep reading. Fixing the Flowise RCE is step one. Your dependency stack is step two.

What CVE-2025-59528 Is#

The vulnerability lives in Flowise's CustomMCP node, which lets users configure connections to external Model Context Protocol servers. The node parses a mcpServerConfig string and passes it directly into a Function() constructor without validation. An attacker can inject arbitrary JavaScript, which executes with full Node.js runtime privileges -- giving access to child_process for command execution and fs for file system access.

No authentication is required in many configurations. A single crafted HTTP POST request is enough.

CVE-2025-59528 is the third Flowise vulnerability under active exploitation. CVE-2025-8943 (CVSS 9.8, OS command RCE) and CVE-2025-26319 (CVSS 8.9, arbitrary file upload) are also being actively exploited in the wild. Upgrading to Flowise 3.1.1 addresses all three.

The exploitation activity detected by VulnCheck originated from a single IP. CVE-2025-59528 has been public since September 2025 -- a fix has existed for months -- and with over 12,000 exposed instances the attack surface is large enough that exploitation is expected to intensify as the vulnerability becomes more widely known.

Patching Flowise Is Step One#

Upgrade path:

# If using npm
npm install flowise@latest
 
# If using Docker
docker pull flowiseai/flowise:latest
docker compose up -d

Official upgrade guide: docs.flowiseai.com

After upgrading, audit server-side data exposure and rotate any credentials that may have been accessible from the compromised Node.js process -- environment variables, database credentials, cloud tokens, API keys.

The Dependency Stack Is Step Two#

Patching Flowise removes the RCE vector. It does nothing for the Python packages your Flowise deployment sits alongside.

Most Flowise deployments in production run next to Python services that use LangChain, the OpenAI SDK, the Anthropic SDK, and supporting libraries like FastAPI and Requests. If any of those packages carry CVE exposure, your agent stack has risk that upgrading Flowise won't address.

Attestd monitors all of them. Here's what the current versions look like:

curl -s "https://api.attestd.io/v1/check?product=langchain&version=0.2.0" \
  -H "Authorization: Bearer YOUR_API_KEY" | jq .

{
  "product": "langchain",
  "version": "0.2.0",
  "supported": true,
  "risk_state": "none",
  "cve_ids": [],
  "confidence": 0.9,
  "last_updated": "2026-04-10T16:58:46.355634Z"
}

You can scan your full Flowise-adjacent stack in a single loop:

from attestd import Client
 
client = Client(api_key="YOUR_API_KEY")
 
flowise_deps = {
    "langchain": "0.2.0",
    "openai": "1.3.0",
    "anthropic": "0.40.0",
    "fastapi": "0.115.0",
    "requests": "2.31.0",
}
 
for package, version in flowise_deps.items():
    result = client.check(package, version)
    if result.risk_state in ("critical", "high"):
        print(f"ALERT: {package}@{version} — {result.risk_state}")
        print(f"  Fixed in: {result.fixed_version}")
        print(f"  CVEs: {result.cve_ids[:3]}")
    else:
        print(f"OK: {package}@{version}")

OK: langchain@0.2.0
OK: openai@1.3.0
OK: anthropic@0.40.0
OK: fastapi@0.115.0
OK: requests@2.31.0

Current versions are clean. But "clean today" is not a permanent state. To show what risk looks like in this stack, here is what Attestd returns for an outdated MongoDB version -- the kind of database a Flowise deployment commonly sits in front of:

{
  "product": "mongodb",
  "version": "3.6.0",
  "supported": true,
  "risk_state": "critical",
  "actively_exploited": false,
  "cve_ids": ["CVE-2018-20802", "CVE-2018-20803", "CVE-2018-20804"],
  "fixed_version": "4.4.30",
  "confidence": 0.95,
  "last_updated": "2026-04-10T16:58:46Z"
}

17 CVEs, critical risk state, fix path to 4.4.30. The same check that shows langchain@0.2.0 as clean returns this for a MongoDB version that's still running in a lot of production environments.

The point is not that your current stack is broken. It's that stack state changes, and checking it manually across 50 transitive dependencies isn't something humans do reliably.

CVEs Are Not the Only Threat Surface#

The Flowise exploitation story is a CVE story: known vulnerability, patch available, administrators didn't apply it. That pattern is repeatable and predictable.

The harder threat is the one that doesn't have a CVE yet.

Two weeks ago, attackers published trojanized versions of LiteLLM -- versions 1.82.7 and 1.82.8 -- to PyPI. The malicious versions were live for several hours before removal. No CVE was filed during the attack window. Any Flowise deployment pulling LiteLLM as a dependency during those five hours installed a credential stealer without any scanner catching it. CVE monitoring alone would not have stopped it.

This is the gap that supply chain monitoring addresses. CVE data tells you about known vulnerabilities in published code. Supply chain monitoring tells you if the code itself has been maliciously replaced.

Next weekend, Attestd is shipping supply chain monitoring. The /v1/check endpoint will return a supply_chain object alongside the existing CVE fields:

{
  "product": "langchain",
  "version": "0.2.0",
  "risk_state": "none",
  "supply_chain": {
    "compromised": false,
    "sources": [],
    "last_updated": "2026-04-10T08:00:00Z"
  }
}

And when a package has been compromised -- as LiteLLM was on March 24 -- the response will surface it directly:

{
  "product": "litellm",
  "version": "1.82.7",
  "risk_state": "none",
  "supply_chain": {
    "compromised": true,
    "sources": ["osv", "registry"],
    "malware_type": "backdoor",
    "description": "TeamPCP supply chain attack — credential stealer in proxy_server.py",
    "compromised_at": "2026-03-24T10:39:00Z",
    "removed_at": "2026-03-24T16:00:00Z"
  }
}

risk_state: none because there are no CVEs. supply_chain.compromised: true because the package was maliciously published. Two different signals, both needed.

What to Do Now#

Patch Flowise to 3.1.1 if you haven't. Rotate credentials if there's any chance your instance was exposed. Then run your dependency stack through Attestd -- the API is free up to 1,000 calls a month, no credit card required.

Get an API key at api.attestd.io/portal/login. Full API reference at attestd.io/docs/api-reference.

Supply chain monitoring launches next weekend. Sign up above to be notified.