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.

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.

Someone has already automated the search

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 was the current stable release as of August 25, 2026, and anything below 1.10.1 has a published exploit. Since then a seventh Langflow flaw came under active attack, and the guidance moved to 1.11.6 or later. See the September 2 update at the end of this article. 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.

Update, September 2, 2026. A seventh Langflow flaw is now under active attack, and it is the same endpoint for the third time.

On the weekend of August 29, VulnCheck’s honeypots started recording exploitation of CVE-2026-0768, CVSS 9.8, CWE-94 code injection. Over 50 detections within hours, and more than 360 by Monday, from roughly twenty source IPs across more than half a dozen countries. Most of the traffic hit UK sensors and originated in Russia. Vulnerable hosts were concentrated in the United States, Germany, Malaysia, Brazil and India.

Three things about this one are worth your time.

It is the validate endpoint again. CVE-2025-3248, the entry we noted above as the only one CISA flags for ransomware use, was code injection in /api/v1/validate/code, fixed in Langflow 1.3.0. CVE-2026-9198, in the table above, reached the same endpoint by minting itself a superuser token first. CVE-2026-0768 is described by ZDI as a flaw in “the handling of the code parameter provided to the validate endpoint,” affecting releases up to 1.4.2. Same feature, third separate exploited vulnerability. This is the point made earlier in this article about a product category built around executing user-supplied code: the fix closes a bug, it does not close the category.

The disclosure timeline is the actual story. ZDI’s advisory, ZDI-26-034, credits Peter Girnus, William Gamazo Sanchez and Alfredo Oliveira of Trend Research, and publishes the dates: reported to the vendor on July 18, 2025, status chased in September and October, vendor notified of intent to publish in December, and released as a zero-day advisory on January 9, 2026 with the mitigation given as “restrict user access to the affected product until patching is available.” Exploitation began roughly thirteen months after the report and nearly eight months after the public advisory. VulnCheck’s Caitlin Condon notes there is still no known public proof-of-concept, meaning whoever is doing this built their own from the advisory.

The loot is your API keys, not your server. The observed commands go straight for LANGFLOW_SUPERUSER, OPENAI_API*, AWS_ACCESS* and AWS_SECRET* environment variables, read /root/.cache/langflow/secret_key, then check for SSH access and the size of the shell history. That is the inverted blast radius this article opened with, made concrete. Note also what stolen model API keys mean specifically: they are billed to you, and the first sign of theft is often the invoice.

What to do. Move to Langflow 1.11.6 or later. Then rotate, in this order: the Langflow secret key, every model API key the instance held, cloud credentials, and any SSH keys reachable from that host. Patching does not un-steal a key that left last weekend.

One configuration detail that explains why so many instances are trivially exploitable: Langflow’s application default for LANGFLOW_AUTO_LOGIN is True, which signs every visitor in as the configured superuser. The official Docker images override it to false, so how you deployed decides what you got. Langflow’s own documentation is unambiguous about the rest: “Never expose Langflow ports directly to the internet without proper security measures. Set LANGFLOW_AUTO_LOGIN=False, use a non-default LANGFLOW_SECRET_KEY, and deploy your Langflow server behind a reverse proxy with authentication enabled.”

For scale, Censys published early findings from its 2026 State of the Internet Report on July 23: exposures of AI and LLM tooling are up more than 60 percent over nine months, from roughly 183,000 distinct public IP addresses in October 2025 to more than 294,000. Langflow specifically grew 169 percent over that period, to about 7,000 publicly exposed instances, a majority of them in North America, and accumulated 18 CVEs between 2024 and 2026, 14 of them scoring above 8.0. The exposure is growing faster than the patching.

Update, September 3, 2026. CISA added seven more entries yesterday. Three of them are the AI stack, and one is the web framework underneath it.

The September 2 batch is the clearest confirmation yet of the argument this article makes, so it is worth listing the relevant part in full.

CVE	Product	CVSS	KEV deadline
CVE-2026-49869	Kestra OSS, workflow orchestration	10.0	September 5
CVE-2026-59822	Berri LiteLLM, AI gateway	8.8	September 16
CVE-2026-48710	Kludex Starlette, Python ASGI framework	medium	September 16

