PoeLLM Malware Finds Its Command Server in a GitHub Poem and Targets Exposed AI Servers

Malware that Lumen’s Black Lotus Labs calls PoeLLM works out where to connect by reading four words from a poem hosted on GitHub, and it has affected more than 3,400 victim servers since April, according to a report the team published on October 7. Lumen says most victims appear to be running vulnerable, internet-facing AI services such as LiteLLM and Ollama, with hundreds more running the Gotenberg PDF converter and the Gitea development platform. The infected machines mine cryptocurrency and are turned into scanners that look for the next victim.

The poem is the unusual part, and it has been described in ways that need care. This report sets out what Lumen published, what I could check against its indicator file, its own figures, and public vulnerability records, and where the numbers and the labels do not match.

What PoeLLM does once it finds a server

Lumen tracks the campaign as Canto Incognito and says it first met the infrastructure while investigating a flaw in Ivanti Sentry, CVE-2026-10520. Its telemetry shows the first commit of the poem on April 13, a brief period of testing against a command server on a router in Brazil, broader scanning and exploitation from May, and a June peak of nearly 800 active servers a day. Victims are mainly in the United States and Western Europe. Lumen says it has blocked all traffic to and from the command servers and that Lumen Defender customers have been protected since it found the malware.

Several of the command servers were routers running the Boa web server with vulnerable admin pages, which Lumen says suggests the operator reuses compromised routers instead of renting servers. It assesses that the operator is Italian-speaking, citing Italian-language comments in the malware, and says with moderate confidence that a server in Italy is the actor’s administrative interface for managing the botnet.

How the poem works

The malware does not carry a fixed address. Lumen says it reads a poem titled “On the Nature of Connection”, stored in a file named dash.css in a GitHub repository owned by the user ejejejdfbbebe. The repository is a fork of the nodejs.org website source, and Lumen says the malware does not appear to have any connection to that code or site. The poem has been updated 11 times since its first commit on April 13, and each version points infected machines to a new command server.

Lumen describes the parsing as plain string matching, with the first three lookups case-insensitive. The malware extracts four words with these rules:

1. Word 1 is the text between In the silent hum of and the next comma.
2. Word 2 is the text between each pulse of and threading.
3. Word 3 is the text between Beyond the wall of and the next comma.
4. Word 4 is found by locating of distant servers, stepping back to the previous whitespace, requiring the four bytes before that word to be the , and taking the word after “the”.

Each word is then looked up in a dictionary hard-coded into the malware, and the four resulting numbers become the four parts of an IPv4 address. Lumen’s worked example comes from a sample found on June 23: driver, diode, decryption, and string map to 92, 119, 165, and 74, giving 92.119.165[.]74, an address that appears in Lumen’s indicator list with activity from July 1 to July 23. The dictionary itself is not published.

I ran those four rules, as Lumen states them, against the poem text in its Figure 5. They return driver, diode, encryption, and tick. They also pull four words out of nonsense text that merely contains the same anchor phrases, so the rest of the poem can say anything. That fits what Lumen reports: “Only the keywords have changed over the 11 iterations we have observed.” Because the dictionary is unpublished I could not compute the current address, and the check tests Lumen’s description of the rules, not the malware itself.

Why a poem? Lumen’s researchers told The Register they cannot get inside the actor’s head, but suggested a poem “serves as a perfect vehicle for hiding an important message”. They added: “To anyone who comes across it, this is simply a poem on GitHub. It has no links, no files to download, no encrypted text that could easily be flagged as malicious, even by advanced models.” They also said they believe the poem itself was written by AI.

I could not look at the repository. When I queried GitHub’s API and the profile page for ejejejdfbbebe on October 7, both returned 404 Not Found, so the poem text here comes from Lumen’s report, and the report does not say whether GitHub has acted on the account. A file on GitHub can be removed by GitHub; the Ethereum smart contract that the backdoor in our report on Wordfence’s mu-plugin discovery used as a command post cannot be removed that way. Lumen’s report does not describe what an infected PoeLLM host does if it cannot read the poem.

A poem, but not a jailbreak

The Register’s headline says “Poetry is the new AI security threat”, and its report calls this the first case of “adversarial poetry” that Lumen has seen in real-world attacks. That term already has a specific meaning. A paper posted to arXiv in November 2025, “Adversarial Poetry as a Universal Single-Turn Jailbreak Mechanism in Large Language Models” by Piercosma Bisconti and nine co-authors, tested 25 frontier models and reports an average jailbreak success rate of 62 percent for hand-crafted poems and about 43 percent for poems produced by a meta-prompt, with attack success up to 18 times higher than prose baselines when 1,200 harmful prompts were converted into verse.

In that research the poem is aimed at a model, to talk it past its safety training. Nothing like that appears in Lumen’s report, whose text never uses the words jailbreak, adversarial, or prompt. It describes an ELF binary that parses the poem with fixed string rules and a dictionary. No model reads the poem and no safety filter is involved; the poem is a pointer placed where, as the researchers put it, it looks like ordinary text. The Register’s own account of the mechanism matches Lumen’s, so the best reading is that “adversarial” is being used loosely, for a poem written to fool human reviewers and scanners. The practical exposure is the servers, not the prompts.

What the campaign does target is AI infrastructure. Lumen’s researchers told The Register it is “relatively unique in its targeting of multiple AI-related services”, unlike other campaigns this year, including the LiteLLM supply chain compromise, which focused on a single service. That compromise, in which a supply-chain gang shipped two malicious versions of the LiteLLM gateway in March, is covered in our report on Google’s TeamPCP mole.

The bugs behind the exploit

