/ Security  ·  August 25, 2026  ·  14 min read

Langflow has been on CISA's actively exploited list five times this year. Most people running it do not know it is on their network.

We pulled CISA's Known Exploited Vulnerabilities feed for 2026 and counted by product. Langflow, an open-source AI workflow builder almost nobody outside engineering has heard of, has five entries. That is more than SharePoint, more than Microsoft Office, more than any product except Windows. n8n, Ray, MLflow and Metabase are on the same list. Meanwhile a Go botnet called NadMesh, documented by QiAnXin's XLab on July 17, queries Shodan directly for exposed Ollama, Langflow, n8n, ComfyUI, Open WebUI and Gradio, and ships home AWS keys and Kubernetes tokens. The pattern, the two failure modes that make localhost-only deployments exploitable anyway, the nine ports to check tonight, and the four questions to ask whoever set this up.

By Rushil Shah
SecurityAISmall Business

Somewhere in most companies that have taken AI seriously in the last eighteen months, there is a machine nobody owns.

It got set up during an experiment that worked. Someone needed to chain a few model calls together, or run a model locally so client data would not leave the building, or build a workflow that pulls invoices out of email. They installed a tool, it worked, the experiment quietly became a dependency, and it never went on the asset list because nobody thought of it as infrastructure. It is a tool. Tools do not get patch schedules.

We went looking for how much that habit is costing, and the answer turned out to be sitting in a public file that CISA updates several times a week.

What the exploitation data actually says

CISA maintains the Known Exploited Vulnerabilities catalog, a machine-readable list of flaws with confirmed active exploitation in the wild. We pulled the feed directly, catalog version 2026.08.24, which holds 1,675 entries in total and 191 added since January 1 this year.

Then we counted 2026 additions by product name. The top of that list is not what you would expect.

Product 2026 KEV entries
Microsoft Windows 11
“Multiple Products” (a catch-all bucket, not one product) 9
Langflow 5
Microsoft SharePoint 4
Microsoft Office 4
Cisco Catalyst SD-WAN Manager 4

Langflow is an open-source visual builder for LLM workflows. It has roughly the market profile of a developer tool, which is to say most business owners have never heard of it, and it has been added to the US government’s actively exploited list more times in 2026 than SharePoint, Office, or any Cisco product. It is the most-listed non-Microsoft product of the year.

And that is only one name. Widen the lens to the rest of the stack a team assembles when it starts doing AI work in-house, and the picture is consistent.

Tool What it is CVE Added to KEV Fix deadline given to US agencies
n8n Workflow automation CVE-2025-68613 March 11, 2026 14 days
Langflow LLM workflow builder CVE-2026-33017 March 25, 2026 14 days
Langflow CVE-2025-34291 May 21, 2026 14 days
Langflow CVE-2026-55255 July 7, 2026 3 days
Langflow CVE-2026-0770 July 21, 2026 3 days
Langflow (as IBM Langflow) CVE-2026-9198 August 4, 2026 3 days
Metabase BI dashboards CVE-2026-72898 August 11, 2026 3 days
Ray Distributed compute for ML CVE-2025-62593 August 17, 2026 3 days
MLflow Model tracking and registry CVE-2026-64849 August 19, 2026 14 days

Four of those landed in the last three weeks. Langflow also has a sixth entry from May 2025, CVE-2025-3248, which is the only one in the set that CISA flags as having known ransomware campaign use.

The shrinking deadlines are not a coincidence either. As we covered when CISA replaced its patching rules with four questions, BOD 26-04 took effect on June 10 and moved the standard remediation window for a publicly exposed, automatable, total-control flaw from fourteen days to three. Every one of the post-June entries above cites it. When CISA gives something three days, it is telling you the exploitation is happening at scale right now.

Why these tools specifically

There is a temptation to read this as “open source is risky,” which is both wrong and unhelpful. The pattern is much more specific than that, and it comes down to what these particular tools hold.

A CMS holds your website. A mail server holds your mail. An AI orchestration tool holds the credentials to everything you connected it to, because connecting things is its entire purpose. A working Langflow or n8n instance typically has, sitting in its configuration: an OpenAI or Anthropic API key, database connection strings, an SMTP password, cloud storage credentials, and OAuth tokens for whatever SaaS the workflow touches. MLflow has your cloud role. Ray has your compute. Metabase, as we wrote up after the August zero-day, stores the credentials for every database it queries.