Kestra, CVSS 10.0, and the bug is one method call. Kestra’s AuthenticationFilter whitelisted the public configuration endpoint from Basic Auth using request.getPath().endsWith("/configs"). A suffix match, not an exact path match. Any API path whose final segment is configs therefore skipped authentication entirely, and because Kestra ships with script execution plugins enabled by default, an unauthenticated caller could create and run an arbitrary workflow. The result is remote code execution as root inside the Kestra worker container. Affected versions are below 1.0.45, and from 1.1.0 up to 1.3.21. Fixed in 1.0.45 and 1.3.21. Microsoft reports exploitation from late June 2026, with the observed activity being a reverse shell, Docker container environment discovery, defence evasion, a cryptocurrency miner and data harvesting. That is the same monetisation pattern as the Langflow campaign above.

LiteLLM, and the fallback that authenticated nobody. CVE-2026-59822 sits in LiteLLM’s MCP Streamable HTTP endpoint. A fabricated Authorization header triggered an OAuth2 passthrough fallback path that, when LiteLLM key validation failed, substituted an empty UserAPIKeyAuth() object rather than rejecting the request. Requests then reached MCP tooling with no valid LiteLLM key at all. Fixed in 1.84.0. Exploitation was observed in honeypots.

Starlette is the one to pay attention to. CVE-2026-48710 is missing Host header validation in Starlette, the ASGI framework that LiteLLM and a great many Python AI services are built on. The routing algorithm uses the raw HTTP path while request.url is rebuilt from the Host header, so a malformed header makes request.url.path differ from the path actually requested, and any middleware enforcing security by inspecting request.url can be walked straight past. Fixed in Starlette 1.0.1. Chained with CVE-2026-42271, a separate LiteLLM flaw where MCP test endpoints spawn user-supplied subprocess configurations with no allowlist and no admin gate, the authentication requirement disappears and the combined chain is rated CVSS 10.0 for unauthenticated remote code execution. CVE-2026-42271 affects LiteLLM 1.74.2 through 1.83.6. Threat intelligence reporting associates exploitation of this chain with Qilin ransomware activity, and we have corrected the attribution below.

Three points to take from this batch.

The dependency is now the attack surface. Every previous entry in this article was a flaw in an AI tool. Starlette is a flaw in the framework a lot of AI tools happen to sit on, and it converts an authenticated-only bug in LiteLLM into an unauthenticated one. If your inventory lists products, it will not catch this. Whatever you run, the question is what it is built on and whether that is current.

Ransomware may have arrived at this category. Up to now the observed payloads on this list were miners and credential theft. A Qilin association on this chain would be a different tier of consequence, and Qilin claimed 1,403 victims between July 2025 and June 2026. Read the sourcing carefully, though, and see the correction below: this association comes from threat intelligence reporting, not from CISA.

Add two names to the audit list. If the twenty-minute audit earlier in this article produced an inventory, add Kestra and LiteLLM to it, along with the port each answers on. LiteLLM in particular tends to be installed as plumbing rather than as a product, which means it is exactly the kind of service nobody remembers is running.

Update, September 5, 2026. The Kestra deadline is today, and re-counting the feed changes one line of this article.

We re-pulled the catalog this morning. Version 2026.09.04, 1,695 entries in total, 211 added since January 1, against 1,675 and 191 when this article was first published on August 25. Twenty new entries in eleven days.

Three things in the refreshed count.

The Kestra remediation deadline lands today. CVE-2026-49869 was added on September 2 with a September 5 deadline for US federal agencies. If you run Kestra and have not moved to 1.0.45 or 1.3.21, the government’s own three-day clock on this one has now run out. That deadline length is not arbitrary: it is what BOD 26-04 assigns to a flaw that is both automatable and total in impact.

LiteLLM is not a one-off. The September 2 entry was its third appearance in the 2026 catalog, after CVE-2026-42208 on May 8 and CVE-2026-42271 on June 8. We named it last time as a tool that gets installed as plumbing rather than as a product. Three KEV listings in four months is what that looks like from the outside, and it moves LiteLLM from “add it to the inventory” to “put it on the same patch cadence as anything else facing the network.”

