Kompromittierte Hosts werden zu Minern und Angriffsplattformen
Laut den Black Lotus Labs von Lumen hat eine Kryptomining-Kampagne mit der Schadsoftware PoeLLM mehr als 2.100 Server kompromittiert. Während der Hochphase beobachteten die Forschenden an einem Tag bis zu 800 gleichzeitig aktive infizierte Systeme.
Die Ergebnisse wurden am 7. Oktober 2026 um 11:04 Uhr von BleepingComputer berichtet. Black Lotus Labs zufolge ist PoeLLM mindestens seit April aktiv; aus der Angabe geht jedoch nicht hervor, auf welches Jahr sich der Beginn bezieht.
Die Kampagne richtete sich gegen Systeme in den USA und Westeuropa. Viele der identifizierten Opfer betrieben LiteLLM, Ollama, die PDF-Konvertierungssoftware Gotenberg oder das Entwickler-Toolkit Gitea mit direktem Internetzugang. Die Forschenden fanden außerdem Hinweise darauf, dass Ivanti Sentry ins Visier genommen wurde.
Mining ist nur ein Teil der Operation. PoeLLM verschafft dem Betreiber Zugriff über eine Remote-Shell und kann einen infizierten Host für HTTP/S-Scans und weitere Exploit-Versuche nutzen. Außerdem enthält die Schadsoftware die Kryptowährungs-Miner XMRig und Iron.
Black Lotus Labs beobachtete, dass kompromittierte Systeme mit Kryptex kommunizierten, einem nach Angaben der Forschenden russischen Kryptomining-Dienst. Die Forschenden gehen davon aus, dass KI- und Large-Language-Model-Umgebungen für Angreifer attraktiv sind, weil manche davon öffentlich erreichbar oder schlecht konfiguriert sind und möglicherweise über GPU-Ressourcen verfügen, die sich zum Mining eignen.
Das bedeutet nicht, dass es sich bei allen Opfern um KI-Server handelte. Zu den gemeldeten Opfern zählen auch Systeme mit Entwicklungs- und Dokumentenkonvertierungssoftware.
Ein auf GitHub gehostetes Gedicht bestimmt die C2-Adresse
PoeLLM ist eine ELF-Schadsoftware mit dem Dateinamen libgcrypt. Für die Ermittlung des Command-and-Control-Servers greift sie auf Text aus einem GitHub-Repository zu, bei dem es sich offenbar um einen Fork von Node.js handelt.
Die Schadsoftware liest vier Wörter oder Wortgruppen aus „On the Nature of Connection“, einem Gedicht in einer Datei namens dash.css. Sie verarbeitet diese Begriffe mithilfe eines fest codierten Wörterbuchs, wandelt sie in Zahlen um und erstellt daraus eine IPv4-Adresse für die Kommunikation mit dem Command-and-Control-Server.
Wird das Gedicht geändert, ändert sich auch die auf diese Weise generierte Adresse. Black Lotus Labs zufolge hatte der Betreiber das Gedicht elfmal geändert; die Forschenden vermuteten, dass mindestens eine weitere Aktualisierung erfolgt sein könnte. Außerdem beobachteten sie, dass mindestens elf C2-Server in Betrieb genommen wurden.
Bei der Analyse dieser Infrastruktur entdeckten die Forschenden auf mehreren C2-Systemen anfällige Administrationsoberflächen für Router. Black Lotus Labs vermutete, dass der Betreiber kompromittierte Router wiederverwendet haben könnte. Die verfügbaren Berichte bestätigen diese Erklärung jedoch nicht.
PoeLLM ist der Name der Schadsoftware, nicht der einer Bedrohungsgruppe. Black Lotus Labs konnte die Operation keinem bekannten Akteur mit ausreichender Sicherheit zuordnen. Mit mittlerer Sicherheit schätzten die Forschenden, dass der Betreiber aus Italien stammt. Grundlage dafür waren Kommentare in der Schadsoftware und ein in Italien gehosteter Server mit der Administrationsoberfläche.
Scans konzentrieren sich auf die Ports 3000 und 4000
Nach der Kompromittierung eines Servers kann die Operation das System nutzen, um weitere Dienste auf den Ports 3000 und 4000 aufzuspüren. In den Berichten werden diese Ports mit Gotenberg- und LiteLLM-Installationen in Verbindung gebracht.
Anschließend kann PoeLLM versuchen, CVE-2026-42271 auszunutzen, eine Sicherheitslücke zur Befehlsausführung in der MCP-Server-Testfunktion von LiteLLM. Die beobachteten Scans und die Exploit-Funktion belegen nicht, dass diese Sicherheitslücke bei allen infizierten Systemen für den Erstzugriff genutzt wurde.
Die Schwachstelle betrifft zwei Endpunkte, über die ein MCP-Server getestet werden kann, bevor seine Konfiguration gespeichert wird:
POST /mcp-rest/test/connectionPOST /mcp-rest/test/tools/list
Von LiteLLM 1.74.2 bis zu Versionen vor 1.83.7 akzeptierten beide Endpunkte eine vollständige MCP-Serverkonfiguration im Request-Body. Diese Daten konnten die Felder command, args und env enthalten, die beim stdio-Transport verwendet werden.
Erhielt ein Endpunkt eine stdio-Konfiguration, versuchte der Proxy, die angeforderte Verbindung herzustellen. Dazu startete er den übergebenen Befehl als Subprozess auf dem Host – mit den Rechten des LiteLLM-Proxy-Prozesses.
Für den Zugriff war ein gültiger Proxy-API-Schlüssel erforderlich, eine Rollenprüfung führten die Endpunkte jedoch nicht durch. Daher konnte ein authentifizierter Nutzer beliebige Befehle ausführen, selbst wenn er einen API-Schlüssel für interne Nutzer mit geringen Rechten verwendete. Die Sicherheitslücke wurde in LiteLLM 1.83.7 behoben.
CVE-2026-42271 hat einen CVSS-v3-Score von 8.8 und den Vektor CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. Als Klassifizierungen sind CWE-77, CWE-78 und ein doppelter Eintrag für CWE-78 angegeben.
Betroffene Produkte und Versionen:
- LiteLLM vor Version 1.83.7; die Beschreibung der Schwachstelle bezieht sich ausdrücklich auf Versionen ab 1.74.2 bis vor 1.83.7
- Red Hat OpenShift AI vor Version 2.25.8
Eine gemeldete Exploit-Kette umgeht die Authentifizierung
Laut BleepingComputer bestätigten Forschende von Horizon.ai, dass sich CVE-2026-42271 mit CVE-2026-48710 verknüpfen lässt, um eine nicht authentifizierte Remotecodeausführung zu erreichen.
Die Einstufung als RCE bezieht sich auf die gemeldete Exploit-Kette. Die NVD-Beschreibung zu CVE-2026-48710 dokumentiert unabhängig davon eine Schwachstelle bei der Validierung des Host-Headers und eine mögliche Umgehung von Sicherheitskontrollen. Die einzelne Schwachstelle wird darin nicht als RCE beschrieben.
CVE-2026-48710 betrifft Starlette-Versionen vor 1.0.1. In den anfälligen Versionen wurde der HTTP-Request-Header Host nicht validiert, bevor Starlette ihn zur Rekonstruktion von request.url verwendete.
Das Routing stützt sich auf den unveränderten HTTP-Pfad, während die rekonstruierte URL den übergebenen Host-Wert enthält. Ein fehlerhafter Header konnte deshalb dazu führen, dass request.url.path vom tatsächlich vom Client angeforderten Pfad abwich.
Diese Diskrepanz konnte Middleware oder Endpunkte beeinträchtigen, die Sicherheitsbeschränkungen anhand von request.url statt anhand des unveränderten scope-Pfads durchsetzen. Starlette 1.0.1 prüft den Header gemäß RFC 9112 §3.2 und RFC 3986 §3.2.2. Bei einem fehlerhaften Wert greift die Version auf scope["server"] zurück.
Die Schwachstelle hat einen CVSS-v3-Score von 6.5 und den Vektor CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N. Sie ist als CWE-444 und CWE-1289 klassifiziert.
Zu den betroffenen Produkten zählen:
- Encode Starlette vor Version 1.0.1
- Red Hat AI Inference Server bis einschließlich Version 3.3.5
- Red Hat Ansible Automation Platform 2.6
- Red Hat Migration Toolkit for Applications vor Version 8.2.0
- Red Hat OpenShift AI vor Version 3.3.5
- Red Hat OpenShift Lightspeed; in den vorliegenden Daten ist keine Version angegeben
- Red Hat Satellite 6.17
- Red Hat Enterprise Linux AI 3.0
CISA führt beide Schwachstellen als aktiv ausgenutzt
CISA nahm CVE-2026-42271 am 8. Juni 2026 in den Katalog der Known Exploited Vulnerabilities (KEV) auf. Für die betroffenen US-Bundesbehörden galt eine Frist zur Behebung bis zum 22. Juni 2026.
CISA fordert dazu auf, gemäß den Herstelleranweisungen Schutzmaßnahmen umzusetzen, bei Cloud-Diensten die einschlägigen Vorgaben aus BOD 22-01 zu befolgen oder das Produkt nicht mehr zu verwenden, falls keine Schutzmaßnahmen verfügbar sind.
CVE-2026-48710 wurde am 2. September 2026 in den KEV-Katalog aufgenommen. Für US-Bundesbehörden galt eine Frist zur Behebung bis zum 16. September 2026. CISA verlangt Schutzmaßnahmen gemäß den Herstelleranweisungen sowie die Befolgung von BOD 26-04, Prioritizing Security Updates Based on Risk und der darin enthaltenen Forensics Triage Requirements.
Die Anweisung verlangt außerdem, bei Cloud-Diensten die einschlägigen Vorgaben aus BOD 26-04 zu befolgen oder das Produkt nicht mehr zu verwenden, wenn keine Schutzmaßnahmen verfügbar sind. Verantwortliche sollten die Erreichbarkeit jedes Assets aus dem Internet bewerten und die Patch-Vorgaben aus BOD 26-04 befolgen.
Diese Fristen gelten für Bundesbehörden und nicht allgemein für jede Organisation.
Weitere Schwachstellen im Umfeld derselben Hersteller – Red Hat, LiteLLM oder Encode – wurden in den vergangenen 90 Tagen ebenfalls in den KEV-Katalog aufgenommen: CVE-2026-59822 am 2. September 2026, CVE-2015-5287 und CVE-2015-3246 am 26. August 2026 sowie CVE-2026-34486 am 4. August 2026.
Abwehrmaßnahmen sollten Exposition, Prozesse und Netzwerkdaten gemeinsam berücksichtigen
Administratoren sollten prüfen, ob LiteLLM-, Ollama-, Gotenberg-, Gitea- und Ivanti-Sentry-Dienste öffentlich erreichbar sind. Bei kritischen Systemen sollte die Erreichbarkeit aus dem Internet eingeschränkt und der externe Zugriff auf vertrauenswürdige IP-Adressen begrenzt werden.
LiteLLM-Installationen sollten auf Version 1.83.7 oder höher aktualisiert werden, um CVE-2026-42271 zu beheben. Nutzer von Starlette sollten auf Version 1.0.1 oder höher wechseln. Betreiber betroffener Red-Hat-Produkte sollten die entsprechenden Herstelleranweisungen umsetzen.
Bei der Untersuchung sind unter anderem Scans auf den Ports 3000 und 4000, unerwartet mit den Rechten des LiteLLM-Proxy-Prozesses gestartete Befehle, der Abruf von dash.css und eine ELF-Datei namens libgcrypt relevant. Dabei handelt es sich um verhaltensbezogene oder kontextuelle Hinweise, die einzeln nicht als eindeutiger Beleg für eine Kompromittierung gelten sollten.
Black Lotus Labs veröffentlichte Indikatoren für eine Kompromittierung, die bei der Auswertung von Netzwerkprotokollen helfen können. Dieser Artikel gibt die Indikatorwerte nicht wieder. Vor einer Suche anhand solcher Indikatoren sollten sich Verteidiger daher auf die von den Forschenden veröffentlichten Informationen beziehen.
Die Zuordnung zu einem Akteur sollte von der Erkennung getrennt bleiben. Die Belege stützen eine Einschätzung mittlerer Sicherheit zur möglichen italienischen Herkunft des Betreibers, aber weder eine bestätigte Identität noch die Zuordnung zu einer benannten Bedrohungsgruppe.
