Compromised hosts become miners and attack infrastructure
A cryptomining operation using the PoeLLM malware has compromised more than 2,100 servers, according to Lumen’s Black Lotus Labs. At peak activity, researchers observed as many as 800 infected systems active during one day.
The findings were reported by BleepingComputer on October 7, 2026, at 11:04 AM. Black Lotus Labs said PoeLLM activity dates back to at least April, but the reported starting point does not specify a year.
The campaign has targeted systems in the United States and Western Europe. Many identified victims operated internet-exposed LiteLLM, Ollama, Gotenberg PDF-conversion software, or the Gitea development toolkit. Researchers also found signs that Ivanti Sentry was being targeted.
Mining is only one part of the operation. PoeLLM gives its operator remote-shell access and can turn an infected host into a platform for HTTP/S scanning and additional exploit attempts. The malware also incorporates the XMRig and Iron cryptocurrency miners.
Black Lotus Labs observed compromised systems communicating with Kryptex, which it described as a Russian cryptomining service. The researchers assess that AI and large-language-model deployments are attractive to attackers because some are exposed or poorly configured and may have access to GPU resources suitable for mining.
That assessment does not mean every victim was an AI server. The reported victim set also includes development and document-conversion software.
A GitHub-hosted poem determines the C2 address
PoeLLM is an ELF malware sample named libgcrypt. Its command-and-control discovery process depends on text retrieved from a GitHub repository that appears to be a fork of Node.js.
The malware reads four words or phrases from “On the Nature of Connection,” a poem stored in a file called dash.css. It processes those terms through a hard-coded dictionary, converts them into numbers, and uses the result to construct an IPv4 address for command-and-control communications.
Changing the poem changes the address generated by this process. Black Lotus Labs said the operator had modified the poem 11 times and suspected that at least one further update may have occurred. The researchers also observed at least 11 C2 servers being brought online.
Analysis of that infrastructure found vulnerable router-administration interfaces on several C2 systems. Black Lotus Labs suggested that the operator may have reused compromised routers, but the available reporting does not establish that explanation as confirmed.
PoeLLM is the malware name, not the identity of a threat group. Black Lotus Labs could not confidently attribute the operation to a named actor. It assessed with moderate confidence that the operator is Italian, based on comments discovered in the malware and an Italy-based server hosting the administrative interface.
Scanning activity focuses on ports 3000 and 4000
After compromising a server, the operation can use that system to scan for additional services on ports 3000 and 4000. The reporting associates those ports with Gotenberg and LiteLLM deployments.
PoeLLM can then attempt to exploit CVE-2026-42271, a command-execution vulnerability affecting LiteLLM’s MCP server test functionality. The observed scanning and exploit capability do not establish that this vulnerability supplied initial access to every infected machine.
The flaw affects two endpoints used to preview an MCP server before its configuration is saved:
POST /mcp-rest/test/connectionPOST /mcp-rest/test/tools/list
From LiteLLM 1.74.2 to versions before 1.83.7, both endpoints accepted a full MCP server configuration in the request body. That data could contain the command, args, and env fields used by the stdio transport.
When an endpoint received a stdio configuration, the proxy attempted to establish the requested connection. In doing so, it launched the supplied command as a subprocess on the host, using the privileges assigned to the LiteLLM proxy process.
Access required a valid proxy API key, but the endpoints did not apply a role check. An authenticated user could therefore execute arbitrary commands even when using a low-privilege internal-user key. The vulnerability was patched in LiteLLM 1.83.7.
CVE-2026-42271 has a CVSS v3 score of 8.8 and the vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. Its recorded classifications are CWE-77, CWE-78, and a duplicate CWE-78 entry.
Affected products and versions are:
- LiteLLM earlier than 1.83.7, with the vulnerability description specifically covering 1.74.2 to before 1.83.7
- Red Hat OpenShift AI earlier than 2.25.8
A reported chain removes the authentication requirement
BleepingComputer reported that Horizon.ai researchers confirmed CVE-2026-42271 could be chained with CVE-2026-48710 to achieve unauthenticated remote code execution.
That RCE characterization applies to the reported chain. The NVD description for CVE-2026-48710 independently documents a Host-header validation weakness and a potential security-control bypass; it does not describe the individual vulnerability as RCE.
CVE-2026-48710 affects Starlette before version 1.0.1. In vulnerable releases, the HTTP Host request header was not validated before Starlette used it to reconstruct request.url.
Routing relies on the raw HTTP path, while the reconstructed URL incorporated the supplied Host value. A malformed header could consequently make request.url.path differ from the path that the client actually requested.
This discrepancy could undermine middleware or endpoints that enforce security restrictions through request.url instead of the raw scope path. Starlette 1.0.1 validates the header against RFC 9112 §3.2 and RFC 3986 §3.2.2, falling back to scope["server"] when it encounters a malformed value.
The vulnerability has a CVSS v3 score of 6.5 with vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N. Its classifications are CWE-444 and CWE-1289.
Affected products include:
- Encode Starlette earlier than 1.0.1
- Red Hat AI Inference Server up to and including 3.3.5
- Red Hat Ansible Automation Platform 2.6
- Red Hat Migration Toolkit for Applications earlier than 8.2.0
- Red Hat OpenShift AI earlier than 3.3.5
- Red Hat OpenShift Lightspeed, with no version specified in the supplied data
- Red Hat Satellite 6.17
- Red Hat Enterprise Linux AI 3.0
Both flaws are listed as exploited by CISA
CISA added CVE-2026-42271 to its Known Exploited Vulnerabilities catalog on 2026-06-08. Covered U.S. federal agencies had a remediation deadline of 2026-06-22.
CISA’s required action is to apply mitigations according to vendor instructions, follow applicable BOD 22-01 guidance for cloud services, or discontinue using the product if mitigations are unavailable.
CVE-2026-48710 entered the KEV catalog on 2026-09-02, with a remediation deadline of 2026-09-16 for U.S. federal agencies. CISA calls for vendor-directed mitigations while following BOD 26-04, Prioritizing Security Updates Based on Risk and its Forensics Triage Requirements.
The instruction also requires applicable BOD 26-04 guidance for cloud services or discontinuation of the product when mitigations are unavailable. Stakeholders must evaluate each asset’s internet exposure and follow the patching guidance in BOD 26-04.
Those dates are federal remediation deadlines, not general deadlines for every organization.
Other vulnerabilities associated with the same Red Hat, LiteLLM, or Encode vendor set also entered KEV during the last 90 days: CVE-2026-59822 on 2026-09-02, CVE-2015-5287 and CVE-2015-3246 on 2026-08-26, and CVE-2026-34486 on 2026-08-04.
Defensive checks should combine exposure, process and network evidence
Administrators should identify publicly reachable LiteLLM, Ollama, Gotenberg, Gitea, and Ivanti Sentry services where applicable. Critical systems should have their internet exposure reduced, with external access restricted to trusted IP addresses.
LiteLLM deployments should be upgraded to 1.83.7 or later to address CVE-2026-42271. Starlette users should move to 1.0.1 or later, while operators of affected Red Hat products should apply the corresponding vendor instructions.
Useful investigation points include scanning involving ports 3000 and 4000, commands unexpectedly launched with the LiteLLM proxy process’s privileges, retrieval of dash.css, and an ELF file named libgcrypt. These details are behavioral or contextual clues and should not be treated individually as conclusive evidence of compromise.
Black Lotus Labs shared indicators of compromise for network-log review. This article does not reproduce their values, so defenders should consult the researchers’ published material before using indicator-based searches.
Attribution should remain separate from detection. The evidence supports a moderate-confidence assessment about the operator’s possible Italian origin, not a confirmed identity or a named threat-group assignment.




