Flowise: 26 flaws in one day, CVE-2026-70477 — update to 3.1.4+

[Updated August 5, 2026] 26 Flowise vulnerabilities were disclosed on August 4 alone. Ten are rated 9.0 or above, topping out at 9.5, and one has been demonstrated all the way to a root shell. Closing all 26 requires 3.1.4 or later; the 3.1.0 this article previously pointed to closes none of them. Details are in the next section.

What follows is the original coverage, centred on CVE-2026-56271 from July.

A new critical flaw in Flowise — the popular tool for building AI chatbots and AI agents without writing code — lets anyone impersonate an administrator when the software runs with its default settings (CVE-2026-56271). It was registered in the U.S. vulnerability database NVD on July 12, 2026, rated 9.8 out of 10. No login is required, and no password needs to be guessed. The cause: the "key" Flowise uses to verify who a user is falls back, in its default state, to the same value on every Flowise in the world — a factory-default master key, in effect.

The good news is that this hole has a fix in 3.1.0 — upgrading closes it (though, as noted above, closing the 26 flaws disclosed on August 4 requires 3.1.4 or later). But Flowise is also a product where this kind of "weak authentication" has surfaced again and again. CVE-2026-56271 is the latest in a line of "walk straight past the login" flaws, following CVE-2025-71327 (a missing-authentication registration API that let anyone create a valid account). Go back further and the still-unpatched CVSS 10.0 flaw CVE-2025-71338 (covered below) also remains open.

So defending Flowise is not settled by "just upgrade to the latest." Which version your Flowise runs, where it can be reached from, and which keys it connects to all matter. This article puts CVE-2026-56271 — the top priority right now — first, then lays out the status of the serious flaws that have recurred since the 2024 overrideConfig flaw (CVE-2024-58351, below), together with a version-by-version quick reference.

What Flowise actually does

Flowise is an open-source tool that lets you build AI chatbots, AI agents, and "let an AI answer from your internal documents" setups (RAG) just by connecting blocks on a canvas. Because you can assemble an AI app without programming knowledge, it is widely used as a "no-code / low-code way to build AI." Its GitHub star count is over 53,000, making it one of the most popular tools in the space.

There are two main ways to use it. One is to rent the official cloud; the other is to run it on your own server, known as self-hosting. The flaws bite in the second case. Flowise can be stood up on AWS, Azure, GCP, or an internal Linux box with a few commands like npm install -g flowise. That ease is exactly why huge numbers of instances sit around the world: left running after a quick test, or exposed to the internet with default settings.

By its nature, Flowise tends to become a collection point for sensitive credentials: API keys that power the AI (the OpenAI or Anthropic keys tied directly to your bill), connection details for internal databases, the internal documents and manuals loaded into RAG, and customer chat histories. All of it gathers on a single Flowise box. Understanding that makes it clear what flows out when a takeover happens.

[Latest] 26 flaws in one day, August 4 — the target is 3.1.4

On August 4, 2026, 26 Flowise vulnerabilities were disclosed in a single day. Ten of them are rated 9.0 or higher, and the top score, 9.5, appears twice. This article sorts all 26 by severity and by the privilege an attacker needs. The count is as of writing (morning of August 5). Publication ran intermittently through the night.

The work is a single upgrade. 25 of the 26 are fixed in 3.1.3 and one is fixed only in 3.1.4, so the target is 3.1.4 or later. The 3.1.0 this article previously pointed to closes none of the 26.

Note: this article initially published these 26 as "two" and then "five." Disclosure continued over several hours and we undercounted; the full set was recounted and replaced on the morning of August 5. The upgrade advice given at the time (3.1.3 or later) was not wrong, but 3.1.4 or later is the accurate floor.

The heaviest fact first

CVE-2026-69255 (severity 9.2) comes with a working exploit chain in the open. The vendor advisory carries this note from the researcher:

"This is not theoretical — a Meterpreter reverse shell session as root has been established on Flowise 3.1.2."

The steps run from injecting Python through data handed to the CSV Agent, all the way to root on the server, laid out stage by stage. An attacker has nothing left to figure out.

