At A Glance
- 1,248 new network-exploitable CVEs were published between September 11 and 17 — 117 of them serious enough to clear our internal severity floor.
- Twelve vulnerabilities landed the maximum possible CVSS score of 10.0 this week. Nine of them hit a single piece of software: vm2, a Node.js sandbox used to run untrusted code.
- IBM’s Langflow, an open-source platform for building AI agent workflows, picked up eight separate CVEs in one week — including one that needs no password at all.
- Cisco and Oracle each dropped their own clusters of maximum-severity bugs this week, the kind that come out of “comprehensive internal security reviews” rather than a researcher’s bug bounty report.
- The worst vulnerability of the week isn’t dangerous because a patch is late. It’s dangerous because the endpoint that runs it was never supposed to be reachable from the open network in the first place.
Every week we say some version of the same thing: a CVE is a disclosed flaw, a KEV is a flaw someone is actively using against real targets, and the gap between the two is measured in the time it takes an attacker to notice what’s reachable. Most weeks that’s an abstraction. This week it’s IBM Langflow.
Langflow is a fast-growing open-source tool for visually building AI agent workflows — the kind of platform that shows up in a proof-of-concept on a Tuesday and is quietly running production agents by the following quarter, often on a box that was never hardened for it. This week it collected eight CVEs. Not eight bugs across a year of disclosures — eight in a single seven-day window, spanning code injection, OS command injection, path traversal, an incomplete security-scanner denylist, and an unauthenticated remote code execution flaw sitting behind a “publicly shared” MCP endpoint. That last phrase is doing a lot of work, and we’ll get to why.
It wasn’t just Langflow. IBM’s own ContextForge MCP Gateway shipped with default administrative credentials — a 9.8 that requires nothing more clever than reading the documentation. And in a coincidence that says more about the maturity of the AI tooling stack than any single vendor’s engineering, vm2 — the sandbox a lot of code-execution and agent-tooling products lean on to contain untrusted code — accounted for nine of this week’s twelve perfect-10.0 CVEs, with sandbox escapes reachable from a default configuration. Three different products, three different vendors, one common thread: software built to run other people’s code, moving faster than the security review cycle around it.
This Week’s Vulnerabilities by the Numbers
Out of 1,248 new network-exploitable CVEs this week, here’s where we’d start if we were triaging a patch queue Monday morning:
- CVE-2026-85025 (9.8, Critical) — IBM Langflow OSS 1.0.0–1.11.5. Unauthenticated remote code execution through publicly shared MCP project endpoints, with the ability to read or modify chat sessions on top. No credentials, no user interaction — just a reachable endpoint. This is the one we dig into below.
- CVE-2026-78573 (9.8, Critical) — IBM ContextForge MCP Gateway 1.0.0–1.0.7. Ships with default credentials that grant full administrative access. If it’s exposed and nobody’s rotated the defaults, it’s already owned.
- CVE-2026-92937 (10.0, Critical) — vm2 3.11.6. An incomplete fix for a prior sandbox-escape advisory, letting sandboxed code reach and execute in the host Node.js process. Relevant to anything running an AI-generated or user-supplied code path through a vm2 sandbox.
- CVE-2026-20130 (10.0, Critical) — Cisco Identity Services Engine (ISE) and ISE-PIC. Disclosed via Cisco’s own internal security review — the kind of finding that tends to precede a very bad week for whoever’s running unpatched ISE at the network edge.
- CVE-2026-20242 (9.8, Critical) — Cisco Secure Firewall Management Center. Unauthenticated remote attacker gets arbitrary root command execution through the External Database Access feature — on a box whose entire job is managing your firewalls.
- CVE-2026-87230 (10.0, Critical) — Oracle Hyperion Financial Management 11.2.26.0.000. Unauthenticated, no privileges, no user interaction, full compromise — in a product that, by definition, holds financial data.
When “Publicly Shared” Means “Publicly Ownable”: The Langflow MCP Flaw
Here’s the mechanism worth sitting with. Langflow lets teams share flows — AI agent pipelines — through MCP (Model Context Protocol) project endpoints, so other tools and agents can call into them programmatically. CVE-2026-85025 exists because the code enforcing “this flow is meant to be public but everything else isn’t” doesn’t actually enforce that boundary correctly. An unauthenticated attacker who can reach the endpoint gets arbitrary code execution on the server hosting it, plus read and write access to chat sessions running through it — meaning any context, credentials, or proprietary data those sessions touched.
There’s no privilege escalation chain required, no social engineering, no waiting for a user to click something. The only precondition CVSS lists is AV:N — attack vector: network. If your Langflow instance can be reached, this vulnerability can be exploited. Full stop.
That’s what makes this year’s crop of AI infrastructure CVEs different in kind from a typical WordPress plugin disclosure. Langflow and IBM’s MCP Gateway aren’t peripheral tools — they’re increasingly the substrate agentic AI runs on, deployed by teams who are moving at the speed the AI roadmap demands and treating network exposure as an afterthought. Eight CVEs against one platform in a week isn’t a fluke; it’s what happens when a category matures in public. We’d bet money this specific flaw, or one like it in the same MCP-endpoint pattern, ends up in CISA’s KEV catalog before the patch cycle catches up — it has every characteristic actively-exploited vulnerabilities share: no auth required, trivially scannable, and sitting on infrastructure most security teams don’t even have inventoried yet.
How NetFoundry Vulnerability Cloaking Prevents This
Patching Langflow matters and we’re not telling anyone to skip it. But CVE-2026-85025 only works because the vulnerable endpoint is reachable on the network at all — and that’s the part patching doesn’t fix on day zero, day thirty, or however long your change window takes.
NetFoundry’s approach is to make the endpoint unreachable until a connection has already been authenticated and authorized — not filtered, not hidden behind a firewall rule that a misconfiguration or a new deployment can quietly punch a hole through, but genuinely absent from the network’s attack surface. There’s no IP address for an unauthenticated scanner to find, no port for it to hit, because the workload never advertises one to begin with. Only identities that are explicitly permitted can even establish a session, and every one of those sessions is tied to a verified identity — so instead of a firewall log full of source IPs, you get an audit trail that says who, not just where from.
For AI workloads specifically — Langflow instances, MCP servers, agent runtimes — that means a flaw like this one stops being a race against the patch calendar. The vulnerable code is still there until you patch it, but the unauthenticated attacker who’d otherwise trigger it never gets a path to reach it. That’s the difference between accepting the risk on your books and compensating for it while the fix works its way through your pipeline.
Don’t Be the Next Reachability Watch Headline
Eight CVEs in one platform, twelve perfect 10.0s across two unrelated vendors, and 1,248 new disclosures in a single week — the volume alone should tell you that patch-and-pray isn’t a strategy, it’s a queue you’ll never clear. The teams that get burned aren’t usually the ones who patched slowly. They’re the ones who didn’t know a given service was reachable from the internet at all until it showed up in an incident report.
If you’re running Langflow, an MCP gateway, or anything built on a code-sandbox like vm2, start there this week: confirm what’s actually exposed, not what you assume is exposed. Then ask whether “exposed” needs to be the default state for that workload in the first place. For most AI infrastructure, it doesn’t.
See how NetFoundry Vulnerability Cloaking makes unpatched systems unreachable before a CVE ever becomes a KEV. See How It Works →
Reachability Watch is published weekly by NetFoundry.
Frequently Asked Questions
What’s the difference between a CVE and a KEV?
A CVE (Common Vulnerabilities and Exposures) is any publicly disclosed security flaw, regardless of whether anyone has used it in an actual attack. A KEV (Known Exploited Vulnerability) is a CVE that CISA has confirmed is being actively exploited in the wild. Every KEV starts as a CVE; only a small fraction of CVEs ever become KEVs — but the ones that do tend to share traits like this week’s Langflow flaw: unauthenticated, network-reachable, and easy to scan for at scale.
Why are AI agent platforms and MCP servers becoming a bigger target?
They’re new, fast-moving, and increasingly production-critical — a combination that historically produces a lot of vulnerabilities. MCP (Model Context Protocol) servers and agent-building platforms like Langflow are also often deployed by teams optimizing for shipping an AI capability quickly, which means network exposure and hardening get less scrutiny than they would on a mature enterprise system.
Does patching fix vulnerabilities like CVE-2026-85025?
Patching fixes the code. It doesn’t retroactively fix the exposure window between disclosure and your next change cycle, and it doesn’t help if the instance was already reachable and scanned before the patch shipped. That gap — the time a vulnerable, reachable service sits exposed — is what identity-first reachability approaches like NetFoundry Vulnerability Cloaking are built to close.
How does NetFoundry protect systems that can’t be patched immediately?
By making the vulnerable service unreachable to anyone without a verified, authorized identity, regardless of patch status. The workload has no discoverable network presence to an unauthenticated attacker — there’s no IP or port to scan, no firewall rule to misconfigure — so an unpatched CVE that requires network reachability to exploit has no path to the target until the connection has already been authenticated.
How often is Reachability Watch published?
Weekly, tracking newly disclosed network-exploitable CVEs and flagging the ones most likely to end up in CISA’s KEV catalog.