One correction to the top of this article. When we first counted, Langflow’s five entries made it the most-listed non-Microsoft product of 2026 outright. That is no longer strictly true. Linux Kernel reached five entries as well, with CVE-2022-0995 on August 26 and CVE-2026-53362 on August 27, so the honest statement today is that Langflow is tied for the most-listed non-Microsoft product rather than clear of the field. SonicWall’s SMA1000 appliances moved to four with the September 2 pair. The argument this article makes does not depend on the tie-break, and the shape of the list has not changed: an LLM workflow builder that most business owners have never heard of is still level with the Linux kernel and ahead of SharePoint, Office and every Cisco product.

Update, September 8, 2026. One correction, and the number that reframes the LiteLLM entries.

Correction on the Qilin attribution. We wrote on September 3 that “CISA’s listing associates the Starlette entry with Qilin ransomware activity.” That was wrong, and we have fixed the sentence above. We re-pulled the KEV JSON feed this morning and checked the field directly: knownRansomwareCampaignUse reads Unknown for CVE-2026-48710, for CVE-2026-59822, and for both earlier LiteLLM entries. The only entry in this entire article that CISA itself flags for ransomware use is CVE-2025-3248, the Langflow flaw added in May 2025. The Qilin association is real reporting, from The Hacker News and other threat intelligence coverage of this campaign, but it is reporting rather than a CISA determination, and we should have said so. The practical difference matters: CISA’s ransomware field is a deliberately conservative signal, and if you prioritise by it, this chain does not currently carry that flag.

The patch was always there. We went back and checked PyPI upload timestamps against the KEV dates for all three LiteLLM entries. The fix for CVE-2026-42208 and CVE-2026-42271 shipped in 1.83.7 on April 13, 2026, and the fix for CVE-2026-59822 shipped in 1.84.0 on May 14, 2026. CISA confirmed active exploitation 25 days, 56 days and 111 days later respectively. Note also that several widely cited write-ups date the 1.83.7 release to May 8, 2026, which is the date CISA added CVE-2026-42208 to KEV, not the date the fix shipped.

That changes what this article is arguing. None of these three were zero-days from an operator’s point of view. In every case a patched release was on the shelf, downloadable, for weeks or months before anyone was reported to be attacking the unpatched one. The current LiteLLM release is 1.100.0, published September 6, which means a still-vulnerable deployment is sixteen minor versions behind on the single component that holds every model API key the business owns. We have written up that decision, along with the hosted alternative and what it costs, in the AI gateway piece.

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

• CISA Known Exploited Vulnerabilities catalog, JSON feed, catalog version 2026.08.24, retrieved August 25, 2026. The product counts, entry dates and remediation windows above are our own analysis of that file.
• BOD 26-04: Prioritizing Security Updates Based on Risk, CISA, June 10, 2026, cited in the required-action text of every post-June entry above
• CVE-2026-9198, NVD, for the auto_login and validate/code chain, the CVSS 9.8 score, the July 17 publication date and the affected range of 1.0.0 up to 1.10.1
• CVE-2025-62593 advisory, GHSA-q279-jhrf-cc6v, Ray project, for the User-Agent heuristic, the DNS rebinding chain, the Firefox and Safari specifics and the 2.52.0 fix
• CVE-2026-64849, NVD, for the unauthenticated webhook test endpoint, the redirect and re-resolution behaviour and the 3.15.0 fix
• CVE-2025-68613, NVD, for the n8n expression evaluation RCE and the 1.120.4, 1.121.1 and 1.122.0 fixed versions
• CVE-2026-0770, NVD and ZDI-CAN-27325, for the exec_globals flaw and the root execution context
• NadMesh Botnet Analysis: A Product-Grade Threat for the AI Service Era, XLab at QiAnXin, July 17, 2026, for ai_harvest.py, the targeted service list, the port and cloud-range scanning scope and the harvested credential types
• New NadMesh Botnet Hunts Exposed AI Services for Cloud Keys and Kubernetes Tokens, The Hacker News, July 2026, for the operator dashboard figures and the distribution-IP trend
• Release dates and current versions verified against the PyPI JSON API for langflow, mlflow and ray, retrieved August 25, 2026

Added for the September 2 update:

