AI SecurityThreat IntelligenceAI Governance
A cryptomining botnet called PoeLLM has compromised more than 3,400 servers, many of them running exposed AI tooling such as LiteLLM and Ollama. Researchers at Lumen's Black Lotus Labs, whose findings were reported by BleepingComputer, say peak activity reached about 800 infected systems in a single day. The campaign has been running since at least April and has used at least 11 command-and-control (C2) servers.
The malware is an ELF binary named libgcrypt. Its unusual trick is how it finds its operator: it reads a poem titled "On the Nature of Connection" from a dash.css file in a GitHub repository, picks out four words or phrases, and maps them to numbers with a hard-coded dictionary to build an IPv4 address. To move the C2, the operator simply edits the poem. Black Lotus Labs counts 11 edits so far.
Once running, PoeLLM provides:
Infected machines then scan for more targets on ports 3000 and 4000, which are associated with Gotenberg and LiteLLM, and try to exploit CVE-2026-42271, a flaw in LiteLLM's MCP server test endpoints. It was first disclosed as requiring authentication, but Horizon.ai researchers confirmed it can be chained with CVE-2026-48710 for unauthenticated remote code execution.
Victims are mainly in the United States and Western Europe. Many run exposed LiteLLM and Ollama, the Gotenberg PDF converter, or the Gitea development toolkit, and Black Lotus Labs also saw signs of Ivanti Sentry targeting. The researchers say AI and LLM deployments are attractive because they are often poorly configured, reachable from the internet, and run on powerful GPUs that suit mining. They could not attribute the campaign with confidence, though they assess with moderate confidence that the operator is Italian.
Patching LiteLLM is necessary, but the more basic question is whether anyone in your organisation knew that server existed. LLM proxies, local model runners and test endpoints are easy to stand up in an afternoon, and they tend to be launched by a developer or data team outside any review process. They also hold something worth stealing beyond GPU time: provider API keys, prompts and the connections to internal systems that MCP tools expose.
Cryptomining is the benign outcome. The same foothold gives an attacker a remote shell next to credentials and model traffic. For related reading on what happens when an AI gateway itself is the weak point, see our coverage of the GitLab AI Gateway flaw.
Obiguard Governance AI is aimed at the part of this that patch tickets do not cover: making AI usage visible and routing it through a controlled path. Instead of each team running its own unmanaged proxy, requests go through a governed gateway with authenticated, per-project API keys, policy rules on prompts and outputs, and an audit trail. That gives you a single place to see which models and tools are in use, and it means provider credentials are issued and revoked centrally rather than pasted into a server that may later be exposed.
It does not patch a vulnerable third-party server. What it reduces is the number of ungoverned AI endpoints and long-lived keys an attacker can find in the first place.
If someone asked you today for a list of every server in your organisation that can call an LLM or run an MCP tool, how long would it take, and would you trust the answer?
See how Obiguard Governance AI works or talk to us about bringing your AI infrastructure under policy.
Obiguard sits in front of every AI request your organization makes — screening prompts and outputs against the guardrails, compliance frameworks, and audit trails that stories like this one make necessary.
See how it works →