One distinction matters. This is a researcher demonstrating it on their own instance, not a report of attacks in the wild. Flowise still does not appear on the US government's catalog of vulnerabilities known to be exploited. That said, the gap between a published working chain and real attacks is usually short.

Both 9.5s are "slip past the checker" flaws

CVE-2026-70477 was reported through Trend Micro's Zero Day Initiative. It executes code by feeding a prompt into the CSV Agent — the very mechanism of instructing an AI in plain language becomes the attack path.

CVE-2026-70470 walks past the denylist that filters dangerous Python keywords by using characters that look identical but are not (Unicode homoglyphs). To a human eye they are the same character; to the denylist they are not a match. It is the limit of "ban the dangerous words" as a defence, laid bare.

Four at 9.4, three of them in the CSV feature

Counting CVE-2026-69264, 69256 and 69259 alongside 70477, 70470 and 69255, six of the 26 sit in the CSV Agent and its Python runtime (Pyodide). The feature for reading a spreadsheet doubled as a window for running code on the server.

The remaining one, CVE-2026-69254, let the sandboxed side overwrite the safety settings of the JavaScript sandbox (NodeVM) itself. Permit every built-in module, require child_process, and OS commands run as root.

Six are reachable without logging in

Six of the 26 can be attacked by someone with no account at all (70477, 70470, 69255, 70478, 69258, 70476). This is where priority belongs.

CVE-2026-70478 (9.2) stands out: the OAuth token refresh endpoint sat on the authentication exemption list, decrypting the stored credential and returning the access token with it. The keys to your connected cloud services walk straight out. Updating Flowise does not help there — leaked credentials stay valid until you revoke and reissue them.

Two of them route around earlier fixes

CVE-2026-69263 (8.7) is a hole in the patch for CVE-2025-8943 from 2025. That mitigation blocked -y and --yes on npx and denied exactly four environment variable names. The equivalent npm_config_yes was not among those four.

Together with 70470 above, both are cases of a denylist-based defence being walked around — the same root as "Why vm2 couldn't stop it" later in this article.

Eight more bite if several teams share one instance

70474, 70473, 70472, 70471, 69262, 69252, 70476 and one un-numbered advisory all cross workspace or organisation boundaries: another team's credentials become visible, their files deletable, their billing manipulable, their variables readable.

None of this matters for a single user. But an organisation that split departments into workspaces on one shared Flowise had a partition that was not really holding.

All 26

The lower the privilege required, the higher the priority. Every fix but one is in 3.1.3; closing all 26 requires 3.1.4.

Four have no CVE number yet. They are published as vendor advisories (GHSA) and numbers follow later. No number does not mean minor.

Reporting credit goes to the security firm elttam for three, Trend Micro's Zero Day Initiative for one, and independent researchers for most of the rest. Twenty-six in a day is not one person digging hard; it is many researchers' reports landing on the same publication date.

CVE-2026-56271: a "shared master key" lets anyone impersonate an admin when left on defaults

The first thing to fix is CVE-2026-56271, registered in NVD on July 12, 2026. In short, the "key" Flowise uses to verify a user's identity was a fixed, hard-coded value in its default state — the same on every install. The severity is 9.8 on CVSS, the international common score that rates severity from 0 to 10 (9.3 under the newer 4.0). It is classified as CWE-321 (Use of Hard-coded Cryptographic Key), and it bypasses authentication entirely.

The people who welcome this hole most are attackers who sweep the internet for Flowise instances reachable directly and, at every admin panel they reach, present a self-made "pass" to walk in. They don't need to steal a password or brute-force one. If the key's value is public information and identical worldwide, they can forge a fake ID that looks like a legitimate login, right on their own machine. What they actually do is assemble a forged token that claims to be an "administrator" and hand it straight to Flowise to enter with the highest privileges. Without ever passing the login screen, they act as an admin inside.

