On 4 August, CISA added three flaws to its exploited-vulnerabilities catalogue, with a remediation deadline of the 7th. One of them is a 9.8 in Langflow, one of those tools somebody spins up in an afternoon to "try some AI stuff". There is nothing subtle about the flaw: one endpoint hands superuser tokens to anyone who reaches the port, and another runs whatever code you send it. Chained together, they give up the whole machine. And the patch had been out for six weeks.
The interesting part is not the flaw. It is that this year alone near-identical advisories have landed on three different products from the same family — the ones that make up a company's AI and automation layer — and they all come down to the same misunderstanding: this software was designed for your laptop and ended up on a server with the company's credentials inside it.
What the Langflow flaw actually does
CVE-2026-9198, published by IBM's PSIRT and catalogued by CISA as "IBM Langflow". It affects Langflow OSS from 1.0.0 to 1.10.0. The NVD description is one you read twice: an unauthenticated attacker chains /api/v1/auto_login — which "mints SUPERUSER tokens to any network caller" — with /api/v1/validate/code — which executes user code via exec() — and achieves full remote code execution on default Langflow deployments.
The name of that first endpoint tells the whole story. Auto login is a convenience: you start the tool on your own machine and you do not have to type a username and password to poke around. As a local convenience, fair enough. What is not fair enough is that convenience surviving when the same container is brought up on a server with an open port — which is exactly what happens when "I will just try it for a bit" turns permanent. That reading is ours; the hard fact is NVD's, and it is enough on its own.
- →23 June 2026: Langflow 1.10.1 ships — the first release without the flaw.
- →17 July: the CVE lands in NVD with a 9.8.
- →4 August: CISA adds it to KEV — which means confirmed exploitation, not theoretical — with a 7 August deadline for federal agencies.
Six weeks between the patch and the KEV listing — and on the NVD record itself, CISA had already flagged exploitation as active since 17 July, eighteen days earlier. That gap is the one that matters: the vendor does not close it, you do. And the 7 August deadline is only legally binding on US federal agencies, but for everyone else it works as a thermometer: once something enters KEV, we are no longer talking about risk, we are talking about people inside.
The same assumption, three times over
If this were one product having a bad run, it would be an anecdote. Look at the other two:
- ✓Open WebUI, CVE-2026-45672 (8.8). Prior to 0.8.12, the
/api/v1/utils/code/executeendpoint executed arbitrary Python through Jupyter for any verified user even when the admin had setENABLE_CODE_EXECUTION=false. The advisory puts it in a sentence worth framing: the configuration says "disabled" and code still executes. - ✓n8n, CVE-2026-25049 (9.9 per NVD). Prior to 1.123.17 and 2.5.2, an authenticated user allowed to create or modify workflows could abuse crafted expressions in workflow parameters to trigger system command execution on the host running n8n.
- ✓n8n, CVE-2026-21858 (10.0). From 1.65.0 to 1.120.x, certain form-based workflows let a remote, unauthenticated attacker read files from the server. Fixed in 1.121.0. And for variety, CVE-2026-59208: with more than one trusted issuer configured, n8n resolved identities using only the token's
suband ignoringiss, so a valid token from one issuer got you in as somebody else's user.
Three products, five advisories, one pattern: the threat model they were designed against is not the one where they end up. They are built for one person, on one machine, on a trusted network, and they land on a multi-user server reachable by half the company — and sometimes half the internet — because that is how the team gets to it from home.
Rule one: a configuration flag is not a control
The Open WebUI case is the cleanest of the five, which is why we use it to explain this. The switch existed. The admin set it to false. And the endpoint did not ask. If that installation came with a compliance document saying "code execution is disabled", that document was false from day one and nobody could have known by looking at the interface.
Hence the rule we apply: a control is something you can verify from outside the thing being controlled. If your only guarantee that code is not executed is that the application promises not to execute it, you do not have a control: you have a preference. Underneath every in-app switch there has to be one that does not depend on the app behaving — a network rule, an authenticating proxy, a closed egress path, a system user with no privileges. That, and not a slide, is what Zero Trust means when applied to something concrete.
Rule two: whoever can edit a workflow is an administrator
An automation platform stores credentials for everything it connects to: that is its job. The CRM API key, the mail OAuth token, the database password, the AI provider key. All in one place, on one machine, because otherwise it cannot automate anything.
Now put that next to CVE-2026-25049: whoever could edit a workflow could run commands on the host. On the org chart, "workflow editor" sounds like a minor role you hand to the marketing person who builds the newsletter send. On the machine, that role and the administrator role are the same thing. The permission to edit automations has to be treated like the permission to administer the server: same people, same second factor, same review. And if you have departments that do not trust each other, that is not a roles problem, it is a separate-instances problem.
Yes, we run one of these too
Writing this without saying so would be cheating: we use n8n for internal automation. This very post gets pushed to LinkedIn by one of its workflows. So we are not going to tell you not to run it, because we do run it, and because for a company that does not want its data going through a third-party service, self-hosting is still the right answer.
What we do say is something else: the day you bring it up, it stops being an experiment. It goes into the inventory with a name and an owner, it gets a patching window like any other service, and it does not hang off the internet "in the meantime". The line between a pilot and production is not size: it is whether anybody finds out when it breaks. A container that has been running for eight months with nobody knowing what version it is on is already production, whatever it is called in the meeting.
When not to self-host it
Three situations where we prefer the vendor's hosted service even when it costs money — and we say so knowing that in all three we lose billable hours:
- →If it will not have an owner. A container with nobody behind it is worse than an expensive subscription: the subscription updates itself and the container stays on the version it was installed with. If nobody commits to looking at it once a month, do not install it.
- →If the plan is to publish it on the internet so the team can get in from home. That sentence is what turns an "authenticated users only" flaw into a flaw for anyone. Remote access is solved with a VPN or an authenticating proxy in front, not by opening the port.
- →If the reason was privacy but there will be no backups or logs. You self-hosted so your data would not leave, and now you have your ERP keys on a machine with no backup and no logs. That is not privacy; it is the same problem with fewer people watching it.
This week's sweep
What we are doing these days on the infrastructures we touch, in case the script is useful:
- 1.Find it. Internal scan of the default ports — 7860 for Langflow, 5678 for n8n, 8080 for Open WebUI, often published as 3000 — plus the awkward question for the team: is there a VPS paid for with someone's personal card? There usually is.
- 2.Minimum versions. Langflow 1.10.1 or later (the current branch is on 1.11.2, from 4 August), Open WebUI 0.8.12 or later, n8n 1.123.17 / 2.5.2 or later and, if you use token exchange with several issuers, 2.27.4 / 2.28.1 or later.
- 3.Get it off the internet. If it is published, put it behind a VPN or an identity-aware proxy. And review what it can reach outbound: a platform that executes code with unrestricted egress is a command console waiting to be found.
- 4.Scoped credentials. No all-powerful service account "so it does not cause trouble". Least privilege per integration and, above all, keys you can rotate without rebuilding the workflows. If rotating one key means touching thirty automations, you are never going to rotate it.
- 5.An owner and a window. A name in the inventory and one date a month to patch. It is the dullest item on the list and the only one that stops this conversation repeating in six weeks with a different CVE.
None of this is specific to AI. It is the same work we described yesterday when writing about the console an IT provider uses to manage your machines — which, incidentally, showed up again in the same 4 August KEV batch with its original flaw — and the other side of the AI inventory the AI Act asks for: the regulation makes you know what AI runs in your company for transparency reasons; KEV makes you know it for rather more urgent ones.
What CISA said on the 4th
It is worth being precise about what a KEV entry means, because it gets muddled. CISA did not say "this software is insecure". It said "someone is using it to get in". Those are very different sentences and only the second one has a date attached. Langflow, n8n and Open WebUI are serious projects that publish their flaws, fix them and document the fixed versions; the five advisories in this post exist precisely because somebody did their job properly. The hole is not in the software: it is in the weeks between a patch shipping and somebody applying it on the machine nobody remembers setting up.
If your company has one of these platforms — and far more do than show up in the inventory — today's check is not a project: open the interface, look at the version, and see whether anyone outside the office can reach it. Ten minutes. It is exactly where we start when we build AI automation for a client: before automating anything, know what is running and who can touch it. If you would rather we looked at it, drop us a line: the first conversation is usually short and ends in a short list.
Sources (verified): CVE-2026-9198 (Langflow OSS 1.0.0–1.10.0, CVSS 9.8 assigned by IBM PSIRT, published 17 July 2026, auto_login + validate/code chain) — NVD; added to the Known Exploited Vulnerabilities catalogue on 4 August 2026 with a 7 August deadline, alongside CVE-2026-34486 (Apache Tomcat) and CVE-2026-18556 (N-able N-central) — CISA KEV; the CISA Coordinator SSVC assessment included in the NVD record itself, dated 17 July 2026 with exploitation: active; release dates for Langflow 1.10.1 (23 June 2026) and 1.11.2 (4 August 2026) — project releases; CVE-2026-45672 (Open WebUI prior to 0.8.12, CVSS 8.8 assigned by the CNA (GitHub), the endpoint executes code even with ENABLE_CODE_EXECUTION=false) — NVD; CVE-2026-25049 (n8n prior to 1.123.17 and 2.5.2, CVSS 9.9 per NVD) — NVD; CVE-2026-21858 (n8n 1.65.0–1.120.x, CVSS 10.0 assigned by the CNA (GitHub), fixed in 1.121.0) — NVD; CVE-2026-59208 (token exchange with multiple issuers, fixed in 2.27.4 and 2.28.1) — NVD; default ports — Langflow documentation plus n8n and Open WebUI documentation. The readings and operational recommendations are ours.
Do you know what version your automation platform is on?
At everyWAN we build automation and AI the way you build production: with an inventory, an owner, auditable permissions and a patching window. No smoke, and no ports left open "in the meantime".
Talk to everyWAN
Microsoft 365
ES 
CAT 
EN