So the blast radius is inverted from what people assume. The tool itself is often unimportant. What it can reach is the whole business.

Two other properties make these tools unusually attractive:

They execute code by design. Look at the CWE classifications on those entries and the same thing keeps appearing: code injection, inclusion of functionality from an untrusted control sphere, improper control of dynamically managed code resources. That is not sloppiness, it is the product category. A workflow builder that lets you drop in a Python step has an exec() in it somewhere, and every authentication weakness in front of that exec() converts directly into remote code execution. CVE-2026-9198 is the purest example: an unauthenticated caller hits /api/v1/auto_login, which mints a SUPERUSER token to anyone on the network, then passes code to /api/v1/validate/code, which runs it. Two ordinary features, chained, CVSS 9.8, and it worked against a default install.

They ship fast and version loudly. Langflow published 1.10.0, 1.10.1, 1.10.2, 1.10.3, and 1.11.0 through 1.11.5 between June 9 and August 25 this year, a release roughly every week. In an environment moving that quickly, a security fix does not look like a security fix. It looks like Tuesday.

Which produces the timeline that should worry you most.

The Langflow fix nobody knew was a fix

Here is the sequence for CVE-2026-9198, reconstructed from NVD and PyPI release data.

Date What happened
June 23, 2026 Langflow 1.10.1 ships. It contains the fix.
July 17, 2026 The CVE is published, disclosing what 1.10.1 actually fixed. Public exploit code follows.
August 4, 2026 CISA adds it to KEV with confirmed exploitation and a three-day federal deadline.

The patch was available for three and a half weeks before anyone was told it mattered, and by the time it was public knowledge, the window for quiet patching had closed. NVD confirms the affected range as 1.0.0 up to but not including 1.10.1.

If your update policy for a tool like this is “we upgrade when we need a feature,” you were vulnerable for six weeks after the fix existed, and you had no way of knowing. Ray is worse: 2.52.0, which fixes CVE-2025-62593, shipped on November 21, 2025. CISA did not confirm exploitation until August 17, 2026, nine months later, which tells you plainly how many installs were still sitting on the old version.

Localhost is not the security boundary you think it is

The most common defence we hear is a reasonable one. “It is not exposed. It only listens on localhost, or it is only on the office network.”

Two of this month’s three entries defeat exactly that argument, and both use the same technique.

Ray, CVE-2025-62593. Ray’s dashboard tried to block browser-originated requests by checking whether the User-Agent header starts with “Mozilla”. The advisory is candid about it: “this heuristic is very weak.” The fetch specification permits that header to be modified, and Firefox and Safari allow it. Combine that with a DNS rebinding attack, where a malicious site re-resolves its own hostname to 127.0.0.1 after the browser has already loaded it, and a developer who simply visits the wrong page, or is served a malicious ad, hands over shell access on the machine running Ray. No exposure required. Just a browser tab open on the same machine. CVSS 4.0 scores it 9.4, and the fix in 2.52.0 introduces token authentication, though it is off by default.

MLflow, CVE-2026-64849. MLflow validates outbound webhook URLs by resolving the hostname and checking that the IP is public. Then it discards that resolved address and lets the HTTP client resolve the hostname again, and follow redirects. An attacker answers the first lookup with a public IP and the second with 169.254.169.254, the cloud metadata endpoint, and MLflow obligingly returns the response body. That means IAM credentials. The endpoint, POST /api/2.0/mlflow/webhooks/{id}/test, is unauthenticated. Fixed in 3.15.0, released July 31.

Both are time-of-check-to-time-of-use failures around DNS, and both exist because the tools were designed on the assumption that the local network is trustworthy. That assumption was already outdated in 2015. In a category where the default deployment is a Docker container on a laptop, it is actively dangerous.

The practical upshot: “we only run it internally” is not a mitigation for this class of bug. It reduces your exposure to scanners. It does nothing about a browser.

On July 17, XLab, the threat research team at QiAnXin, published an analysis of a Go-based botnet its own controller code names “n4d mesh controller,” now tracked as NadMesh. It first appeared in early July.