What you lose once they're in is whatever Flowise tends to hoard. They burn through the API keys that power the AI (the OpenAI or Anthropic keys tied directly to your bill), exfiltrate the internal databases it connects to and the contracts and customer logs fed into RAG, and turn the always-on server into a relay for the next attack. Worse, an intrusion via a forged token looks like a "valid login" in the records, so it's easy to miss after the fact. Organizations and solo developers who expose the admin panel to the internet take the direct hit.

Why it becomes a "shared master key"

Flowise issues each logged-in user a token that acts like an "entry pass" (a JWT), and from then on checks access by the validity of that pass. Whether a pass is genuine is verified with a secret phrase (a secret key) that only the server should know. As long as no one else knows it, forged passes can't be made. Conversely, if the phrase is public, anyone can forge a pass that looks real.

CVE-2026-56271 is exactly about how the software behaved when that phrase was missing. According to the vendor advisory (GHSA-cc4f-hjpj-g9p8) and VulnCheck's analysis, the authentication middleware (enterprise/middleware/passport) would, when the administrator had not set a secret key via environment variables, silently fall back to a hard-coded default written in the source. Those defaults were the strings auth_token and refresh_token — obvious to anyone who reads the source. The default issuer and audience for the pass were the fixed strings ISSUER and AUDIENCE, so every ingredient needed for impersonation is available from public information alone.

The flaw was found by kolega-ai-dev through a code scan by Kolega.dev. It affects 3.0.13 and earlier and is fixed in 3.1.0. The fix stops falling back to the dangerous defaults and instead halts at startup if the keys are unset. The remedy is clear: upgrade to 3.1.0 or later (ideally the latest), and always set secret keys like JWT_AUTH_TOKEN_SECRET to a sufficiently long, random value that only you know. Concrete steps are in "What to do right now" below.

The four critical flaws disclosed in June, at a glance

Flowise's authentication problems did not start with this one. Just ahead of it, on June 25, 2026, security firm VulnCheck — which has tracked attacks on Flowise before — disclosed four critical flaws at once, including one rated a perfect 10.0. All need no authentication (or bypass authentication itself), and ultimately lead to running arbitrary code on the server or seizing legitimate API access. Start with the overview below.

The latest stable release is 3.1.3 (June 25). CVE-2025-71334 and CVE-2025-71336 are closed by moving to 3.0.6 or later, but CVE-2025-71338 and CVE-2025-71327 are not — no fixed version exists even on the latest release, so defending them depends on the "cut off exposure, wall off with authentication" operation described later.

Who targets these four, and what are they after

CVSS numbers alone make it hard to see "does this affect me," so let's sketch the attacker first. The biggest concern right now is indiscriminate scanners that sweep the internet for Flowise instances reachable directly and fire off no-login exploits at every one that answers. They don't pick targets. Like crawlers, they walk address ranges worldwide and push known attacks at any Flowise that responds. A 10.0 flaw with no patch is an ideal target for this kind of automation.

Once inside, what they do is overwrite the server's own configuration files via a crafted file name, so their program launches on the next restart. With that foothold, the rest is an ordinary takeover. They burn through someone else's AI budget with the API keys stored in Flowise, siphon the internal databases it connects to and the contracts and customer logs fed into RAG, and repurpose the always-on cloud server for crypto mining or as a relay for the next attack. With the registration-API abuse (CVE-2025-71327), they can hammer the API with an account they created themselves, so their traffic hides among "valid logins" and detection lags.

The final cost lands on the company or solo developer who built Flowise into their work. Worse than a server going down is having your AI spend drained by a stranger, your internal documents and customer conversations turned into someone else's stored data, and your own server rebuilt into a tool for attacks. And because this round cannot be fully resolved by a version bump, whether your Flowise is reachable from the outside is exactly what decides whether you get hit. As covered below, a prior Flowise flaw reportedly exposed 12,000 to 15,000 instances — so "no one targets our little test box" does not hold.

A closer look at the four flaws

CVE-2025-71338: writing arbitrary files via a crafted file name (CVSS 10.0, no patch)

This is the most severe of the four. Flowise has an API, /api/v1/document-store/loader/process, that ingests documents to load into RAG. According to VulnCheck's analysis, the internal file-saving code (storageUtils.ts) took the externally supplied fileName and used it to build a path without validation.

