PoeLLM hides its address in a poem, but the LiteLLM flaw Lumen names was fixed 177 days before its report

177 days between the fix and the report

LiteLLM 1.83.7, the release that fixes the flaw Lumen links to the PoeLLM botnet, was uploaded to PyPI on 13 April 2026. Lumen's Black Lotus Labs published its report on 7 October 2026. That is 177 days (derived). The vendor's stable release followed on 19 April, 171 days before the report, and the GitHub advisory on 25 April, 165 days before it. The CVE record, CVE-2026-42271, came on 8 May: 152 days.

Lumen says PoeLLM, active since at least April, has hit more than 3,400 servers. Most appear to run exposed AI services, LiteLLM and Ollama, and hundreds ran Gotenberg or Gitea. It mines cryptocurrency on them and turns some into scanners. Its distinctive trick is that the address of its command server is worked out from a poem posted on GitHub. For LiteLLM, Lumen says the endpoint in one malware sample was "likely the exploitation path" for CVE-2026-42271, a command-execution flaw in LiteLLM, an open-source proxy that works as an AI gateway to model providers. CyberScoop, The Hacker News, BleepingComputer and The Register all carried the story on 7 October. This briefing reads Lumen's post in full and treats the press as pointers.

Lumen is a network operator that also sells security services. Its post says Lumen Defender customers have been protected since the discovery, and it suggests a managed secure access service as one mitigation. That is a commercial interest to note, not a reason to doubt the telemetry. It is a reason to keep what Lumen observed apart from what it recommends.

What the number does establish is narrower. For the one LiteLLM flaw Lumen names, a fix, an advisory and a CVE record were public for months before the report, and CISA listed the flaw in its Known Exploited Vulnerabilities (KEV) catalogue on 8 June, 121 days before it. The rest of this briefing sets out what Lumen states and leaves open, service by service, then the UK clock and a checklist in the order worth doing. Sources were read between about 17:50 and 18:10 BST on 7 October 2026; Lumen's text and the KEV catalogue can change.

One report, two victim counts

Four outlets reported the larger figure (The Register rounded it to more than 3,000). Lumen's own post carries two. Its key takeaways say PoeLLM has impacted more than 3,400 victim servers. Its body says almost 2,200 twice: once as the number of affected servers at the mid-June peak, and once as the total since April. BleepingComputer's correction note says the report it first received gave 2,100, and that the researchers raised the figure to 3,400 in the live report. This site's reading, which is inference, is that the headline figure was revised after the body was written and the body was not brought into line. The gap is 1,200 servers, 55 per cent more than the lower figure (derived).

Lumen's wording on the count and the peak, and what each line does not establish. Read from Lumen's post of 7 October 2026 and its Figure 2.

1. Where

   Key takeaways

   What Lumen says

   More than 3,400 victim servers; peak activity exceeding 800 active servers per day

   What it does not establish

   The counting unit (IP addresses, hosts or infections) or the period

2. Where

   Body, timeline

   What Lumen says

   At the mid-June peak, almost 2,200 affected servers, nearly 800 active per day

   What it does not establish

   Whether that is a running total at mid-June or the whole campaign

3. Where

   Body, command section

   What Lumen says

   Since April, almost 2,200 victim servers; at its peak almost 800 a day

   What it does not establish

   Anything above 2,200. It reads as a total, so it conflicts with the first row unless it is stale

4. Where

   Figure 2

   What Lumen says

   A line chart titled as active victims per day, captioned as a victim count for April to September. The top is close to 800 in mid-June; a late rise reaches about 380 in early October (read by eye)

   What it does not establish

   A cumulative total: it is a daily figure, and a September end date does not match a line that runs into October

5. Where

   Telemetry text

   What Lumen says

   Netflow showed over 1,000 additional IP addresses contacting one command address, most running AI or developer tools

   What it does not establish

   Whether an IP address is a server, or what share of the total those 1,000 are

