Someone is using a poem on GitHub to coordinate a cryptomining botnet called PoeLLM, according to Lumen's Black Lotus Labs. Gamers, if you read that as "PoE" and thought of Path of Exile, there is some currency farming involved, but it's at the server owner's expense.
Once installed on a compromised server, the malware translates selected words from the poem into an IP address. By editing those words, its operator can point infected machines to another command-and-control server.
The compromised hosts mine cryptocurrency, with some also recruited to scan for additional victims. Lumen's Black Lotus Labs describes affected deployments running LiteLLM, Ollama, Gotenberg and Gitea in its investigation into PoeLLM. The researchers traced activity back to April 2026; The Hacker News covered their findings yesterday, October 7, 2026.
If you host these services, start with the machines running them. Include the development server you kept after a demo.
1. Check which ports are publicly reachable
On a Docker host, this read-only command lists running containers with their images and port mappings:
docker ps --format 'table {{.Names}}\t{{.Image}}\t{{.Ports}}'
The fields are documented in Docker's container listing reference.
An entry such as 0.0.0.0:4000->4000/tcp means Docker has published port 4000 on all IPv4 host addresses. Whether it is reachable from the internet also depends on your network configuration. Check IPv6 mappings too, along with any reverse proxy forwarding public requests to the service. Docker explains how published ports work].
For a server you control, test access from outside its private network. On a work deployment, ask the platform owner to verify the cloud firewall rules and public routes. Record which address they checked.
2. Check who can reach each service
If your application and Gotenberg share a Compose network, the application can call gotenberg:3000. Remove the host ports mapping when that is the only connection required. Gotenberg's maintainers explicitly advise keeping the service behind a firewall. Their installation guide shows this setup.
For a container that needs to accept calls from your local machine, bind the published port to localhost:
ports:
- "127.0.0.1:3000:3000"
Docker versions older than 28.0.0 have a documented exception that can let machines on the same local network reach localhost-published ports. Update the engine before relying on this setting. A reverse proxy or tunnel can also expose a locally bound service, so review those routes.
Lumen's report identifies Ollama on compromised servers and leaves the specific entry point for those hosts unspecified. For your own deployment, check whether changes to OLLAMA_HOST or a public proxy or tunnel have exposed the API. Ollama listens on 127.0.0.1:11434 by default, as documented in its FAQ.
After changing access, run the application's normal request and verify that direct public access is blocked. If another machine needs the service, work with whoever manages the network to provide private access.
3. Check the software version running in your deployment
Lumen links the /mcp-rest/test/connection endpoint found in one PoeLLM sample to LiteLLM vulnerability CVE-2026-42271.
The maintainer's advisory identifies affected versions as 1.74.2 up to, but excluding, 1.83.7. The flaw allowed a caller with a valid, low-privilege API key to execute commands through MCP test endpoints. Version 1.83.7 introduced the fix.
Choose a currently supported release that includes this fix and subsequent security updates. Check the package version inside the running deployment, then confirm the replacement instance is running the expected version after you deploy.
If you must delay the upgrade, the advisory provides a temporary workaround: block POST requests to both /mcp-rest/test/connection and /mcp-rest/test/tools/list at the reverse proxy or API gateway. Ensure callers cannot reach the backend directly and bypass that restriction. This will also affect workflows that use those endpoints.
For the other services in your deployment, check their own advisories against the installed versions.
4. Check for signs of compromise
Black Lotus Labs publishes PoeLLM indicators on GitHub, including command-and-control addresses and malware hashes. Compare the addresses with retained outbound connection logs, including the dates associated with each indicator. Review the period when the vulnerable service was exposed, even after you have patched it.
Investigate unexplained CPU usage alongside the processes and connections responsible for it. Resource spikes need corroboration, especially on a machine that normally runs expensive AI workloads. A search that finds no known indicators leaves gaps wherever logs are missing or the attacker has changed addresses.
If another team holds the network logs, give them the host identity and the period it was exposed. Ask them to check the published indicators and unusual outbound scanning. Keep the results with the deployment issue so the investigation has a record.
5. Check that you can isolate and rebuild the server
For a work system, involve your incident responders and coordinate isolation of the affected host. Preserve available evidence before cleanup. CISA's incident response playbook covers containment and rotating credentials where compromise is suspected.
On a server you manage yourself, restrict its network access and preserve logs before recovery. Plan to rebuild a confirmed compromised host from a trusted image, with the vulnerable service patched before reconnecting it. Revoke and replace credentials the attacker could have accessed, using a clean machine.
Give whoever handles recovery the deployed version and the configuration that exposed the service. Identify the credentials available to the affected process by name so their owners can assess and replace them.
I just started a Discord community for developers interested in security. Come chat about stories like this and share any useful resources you've found. I'd love to hear what you're seeing in your own projects. Or, just come and chat. :)
Top comments (0)