Mixing ../ ("up one level") into the file name lets you jump past the intended save location and drop a file anywhere on the server. This technique is called path traversal. In the public proof-of-concept (PoC), Flowise's own package.json is overwritten so that the planted command runs automatically when the server restarts, reaching remote code execution (RCE). No authentication is needed. The CVSS is a perfect 10.0 under both 3.1 and 4.0, classified as CWE-73 (External Control of File Name or Path). It was reported by pyozzi-toss. As noted, the vendor advisory's fixed-version field is blank, with no "upgrade to this version to fix it" guidance at this time.

CVE-2025-71334: arbitrary file read/write from an unchecked chat-flow ID (CVSS 9.8, fixed in 3.0.6)

This shares the same root: an externally supplied value used in a path. Flowise handles the AI flows you build with identifiers like chatflowId and chatId, but it did not check that these were the expected form (a UUID or a number). Per the advisory (GHSA-q67q-549q-p849), planting path-traversal values into these identifiers lets an attacker write arbitrary files via /api/v1/chatflows or read files through other endpoints, leading to code execution. The CVSS is 9.8 under 3.1 and 9.3 under 4.0. The fix shipped in 3.0.6, which now validates the identifiers properly.

CVE-2025-71336: unauthenticated OS command execution via Custom MCP (CVSS 9.8, fixed in 3.0.6)

Flowise's "Custom MCP" is a block for calling external MCP servers (the mechanism that lets an AI use tools); by design it runs OS commands, such as launching a local MCP server. According to the advisory (GHSA-6933-jpx5-q87q), a config sent here was executed without a sandbox and slipped past weak authentication/authorization, allowing arbitrary OS commands to run. It is classified as CWE-78 (OS command injection), CVSS 9.8 under 3.1 and 9.3 under 4.0, fixed in 3.0.6.

This "command execution from Custom MCP" belongs to the same feature and the same fix release (3.0.6) as CVE-2025-59528 (CVSS 10.0, confirmed under active attack in April 2026), which we covered earlier — a closely related flaw. It shows the Custom MCP area being patched as a series of related points. Either way, if you run a version before 3.0.6 and use Custom MCP, this is a priority to update.

CVE-2025-71327: an unprotected registration API lets anyone create a valid account (CVSS 9.1, no patch)

The last one is different in kind: not code execution but an authentication bypass. Flowise's /api/v1/account/register (account registration API) is unprotected, and per the advisory (GHSA-v5w9-prxf-w882), an unauthenticated third party can create an account even after the organization's initial setup is complete. The created account can access the API with legitimate privileges, effectively walking straight past authentication. It is classified as CWE-306 (Missing Authentication for Critical Function), CVSS 9.1 under 3.1 and 9.3 under 4.0. Versions up to 3.0.1 (the latest at the time of report) are affected; reporters are ReeFSpeK and ERANV-EVA. This too has no fixed version listed in the vendor advisory, so making the registration API unreachable from the outside is the interim defense.

Is your Flowise affected? (version quick reference)

Flowise patches actively, but serious takeover holes have appeared repeatedly across versions over time. Check the version you run with npm list -g flowise or in the admin UI, and match it to the holes below.

What this table shows is that "I'm safe because I'm on the latest version" does not hold. Holes that a patch can close should of course be upgraded immediately, but as long as there is a hole with no fix yet — this round's 10.0 (CVE-2025-71338) — the top priority, regardless of version, is to rethink the operation itself: never expose Flowise to the internet, and always require authentication. Apply the measures below as well.

What to do right now

1. Stop exposing it directly to the internet, now. With a 10.0 hole that has no patch, this comes first. If it runs in the cloud, restrict access to the admin panel and API by firewall or security group to trusted IPs only, and if you need it on the go, switch to a VPN, an SSH tunnel, or an authenticated reverse proxy. In particular, making /api/v1/document-store/loader/process (CVE-2025-71338) and /api/v1/account/register (CVE-2025-71327) unreachable from outside is the real interim defense.