Where	What Lumen says	What it does not establish
Key takeaways	More than 3,400 victim servers; peak activity exceeding 800 active servers per day	The counting unit (IP addresses, hosts or infections) or the period
Body, timeline	At the mid-June peak, almost 2,200 affected servers, nearly 800 active per day	Whether that is a running total at mid-June or the whole campaign
Body, command section	Since April, almost 2,200 victim servers; at its peak almost 800 a day	Anything above 2,200. It reads as a total, so it conflicts with the first row unless it is stale
Figure 2	A line chart titled as active victims per day, captioned as a victim count for April to September. The top is close to 800 in mid-June; a late rise reaches about 380 in early October (read by eye)	A cumulative total: it is a daily figure, and a September end date does not match a line that runs into October
Telemetry text	Netflow showed over 1,000 additional IP addresses contacting one command address, most running AI or developer tools	Whether an IP address is a server, or what share of the total those 1,000 are

Three points hold across every version. The peak is dated mid-June and is about 800 active servers in a day, which is a daily figure and not a total. Lumen does not state its counting unit, and counting IP addresses seen in network telemetry, as its description of the netflow work suggests, can overstate or understate servers when addresses change or sit behind a shared one (inference). And the shares are unknown: Lumen says most victims "appear" to run LiteLLM or Ollama and that hundreds ran Gotenberg or Gitea, with no split. This briefing quotes the numbers and uses neither as an estimate for any UK organisation.

The poem hides an address. It is not an attack on AI

Lumen's account of the trick is short. The malware reads a poem hosted in a repository on GitHub, picks keywords out of it, and converts them through a table built into the malware into the address of its current command server. When the operator wants a new server, the operator edits the keywords, and every infected host works out the new address by itself with no malware update. Lumen counts 11 edits since the first commit on 13 April and says the way the poem is read has not changed. This briefing gives the idea and not the scheme.

