Two critical vulnerabilities in widely deployed developer tooling are now being exploited together in the same campaigns, according to research from VulnCheck cited by multiple outlets on September 1, 2026. The first, CVE-2026-0768, is a CVSS 9.8 remote code execution flaw in Langflow, the open-source visual builder used to wire together AI agent workflows. The second, CVE-2026-66066, is a critical Ruby on Rails bug that chains a file-read bug into full code execution. Attackers are reportedly using both for credential probing and command-and-control activity, turning two unrelated pieces of software into one attack path against exposed servers.
The timing matters. Langflow sits at the center of the current rush to build “agentic” AI pipelines inside enterprises, and it has now racked up at least three critical remote-code-execution disclosures in roughly a year. CVE-2026-0768 is not a new bug quietly patched and forgotten. It is a year-old disclosure that has jumped from theoretical risk to active exploitation, and it landed the same week researchers flagged a second, unrelated framework being hit by the same attackers.
What CVE-2026-0768 Actually Does to a Langflow Server
CVE-2026-0768 lives inside Langflow’s code validator, the component that runs whenever a user builds or tests a custom node in the platform’s drag-and-drop workflow editor. According to the National Vulnerability Database entry and reporting from SecurityWeek, the flaw sits in how Langflow handles the “code” parameter passed to its internal “validate” endpoint. The server accepts a string from the client and runs it as Python without properly checking what is inside it first.
That gap turns a normal feature into a weapon. Anyone who can reach the endpoint can submit a crafted “code” value and get it executed on the server, no login required. SecurityWeek reports that all Langflow releases up to version 1.4.2 are affected, and NVD’s write-up confirms the resulting code runs in the context of the root user rather than a sandboxed or limited account. A successful hit does not just leak a file or crash a process. It hands an attacker a root shell on the box running the workflow engine.
The bug carries a CVSS score of 9.8, the same ceiling assigned to bugs that require zero authentication, zero user interaction, and deliver total compromise of confidentiality, integrity, and availability. For a tool that enterprises increasingly plug into internal data sources, API keys, and model credentials, root-level RCE is close to the worst-case outcome the scoring system can describe.
CVE-2026-66066 Adds a Second Way In, This Time in Rails
The second flaw in the same wave of reports has nothing to do with AI tooling on paper. CVE-2026-66066 is a critical vulnerability in Ruby on Rails, the web application framework that still powers a large share of production backend services outside the AI space entirely. German outlet IT-Boltwise assigns it a CVSS score of 9.5 and describes the bug as a chain that starts with unauthorized file-read access and ends in remote code execution, exposing server files and application secrets along the way.
What makes CVE-2026-66066 newsworthy is not the bug in isolation. Rails vulnerabilities of this severity surface periodically and get patched inside normal release cycles. What changed is that VulnCheck’s telemetry, cited by both The Hacker News and IT-Boltwise, shows the same attacker infrastructure probing for both the Langflow flaw and the Rails flaw during the same operational window. Two frameworks with no shared codebase, no shared maintainer, and no obvious technical link are being scanned for and exploited by what appears to be a single opportunistic campaign hunting for whichever door happens to be unlocked.
How VulnCheck Caught the Pattern: Credential Probing and C2
VulnCheck’s research, summarized across SecurityArsenal, IT-Boltwise, and WIU Cybersecurity News, describes the observed activity in two buckets. The first is credential probing, where compromised servers are used to hunt for stored API keys, database credentials, and cloud service tokens sitting on disk or in environment variables. The second is command-and-control setup, where the initial code execution is used to drop a beacon or backdoor that lets the attacker return later without repeating the exploit.
None of the reporting names a specific intrusion set or APT group behind the activity. SecurityArsenal, IT-Boltwise, and WIU Cybersecurity News all describe campaign behavior rather than attribution, which is common in the early days of active-exploitation tracking before defenders have pieced together enough infrastructure overlap to name a group with confidence. That absence of a named actor does not make the activity less urgent. If anything, opportunistic, un-attributed scanning tends to spread faster because it is automated and untargeted, hitting anything reachable rather than a curated list of victims.
SecurityArsenal’s guidance is blunt about the timeline defenders are working with: it advises against waiting for a normal patch window at all, telling teams to upgrade immediately and lock down internet-facing instances rather than deploy proof-of-concept code or delay remediation.
From a July 2025 Report to a September 2026 Exploitation Wave
The most striking detail in SecurityWeek’s coverage is how long CVE-2026-0768 sat before attackers picked it up. The outlet reports the flaw was originally reported through Trend Micro’s Zero Day Initiative in July 2025, then publicly disclosed as a zero-day in January 2026. That is roughly eight months between private disclosure and public knowledge, and another eight months between public disclosure and confirmed active exploitation as of September 1, 2026.
That gap is not unusual for infrastructure software with a smaller install base than, say, a mainstream CMS. Fewer eyes means slower patch adoption, and slower patch adoption means a wider window during which a public zero-day sits unexploited simply because nobody has gotten around to weaponizing it yet. The lag also means a meaningful number of Langflow deployments running versions up to 1.4.2 have likely gone over a year without applying a fix that has been publicly known since January.
| Attribute | Langflow CVE-2026-0768 | Ruby on Rails CVE-2026-66066 |
|---|---|---|
| CVSS score | 9.8 (Critical) | 9.5 (Critical) |
| Vulnerability type | Unauthenticated code injection in validator endpoint | File-read chained to remote code execution |
| Authentication required | No | No (per reporting) |
| Execution context | Root user | Application server context |
| Affected versions | Up to and including 1.4.2 | Not itemized in current reporting |
| Disclosure path | Reported to ZDI July 2025; public zero-day January 2026 | Disclosed alongside active exploitation reports, September 2026 |
| Exploitation status | Active, per VulnCheck | Active, chained with CVE-2026-0768 per VulnCheck |
| Primary attacker goal observed | Credential probing, C2 deployment | Credential probing, C2 deployment |
Why AI Workflow Tools Keep Ending Up on the CVE List
CVE-2026-0768 is not Langflow’s first brush with a critical rating, and it is not the only AI-adjacent workflow platform to post one this year. The Cloud Security Alliance’s research on Langflow’s CVE-2025-34291 describes a separate critical vulnerability chain, rated 9.4 under CVSS v4.0, that let an attacker take over an account and achieve remote code execution just by getting a victim to visit an attacker-controlled page in versions up to 1.6.9. A third Langflow bug, CVE-2026-33017, targets the platform’s “build_public_tmp” endpoint and scored 9.8 under NVD’s v3.1 scale, or 9.3 under GitHub’s own v4.0 rating, affecting versions up to 1.8.2 before a fix shipped in 1.9.0.
Langflow is not alone in this pattern. The Cloud Security Alliance documented three separate critical vulnerabilities in n8n, a competing workflow automation platform, under active exploitation as of March 2026: CVE-2025-68613, CVE-2026-27577, and CVE-2026-27493. The Alliance’s research note puts the severity range at CVSS 9.9 for an authenticated expression-injection bug up to a 9.5-to-10.0 band for unauthenticated remote code execution, and it points out that all three “affect the same application surface used by enterprises to orchestrate agentic AI workflows, large language model integrations, and automated data pipelines,” a description that could apply almost word for word to Langflow’s own bug history.
MLflow, the machine learning lifecycle platform, has its own entry on this list. Security Affairs reported that CISA added an MLflow flaw to its Known Exploited Vulnerabilities catalog after confirming a remote attacker could exploit versions before 3.15.0 without authentication, using the bug to reach internal services from an exposed server, including cloud metadata endpoints that can hand over temporary cloud credentials.
| Platform | CVE(s) | CVSS | Vulnerability Type | Status |
|---|---|---|---|---|
| Langflow | CVE-2026-0768 | 9.8 | Unauthenticated RCE via code validator | Active exploitation, September 2026 |
| Langflow | CVE-2026-33017 | 9.8 (NVD) / 9.3 (GitHub) | Unauthenticated RCE via build_public_tmp endpoint | Patched in 1.9.0 |
| Langflow | CVE-2025-34291 | 9.4 (CVSS v4.0) | Account takeover chained to RCE | Affects versions through 1.6.9 |
| n8n | CVE-2025-68613, CVE-2026-27577, CVE-2026-27493 | 9.5 to 9.9 | Expression injection and unauthenticated RCE | Active exploitation confirmed March 2026 |
| MLflow | Unspecified (pre-3.15.0 flaw) | Not disclosed in cited reporting | Unauthenticated SSRF to internal services | Added to CISA KEV catalog |
| Ruby on Rails | CVE-2026-66066 | 9.5 | File-read chained to RCE | Active exploitation, chained with Langflow bug |
What Security Researchers Are Saying
The Cloud Security Alliance has been tracking this category of vulnerability closely enough to publish a dedicated research note on the risk. Describing the n8n disclosures, the organization wrote that “these flaws span a critical severity range, from authenticated expression injection (CVSS 9.9) to unauthenticated remote code execution (CVSS 9.5–10.0), and affect the same application surface used by enterprises to orchestrate agentic AI workflows, large language model integrations, and automated data pipelines” (Cloud Security Alliance research note).
The Alliance also noted that the exploitation problem is not confined to one incident. In its own words: “Three critical vulnerabilities affecting the n8n workflow automation platform — CVE-2025-68613, CVE-2026-27577, and CVE-2026-27493 — are under active exploitation as of March 2026” (source). Six months on, the same category of tool, Langflow, is now on the same list.
On Langflow specifically, the Cloud Security Alliance’s earlier research note on CVE-2025-34291 described the bug in stark terms: “CVE-2025-34291 is a critical vulnerability chain (CVSS v4.0: 9.4) in Langflow versions up to and including 1.6.9, enabling full account takeover and remote code execution through a single victim browser visit to an attacker-controlled page” (Cloud Security Alliance).
Security Affairs, reporting on the separate MLflow catalog addition, framed the exposure risk in terms enterprises will recognize immediately: “The vulnerability allows attackers to make requests from an exposed MLflow server to internal services, including cloud metadata endpoints, potentially exposing temporary cloud credentials” (Security Affairs). That is the same underlying risk driving the Langflow and Rails story: a workflow tool sitting closer to cloud credentials than most security teams assume, exploited by attackers who know exactly what they are looking for.
Market Impact: Enterprise AI Pipelines Under the Microscope
Langflow’s appeal was never a mystery. It gives teams a visual, low-code way to wire together large language model calls, vector databases, and custom Python logic without writing a full application from scratch. That same design, letting users submit code snippets that the server executes to test a workflow, is precisely the feature CVE-2026-0768 abuses. The tradeoff between fast prototyping and a hardened execution boundary is now playing out in public exploitation logs.
The financial and operational stakes go beyond a single patched box. A Langflow instance compromised at the root level typically sits inside a broader pipeline connected to API keys for commercial LLM providers, internal databases, and sometimes cloud IAM roles with far more reach than the workflow tool itself needs. That is exactly the attack surface the Cloud Security Alliance flagged when it grouped Langflow, n8n, and similar orchestration tools together as sharing “the same application surface used by enterprises to orchestrate agentic AI workflows.”
For security teams, the practical impact lands in three places at once: incident response headcount gets pulled toward triaging AI infrastructure that was often deployed by data science teams outside normal change management, cyber insurance underwriters start asking pointed questions about which workflow tools are internet-facing, and procurement conversations about new AI tooling now come with a security review step that did not exist a year ago.
Langflow, n8n, and MLflow: Comparing the Security Track Records
Set side by side, the three platforms show a similar shape of risk even though they serve different roles in an AI pipeline. Langflow leads on raw count, with three critical disclosures across roughly a year, all clustered around code execution through either the validator, a temp-file endpoint, or a browser-triggered account takeover chain. n8n’s three flaws, tracked by the Cloud Security Alliance, span a tighter window and a similarly brutal severity range, and unlike Langflow’s staggered disclosures, all three were flagged as under active exploitation in the same March 2026 window.
MLflow’s disclosed issue takes a different shape: rather than direct code execution, its pre-3.15.0 flaw is a server-side request forgery bug that lets an attacker pivot from an exposed server into cloud metadata services, a path that has burned plenty of non-AI cloud workloads long before MLflow existed. That it earned a spot on CISA’s Known Exploited Vulnerabilities catalog puts it in a more clearly documented remediation category than CVE-2026-0768, which, based on the reporting reviewed for this story, has not been confirmed as KEV-listed.
The common thread across all three platforms is not a shared codebase or vendor. It is a shared design assumption: that the person configuring a workflow can be trusted with a fairly direct line to server-side code execution, because that is the feature the product sells. Attackers have simply worked out how to reach that line without the trust part.
Historical Context: How Low-Code AI Tooling Got Here
Langflow is developed as an open-source project under the DataStax umbrella, built to give developers a drag-and-drop interface for assembling chains of LLM calls, retrieval steps, and custom logic, the same category of tooling that exploded in popularity through 2024 and 2025 as companies raced to ship internal AI assistants and automation without hiring large in-house ML engineering teams. That speed came with a tradeoff familiar to anyone who has watched a fast-growing open-source project mature: security hardening, sandboxing, and least-privilege defaults tend to arrive after adoption, not before it.
Earlier Langflow disclosures targeting internet-facing instances found through scanning tools like Shodan, Censys, or FOFA on default ports show attackers were already treating exposed workflow builders as a known target category well before the current wave. CVE-2026-0768 extends that pattern rather than starting it. What is different in September 2026 is the pairing with an unrelated Rails flaw in the same campaign, a sign that attackers are now running opportunistic, multi-framework scans rather than focusing on a single product’s install base.
What Defenders Should Do Right Now
SecurityWeek’s guidance is straightforward: upgrade Langflow to the fixed release referenced in the project’s own security advisory rather than treating this as routine patch-cycle maintenance. SecurityArsenal goes further, telling defenders not to wait for a scheduled patch window at all given confirmed active exploitation.
A basic first step for any team running Langflow is confirming which version is actually deployed, since instances left on releases through 1.4.2 remain exposed to CVE-2026-0768.
curl -s -o /dev/null -w "%{http_code}\n" https://YOUR-LANGFLOW-HOST/health
pip show langflow | grep -i versionBeyond version checks, the practical hardening steps mirror standard advice for any internet-facing developer tool: take Langflow and Rails instances that do not need public exposure off the open internet, put what remains behind authentication at the network layer rather than relying solely on application-level login, and rotate any credentials, API keys, or cloud tokens that were reachable from a vulnerable instance, since a root-context RCE means those secrets should be treated as potentially exposed rather than merely at risk.
Predictions: Where This Story Goes From Here
- Expect a CISA Known Exploited Vulnerabilities catalog addition for CVE-2026-0768 within weeks if VulnCheck’s active-exploitation findings hold up, following the same path MLflow’s flaw already took.
- More AI workflow and orchestration platforms will likely disclose critical RCE bugs before the end of 2026, given that Langflow, n8n, and MLflow have all posted one in the same twelve-month stretch.
- Attackers will keep pairing unrelated CVEs, like the Langflow and Rails combination seen here, into single opportunistic scanning campaigns rather than running one-CVE-at-a-time operations.
- Enterprise security teams will push AI tooling procurement toward vendors that can show a sandboxed or containerized code-execution model, rather than the direct-to-server execution pattern behind CVE-2026-0768.
- Expect renewed attention on internet-facing exposure scanning for AI workflow tools specifically, echoing the earlier Shodan and Censys sweeps documented against older Langflow releases.
The Bigger Picture for AI Supply Chain Security
None of the individual bugs behind this story are exotic. Unvalidated input reaching a code execution path, a file-read chain escalating into RCE, an SSRF pivot into cloud metadata, these are OWASP-era vulnerability classes that predate the AI boom by well over a decade. What has changed is where they now sit: inside the connective tissue between large language models, internal data, and cloud credentials, rather than inside a standalone web app with a narrower blast radius.
That shift is what makes VulnCheck’s Langflow-and-Rails finding worth watching past this news cycle. It is not really a story about two bugs. It is an early data point on how attackers are learning to treat the AI tooling layer as just another part of the ordinary attack surface, scanned, chained, and monetized with the same opportunistic playbook used against any other exposed service.
Frequently Asked Questions
What is CVE-2026-0768?
It is a critical, unauthenticated remote code execution vulnerability in Langflow, scored 9.8 on the CVSS scale, that lets an attacker run arbitrary Python code in the context of the root user through the platform’s code validator.
Which Langflow versions are affected by CVE-2026-0768?
SecurityWeek reports that all Langflow releases up to and including version 1.4.2 are affected. Users should upgrade to the fixed release referenced in the project’s own security advisory.
What is CVE-2026-66066?
It is a critical Ruby on Rails vulnerability, rated 9.5 by IT-Boltwise, that chains unauthorized file-read access into remote code execution, exposing server files and application secrets.
Are CVE-2026-0768 and CVE-2026-66066 being exploited together?
Yes. VulnCheck’s research, cited by The Hacker News, SecurityArsenal, and IT-Boltwise, describes attackers targeting both flaws in the same campaigns for credential probing and command-and-control activity, even though Langflow and Ruby on Rails are unrelated codebases.
Is CVE-2026-0768 listed in the CISA Known Exploited Vulnerabilities catalog?
Based on the reporting available at publication time, KEV inclusion for CVE-2026-0768 has not been confirmed. A separate MLflow flaw referenced in this story has already been added to the KEV catalog.
Has a specific hacking group been blamed for the exploitation?
No. Current reporting from SecurityArsenal, IT-Boltwise, and WIU Cybersecurity News describes campaign behavior, credential probing and C2 setup, without attributing the activity to a named threat actor.
Why do AI workflow platforms keep getting hit with critical vulnerabilities?
Tools like Langflow, n8n, and MLflow are built to let users submit code or configuration that the server executes as part of normal use. That design, prioritizing fast prototyping of AI pipelines, creates a direct path to code execution that attackers can reach if input validation has gaps.
What should a company running Langflow internally do right now?
Confirm the deployed version, upgrade immediately if it is 1.4.2 or earlier, remove public internet exposure where it is not required, and rotate any credentials or API keys that were reachable from the affected instance.