• ZDI-26-034: Langflow code Code Injection Remote Code Execution Vulnerability, Zero Day Initiative, for the CVE-2026-0768 description, the CVSS 9.8 vector, the credited Trend Research authors and the full July 2025 to January 2026 disclosure timeline
• Critical Langflow flaw exploited to steal OpenAI and AWS keys, BleepingComputer, September 1, 2026, for the VulnCheck canary detection counts, the targeted environment variables and secret key path, and the traffic origin
• Hackers Start Exploiting Critical Langflow Vulnerability, SecurityWeek, for the affected version range, the escalation from 50 to over 360 detections, and the Caitlin Condon comment that no public proof-of-concept is known
• Attackers Exploit Critical Langflow and Rails Flaws in Credential Harvesting Campaigns, The Hacker News, September 2026, for the roughly twenty source IPs across more than six countries and the geographic distribution of vulnerable hosts
• Same Target, Different Playbooks: Two Attackers, Two Different Paths to Pwning the AI Stack, VulnCheck, for the count of 12 Langflow CVEs targeted and the 15,000-plus successful exploitation attempts across CVE-2026-0769, CVE-2025-3248 and CVE-2026-5027
• GHSA-rvqx-wpfh-mfx7, GitHub Advisory Database, for CVE-2025-3248 being code injection in /api/v1/validate/code fixed in Langflow 1.3.0, which establishes that this is the third exploited flaw in the same endpoint

Added for the September 3 update:

• CISA Adds Seven Known Exploited Vulnerabilities to Catalog, CISA, September 2, 2026, for the seven entries in the batch
• CISA Adds Seven Exploited Flaws as Attackers Deploy Reverse Shells and Mint Admin Tokens, The Hacker News, September 2026, for the CVSS scores, the per-entry KEV remediation deadlines of September 5 and September 16, the Microsoft attribution of the Kestra exploitation to late June 2026 and the observed reverse shell, container discovery, miner and data harvesting activity, the honeypot observation on the LiteLLM entry, and the Qilin ransomware association on the Starlette entry
• CVE-2026-49869, NVD, for the AuthenticationFilter suffix-match flaw on /configs, the default-enabled script execution plugins, the root execution context inside the worker container, the affected ranges below 1.0.45 and 1.1.0 up to 1.3.21, and the 1.0.45 and 1.3.21 fixes
• CVE-2026-59822, NVD, for the MCP Streamable HTTP endpoint, the OAuth2 passthrough fallback substituting an empty UserAPIKeyAuth() object on failed key validation, and the 1.84.0 fix
• HTTP Request Smuggling in starlette, Snyk, for the Host header reconstruction mismatch between routing path and request.url.path, the middleware bypass consequence, and the Starlette 1.0.1 fix
• CVE-2026-42271 chained with CVE-2026-48710, Horizon3.ai, for the chain producing unauthenticated remote code execution, the CVSS 10.0 rating of the combined chain, the MCP test endpoint subprocess flaw with no allowlist or admin gate, and the affected LiteLLM range of 1.74.2 to 1.83.6
• Qilin (cybercrime group) and Qilin ransomware group profile, SOCRadar, for the 1,403 victims claimed between July 2025 and June 2026
• API keys and authentication, Langflow documentation, for the LANGFLOW_AUTO_LOGIN default of True, the Docker image override, and the quoted warning about exposing Langflow ports to the internet
• Censys Finds AI/LLM Tool Exposures Up More Than 60%, reporting on early findings from the Censys 2026 State of the Internet Report published July 23, 2026, for the growth from roughly 183,000 to over 294,000 exposed IP addresses, Langflow’s 169 percent growth and roughly 7,000 exposed instances, and the 18 CVEs of which 14 score above 8.0
• Known Exploited Vulnerabilities Catalog JSON feed, CISA, re-downloaded September 8, 2026, and read field by field for the September 8 correction: knownRansomwareCampaignUse is Unknown on CVE-2026-48710, CVE-2026-59822, CVE-2026-42271 and CVE-2026-42208, and Known only on CVE-2025-3248 among the entries discussed here
• litellm release history, PyPI JSON API, queried September 8, 2026, for the upload timestamps of 1.83.7 (April 13, 2026), 1.84.0 (May 14, 2026) and the current 1.100.0 (September 6, 2026), which are the basis for the 25, 56 and 111 day figures in the September 8 update