The design earns its attention. A Lumen researcher told CyberScoop that to anyone who comes across it, "this is simply a poem on GitHub", with no links, no files and no encrypted text for a scanner to flag. His point is that there is no reason to call the poem malicious without the malware that reads it. The design has a cost too, and it is on the record. Lumen lists 12 command addresses, one more than its count of edits, which fits an initial address plus 11 changes (inference). Nine had ended by publication, with observed spans of 4 to 122 days (derived from Lumen's list), and three were still active. Rotation by poem makes an address list a weak control, so the behaviours later in this briefing matter more than the indicators.

The same split between a clever disguise and an ordinary way in ran through the Cling botnet briefing. The disguise is what gets written about. The door is what a defender can still close.

How servers get in, service by service

Lumen's post names five kinds of target and gives a way in for only some of them. The table keeps stated and not stated apart.

Entry points by service, as Lumen states them (post of 7 October 2026), with what the public records read for this briefing add.

1. Service

   LiteLLM, an AI gateway

   What Lumen states

   Most victims appear to run vulnerable LiteLLM or Ollama. Scanning targets port 4000. One sample's target endpoint was likely the path for CVE-2026-42271

   Not stated

   How the exploit met the CVE's need for a valid API key; which builds victims ran

2. Service

   Ollama, a local model server

   What Lumen states

   Named with LiteLLM as the most common victim

   Not stated

   Any flaw, port or method. Ollama's FAQ says it listens on loopback by default

3. Service

   Gotenberg, a PDF converter

   What Lumen states

   Hundreds of servers, with Gitea. Scanning targets port 3000. Its install guidance warns against internet exposure

   Not stated

   Any flaw. Exposure itself looks to be the issue (inference)

4. Service

   Gitea, code hosting

   What Lumen states

   Hundreds of servers, with Gotenberg

   Not stated

   Any flaw, port or method

5. Service

   Ivanti Sentry, a mobile gateway

   What Lumen states

   Where Lumen first met the infrastructure: a compromised Sentry victim contacted a command server, then began scanning. CVE-2026-10520. Targeting is "possible"

   Not stated

   How many, and whether PoeLLM or another actor compromised the Sentry first

6. Service

   Routers, as command hosts

   What Lumen states

   Several command servers were routers with a vulnerable admin web server. CVE-2018-21027 and CVE-2018-21028 named

   Not stated

   Any evidence of exploitation (Lumen found none); who owns the routers

Service	What Lumen states	Not stated
LiteLLM, an AI gateway	Most victims appear to run vulnerable LiteLLM or Ollama. Scanning targets port 4000. One sample's target endpoint was likely the path for CVE-2026-42271	How the exploit met the CVE's need for a valid API key; which builds victims ran
Ollama, a local model server	Named with LiteLLM as the most common victim	Any flaw, port or method. Ollama's FAQ says it listens on loopback by default
Gotenberg, a PDF converter	Hundreds of servers, with Gitea. Scanning targets port 3000. Its install guidance warns against internet exposure	Any flaw. Exposure itself looks to be the issue (inference)
Gitea, code hosting	Hundreds of servers, with Gotenberg	Any flaw, port or method
Ivanti Sentry, a mobile gateway	Where Lumen first met the infrastructure: a compromised Sentry victim contacted a command server, then began scanning. CVE-2026-10520. Targeting is "possible"	How many, and whether PoeLLM or another actor compromised the Sentry first
Routers, as command hosts	Several command servers were routers with a vulnerable admin web server. CVE-2018-21027 and CVE-2018-21028 named	Any evidence of exploitation (Lumen found none); who owns the routers

The CVEs Lumen names, as recorded. Dates from CVE.org, the GitHub advisory, PyPI and CISA KEV version 2026.10.04; ages to 7 October 2026 are derived.

1. CVE and product

   CVE-2026-42271, LiteLLM command execution, CVSS 8.8. Fixed in 1.83.7

   Dates, with age

   PyPI 13 Apr (177 days); advisory 25 Apr (165); CVE record 8 May (152); KEV 8 Jun (121)

   Lumen's link to PoeLLM

   Endpoint in one sample was "likely the exploitation path"

2. CVE and product

   CVE-2026-10520, Ivanti Sentry command injection, CVSS 10.0 set by Ivanti. Fixed in R10.5.2, R10.6.2, R10.7.1

   Dates, with age

   CVE record 9 Jun (120 days); KEV 11 Jun (118)

   Lumen's link to PoeLLM

   How Lumen first met the infrastructure; Sentry targeting is "possible"

3. CVE and product

   CVE-2018-21027 and CVE-2018-21028, Boa web server: out-of-memory and memory leak

   Dates, with age

   Both records 11 Oct 2019 (2,553 days); not in KEV

   Lumen's link to PoeLLM

   Router admin page was vulnerable; no direct evidence of exploitation

CVE and product	Dates, with age	Lumen's link to PoeLLM
CVE-2026-42271, LiteLLM command execution, CVSS 8.8. Fixed in 1.83.7	PyPI 13 Apr (177 days); advisory 25 Apr (165); CVE record 8 May (152); KEV 8 Jun (121)	Endpoint in one sample was "likely the exploitation path"
CVE-2026-10520, Ivanti Sentry command injection, CVSS 10.0 set by Ivanti. Fixed in R10.5.2, R10.6.2, R10.7.1	CVE record 9 Jun (120 days); KEV 11 Jun (118)	How Lumen first met the infrastructure; Sentry targeting is "possible"
CVE-2018-21027 and CVE-2018-21028, Boa web server: out-of-memory and memory leak	Both records 11 Oct 2019 (2,553 days); not in KEV	Router admin page was vulnerable; no direct evidence of exploitation

The record for CVE-2026-42271 says the two affected test endpoints were gated only by a valid proxy API key, with no role check, so any authenticated user, including a holder of a low-privilege key, could run commands on the host. A scanner with no key could not use that on its own, and Lumen does not say how PoeLLM's exploit servers obtained one, or whether their targets ran without authentication. Other records narrow the gap without closing it. CISA lists two more LiteLLM flaws as exploited that Lumen does not mention: an SQL injection in API key verification, CVE-2026-42208, added to KEV on 8 May and fixed in the same 1.83.7 according to its record's affected range, and an authentication bypass in the MCP endpoint, CVE-2026-59822, added on 2 September and affecting builds below 1.84.0. CISA's KEV entry for a Starlette flaw, CVE-2026-48710, says it could be chained with CVE-2026-42271, and BleepingComputer reports that Horizon.ai confirmed the chain. None of this says PoeLLM uses any of them. It does say that "patched against the one CVE in the report" is not the same as "patched".

Gotenberg is the clearest case of exposure as the problem. Lumen names no flaw for it, and shows a screenshot of the installation guide, which says: "Don't expose Gotenberg to the public internet." The same sentence is on the page today. Ollama's FAQ says it binds to the loopback address by default and that the bind address is changed by a setting, so an exposed Ollama is one that someone chose to expose, or whose port a container or proxy published (inference from the FAQ; Lumen does not say how any victim was exposed). For Gitea, Lumen names no flaw and no port. CISA's catalogue lists one Gitea flaw, CVE-2026-60004, added on 25 August; Lumen does not mention it.

The command servers are the other half of the entry story. Lumen says several were routers whose admin pages ran a vulnerable Boa web server, and names CVE-2018-21027 and CVE-2018-21028 for the first of them, adding that it found no direct evidence of exploitation. Both records were published on 11 October 2019, 2,553 days before the report, and describe an out-of-memory condition and a memory leak, not code execution. NVD scores them 9.8 and 7.5, which is one more reason a score does not rank a flaw for you. The owners of those routers are victims too, and Lumen does not say anyone told them.

The dates, to scale

The diagram puts the public record and Lumen's account on one axis. Two things show. The fixed release and the advisory both sit before May, the month Lumen gives for the start of broad scanning and exploitation; the CVE record, on 8 May, sits inside it. And the first poem commit shares a date, 13 April, with the PyPI upload. No source connects the two events, and this briefing does not.

How an infected server is controlled, and where to cut it

Lumen's account of the control path is consistent across its text and its Figure 4. A scanner or an exploit server sends a crafted request to a vulnerable service, telling it to download a file from a command server. Once the payload runs, it checks in with one of several command ports and starts mining: bots have been seen contacting a Kryptex mining pool, presumably through the XMRig and Iron miners in the payload. Some victims are then conscripted as scanners and exploit servers, which is how the botnet grows. Pools of victims have recently been seen probing SSH and other login portals, which Lumen reads as experiments in distributed brute force of uncertain maturity; many of those targets were dedicated servers in Italy. Lumen assesses with moderate confidence that an Italy-based server, which contacted several command addresses and once hosted monitoring dashboards, is the actor's administrative interface.

The cut lines are where a defender has leverage that does not depend on a list of addresses. The first two are about the host, the next two about what it talks to, and the last about what it does when nobody is using it. None is a vendor instruction. Lumen's own recommendations are shorter: check logs for connections to its indicators, audit external exposure after installing new open-source tools, follow router and firewall hygiene, consider a managed secure access service, and use attack surface management.

What Lumen did, and what it left out

Lumen says it has blocked all traffic to and from the PoeLLM command servers, will keep monitoring, and that Lumen Defender customers have been protected since it found the malware. The same post lists three of 12 command addresses as still active at publication, so a block is not a takedown.

Stated and not stated, checked against Lumen's post of 7 October 2026, with CyberScoop and The Register where marked.

1. Question

   Lumen's response

   Stated

   Blocked all traffic to and from the command servers; continuing to monitor; Defender customers protected from discovery

   Not stated

   How far the block reaches, or any takedown. Three of 12 addresses were active at publication

2. Question

   Who was told

   Stated

   Nothing on this in the post

   Not stated

   Whether victims or router owners were notified, or the poem repository reported or removed

3. Question

   Where victims are

   Stated

   Predominantly the United States and Western Europe, shown on a heat map

   Not stated

   Any UK figure. The map has no scale, and Western Europe is undefined (the UN groups the UK under Northern Europe)

4. Question

   Who runs it

   Stated

   Associated with an Italian-speaking actor; Italian comments in the code; moderate confidence an Italy-based server is its admin interface

   Not stated

   Identity, group size or links to others. CyberScoop says the researchers do not know how many people are involved and have seen no links

5. Question

   The money

   Stated

   Financially motivated; XMRig and Iron miners; a Kryptex pool

   Not stated

   Which coin, hash rate or earnings, or how much GPU time was used. Lumen says GPU hardware may also have been a draw

6. Question

   Harm beyond mining

   Stated

   Remote shell, scanning, and early distributed brute force of uncertain maturity

   Not stated

   Data theft, key theft or model abuse as observed events. Lumen lists data loss, LLM jacking and lateral movement as risks of exposed AI tools, and CyberScoop reports Lumen saying other achievements remain under investigation

7. Question

   Who wrote the poem

   Stated

   Nothing in the post

   Not stated

   The Register says the researchers believe the poem was written by AI; the post does not say so

Question	Stated	Not stated
Lumen's response	Blocked all traffic to and from the command servers; continuing to monitor; Defender customers protected from discovery	How far the block reaches, or any takedown. Three of 12 addresses were active at publication
Who was told	Nothing on this in the post	Whether victims or router owners were notified, or the poem repository reported or removed
Where victims are	Predominantly the United States and Western Europe, shown on a heat map	Any UK figure. The map has no scale, and Western Europe is undefined (the UN groups the UK under Northern Europe)
Who runs it	Associated with an Italian-speaking actor; Italian comments in the code; moderate confidence an Italy-based server is its admin interface	Identity, group size or links to others. CyberScoop says the researchers do not know how many people are involved and have seen no links
The money	Financially motivated; XMRig and Iron miners; a Kryptex pool	Which coin, hash rate or earnings, or how much GPU time was used. Lumen says GPU hardware may also have been a draw
Harm beyond mining	Remote shell, scanning, and early distributed brute force of uncertain maturity	Data theft, key theft or model abuse as observed events. Lumen lists data loss, LLM jacking and lateral movement as risks of exposed AI tools, and CyberScoop reports Lumen saying other achievements remain under investigation
Who wrote the poem	Nothing in the post	The Register says the researchers believe the poem was written by AI; the post does not say so

What this means for a UK estate

Neither Lumen nor the four outlets name a UK victim or give a UK count, so what follows is inference, labelled. Lumen's map says victims are predominantly in the United States and Western Europe, with no scale. Under the UN M49 grouping the UK is in Northern Europe, and Western Europe means nine countries: Austria, Belgium, France, Germany, Liechtenstein, Luxembourg, Monaco, the Netherlands and Switzerland. Lumen does not say which grouping it uses, so its map neither places the UK in nor rules it out.

Who in the UK might run these services follows from what they are for. LiteLLM is a gateway in front of model providers, Ollama runs models on your own hardware, Gotenberg converts documents to PDF and Gitea hosts code. Lumen's researchers told The Register that AI makes tools such as LiteLLM, Ollama and Gotenberg easier to deploy, without anything checking that they are patched. The likely owners are therefore teams rather than central IT: a university research group, a start-up's engineering team, a council digital team trialling an assistant, a department's data science group (inference; no source gives a UK count or names a UK operator). That is the estate an asset register tends to miss.

Cyber Essentials gives a dated rule. The NCSC's requirements for IT infrastructure v3.3, April 2026, apply to software in scope that can accept incoming connections from internet-connected devices. They require updates that fix vulnerabilities the vendor calls critical or high risk, or that score 7 or above on CVSS v3, within 14 days of release. CVE-2026-42271 scores 8.8. Counting 14 days from the PyPI release of 13 April gives 27 April; from the stable release of 19 April it gives 3 May (derived). Lumen dates broad scanning and exploitation to May without a day. If the gateway was in scope and the rule was kept, it was on the fixed build by 3 May at the latest.

Scope is the catch. The scope text says publicly available commercial web applications are in scope by default and bespoke or custom components are not. It does not mention open-source services, so whether a self-hosted gateway is in scope is a decision to settle with the assessor (inference). The firewall requirement is plainer: block unauthenticated inbound connections by default, and have each inbound rule approved and documented.

The NCSC's vulnerability management guidance, version 2.1, reviewed 1 May 2026, sets out a policy of updating by default, a response to active exploitation and identifying your assets, which is where the checklist below starts. The free NCSC Early Warning service takes an organisation's public IP addresses and domain names and sends alerts about malware and vulnerabilities affecting its network; the NCSC says it should not be the only layer of defence. For an AI gateway with a self-hosted patch clock, see GitLab's AI Gateway has a second 9.9. For an earlier botnet that went for exposed hosts and AI keys, see the Docker botnet that installed an open source AI agent.

Cost is left out on purpose. Lumen gives no power draw, GPU utilisation, hash rate or earnings figure, and neither does any outlet, so this briefing offers no estimate of what a hijacked server cost in electricity or cloud bills. The only cost-shaped evidence is Lumen's hedged remark that GPU hardware may have been part of the appeal.

What to do, in the order worth doing

The question the count leaves

Lumen found the victims it describes in netflow telemetry on its own network, and the post does not mention any victim reporting a compromise. If one of your AI servers began talking to a botnet tonight, whose telemetry would show it first: yours, or your carrier's?

Key facts