Flowise Security: Self-Hosted Flowise AI Hardening, Enterprise Controls and the Unpatched 3.1.4 Advisories
The Flowise repository was archived on August 13, 2026 and version 3.1.4, published on July 29, is the last release that will ever exist. Advisories published after the code freeze name 3.1.4 as affected and list no patched version, because there is nobody left upstream to publish one.
Direct answer
Flowise is a visual builder for LLM apps and agents with more than 55,000 GitHub stars, acquired by Workday in August 2025 and wound down in 2026. The sunset notice is specific about what stops: "Active feature development ceases immediately. We will no longer be reviewing or accepting new Pull Requests," and "Official core team presence in Discord and GitHub will conclude." It makes no commitment to security patches and names no successor product. The honest recommendation for most teams is to migrate off, not to buy a control plane to wrap a dead application. Migrations take quarters, though, and the instance keeps running in the meantime. AgentShield is for that gap: a policy point outside the application that limits what a compromised Flowise instance can reach, regardless of whether the application itself can still be patched.
Try it live
Watch AgentShield block an attack in real time.
Pick a scenario and drive the inspection lane yourself. No signup needed.
Run a request
Runs the live engine on your text. Nothing is stored, no account needed.
Inspection lane
INSPECTINGPolicy trace
High-risk action held for approval
Audit trail
- § · → → →
The risk
A mid-size company stood up self-hosted Flowise in 2025 so that non-engineers could assemble chatflows. It holds OAuth credentials for the CRM, a read-write database connection and a handful of custom tools, and it sits inside the network because that was the secure-looking choice. In August 2026 the repository is archived. A week earlier, roughly two dozen advisories land in a single day. One of them describes an authentication bypass on the OAuth2 credential refresh endpoint that needs no login at all, rated 8.7, affecting "Flowise through 3.1.4". The version they are running is 3.1.4. There is no upgrade, because 3.1.4 is the end of the line, and the team that would have written the fix announced its own conclusion on August 31.
How AgentShield handles it
Treat the Flowise instance as untrusted infrastructure that still has to work. Put a policy point between it and everything it can reach, so that the blast radius stops being a function of unpatched application code. Scope the credentials it holds to the minimum each chatflow actually needs, take irreversible actions away from it entirely and route them through an approval gate, inspect tool output before a downstream step acts on it, and keep an audit record outside the box so that if the instance is compromised the evidence is not inside the thing that was compromised. Then migrate on a real timeline rather than an emergency one.
The controls
The controls that secure what a self-hosted Flowise instance can still reach, now that 3.1.4 is the last release.
What the Flowise sunset commits to, and what it leaves open
Read the sunset notice literally, because the gap between what it says and what people assume it says is where the risk lives. It is a clear, professional wind-down that tells you exactly which activities stop. It does not tell you that anybody will fix a vulnerability found afterward, and it does not claim anyone will.
| Date | What happened | What it means operationally |
|---|---|---|
| July 29, 2026 | Code freeze. Version 3.1.4 published, the final release | "Active feature development ceases immediately. We will no longer be reviewing or accepting new Pull Requests." Any fix now has to come from you or a fork |
| August 4, 2026 | A large batch of security advisories published on a single day, a substantial share rated critical | They arrived after the code freeze, so the usual patch-and-upgrade response was already unavailable |
| August 10, 2026 | Archive date stated on the vendor sunset page | The repository moves to public archive status and becomes read-only |
| August 13, 2026 | Repository actually archived on GitHub | The stated date and the recorded date differ by three days. Use the GitHub record for evidence |
| August 31, 2026 | "Official core team presence in Discord and GitHub will conclude." | No maintainer to triage a report, and no coordinated disclosure path |
The notice offers one continuation path: "Flowise source code will still remain on Github and the Apache 2.0 licensed code is yours to keep building on," with an encouragement to fork the repository and maintain internal updates or community-led forks. That is a genuine and generous position for a project to take on its way out, and for some teams forking is the right answer. The next section is about why it covers less of the codebase than it first appears to.
One thing the notice does not do is name a successor product. If you are writing a migration plan, there is no vendor-endorsed destination to point at, which means the choice of where to go is entirely yours to justify.
The fork path does not cover the authentication layer, because it is not Apache 2.0
This is the part we have not seen written anywhere else, and it changes the build-versus-migrate maths for any team that was relying on "we will just fork it".
Flowise is not uniformly Apache 2.0. The license file carves out an exception: all content under the packages/server/src/enterprise directory, plus files carrying an explicit copyright notice such as IdentityManager.ts, is licensed under a Commercial License rather than Apache 2.0. That directory and that file are not incidental. They are the authentication, single sign-on and role-based access control layer.
So the fork advice holds for the parts of Flowise that build and run chatflows, and it is weakest at exactly the layer where the post-freeze advisories cluster. A community fork can keep improving node types and connectors under Apache 2.0. A community fork cannot freely take over maintenance of the identity and access-control code, which is where an authentication bypass would need to be fixed.
| If your plan is | Realistic outcome | What still needs a separate control |
|---|---|---|
| Upgrade to a patched release | Not available. 3.1.4 is the final release and advisories against it list no patched version | Everything |
| Fork and self-maintain | Workable for the Apache 2.0 majority of the codebase. The enterprise identity layer sits under a Commercial License, so check your rights before you plan to patch it | Authentication, SSO and RBAC fixes, and the engineering time to keep pace with new findings |
| Wait for a community fork to mature | Possible, but no fork has an obligation to you, an SLA, or a disclosure process | Everything, for as long as you wait |
| Migrate to another platform | The right answer for most teams, and it takes a quarter or more for a real estate of chatflows | Whatever the instance can reach during the migration window |
| Isolate the instance and constrain what it can do | Achievable this week, and it is compatible with all of the above | Nothing, if the policy point sits outside the application |
Only the last row is something you can finish quickly, and it is the only one that helps no matter which of the others you eventually pick. That is the honest case for a control plane here, and it is a narrow one: we are not claiming to fix Flowise.
Why an archived AI builder is a different risk from ordinary unpatched software
Plenty of organizations run software past its end of life and manage the risk fine. An agent builder is harder, for three specific reasons rather than general anxiety.
First, it holds credentials by design. The whole point of a visual builder is that a non-engineer can connect the CRM, the database and the ticketing system without writing code, so the instance accumulates long-lived tokens for systems it was never security-reviewed against. The published advisory set includes an authentication bypass reaching the OAuth2 credential refresh endpoint: "Flowise through 3.1.4 contains an authentication bypass vulnerability that allows unauthenticated attackers to access the OAuth2 credential refresh endpoint by exploiting prefix-based whitelist matching in the authentication middleware." No login required, and 3.1.4 is what you are running.
Second, the code-execution surface is intentional. Chatflows can run generated code, which means the distance between a successful prompt injection and command execution is short. One advisory describes a prompt injection to a CSV agent node causing the model to emit a Python script that bypasses the blocklist validator and executes in an unsandboxed environment, letting an attacker "execute arbitrary code in the context of the user running the server". Another describes a sandbox escape in the JavaScript execution path that lets any authenticated user run system commands as root. These are not theoretical categories on this product, and agent sandboxing is the control they point at.
Third, the MCP surface is live. Flowise has had remote code execution issues in its custom MCP node path, and reporting on the stdio MCP transport notes that input-validation style fixes are straightforward to work around when the feature still permits user-controlled process execution. If you must keep the instance up, forcing the MCP transport to SSE rather than stdio removes the most direct version of that path. The wider problem is covered on MCP server security.
Put together: a networked application with stored credentials, deliberate code execution, an MCP path, no upstream maintainer, and a final release that several open advisories name as affected. The usual end-of-life playbook assumes you can at least apply a vendor patch for something critical. Here you cannot.
What to do if you cannot migrate off Flowise this quarter
Most teams reading this already know they should leave. The question is what to do about the eight to twenty weeks between deciding that and finishing it, while the instance keeps serving the business.
Start with the things that cost nothing and need no vendor. Take the instance off any network path that does not require it, and put it behind your existing SSO rather than its own login. Rotate every credential it holds, then re-issue each one scoped to the narrowest permission the specific chatflow needs, which is usually far less than what was pasted in originally. Turn off node types nobody is using, particularly the code-execution and custom MCP paths. If the MCP feature is in use, force the SSE transport. Then inventory the chatflows, because in our experience the list is longer than the owner expects and a third of them are abandoned experiments that can simply be deleted.
After that, the residual risk is the part you cannot fix inside the application: a compromised instance still holds whatever access you left it. That is where a control point outside the box does work that hardening cannot.
| Residual risk | Why hardening Flowise does not close it | What an external policy point does |
|---|---|---|
| Stolen credentials used against the CRM or database | The credential is valid. The application cannot distinguish a legitimate chatflow from an attacker holding its token | Per-agent tool and data permissions mean the token only works for the specific calls that chatflow is scoped to, from the policy point rather than from the app |
| An irreversible action triggered through a compromised flow | Nothing in the builder requires a person to confirm a delete, a refund or an outbound send | Human approval gates hold the action for a named approver before it executes |
| Prompt injection reaching a tool call | Validator-style checks inside the app are the layer the published advisories describe being bypassed | An injection firewall on the action path screens the call itself, not only the text |
| No trustworthy record of what happened | If the instance is compromised, logs kept inside it are evidence an attacker can reach | An immutable audit trail held outside the application survives the box it describes |
| The same problem on whatever you migrate to | Every destination has its own advisory history and its own defaults | One policy that follows the workload, so the migration does not restart your controls from zero |
Two honest limits. We do not patch Flowise, we cannot make an archived application supported, and anyone who tells you a security product makes end-of-life software safe to run indefinitely is selling you a story. And if your Flowise instance is a single internal chatbot with no credentials and no code execution, you do not need us for this. Turn it off or wall it off and get on with the migration.
On the destination: moving to another visual builder is not automatically a security upgrade. The main open-source alternatives have their own critical remote code execution history, including issues serious enough to draw wider advisory attention, so check the current advisory status and the maintenance health of whatever you shortlist rather than assuming the newer logo is safer. Teams with engineering capacity often do better moving the logic into a maintained framework directly, which is the ground covered on LangChain security and n8n security. Whatever you pick, decide where the tool permissions and the approval gates will live before you migrate the first chatflow, not after.
FAQ
Common questions about flowise security.
Is Flowise still maintained?
No. Flowise announced a code freeze on July 29, 2026, stating that active feature development ceases immediately and that new pull requests will no longer be reviewed or accepted. The repository was archived on GitHub on August 13, 2026, and the notice states that official core team presence in Discord and GitHub concluded on August 31, 2026. No successor product is named.
Is it safe to keep running self-hosted Flowise?
It depends entirely on what the instance can reach. A networked instance holding OAuth credentials and database connections, with code execution enabled, is carrying real risk, because advisories published after the code freeze name 3.1.4 as affected and list no patched version. An isolated instance with no credentials and no code-execution nodes is a much smaller problem. Inventory what it holds before deciding.
What is the last version of Flowise?
Version 3.1.4, published on July 29, 2026 alongside the code freeze. It is the final release, so several open advisories describing versions "through 3.1.4" have no upgrade path. Where a patched version would normally be listed, there is nothing, because there is no longer a maintainer team to publish one.
Can I just fork Flowise and maintain it myself?
Partly. The sunset notice says the Apache 2.0 licensed code is yours to keep building on. The license file carves out the packages/server/src/enterprise directory and files such as IdentityManager.ts under a Commercial License instead, and that is the authentication, SSO and access-control layer. Check your rights there specifically, because it is where the post-freeze advisories cluster.
Should I migrate off Flowise or secure it?
Both, in that order of intent and the reverse order of timing. Migration is the correct destination and it takes a quarter or more for a real estate of chatflows. Containment is achievable this week and protects you during the migration window. Buying a control plane as a permanent substitute for migrating is the wrong call, and we would rather say so than sell it.
What should I migrate Flowise to?
There is no vendor-endorsed destination, so justify the choice yourself. The other open-source visual builders have their own critical remote code execution history, so check current advisory status and maintenance health rather than assuming a newer product is safer. Teams with engineering capacity often move the logic into a maintained framework directly, which also makes the controls explicit in code.
Does AgentShield fix the Flowise vulnerabilities?
No, and nobody can. We do not patch Flowise and an archived application cannot be made supported. What an external policy point does is limit what a compromised instance can reach: scoped tool and data permissions, approval gates on irreversible actions, and an audit trail held outside the box so the evidence survives the thing it describes.
How do I reduce Flowise risk this week without a migration?
Remove unnecessary network exposure and put it behind your existing SSO. Rotate every stored credential and re-issue each scoped to the one chatflow that needs it. Disable unused node types, especially code execution and custom MCP. If MCP is required, force the SSE transport rather than stdio. Then delete abandoned chatflows, which usually cuts the inventory noticeably.
More use cases