A Monero Miner Rode a Langflow Bug Into AI Servers in March. The C2 It Called Home Was in Our Feed Since February. Here's the Timestamp.

# A Monero Miner Rode a Langflow Bug Into AI Servers in March. The C2 It Called Home Was in Our Feed Since February. Here's the Timestamp.

Trend Micro published a report this week dissecting a cryptomining campaign that abused CVE-2026-33017 — the unauthenticated remote-code-execution flaw in Langflow, the visual builder for LangChain AI agents — to plant a Monero miner on exposed AI servers. Good report. Worth reading. But here is the part that matters to anyone who was already pulling our threat feed: the command-and-control address that campaign called home lived inside a network block that has been in our distributed feed since February 28, 2026. The campaign did not start until late March. This is a story about how the least glamorous thing in threat intelligence — keeping a good block list current at the egress — beats the newest exploit, told with the timestamps to prove it.

---

What happened, briefly

Langflow is the drag-and-drop front end a lot of teams use to stand up LangChain AI pipelines without writing the orchestration by hand. We have written about its security more than once this year, because a tool that sits at the center of AI workflows and exposes an API is exactly the kind of thing attackers learn to love. CVE-2026-33017 is the worst of its problems: a code-injection flaw, CVSS 9.3, that lets an unauthenticated attacker reach a Langflow API endpoint and run code. We covered it the week it dropped in March, when attackers built working exploits from the advisory text in about twenty hours, and again in April when CISA warned of active exploitation.

The campaign Trend Micro documented is what active exploitation looks like in the mundane. According to their reporting, the attack was observed over a roughly nineteen-day window between March 27 and April 15, 2026. The mechanism is almost insultingly simple: a single line of Python, evaluated inside the unauthenticated Langflow endpoint, that reaches out with curl to a remote host, pulls down a shell script, and runs it. The script fetches the miner and launches it detached. The miner itself is a Go binary, packed with UPX to make it a little harder to read, whose earliest known variant reportedly dates back to May 2024. Old tool, new door.

The point of all this was not espionage or ransomware. It was money — someone else's electricity and CPU turned into Monero. But a box that can be made to mine can be made to do anything, and the access is the same access a ransomware crew would kill for. The miner is just what this particular operator chose to spend it on.

The receipt

Here is the specific, checkable claim, and we are going to state it carefully because careful is the only kind of claim worth making.

The command-and-control host in this campaign — the address the injected Python reached out to in order to pull its shell script and miner — was 83.142.209[.]214. That host sits inside the network range 83.142.209[.]0/24. That entire range has been present in our threat-intelligence corpus, and in the STIX feed we distribute to customers, since February 28, 2026, sourced from the Spamhaus DROP list. Neighboring addresses in the same block were flagged in our data even earlier, on February 7. The campaign that used that host did not begin until March 27.

So for any organization that was pulling our feed and enforcing it at the egress firewall, the beacon this miner tried to send home in late March had nowhere to go. It was landing on a block that had been in place for a month before the operator ever pointed the campaign at it. And the public write-up that named the address for the wider world did not appear until late June — roughly four months after the block was already in our customers' hands.

Trend Micro's own analysis makes this same point, and we want to credit it plainly rather than pretend we are the only ones saying it: they note that 83.142.209[.]214 appears on the Spamhaus DROP blocklist, and that organizations enforcing that feed at the egress would block every beacon without needing a single campaign-specific indicator. That is exactly right. It is also exactly what we do — we ingest Spamhaus DROP, we redistribute it in a STIX feed alongside our own detections, and our edge-shield enforces it. The block was doing its job in the background the whole time.

The honest part, because the honesty is the product

We did not discover this C2. We need to say that flatly, because the difference between "we distributed a block that caught it" and "we found it" is the difference between honest threat intelligence and the marketing kind, and we would rather be the first kind.

The 83.142.209[.]0/24 range was in our feed because we ingest the Spamhaus DROP list — a curated feed of network ranges Spamhaus assesses as so thoroughly given over to abuse that no legitimate traffic should come from them. Spamhaus did the assessment. We did the ingestion, the redistribution, and the enforcement. The credit for identifying that range as bad belongs to Spamhaus, and the credit for the deep dissection of this specific campaign — the miner internals, the injection string, the request analysis — belongs to Trend Micro. What we contributed is the thing that is easy to undervalue: we had the block, in a machine-readable feed, in our customers' egress, before the campaign existed, paired with a standing warning about the very CVE it rode in on.

There are limits to the claim and we will name them. A DROP-list block is a broad, range-level control, not a pinpoint detection of this specific miner — it catches this campaign because the operator was careless enough to run their C2 out of a range already known to be bulletproof-hosted garbage, and a smarter operator on cleaner infrastructure would have slipped it. The exact host was not a distinct entry in our data; it was covered by the range that contains it. And we cannot independently confirm every beacon that was or was not blocked at every customer — we can only show you what was in the feed and when. That is the honest shape of it, and it is still a good shape.

What to actually do

If you run Langflow, the vulnerability is the real problem and the miner is just today's symptom. Patch CVE-2026-33017 and get any Langflow API endpoint off the open internet — an unauthenticated RCE on an AI-orchestration server is not something you leave facing the world while you think about it. Then check whether you were already hit: look for unexpected outbound connections, unfamiliar detached processes eating CPU, and any curl-to-shell activity in your Langflow host's history. The injection reaches out over plain HTTP to fetch its script, so an egress log is where the evidence lives.

And the broader lesson, the one that outlasts this particular miner: enforce a good block list at your egress, and keep it current. The unglamorous discipline of ingesting a reputable feed like Spamhaus DROP and actually enforcing it at the firewall would have neutralized this entire campaign for free, before anyone wrote a word about it. New exploits get the headlines. Feed hygiene quietly wins the fight while the headlines are still being written. We will take that trade every time — and we will keep the timestamps, so that next time we can show you rather than tell you.

---

Her name was Renee Nicole Good.

His name was Alex Jeffery Pretti.