PoeLLM malware had compromised more than 3,400 servers by October 7, 2026, according to Lumen Black Lotus Labs and independent reporting. The active Canto Incognito campaign targets exposed services including LiteLLM, Ollama, Gotenberg and Gitea, then installs cryptocurrency miners and reuses infected hosts to scan for more victims. Operators should restrict exposure, patch services and investigate abnormal compute use immediately.
What is PoeLLM malware?
PoeLLM malware is a malware family that converts compromised servers into cryptocurrency miners, network scanners and exploit launchpads. Lumen Black Lotus Labs publicly disclosed the family on October 7, 2026, as the payload used by a financially motivated campaign called Canto Incognito, which remained active at the time of publication.
The name can mislead. PoeLLM isn’t malicious artificial intelligence, nor is it known to attack language models through prompts. Its connection to AI comes from the infrastructure at risk: Internet-facing model gateways and local model servers can provide attackers with valuable CPU or GPU capacity.
Once inside, the malware installs the XMRig and Iron miners and connects mining workloads to the Kryptex service, according to The Hacker News’s 2026 reporting. The stolen processing power can generate cryptocurrency for the operators while leaving the victim with higher cloud charges, slower inference and less capacity for legitimate work.
Mining is only part of the damage. BleepingComputer reported in 2026 that compromised machines also served as HTTP and HTTPS scanners and exploit servers. A neglected development endpoint can therefore become infrastructure for attacking someone else, a pattern also seen when the Carbonato botnet abused exposed Docker hosts.
How did PoeLLM malware reach more than 3,400 servers?
PoeLLM malware spread by recruiting vulnerable, Internet-accessible services from at least April through October 2026. Lumen Black Lotus Labs and independent reports placed the cumulative count above 3,400 servers on October 7, 2026, with infections concentrated mainly in the United States and Western Europe rather than evenly distributed worldwide.
The first commit to the attacker’s GitHub repository was recorded on April 13, 2026. That repository helped infected systems locate command-and-control infrastructure, but the commit date doesn’t prove that every infection phase began that day.
A useful scale check comes from the published dates. Dividing more than 3,400 compromised servers by the roughly 177 days from April 13 to October 7, 2026, gives an average exceeding 19 newly counted victims per day. Real recruitment wasn’t linear: nearly 800 infected systems were active per day at the campaign’s mid-June 2026 peak.
Published totals require care. Reporting around the October 7, 2026 disclosure updated earlier estimates of roughly 2,100 to 2,200 victims to more than 3,400, while parts of Lumen’s material reportedly retained the lower figure. The defensible reading is more than 3,400 cumulative compromises, not 3,400 simultaneously active machines.
Black Lotus Labs found the wider operation in June 2026 while investigating an Ivanti Sentry system associated with CVE-2026-10520, The Register reported. That finding doesn’t establish Ivanti Sentry as the entry point for every victim. Treating one investigated device as a universal infection vector would send defenders in the wrong direction.
Which Internet-facing services did the campaign target?
PoeLLM malware targeted exposed LiteLLM, Ollama, Gotenberg and Gitea services in 2026, while researchers also found evidence involving Ivanti Sentry. The affected set spans AI gateways, local model serving, document conversion and developer infrastructure, showing that the campaign follows reachable compute and exploitable services rather than one narrowly defined product category.
| Service | Typical role | Reported 2026 campaign connection |
|---|---|---|
| LiteLLM | Gateway and proxy for language-model APIs | Observed target |
| Ollama | Local large language model serving | Observed target |
| Gotenberg | Containerized document conversion API | Observed target |
| Gitea | Self-hosted Git service | Observed target |
| Ivanti Sentry | Mobile gateway component | Evidence of targeting; not established as every victim’s infection vector |
The mix matters. Gotenberg and Gitea aren’t large language model servers, yet both fit an attacker’s practical criteria: reachable application services, useful compute or access, and opportunities to move from one exposed system to the next. Calling Canto Incognito purely an “AI server attack” hides that broader operational risk.
Developer tooling deserves the same scrutiny as production inference endpoints. Recent incidents involving a JFrog Artifactory flaw and persistent backdoors and a critical GitLab vulnerability exploited in the wild illustrate why repositories and build systems shouldn’t sit outside normal exposure reviews.
Why does the malware use a poem on GitHub?
PoeLLM malware reads four words or phrases from a GitHub-hosted poem and maps them through an embedded dictionary to reconstruct its current command-and-control IPv4 address. This 2026 technique lets the operator redirect infected servers by editing public text, without shipping a replacement malware binary to every compromised host.
The poem isn’t a literary gimmick pasted onto ordinary command and control. It’s a compact indirection mechanism. Reporting in 2026 documented 11 poem changes and 12 identified addresses, demonstrating that the operator could rotate destinations while preserving the same lookup logic on infected machines.
GitHub isn’t alleged to be participating in the attack; its repository content was abused as a discovery channel. Defenders that block only a known command server may therefore get temporary relief while missing the stable behavior: retrieval of public content, local decoding and a subsequent connection to a newly derived IPv4 address.
Three identified command addresses were reportedly still active on October 7, 2026, even though Lumen had null-routed infrastructure visible through its own network. Honestly, a static IP blocklist is too brittle as the primary defense here. Egress policy and behavioral detection offer a longer-lived control.
How should operators detect and stop PoeLLM malware?
Operators should contain PoeLLM malware by removing unnecessary Internet exposure, requiring authentication, patching affected services and isolating containers with least privilege. In 2026, defenders should also rotate exposed credentials, restrict outbound connections and investigate unexplained CPU or GPU consumption, mining-pool traffic, broad scanning and exploit-serving behavior.
Start with the reachable service, not the malware name. An unauthenticated model endpoint or management interface can be found again after a miner is deleted. Put private workloads behind a VPN, identity-aware proxy or tightly scoped firewall rule, then verify from an external network that the original port is no longer public.
The following response order addresses both the initial exposure and the compromised host’s ability to spread:
- Inventory Internet-facing LiteLLM, Ollama, Gotenberg, Gitea and Ivanti Sentry systems, including temporary test deployments and cloud instances created outside standard provisioning.
- Remove public access where it isn’t required; otherwise enforce authentication, source restrictions and rate limits appropriate to the service.
- Apply vendor patches and review release guidance for every affected product rather than assuming a single vulnerability explains the 2026 campaign.
- Quarantine suspected hosts, preserve logs and inspect containers, processes, scheduled tasks and persistence before rebuilding from a trusted image.
- Rotate API keys, service tokens, SSH credentials and secrets accessible from the host, including credentials mounted inside containers.
- Restrict outbound access and alert on Kryptex or mining-pool connections, sustained compute saturation, Internet-wide scans and unexpected exploit traffic.
Least privilege has two layers here. Run containers without excessive host permissions, and limit the network destinations those workloads can reach. Runtime controls are increasingly part of practical AI governance for production systems, because policy documents can’t stop a hijacked container from mining or scanning.
Don’t rely on low inference traffic as proof of safety. A compromised server may show little legitimate model use while its processor remains pinned by XMRig or Iron. Compare compute, network and billing baselines against the same workload and time window; sudden sustained utilization with no matching request volume deserves immediate investigation.
Black Lotus Labs attributed Canto Incognito to an Italian-speaking actor with moderate confidence in 2026, based on Italian-language artifacts and network-flow indicators. That attribution shouldn’t change containment priorities. Researchers also observed traffic toward SSH and other login portals that might indicate brute-force experimentation, but the capability’s maturity remained uncertain in 2026.
Frequently asked questions about PoeLLM
Is PoeLLM an AI-generated virus?
PoeLLM is not reported to be an AI-generated virus. The malware’s name reflects its poem-based command-server discovery and its targeting of exposed infrastructure that includes AI services.
Does PoeLLM infect only Ollama servers?
PoeLLM affected more than Ollama deployments in 2026. Observed targets included LiteLLM, Gotenberg and Gitea, with additional evidence involving Ivanti Sentry.
Does deleting the cryptominer remove the infection?
Deleting XMRig or Iron alone doesn’t establish that a compromised host is clean. Operators should isolate the server, investigate persistence and scanning activity, rotate accessible secrets, close the original exposure and rebuild from a trusted image when integrity can’t be proven.
Was the campaign still active in October 2026?
Canto Incognito was still recruiting vulnerable Internet-facing systems when researchers disclosed the campaign on October 7, 2026. Follow-up reporting through October 12, 2026 continued to cite more than 3,400 affected servers, with no reliable substantially newer total identified by October 13, 2026.