A critical unauthenticated remote code execution flaw in Langflow, the popular open-source framework for building AI agents and RAG pipelines, was weaponized in the wild roughly 20 hours after its public disclosure — and before any proof-of-concept code existed. Tracked as CVE-2026-33017, the bug lets anyone on the internet run arbitrary Python on an exposed instance with a single unauthenticated HTTP request. Sysdig's Threat Research Team (TRT) captured the first live exploitation attempts on honeypots within a day of the advisory, and CISA later added the flaw to its Known Exploited Vulnerabilities catalog. Organizations running Langflow should treat exposed instances as potentially already compromised.

A zero-day that lands on AI infrastructure

On March 17, 2026, maintainers disclosed a critical vulnerability in Langflow, the visual, drag-and-drop framework that developers and data teams use to assemble LLM-powered workflows, Retrieval-Augmented Generation (RAG) systems, and autonomous agents. With more than 145,000 GitHub stars, Langflow's reach is exactly what makes it an attractive target.

The flaw, CVE-2026-33017, allows unauthenticated remote code execution. No login, no token, and no API key sit between an attacker and code execution — a single crafted request is enough to run server-side Python.

This is a separate issue from CVE-2025-3248, an earlier Langflow RCE that CISA placed in its Known Exploited Vulnerabilities (KEV) catalog back in May 2025. Reference records for the new bug are available at NVD and the CVE.org record, and the original GitHub advisory is published as GHSA-vwmf-pq79-vjvx.

How the vulnerability works

The defect lives in an endpoint intended to let unauthenticated users build public flows:


POST /api/v1/build_public_tmp/{flow_id}/flow

By design this route is reachable without credentials. The problem is that it accepts attacker-supplied flow data whose node definitions can carry arbitrary Python code, and that code is then executed server-side with no sandboxing and no input validation. An attacker simply assembles a malicious flow payload, sends it, and lets the server run the embedded code. The same "public flow" convenience that makes Langflow easy to share with collaborators is what turns the endpoint into an unauthenticated code-execution primitive in production.

The 20-hour exploitation timeline

Within hours of the advisory, Sysdig TRT stood up a fleet of deliberately vulnerable Langflow honeypots spread across multiple cloud providers and regions. The telemetry shows just how fast modern actors move:

  • Mar 17, 20:05 UTC — Advisory GHSA-vwmf-pq79-vjvx published on GitHub
  • Mar 18, 16:04 UTC — First exploitation attempt from 77.110.106.154
  • Mar 18, 16:05 UTC — Second actor, 209.97.165.247, begins probing
  • Mar 18, 16:39 UTC — Sustained scanning spreads across multiple honeypot nodes
  • Mar 18, 20:55 UTC — First advanced actor escalates to environment-variable exfiltration

That puts roughly 20 hours between disclosure and first exploitation. Notably, no public PoC repository existed yet. Attackers built a working exploit from the advisory text alone — the documented endpoint path and the code-injection-via-node-definitions mechanism were all they needed.

Phase 1: automated nuclei scanning (hours 20–21)

The earliest hits came from automated scanning infrastructure. Four source IPs surfaced within minutes of one another, all sending an identical payload that would:

  • run the id command on the target,
  • base64-encode the output, and
  • exfiltrate the result to a unique interactsh callback subdomain.

The fingerprints made the tooling obvious. Requests carried the header Cookie: client_id=nuclei-scanner, and a preceding flow-creation request named the flow nuclei-cve-2026-33017. One IP, 205.237.106.117, rotated through seven different User-Agent strings across eight requests, including values like Knoppix; Linux i686 — entries from nuclei's random UA wordlist that no real browser sends. Every request reused the same Python template, varying only the callback subdomain, consistent with a nuclei template using the {{interactsh-url}} placeholder.

At the time of analysis, no CVE-2026-33017 template existed in the official nuclei-templates repository. That strongly implies a privately written template was deployed at scale within hours of disclosure — either one operator working through many proxies or a small group sharing the template.

Phase 2: custom scripts and post-exploitation recon (hours 21–24)