2. Update the holes that do have a fix. This round's CVE-2026-56271 is fixed in 3.1.0, and CVE-2025-71334, 71336, and 59528 in 3.0.6. If any apply, get all the way to the latest 3.1.3. If installed globally via npm, run npm update -g flowise; with Docker, pull the latest image and recreate the container. Note that even the latest version does not close CVE-2025-71338 or 71327, so always pair this with the exposure measures in step 1.

3. Always enable authentication, and set the secret keys yourself. Flowise can be protected with a username and password. Historically authentication was added later, and many instances run defenseless in their default state, which is exactly why over 10,000 were exposed worldwide. Set the environment variables FLOWISE_USERNAME and FLOWISE_PASSWORD, and enable API-key protection as well. On top of that, to close CVE-2026-56271, explicitly set the identity-token secret keys JWT_AUTH_TOKEN_SECRET and JWT_REFRESH_TOKEN_SECRET to sufficiently long, unguessable random values. Leaving them empty falls back to the hard-coded defaults and opens the door to impersonation. A value generated with openssl rand -hex 32 is a safe choice.

4. Rotate the keys and passwords you've connected. If there's any chance an affected version was exposed, treat every API key (OpenAI, Anthropic, etc.), database credential, and token registered in Flowise as leaked and reissue them. Check your AI usage bills for unexplained spikes too.

5. Inspect for signs of compromise. On the server running Flowise, check ps aux for unfamiliar processes (such as crypto miners), /tmp and /var/tmp for unknown executables, a tampered package.json, and any suspicious cron entries or outbound connections. Because CVE-2025-71338 hinges on overwriting config files, verify that Flowise's own files have not been altered. If anything looks off, rebuilding from a clean environment is the surest path.

CVE-2024-58351: how overrideConfig becomes a takeover path

Trace the four new flaws back and you reach what could be called the "origin" of Flowise's vulnerabilities: the overrideConfig flaw found in 2024. The number is recent (NVD formally registered it in June 2026), but the lineage of "execute or store external input as-is" that recurs afterward starts here. Understanding the background makes it clearer why this year's four happened.

CVE-2024-58351: unauthenticated code execution via the config-override feature (CVSS 9.8, fixed in 2.1.4)

CVE-2024-58351 is rooted in the design of Flowise's overrideConfig feature. NVD classifies it as CWE-94 (Improper Control of Generation of Code). The CVSS score is 9.8 under version 3.1 and 9.3 under the newer version 4.0, both in the top tier.

overrideConfig is meant as a developer convenience. When you call a Flowise AI flow from the outside, you can inject "run it with this config for now" into the request. The problem is that this injection was almost unrestricted by default. The vendor's own advisory (GHSA-5cph-wvm9-45gj) states that "overrideConfig should have an explicit allow list," pointing to the absence of that allow list as the core problem. The flaw was reported by ryanhalliday.

What can be swapped is not just the prompt text handed to the AI. Some Flowise blocks execute code passed in as config inside a so-called sandbox, an isolated environment. A sandbox is supposed to be a "safe box you can't escape from," but the vm2 library Flowise used has a known weakness that lets you break the box and reach the host server outside it. The attacker sends crafted code into that box via overrideConfig, breaks out (a sandbox escape), and runs arbitrary programs on the server. The fix shipped in 2.1.4, and every version before it remains affected.

Why "vm2" couldn't stop it

At the center of the overrideConfig hole was a library called vm2. It is a mechanism for running JavaScript code in isolation, and many tools adopted it as a "safe box for running externally supplied code." But vm2 had escape vulnerability after escape vulnerability found in it, until the author himself declared that "fixing the vulnerability seems impossible" and ended development.

In other words, Flowise was using a box that structurally cannot be sealed to execute external input. The vendor's advisory recommends moving to a more robust isolation approach such as isolated-vm. As this round's CVE-2025-71336 (Custom MCP) — "OS commands running with no sandbox" — shows, the more an AI tool has a feature that "runs the user's code or expressions on the spot," the more this "choice of box" directly decides the safety of the whole product. The same pattern keeps showing up in cases we have covered, such as the Langflow tar-link RCE and the LiteLLM command injection.

