A futuristic cybersecurity command center links server racks and a global network to a hooded operator behind a glowing digital shield.
A malware family that hides its command server inside a poem is quietly turning exposed AI gateways into cryptominers. Lumen's Black Lotus Labs (BLL) calls it PoeLLM. The unusual part isn't the mining, which is old news. It's the way the botnet finds its controllers, and the fact that the targets are the AI plumbing many organizations have wired up in a hurry.

What PoeLLM is and what it does​

BleepingComputer describes a cryptomining campaign that uses PoeLLM to turn compromised servers into scanners and exploit launchpads. Its uncommon trick is to pull keywords from a poem hosted on GitHub and use them to find its command-and-control (C2) address.

The reported capabilities are broad:

  • Remote-shell access.
  • XMRig and Iron cryptocurrency miners.
  • HTTP/S scanning.
  • Exploit deployment.

BLL also found that victims talk to Kryptex, a Russian crypto-mining service.

The poem trick, explained​

According to BleepingComputer's account of the BLL report, PoeLLM is an ELF binary named libgcrypt. It retrieves four words or phrases from a poem titled "On the Nature of Connection". The poem sits in a dash.css file in a GitHub repository that appears to fork Node.js. A hard-coded dictionary maps those words to numbers, which produces an IPv4 address for the C2.

The operator doesn't need to touch the malware to move the C2. To change the address, the operator just edits the poem.

BLL's Ryan English told CyberScoop why this is hard to defend against. The C2 IP address is invisible outside the victim's netflow. To anyone else, it's a poem on GitHub with no links, no downloads and no encrypted blob to flag. A poem on a public code host looks harmless to a scanner, so the usual signals don't fire.

In practical terms, that means blocking a known-bad IP is a short-lived fix. Egress monitoring and anomaly detection on servers that have no reason to make odd outbound connections matter more. That is my analysis, not BLL's stated guidance.

Scale: two reports, two numbers​

The figures differ depending on the outlet:

ItemBleepingComputerCyberScoop
Servers compromisedMore than 2,100More than 3,400 since April
Peak daily activityUp to about 800 infected systems in one dayNot stated in the excerpt
Poem changes11, with another suspected"At least a dozen"

BleepingComputer reports more than 2,100 compromised servers, with as many as 800 infected systems active on a single day. CyberScoop reports more than 3,400 servers compromised since April. I can't tell from the available material why the totals differ. The gap could come from the reporting date, the counting method or an updated figure. I haven't seen the underlying BLL report, so treat all counts as BLL estimates and expect them to move.

The campaign has been active since at least April and has grown since then. At least 11 C2 servers have been spun up, and targets span the United States and Western Europe.

Who is in the crosshairs​

Many victims run exposed AI tools such as LiteLLM and Ollama, the Gotenberg PDF converter and the Gitea development toolkit. BLL also uncovered signs of Ivanti Sentry targeting. Running one of these products does not mean a server is compromised, and the reporting doesn't say every instance was vulnerable. The pattern is that these are services that often end up internet-facing.

BLL's reasoning, as relayed by BleepingComputer, is that AI/LLM deployments are attractive because they are often poorly configured, exposed online and typically run on powerful GPU clusters suited to cryptomining. That is a general tendency, not a claim about every deployment.

The LiteLLM bug at the center​

Once a server is compromised, it becomes a springboard. It scans ports 3000 and 4000, which are associated with Gotenberg and LiteLLM, and tries to exploit CVE-2026-42271. Scanning those ports doesn't prove that everything listening there is vulnerable.

Red Hat's record describes the flaw this way:

  • Two LiteLLM endpoints that preview an MCP server before saving it accepted a full server configuration, including command-execution parameters.
  • An authenticated user, even one with a low-privilege internal-user key, could send a crafted configuration and run arbitrary commands on the proxy host with the privileges of the proxy process.
  • Red Hat rates it Important for LiteLLM as deployed in products such as Ansible Automation Platform and OpenShift AI. It carries a CVSS v3 base score of 8.8 and is classed as OS command injection (CWE-78).

That fits BleepingComputer's account that the bug was originally disclosed as requiring authentication and rated high severity. The "unauthenticated" part comes from a chain. The report says Horizon3.ai researchers confirmed it could be combined with CVE-2026-48710 for unauthenticated remote code execution (RCE). I haven't independently reviewed that research. The bug alone requires credentials, but a chain may not.

On patching, LiteLLM's own advisory lists the issue as "Authenticated command execution via MCP stdio test endpoints", rated High, and 1.83.7 as the patched version. If you run a vendor-packaged build, such as one bundled in a Red Hat product, confirm the fix with that vendor. A version number alone may not tell you whether a backported fix is in place.

Infrastructure and attribution​

BLL found that several C2 servers had vulnerable router administration interfaces, which suggests the attacker reused compromised routers. The researchers could not make a confident attribution. They assess with moderate confidence that the operator is Italian, based on comments in the malware and an Italy-based server hosting the administrative interface. That is a lead, not a verdict.

What admins should do now​

The recommended defenses are fairly standard, and for this campaign they are specific enough to act on. The BLL guidance relayed in the reporting is to apply the latest security updates, reduce public exposure for critical assets and restrict external access to trusted IPs. Here is how that maps onto a checklist:

  1. Inventory every internet-reachable AI gateway and helper service. That includes LiteLLM, Ollama, Gotenberg, Gitea and Ivanti Sentry, plus anything on ports 3000 and 4000.
  2. Patch LiteLLM to 1.83.7 or later, or to the vendor's fixed build. Until then, limit who can reach the MCP test endpoints.
  3. Shrink exposure. Put these services behind a VPN or an allow-list. Treat router and appliance admin interfaces as separate risks.
  4. Review network logs against BLL's published indicators of compromise. A hit warrants investigation. A miss does not prove a host is clean, especially with a C2 that changes by editing a poem.
  5. Watch for symptoms such as unexpected outbound connections, new scanning from internal hosts, and sustained GPU or CPU load with no matching workload. These are my suggestions, not BLL's.
  6. Treat suspected infections as incidents. Isolate and investigate the host. Patching won't remove malware that is already installed, and a LiteLLM host may also hold provider API keys that need rotating.

Why Windows and enterprise readers should care​

PoeLLM is a Linux ELF threat, so it won't run on a Windows desktop. But many Windows-centric shops now run LiteLLM, Ollama or Gitea next to their Azure and Microsoft 365 estate, often as quick proofs of concept that quietly become production. Those machines are the ones that skip patch cycles. A compromised AI gateway is also more than a free mining rig. It is a foothold inside the network.

The broader lesson is familiar. Attackers don't need novel exploits when exposed, under-managed services are plentiful. The poem is clever. The real problem is that so many of these servers are open to the internet.

 

References

  1. PoeLLM malware infects exposed AI servers in cryptomining attacks BleepingComputer 2026-10-07T11:04:08-04:00
  2. CVE-2026-42271 - Red Hat Customer Portal access.redhat.com
  3. PoeLLM malware has assembled a sweeping botnet, taking technical cues from a poem cyberscoop.com