A second, more capable wave followed. These actors used custom Python scripts, identifiable by a consistent python-requests/2.32.3 User-Agent with no rotation, and moved past validation probes into active reconnaissance.

Most seriously, at least one of them progressed to environment-variable exfiltration — harvesting the secrets stored in the Langflow host's environment. In AI pipeline deployments those variables routinely hold:

  • LLM API keys (OpenAI, Anthropic, and others)
  • Database connection strings
  • Cloud provider credentials (AWS, GCP, Azure)
  • Third-party service tokens

Because a Langflow instance usually sits at the hub of a wider workflow — wired into downstream databases, vector stores, and external APIs — stealing those secrets is a software supply chain problem. Credentials lifted from one exposed node can pivot into a far larger compromise.

Why this one is especially dangerous

Several risk factors stack up here:

  • No authentication. The vulnerable endpoint is public by design — nothing stands between an attacker and execution.
  • Single request. Minimal tooling is required, lowering the bar for unsophisticated actors.
  • High-value targets. Langflow nodes are typically connected to sensitive model APIs and data stores, so post-exploitation impact is severe.
  • Rapid weaponization. The ~20-hour window proves advisory text alone is enough to build a working exploit; conventional patch cadences can't keep up.

On the prioritization front, the picture has since changed: although the flaw was being exploited from March 18, CISA did not add CVE-2026-33017 to the KEV catalog — as a "Langflow Code Injection Vulnerability" — until March 25, 2026, about a week after in-the-wild activity began (see the CISA KEV alert). Teams that gate remediation on KEV inclusion therefore had a multi-day blind spot while attacks were already underway — a reminder not to wait for KEV listing to justify urgency.

Detection and mitigation

Treat any internet-facing Langflow instance as an active incident:

  • Patch now. Apply the latest Langflow release that fixes CVE-2026-33017.
  • Restrict network access. If you can't patch immediately, block public access to the /api/v1/build_public_tmp/ endpoint at the firewall or reverse proxy.
  • Assume secret theft. Rotate every API key, database credential, and cloud token that lived on an exposed host.
  • Review runtime telemetry. Hunt for unexpected child processes spawned by the Langflow process, anomalous outbound HTTP connections, and base64-encoded blobs in network logs.
  • Deploy runtime threat detection. Tools such as Falco can flag the suspicious syscalls and process behavior that accompany RCE in containerized environments, giving you a safety net independent of patch status.
  • Watch the scanner tells. Alert on requests carrying Cookie: client_id=nuclei-scanner and on flows named after CVE identifiers.

Technical background: code injection via untrusted flow definitions

The following is a general explanation of this vulnerability class, not a reproduction of the exploit used in these attacks — the source did not publish working PoC code.

This bug belongs to a broad family of injection flaws in which a server deserializes or evaluates user-controlled data as executable logic. Low-code and pipeline tools are especially prone to it because a "node," "step," or "transform" often maps directly onto code that the engine runs. When such a definition is accepted from an unauthenticated client and executed without sandboxing, the data boundary collapses into a code boundary.

Generically, a vulnerable handler does something equivalent to evaluating a field pulled straight from the request body:


# ILLUSTRATIVE ONLY — not the Langflow code
def build_node(node_def):
    # user-supplied 'code' executed in the server context
    exec(node_def["code"])

The defenses are the same ones that apply to any code-execution surface: never exec/eval untrusted input, require authentication on endpoints that materialize user logic, run worker code in a sandbox with no ambient secrets, and keep credentials out of the process environment of internet-facing services. As organizations rush AI tooling — Langflow, LangChain, AutoGPT, and similar — into production, security teams should subject these platforms to the same scrutiny they apply to any other web application or cloud API.

Takeaways

CVE-2026-33017 shows that critical flaws in AI-adjacent infrastructure can be exploited in under a day, with no public PoC required. Sysdig's honeypot data makes clear that attackers monitor advisories in near real time, reverse-engineer exploits from documentation, and scan the internet within hours — compressing the patch window toward zero. The answer is layered: fast patching, network segmentation, runtime detection, and disciplined credential hygiene working together. If you run Langflow or any exposed AI pipeline tooling, respond to this as an active incident rather than a future risk.