PoeLLM turns exposed AI services into an asset-inventory test
A cryptomining campaign used public services, rotating infrastructure and a poem-hosted address trick. The workforce decision is simple: assign ownership and patch evidence for every exposed AI endpoint.
What happened
Lumen Black Lotus Labs described a campaign active since April that compromised thousands of exposed servers and used changing words in a GitHub-hosted poem to locate command infrastructure.
Why it matters
The report names AI-related services among observed victims, but the central control gap is broader: organisations cannot patch, restrict or investigate an internet-facing service they have not inventoried and assigned.
Lumen Black Lotus Labs’ PoeLLM report describes a cryptomining campaign tracked since April 2026. Operators changed four words in a poem hosted on GitHub to encode current command addresses; the poem changed 11 times. Lumen says the campaign reached more than 3,400 victim servers at peak scale, although another count in the report is lower, so the exact total should be treated cautiously.
Observed victim services included LiteLLM and Ollama as well as Gotenberg and Gitea. That does not make this an LLM prompt-injection incident. The report describes exposed services, exploitation, miners and scanning infrastructure. A reviewed GitHub advisory for CVE-2026-42271 records a high-severity authenticated command-execution flaw affecting LiteLLM versions from 1.74.2 up to but not including 1.83.7. It was fixed before the report, but the sources do not prove that every PoeLLM infection used that vulnerability.
Attribution remains bounded. Lumen reports language and infrastructure clues and uses moderate confidence; those clues do not identify every operator or victim. The campaign’s changing address mechanism is notable, but it should not distract from ordinary exposure, credential, patch and egress controls.
Turn the report into an ownership drill
Export externally reachable endpoints from cloud, container, DNS and vulnerability inventories. Reconcile them against actual listening services and name an owner for each one. For LiteLLM, record the running version and whether it is in the affected advisory range; do not infer safety from a package manifest alone. For Ollama, Gitea and Gotenberg, verify exposure, authentication and need.
Then test whether the security team can produce patch evidence, rotate credentials, review suspicious child processes and outbound mining traffic, and remove an unowned service. Record the required capabilities in the AI data security skill. Stop internet exposure where no business owner can justify and monitor the service.