Cut-paper collage illustration: a sealed cardboard archive box with packing tape, paper AI workflow nodes spilling out of the open top, and a cracked paper shield leaning against it

On August 13, the FlowiseAI/Flowise repository was archived on GitHub and set read-only. Over 55,000 stars, more than 3,600 commits, done. The README now points to a "Future of Flowise" discussion thread where a roadmap used to be.

Then in September, six security advisories were published against it. Two critical, four high. Every one of them affects all versions up to and including 3.1.4, the final release. None of them lists a patched version. There is no patched version, because there is no one left to ship one.

If you run Flowise anywhere — homelab, side project, or production — this post is about what to do. Underneath that is a durable lesson about a risk class most of us undercount: archived dependencies that keep running just fine while their security story quietly ends.

What the six advisories actually are

Two are critical, and both live in the Enterprise SSO code. The first (GHSA-cffm-583c-vffr) is cross-identity-provider account takeover: Flowise matches SSO users by email address alone, with no binding to the provider that issued the login. Anyone who can get a verified sign-in for your email at any configured provider — a self-registered Auth0 account, for example — gets your session. The second (GHSA-vf3j-89vf-r697) is arguably worse: a pending invitation can be claimed without the invite token, through the same email-matching path. Every pending invite is a foothold.

The four high-severity ones are all missing authorization checks across workspaces: stored credentials can be pulled cross-workspace (GHSA-27w2-26m5-x82c), chat history can be read and deleted by low-privileged API keys (GHSA-ppmg-4cx6-95hh), document-store upsert history leaks the same way (GHSA-jvx3-mjpw-r4gh), and in queue mode the BullMQ dashboard at /admin/queues exposes every tenant's job payloads to any signed-in user (GHSA-rpcc-gw54-mfgx).

The uncomfortable detail: fixes for at least two of these exist as commits on the archived main branch, merged August 7. They were never cut into a release. No npm package and no Docker image contains them. The code is right there, and you cannot get it through any supported channel.

"No fix available" is a different sentence than you think

Most of the time, "no fix yet" means "wait for the next release." Your scanner flags the finding, you schedule the patch window, life goes on. Here there is no next release. 3.1.4 is the final version on npm and the final image on Docker Hub, both from the July 29 code freeze.

Worse, your tooling probably will not even tell you. The advisories carry no CVE IDs, and OSV.dev had no record of them when checked on October 12 — which means npm audit, Dependabot, and OSV-Scanner will look at a Flowise 3.1.4 install and call it clean. The machinery that is supposed to catch exactly this class of problem has a blind spot shaped exactly like it. I would not assume that blind spot is unique to Flowise.

If you still run it: contain first, migrate second

I am not going to tell you to rip it out tonight. But treat it as compromised-adjacent and act like it:

  1. Pin 3.1.4. Older versions carry an August batch too, including LLM API key theft through a user-set base URL and code execution through the SQL Database Chain node. Pin flowiseai/flowise:3.1.4, not latest.
  2. Harden SSO or switch off the risky parts. Use one provider that strictly verifies email, restrict SSO to your domains, disable password login while SSO is on, and cancel stale invitations. These are the advisories' own mitigations.
  3. Assume workspace isolation is decorative. Every account and API key on an instance should be treated as able to see every workspace on that instance. One instance per team you actually trust.
  4. Block /admin/queues at the reverse proxy if you run queue mode. In nginx that is location ^~ /admin/queues { return 404; }. In Caddy: respond /admin/queues* 404.
  5. Keep port 3000 off the internet. Bind it to localhost and reach it over a VPN, an SSH tunnel, or an authenticating proxy. On Linux, Docker-published ports bypass ufw, so "it is behind the firewall" may not mean what you think.

Then plan the exit. Export chatflows, agentflows, tools, and variables as JSON. Back up the .flowise data folder — and note the secret key in there encrypts your stored credentials, so treat the backup accordingly. The maintained alternatives are Langflow, Dify, and n8n, each under its own license. None of them imports Flowise flows, so budget rebuild time, not migration time. Community forks have appeared; I have not reviewed any of them, and a fork means trusting new maintainers with code that holds your provider API keys. Check who runs it, and whether its fixes are public and reviewable, before you bet on one.

The durable lesson: archived is a risk class, not an event

Here is the part that outlives Flowise. Every homelab and every small shop has dependencies that were archived, abandoned, or quietly wound down while the software itself kept running perfectly. The binary does not know its project died. Your uptime monitor stays green. The risk does not announce itself — it just stops getting fixes, and one day the advisories land with no patched version attached.

I keep a standing checklist for this now. It runs against everything I self-host, a couple of times a year and whenever something smells off:

  1. Inventory what is actually running. Containers, npm and pip packages, system packages, the binary someone compiled in 2021 that nobody remembers. If you cannot list it, you cannot assess it.
  2. For each item, check upstream status. Is the repo archived? When was the last commit? The last release? A project with no commits in a year is not necessarily dead, but it goes on the watch list.
  3. Check the advisory feed per project. The repo's security advisories page, OSV.dev, the project's own changelog. Do this even for things your scanner covers. Scanners have blind spots, as demonstrated above.
  4. Classify by exposure. Internet-facing or internal-only? Does it hold secrets, credentials, or API keys? Is it multi-tenant, where one user's flaw becomes everyone's? Archived plus internet-facing plus holds secrets is the combination that should ruin your afternoon.
  5. Decide per item: migrate, isolate, or accept. Migration is the real fix. Isolation (network controls, proxy rules, disabled features) buys time. "Accept" is allowed, but write down what you are accepting and revisit it. Undocumented acceptance is just neglect with extra steps.
  6. Re-check on a schedule. Archive status can change overnight, as Flowise proved. Put it on the calendar next to the cert renewals.

None of this is exotic. It is the boring reliability playbook applied to the supply chain instead of the servers. The exciting alternative is finding out from an advisory with no patched version.

The quiet part

Flowise had over 55,000 stars. For two years it was the default answer to "I want a visual AI agent builder I can self-host." It still ended with a sunset notice, an archived repo, and six advisories that will never be fixed. Popularity is not maintenance. Stars are not a security policy.

The next one is already in your stack. Go find it before its advisories find you.

Sources