Why this isn't just an old bug: the chain of Flowise takeovers

The lineage that overrideConfig (CVE-2024-58351) opened — "executing or storing external input as-is" — has recurred in Flowise ever since. This year's four are the latest chapter.

Published in September 2025, CVE-2025-59528 was extremely severe, with a perfect CVSS of 10.0. A config sent to the "CustomMCP" block, used to connect to an external MCP server, was executed as JavaScript without checks, allowing arbitrary code to run without authentication. It was fixed in 3.0.6. That this round's CVE-2025-71336 belongs to the same Custom MCP feature and the same 3.0.6 fix shows how persistently that feature has been targeted.

No confirmed attacks does not mean "safe." A state where the technical details and a PoC are public while no fix exists is exactly the easiest moment for attackers to move. The ease of "building AI without writing code" is a hair's breadth from a design that "runs external input as-is," and Flowise is the product where that difficulty concentrates.

The Flowise vulnerability timeline so far

← Swipe to move

Actively exploited CVEs and related reading

As of July 2026, neither CVE-2026-56271 nor any of June's four flaws are listed in the U.S. CISA "Known Exploited Vulnerabilities (KEV)" catalog. On the other hand, Flowise's CVE-2025-59528 has confirmed real-world exploitation and is being watched for KEV inclusion. We keep the latest status of confirmed-exploited CVEs updated in our CISA KEV dashboard (Japanese).

Vulnerabilities in npm-distributed OSS like Flowise can spread into unexpected places through dependency chains. To check whether the packages you use carry known holes, see our OSS supply-chain scanner. AI-tool takeovers keep happening as the flip side of the same "let the AI do anything" convenience, as we've covered with Langflow being attacked 20 hours after disclosure, the flaw in Amazon's AI dev tool Kiro, and the AutoGPT vulnerability.

Summary

On July 12, 2026, a new critical flaw, CVE-2026-56271, was disclosed in Flowise. When the secret key used to verify identity is unset, it silently falls back to a shared, hard-coded default, letting anyone forge a token and impersonate an administrator — a CVSS 9.8 flaw. This one is fixed in 3.1.0, so upgrading and setting the secret keys yourself closes it. Meanwhile, of June's four flaws, CVE-2025-71338 (arbitrary file write in the document-ingest API, CVSS 10.0) and the missing-authentication registration flaw CVE-2025-71327 still have no fix.

Most of these belong to the same "weak authentication or careless handling of external input" lineage as the 2024 overrideConfig flaw (CVE-2024-58351) and the actively exploited CVE-2025-59528. Upgrade the holes a patch can close to the latest 3.1.3 right away; for the ones it can't, keeping Flowise off the public internet and behind authentication is the only realistic defense. Which version is your Flowise on, where can it be reached from, and what keys does it connect to? The more conveniently you use it, the more worthwhile it is to take this moment for a full inventory.

References

• ▸ NVD - CVE-2026-56271 (hard-coded identity-token secret, CVSS 9.8)
• ▸ FlowiseAI Advisory - GHSA-cc4f-hjpj-g9p8 (CVE-2026-56271)
• ▸ VulnCheck - Flowise weak default JWT secrets in authentication middleware
• ▸ NVD - CVE-2025-71338 (document-store path traversal, CVSS 10.0)
• ▸ NVD - CVE-2025-71334 (chatflowId validation)
• ▸ NVD - CVE-2025-71336 (Custom MCP OS command execution)
• ▸ NVD - CVE-2025-71327 (registration API missing auth)
• ▸ FlowiseAI Advisory - GHSA-8vvx-qvq9-5948 (CVE-2025-71338)
• ▸ VulnCheck - Flowise arbitrary file write to RCE via document store API
• ▸ FlowiseAI Advisory - GHSA-3gcm-f6qx-ff7p (CVE-2025-59528)
• ▸ NVD - CVE-2024-58351 (overrideConfig)
• ▸ The Hacker News - Flowise under active exploitation
• ▸ Flowise releases (GitHub)
• ▸ CISA - Known Exploited Vulnerabilities Catalog