Langflow CVE-2026-33017 Exploited to Steal AWS Keys and Deploy

Threat actors are exploiting a newly identified Langflow vulnerability to surreptitiously steal cloud keys and repurpose compromised systems as nodes within a new NATS-based botnet. This campaign highlights a critical risk: a single exposed AI workflow tool can initiate widespread credential theft and cloud resource abuse, as detailed in <a rel="noreferrer noopener" target="_blank" href

According to researchers, the operation centers on CVE-2026-33017, an unauthenticated remote code execution flaw in Langflow that was added to the CISA KEV catalog in March 2026.

By hitting a public endpoint with no login required, the attacker can run commands directly in the Langflow container and dump sensitive environment variables.

In the incident analyzed, that simple step was enough to expose live AWS access keys that later powered a broader cloud reconnaissance and abuse phase.

Researchers from Sysdig first documented this activity after watching an operator compromise a Langflow instance and then pivot into the victim’s cloud account.

Over a short 30 minute window, the threat actor pulled down both a Python worker script and a Go based binary from their infrastructure, revealing how they intended to scale the attack beyond a single host.

Langflow CVE-2026-33017 Exploited

Static analysis showed that this tooling, which the attacker called KeyHunter, was designed to systematically harvest API keys from web content and cloud development platforms.

The impact stretches beyond one vulnerable application. Once the Langflow service is exploited, the stolen AWS keys allow the attacker to list cloud resources, probe AI services, and attempt free usage of high end language models. The same worker framework can also validate keys for other platforms like OpenAI or Anthropic, turning every compromised Langflow instance into a feed of monetizable credentials.

In the Sysdig case, the operator also tried to escape the container using DirtyPipe and DirtyCred, signaling an interest in deeper host control if the initial foothold allowed it. Their efforts to run a Go based worker failed due to memory issues, so they fell back to the Python worker as the stable path for data collection.

The Langflow specific piece of this story is the unauthenticated API endpoint that powers CVE-2026-33017. By invoking a public build endpoint under /api/v1/build_public_tmp//flow, the attacker’s payload was able to capture the process environment and read AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY values directly. No phishing or social engineering was required; simple automation against internet facing Langflow nodes would be enough to harvest keys at scale.

From there, the credentials were immediately tested using the sts:GetCallerIdentity API to confirm that they were both valid and active. Over the following hours, the same keys were used for a classic cloud reconnaissance sweep, including S3 bucket listing, EC2 instance enumeration, and checks against logging, cost, and identity services.

The operator then turned to AWS Bedrock, probing model invocation endpoints in an apparent attempt at “LLM jacking” to run large language models without paying.

This activity dovetails with the capabilities baked into the KeyHunter Python worker, which exposes functions named validate_aws and validate_ai to automatically check and classify harvested keys. The worker can also scrape arbitrary web pages and specific cloud code platforms, creating a single pipeline where one compromised Langflow host feeds many follow on attacks.

By treating stolen Langflow keys as just one input stream, the attacker can maximize value from every environment variable they capture.

To reduce the risk, Sysdig recommends patching Langflow to a version that fixes CVE-2026-33017, since the vulnerable endpoint’s lack of authentication makes scanning trivial.

Any Langflow instance that was exposed before patching should be treated as compromised, with immediate rotation of AWS, OpenAI, Anthropic, and Hugging Face keys that could have been reachable from that environment.

NATS worker turns Langflow hosts into C2 nodes

What makes this campaign stand out is the use of a NATS message broker as the command and control channel instead of a traditional web panel. The attacker’s worker connects to a NATS server at 45.192.109.25:14222 over an authenticated session and subscribes to subjects such as task.scan_cde, task.scan_web, task.validate_aws, and task.validate_ai.

This setup lets the operator queue work centrally, have workers pull tasks, and then receive structured results back using JetStream pull consumers with explicit acknowledgements.

NATS also enforces subject level permissions, which the attacker had to work around in real time. When their initial heartbeat messages were blocked, they pushed a quick enumeration script to see which subjects the worker user could publish to, eventually settling on channels like heartbeat.worker and worker.result. This is effectively the principle of least privilege applied to a botnet, preventing a captured worker from snooping on the operator’s own control messages.

The Go binary and its install script show that the goal was a durable, cross platform worker pool. The deploy.sh script installs the worker under /opt/keyhunter-worker/ as a systemd service, configured to restart automatically and survive reboots on both x86_64 and aarch64 systems. Once deployed, each worker can maintain many outbound connections and scrape credential rich code sandboxes while blending in as normal browser traffic.

Defenders can look for several clues. Sysdig notes that existing rules for suspicious system service changes, outbound C2 connections, and AWS runtime analytics already flag parts of this behavior, even though the C2 channel uses a legitimate messaging server.

They also advise blocking outbound traffic to the known NATS and staging hosts involved in this incident and tightening egress from AI tooling so that these services can only talk to specific LLM and database endpoints instead of the open internet.

Indicators of Compromise:-

Note: IP addresses and domains are intentionally defanged (e.g., [.]) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat intelligence platforms such as MISP, VirusTotal, or your SIEM.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.