In a campaign tracked by Black Lotus Labs, vulnerable AI and developer services became entry points for malware that mined cryptocurrency and searched for new victims. Its command-server address came from an unlikely source: a poem stored on GitHub.
A company deploys an AI service on a cloud server. Its API responds normally, and developers can use it to connect an application to language models. But an exposed service is running vulnerable software. An attacker finds it, gains access, and installs malware.
The AI service may continue to work. Meanwhile, the compromised machine could be consuming resources to mine cryptocurrency and searching the internet for other vulnerable servers.
That is the risk illustrated by Canto Incognito, a campaign investigated by Lumen’s Black Lotus Labs. The researchers reported that its PoeLLM malware had affected more than 3,400 servers since activity began in April. Targeted or affected installations included AI infrastructure software such as LiteLLM and Ollama, as well as Gotenberg and Gitea. The number describes servers observed by researchers, not companies or people. [1]
The investigation is notable partly because infected computers used words in a poem hosted on GitHub to calculate where to find the attacker’s command server. But the underlying compromise did not depend on tricking a language model with a prompt. It involved vulnerable network services, malicious software and unauthorized use of computing resources.
An AI service is still a server
Self-hosted AI deployments run on operating systems, containers, API gateways, authentication services and network infrastructure. These components need the same controls as other production software.
Ollama supports running models on local or self-managed systems. LiteLLM can act as an API gateway across model providers. Neither product is inherently malicious. Risks arise when vulnerable versions, excessive permissions or unnecessarily exposed endpoints make a deployment reachable and exploitable.
PoeLLM also affected Gotenberg, a document-conversion service, and Gitea, a code-hosting platform. The operator did not exclusively seek AI model servers: vulnerable systems could supply computing resources and a foothold for further attacks. [1]
A documented weakness in the LiteLLM gateway
One specific vulnerability examined in connection with the campaign was CVE-2026-42271. LiteLLM supports the Model Context Protocol (MCP), through which AI applications can communicate with external tools. Some MCP connections use standard input and output (stdio), which can require launching a local process.
The vulnerable LiteLLM implementation offered two test endpoints that accepted an MCP server configuration. That configuration could include a command, its arguments and environment variables. In certain cases the gateway spawned the specified command on its host. The endpoints checked for a valid API key but did not require the administrator role. A lower-privileged authenticated user could therefore cause command execution with the permissions of the LiteLLM process. [2]
This was an authorization failure in a tool-integration feature, not a model generating unsafe text. A gateway API key was insufficient protection if that key could access functions with administrative consequences.
The advisory covers LiteLLM versions 1.74.2 up to, but not including, 1.83.7. It lists a CVSS 4.0 score of 8.7 (High) and confirms a fix in 1.83.7. The fixed endpoints require the PROXY_ADMIN role. The advisory also describes a temporary gateway-level block of both MCP test endpoints for environments unable to upgrade immediately. [2]
Black Lotus Labs found an exploit reference to /mcp-rest/test/connection in a malware sample and described it as a likely exploitation route for some victims. It did not establish that every PoeLLM infection used this CVE. Other products and exposure paths were present in the campaign. [1]
What the malware did after gaining access
Black Lotus Labs examined a Linux executable identified as libgcrypt. It contained remote-shell capabilities, scanning and exploit functionality, and cryptocurrency miners including XMRig and Iron. The researchers observed infected hosts communicating with Kryptex mining infrastructure. [1]
Cryptomining allows attackers to use the victim’s computing resources for their own benefit. The effect may appear as sustained processor utilization, increased cloud costs or degraded service responsiveness. Not every infected server was confirmed to contain a high-end AI GPU, and the investigation does not show that every miner consumed GPU capacity.
The campaign also used compromised systems to search for additional victims. Machines already infected became scanners and exploit servers, extending the operator’s reach while hiding some activity behind infrastructure belonging to other organizations. The researchers saw possible experimentation with distributed attacks on SSH and other login services, but did not characterize that capability as fully established. [1]
A poem that led malware to its command server
Malware usually needs a command-and-control server (C2) from which its operator can send instructions or stage additional files. If the malware embeds one permanent server address, defenders may block that destination.
PoeLLM used a changeable address-discovery mechanism. The malware fetched text from a file called dash.css in a GitHub repository that resembled a fork of the Node.js website source. The file contained a poem titled On the Nature of Connection. The malicious file was not part of the legitimate Node.js project. [1]
The malware extracted four selected words or phrases from specific positions in the poem. Its internal dictionary mapped those selections to numbers, which were combined as the four components of an IPv4 address. When the operator changed those words, an infected system could calculate a different C2 address without needing a new malware binary.
Black Lotus Labs recorded 11 revisions of the poem and identified 12 C2 addresses used during the campaign. [1]
This was data encoding performed by ordinary malware code, not a prompt-injection technique. GitHub hosted the changing text. The public evidence does not show GitHub itself was compromised. The technique makes fixed-address blocking less durable, but does not make the traffic invisible to monitoring.
Accessible text alternative for this figure
Four steps. Step 1, an exposed service such as LiteLLM or another vulnerable AI or developer tool. Step 2, a compromised host, where the malware executes, mines cryptocurrency and scans. Step 3, downstream activity: cryptomining and a search for new targets.
Step 4, dynamic command-server discovery: the malware fetches a GitHub-hosted poem and converts selected words into an IP address, which gives the compromised host the location of its command server. The schematic is explanatory and not an exact replay of one victim’s infection. The specific initial exploits differed across hosts.
Why standard security monitoring matters
This campaign shows why security teams should examine both how services are reached and what a server does after compromise.
An unnecessarily public AI gateway expands the attack surface. A vulnerable administrative or integration endpoint may permit a privilege boundary to be crossed. A process running with broad operating-system permissions increases the damage. If outgoing traffic is unmonitored, the server may contact C2 or mining infrastructure or probe other hosts before anyone notices.
Cryptomining may generate unusual resource use, but high CPU or GPU load alone proves nothing: legitimate inference can also be expensive. Investigators need process evidence, network records, access logs and current indicators of compromise.
| Control | Practical check | What it helps address |
|---|---|---|
| External exposure | Inventory AI gateways, model servers and support services, and remove unnecessary public access | Internet scanning and initial reachability |
| Patch management | Review affected products and versions against current advisories | Known exploitable software flaws |
| Authorization | Restrict privileged administration and tool-execution endpoints | Lower-privilege access to dangerous operations |
| Runtime isolation | Use least-privileged users, limited containers and scoped credentials | Impact of successful host-level execution |
| Egress monitoring | Investigate unexpected destinations, scanning and mining-pool connections | Post-compromise activity |
| Process monitoring | Examine unexplained executables and sustained compute activity | Malware and resource abuse |
| Incident recovery | Preserve evidence, isolate affected workloads and rebuild from trusted sources | Containment and eradication |
For organizations running the affected LiteLLM versions, the most direct action is to update to 1.83.7 or a later fixed version, verify that the vulnerable endpoints are appropriately restricted, and investigate whether the system shows signs of compromise. A network block is a temporary mitigation, not a substitute for a patch and investigation. [2]
Black Lotus Labs published historical C2 indicators and links to its current threat-intelligence resources. Teams should use the latest available indicators, but should not treat a list of historical IP addresses as comprehensive: the campaign was designed to move between destinations. [1]
What the research cannot tell us
The 3,400-plus figure is the researcher-reported count of affected servers in the report’s key takeaways. The body of the report refers to almost 2,200 victim servers and does not reconcile the two counts, so they should not be added together. Neither figure establishes the number of organizations or end users affected. [1]
The public findings do not identify a confirmed exploitation chain for each victim. They do not establish that information was stolen from every affected server. Black Lotus Labs assessed a possible Italian-speaking operator, based on language artifacts and infrastructure observations, but did not establish the operator’s identity or nationality. [1]
The broader lesson for AI deployments
PoeLLM stands out because it hid its changing command-server address inside a poem. The weaknesses it exploited are more familiar: exposed applications, vulnerable features and inadequate security boundaries around production services.
Running a model on your own infrastructure gives an organization more control over where its workloads execute. It also makes the organization responsible for securing the surrounding software and network environment.
The model does not need to be fooled for its server to be compromised. AI infrastructure needs ordinary production security, restricted access, sound authorization, prompt patching, monitored outbound traffic and tested recovery, alongside AI-specific safeguards.
References and further reading
The advisory and the Lumen report were opened and checked on 14 October 2026. Indicator lists change, so use the current published indicators and do not treat a historical list as complete.
- Black Lotus Labs: Canto incognito: tracking the PoeLLM malware. Lumen, 2026. Primary campaign investigation, telemetry, malware analysis and indicators of compromise.
- GitHub Security Advisory GHSA-v4p8-mg3p-g94g and CVE-2026-42271. Published April 2026, updated June 2026. LiteLLM scope, versions, severity, patch and workaround.
- Gotenberg: Installation guidance. Official deployment and exposure guidance.
- Black Lotus Labs: Public threat-intelligence repositories. Additional campaign indicators, including the PoeLLM indicator file. Verify at release time.