Lumen ties the LiteLLM exploit path to CVE-2026-42271, a command injection flaw in two endpoints LiteLLM uses to preview an MCP server before saving it: POST /mcp-rest/test/connection and POST /mcp-rest/test/tools/list. According to the project’s advisory, they accepted a full server configuration, including the command, arguments, and environment for a local (stdio) connection, and ran the supplied command as a subprocess on the proxy host. They were gated only by a valid proxy API key, with no role check, so a holder of a low-privilege key could run arbitrary commands. LiteLLM fixed the bug in version 1.83.7 by requiring the proxy admin role for both endpoints; NVD lists versions 1.74.2 up to but not including 1.83.7 as affected.

The timeline is short. NVD published the record on May 8, Lumen dates the operator’s broader scanning and exploitation of LiteLLM and Gotenberg to May, and CISA added the flaw to its Known Exploited Vulnerabilities catalog on June 8.

Lumen’s figures say more than its text does. The malware code shown in its Figure 9 builds a POST to /mcp-rest/test/connection with a JSON body that sets the transport to stdio and the command to python3. The Python it passes downloads a file from port 81 of the command server, path /anonymus/client, into /tmp/c using curl, then wget, then Python’s urllib as fallbacks, and makes the file executable. That matches the advisory: the endpoint is told to start a local connection that is really a download command.

Two other details in that snippet bear on the authentication question. The request routine is also passed the string a/?x=, and the code logs a hit as [VULN] with an optional (bypass) tag. The BadHost write-ups describe the Starlette flaw, CVE-2026-48710, with a Host header such as example.com/health?x=, which has the same shape as a/?x=. Lumen’s text does not say what either detail means, so this is my reading of a screenshot, not a finding by Lumen. It points toward PoeLLM using the authentication bypass that Horizon3 described, which would explain how a bug that needs a valid key is being exploited against internet-facing servers.

Horizon3 researchers report that the Starlette bug, which lets a crafted Host header make request.url.path differ from the path actually routed, can be chained with CVE-2026-42271 to give unauthenticated remote code execution on LiteLLM 1.74.2 through 1.83.6 where Starlette is 1.0.0 or earlier. They assess the chain at CVSS 10.0. NVD says Starlette fixed the flaw in 1.0.1. CISA added it to the catalog on September 2 and says in its entry that it could be chained with the LiteLLM bug.

Lumen first met the infrastructure through CVE-2026-10520, a command injection flaw in Ivanti Sentry that NVD says lets a remote unauthenticated attacker run code as root on versions before R10.5.2, R10.6.2, and R10.7.1. CISA added it to its catalog on June 11. Lumen says an Ivanti Sentry host contacted a PoeLLM command server in early June and then began scanning for other vulnerable devices, but it calls Sentry targeting only “possible” and does not say how that host was compromised. The report names no exploited flaw for Ollama, Gotenberg, or Gitea.

What to check

• LiteLLM: upgrade to 1.83.7 or later. If you cannot yet, the advisory says to block POST /mcp-rest/test/connection and POST /mcp-rest/test/tools/list at your reverse proxy or API gateway. Check the Starlette version in the same environment too: the OSTIF disclosure says to update to 1.0.1 and, in your own middleware, to read request.scope["path"] instead of request.url.path when making security decisions.
• Exposure: Gotenberg’s installation guide tells users “Don’t expose Gotenberg to the public internet. Treat it like a database: keep it behind your firewall.” Lumen’s advice is to keep auditing external exposure after installing new open-source tools and to restrict service ports as far as possible.
• Hunting: search network logs for the 12 addresses and three sample hashes in Lumen’s indicator file (three addresses were still active on October 7), downloads from port 81 and beacons to ports 3778, 5001, 5002, and 9999 from AI servers, and the Kryptex endpoints above. The malware’s file name, libgcrypt, borrows that of a real cryptography library, so match on hashes and location, not the name.
• Egress control (my suggestion, not Lumen’s): a LiteLLM, Ollama, Gotenberg, or Gitea host rarely has a reason to read arbitrary GitHub repositories or reach mining pools. An outbound allowlist would block both the poem lookup and the miners.

Where the numbers do not line up

The victim count has moved. Lumen’s key takeaways now say more than 3,400 victim servers, but its body text still says “almost 2,200” both for the peak and for the total since April. The Register, quoting the researchers, says more than 3,000, and BleepingComputer says the copy of the report it first received said 2,100 servers and that the researchers raised the figure to 3,400 in the live version. My reading is that the body text was not updated; Lumen has not said so. Peak daily activity is “exceeding 800” in the takeaways and “nearly 800” in the body.

Lumen’s Figure 2 plots active victims per day. On my reading of the chart, it peaks just under 800 in June, stays mostly below about 150 a day through September, and climbs back to somewhere between 350 and 400 at the start of October, which fits the report’s statement that the malware continues to infect new victims. The body text does not explain the October rise.

The command-server count is easier to reconcile. BleepingComputer says at least 11 were set up; Lumen lists 12 addresses, which matches the poem’s first commit plus 11 updates, or 12 versions. The date windows in that list overlap heavily, though: seven of the 12 addresses have a window covering July 20, and four cover September 20, so a single poem pointing at one server at a time does not describe everything Lumen saw. Those are first-seen and last-seen dates from telemetry, so the overlap could reflect victims that keep contacting older servers, but the report does not say.

For related coverage of attackers hiding or delegating command and control, see Cisco Talos’s CLOSEDQUORUM, a Windows implant that lets four chatbots vote on its next action, and ThreatDown’s Carbonato, a Docker botnet run by an unmodified open-source AI agent.