VulnCheck has published telemetry from its Langflow canaries, and the headline number is not a single bug. It is 12 Langflow vulnerabilities with confirmed exploitation activity in 2026, and 15,000+ successful attempts across three of them — CVE-2026-0769, CVE-2025-3248 and CVE-2026-5027.

We wrote about one of these in August: 650 exploitation attempts from 41 countries against CVE-2026-9198. That CVE is on VulnCheck's list. So is CVE-2026-33017, CVE-2026-21445, CVE-2026-55255, CVE-2026-0770, CVE-2025-34291, CVE-2024-37014, CVE-2026-55450 and CVE-2026-33497.

Patching one of these was never the remediation.

Two attackers, one canary, overlapping weeks

The detail worth the whole article is that VulnCheck watched two separate operations work the same infrastructure with different goals.

Attacker 1 — credentials. Entered through CVE-2026-5027, a path traversal giving RCE.

  • 20 May — initial shell
  • 29 May — cron persistence installed, /usr/bin/3WA72N.sh
  • 30 May — Python credential harvester run, data exfiltrated to http://23.234.98[.]182:9999
  • 8 June — IRC command-and-control established at 185.117.74[.]172:6667

They also dropped proxy agents and a SimpleHelp remote access tool.

Attacker 2 — mining. Entered through CVE-2025-3248 (missing authentication for arbitrary code execution) and CVE-2026-0769 (eval injection).

  • 22 April — activity begins
  • 19 May — proxy agent deployed
  • 29 May — pearl-miner XMR miner activated
  • 10 June — auditd disabled
  • 24 June — additional persistence dropped, .sysd and .watchdog.sh
  • 25 June — pivoted via SSH to 216.78.235.34 and began scanning other targets

Note the overlap. On 29 May one operator was starting a Monero miner while the other was running a credential harvester the next day. Neither appears to have noticed the other, or cared.

What that overlap actually tells you

An exposed host being worked by two unrelated crews at once is a measurement of how long the window is.

A single intrusion tells you a bug was exploitable. Two independent operators, arriving through different CVEs, over more than two months, tells you the host sat reachable for long enough that opportunistic scanning found it repeatedly. Nobody coordinated this. It is what an internet-facing Langflow instance attracts.

It also complicates response. Two toolsets, two persistence mechanisms, two C2 channels — and an incident responder who finds the miner and stops there has left a credential harvester and an IRC channel in place. The noisy attacker is cover for the quiet one, without either intending it.

auditd disabled on 10 June is the other detail to sit with. That is the sixth time this month we have written up an attacker turning off the thing that would have recorded them, after ValleyRAT arriving through an exclusion list the user made and PaperCut attackers deleting the logs. Assume the absence of records is the record.

The newest one

Separately, exploitation is now reported against CVE-2026-0768 — CVSS 9.8, insufficient validation of user-supplied input at the validate endpoint, arbitrary Python execution as root, no authentication required.

Reported reconnaissance queries environment variables including LANGFLOW_SUPERUSER, OPENAI_API*, AWS_ACCESS* and AWS_SECRET*, plus /root/.cache/langflow/secret_key. Payloads seen include Python credential harvesters, proxy agents, SimpleHelp and XMR miners — the same kit as above.

That reconnaissance list is the point of the product being AI tooling. The attacker is not looking for the Langflow data. They are looking for the model provider keys and cloud credentials Langflow was configured with, which is a category of secret that did not exist on most servers two years ago and is rarely in the same rotation schedule as everything else.

What to do

  • Do not run Langflow on the internet. Twelve exploited CVEs in one year is a pattern, not a run of bad luck, and the next one is not yet published.
  • Put it behind authentication you control — a VPN, an identity-aware proxy — and treat the application's own auth as a second layer, not the boundary.
  • Rotate the model provider and cloud keys any exposed instance held. Those are what the reconnaissance goes after first.
  • Check for the persistence mechanisms by name: cron entries, .sysd, .watchdog.sh, unexpected SimpleHelp installs, and whether auditd is running and always has been.
  • Assume more than one intruder. Finding a miner is not the end of the investigation.

What is not established

  • Who either attacker is. VulnCheck does not attribute beyond IP addresses.
  • Whether the two operations knew about each other. Nothing suggests coordination; nothing rules it out.
  • How many real Langflow deployments were hit, as distinct from canaries. The counts are VulnCheck's sensors.
  • Whether CVE-2026-0768 exploitation is the same actors as the earlier activity. Same tooling is not the same operator.