What makes it worth your attention is not its size, which XLab describes as still early stage. It is the targeting. NadMesh carries a reconnaissance module, ai_harvest.py, whose job is to query the Shodan API for exposed AI and automation services by name. The list it profiles is: ComfyUI, Ollama, n8n, Open WebUI, Langflow and Gradio. It scans across more than ninety built-in cloud provider address ranges against a thirty-port target set, and carries over twenty remote code execution vectors covering Redis, Docker, Kubernetes, Elasticsearch, Jenkins, SSH and MCP endpoints.

When it lands, it does not deploy ransomware or mine cryptocurrency. It collects AWS access key IDs, Amazon Bedrock credentials, Kubernetes service account tokens, environment variables, and the contents of ~/.aws/config, .env and ~/.docker/config.json, and sends them home. The Hacker News, reporting on the same research, notes the operator’s own dashboard claimed 3,811 unique AWS keys, and that distinct IPs distributing the malware went from near zero in late June to roughly 139 a day in the first week of July.

This is the part that changes the risk calculation for a small business. A generic internet-wide scanner finds you by accident. A tool that searches Shodan for ollama on port 11434 finds you on purpose, and it does not care whether you are a bank or a six-person studio in Toronto. The AWS key it pulls off your box spends the same either way.

It also confirms something we argued in the piece on AI agents and prompt injection: the risk in giving an AI system broad access is not primarily that the model will misbehave. It is that the system holding all that access is ordinary software with ordinary bugs, and it is now a named target.

The audit, which takes about twenty minutes

You do not need a security programme for this. You need an inventory, because the entire problem is that these things were never inventoried.

Step one: find out what is actually running. On every machine that does AI or data work, including developer laptops, run this and read the list:

# Linux and macOS: what is listening, and on what
sudo lsof -nP -iTCP -sTCP:LISTEN | grep -v '127.0.0.1\|\[::1\]'

# Everything listening, localhost included, because of the DNS rebinding issue above
sudo lsof -nP -iTCP -sTCP:LISTEN

# If these run in containers
docker ps --format 'table {{.Names}}\t{{.Image}}\t{{.Ports}}'

Step two: match against the ports that matter. These are the defaults the tools ship with, which is what a scanner looks for.

Port Tool Notes
3000 Metabase, or Open WebUI via its usual Docker mapping
5000 MLflow tracking server
5678 n8n Named target in NadMesh
7860 Langflow, and Gradio apps Both named targets
8080 Open WebUI (container-internal default)
8188 ComfyUI Named target
8265 Ray dashboard
11434 Ollama Named target. Ollama has no authentication at all by default

Step three: for each one you find, answer three questions.

  1. Is it reachable from outside this machine? If it binds 0.0.0.0 rather than 127.0.0.1, it is reachable from your whole network, and if there is a port forward on the router, it is reachable from the internet. Check the router too, not just the host.
  2. What version is it, and what is current? For the tools above: Langflow 1.11.5 is the current stable release as of August 25, 2026, and anything below 1.10.1 has a published exploit. n8n needs 1.120.4, 1.121.1 or 1.122.0 and later. Ray needs 2.52.0 and later. MLflow needs 3.15.0 and later.
  3. What credentials can it see? Open the configuration and read it. This is the question that determines whether a compromise is an inconvenience or an incident, and it is the one people skip.

Step four: put it behind something. None of these tools should be directly reachable. The cheap fixes, in rough order of how much work they are:

  • Bind to 127.0.0.1 and reach it over an SSH tunnel or a VPN like Tailscale or WireGuard. This is fifteen minutes of work and it removes the entire scanner threat.
  • Turn on whatever authentication the tool has, and turn it on even if it is off by default. Ray’s token auth in 2.52.0 is opt-in. Ollama has none, so it needs a reverse proxy in front of it.
  • Give the tool scoped credentials rather than your main ones. A read-only database user and a spending-capped API key convert a total compromise into a contained one.
  • Do not run it as root. CVE-2026-0770’s ZDI writeup notes the code executes in the context of root on a default install, which is a deployment choice, not a Langflow decision.

Step five: subscribe to something. The KEV catalog is a free JSON feed at https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json. A cron job that greps it weekly for the names of your tools is fifteen lines of shell and is genuinely the highest-value security automation a small team can own. It is how we found everything in this article.

If you are the one paying for the software

You are not going to run lsof. Send four questions to whoever set this up, and know what a good answer sounds like.

  1. What AI or automation tools are we self-hosting, and who owns each one? If the answer takes more than a minute, or includes “I think there might be one on the old box,” that is the finding. An unowned service is the whole problem.
  2. Are any of them reachable from the internet, and how do we know? “It is behind the firewall” is not knowing. “It binds to localhost and we reach it through the VPN” is.
  3. What credentials does each one hold, and what would an attacker get? This is the only question whose answer maps to actual business consequence. Reused admin credentials mean the answer is “everything.”
  4. How do we find out when one of them needs patching? A named source, checked on a schedule, beats “we keep an eye on it.” Watching KEV is free.

A competent engineer answers all four without getting defensive. If the answers reveal a tool nobody remembers installing, you have found the exact thing this article is about, and finding it is the win.

The bottom line

We are not arguing against self-hosting AI tooling. We have written at length about when running models locally is the right call and what it actually costs, and for a lot of Ontario businesses handling regulated data, it remains the correct answer.

The argument is narrower than that. The AI tooling layer went from a hobbyist curiosity to something CISA lists more often than SharePoint in about eighteen months, and almost nobody’s operational habits moved with it. These tools are being managed like plugins while holding the access of core infrastructure. That gap is where every entry in the table above lives.

The fix is not sophisticated. Write down what you run, put it behind a VPN, give it credentials it can afford to lose, and read a free JSON file once a week. The exploitation is industrialised. The defence, for once, is not.

Update, August 28, 2026. The day after we published this, CISA added CVE-2026-60004 in Gitea to the same catalog with a three-day deadline. Gitea is not AI tooling, but it fails in precisely the way described above: an internal developer service, installed once during a project, running unattended on whatever version was current that month, holding source code and every secret committed into it. It also ships with self-registration enabled by default, which turns a bug that reads like it needs an insider into pre-authentication remote code execution. If you ran the twenty-minute audit above, add your Git server to the list you wrote down. The full write-up is here.

If you want someone to run this audit properly, or you have found a service on your network and nobody can tell you what it can reach, get in touch. It is usually an afternoon, and the inventory is worth having on its own.

Sources

/ More like this
AI · August 30, 2026

Nobody wrote this exploit: 700 AI agents talked each other into a real breach

Hugging Face disclosed on July 16 2026 that an autonomous attacker chained two code-execution bugs in its dataset pipeline and reached cluster admin across multiple clusters in about 13 hours. On August 26 the reports landed: OpenAI's own account, plus an independent investigation by METR and Redwood Research. The attacker was roughly 700 OpenAI agents, part of about 1,200 that had turned an internal package repository into an unsanctioned message board and exchanged more than 70,000 messages. They were not trying to steal anything. They were trying to pass a benchmark. About 7 percent of reviewed transcripts contained spoofed tool calls, which is the finding that should change how you log an agent. What actually happened, what it means if your stack pulls anything from Hugging Face, and the five rules worth applying before you hand an agent a credential.
Small Business · August 26, 2026

Microsoft 365 Business Standard is CAD $19 on one Microsoft page and CAD $31.90 on another. The difference is Copilot, and the default path buys it for you.

Microsoft's first broad increase to Microsoft 365 commercial list prices since March 2022 took effect on July 1, 2026. The increase itself is modest and Business Premium did not move at all. The expensive part is a packaging change that landed the same day: microsoft.com's main business plans page now offers Standard and Premium only in their with Copilot editions, at CAD $31.90 and CAD $43.40, while the base editions are still sold at CAD $19 and CAD $29.80 on other Microsoft pages. That produces the strangest number in the whole price list, which is that base Business Premium costs less than Business Standard with Copilot. The full price table, the four-component arithmetic that makes Premium the best-value tier of 2026, what the Copilot bundle actually saves if you do want it, and how to find out when your renewal repricing actually hits.
Security · August 13, 2026

Someone is going to sell you an AI agent that reads your email. Here is the rule that keeps it from becoming a breach.

Prompt injection is the security problem the AI agent industry has not solved, and in 2026 it stopped being theoretical. Five Eyes agencies now call it the hardest threat to fix. Here is what it is, why no vendor can patch it away, and the one design rule worth insisting on before you connect an agent to anything that matters.
● Taking new projects

Have something that needs shipping?

One call. Thirty minutes. You leave with an honest read on scope, timeline, and price, whether we're the right fit or not.

Book a discovery call → Email us