Lumen Black Lotus Labs zufolge hat die von ihnen PoeLLM genannte Malware seit April 2026 mehr als 3.400 Server betroffen. Sie verwandelte kompromittierte Rechner in Kryptowährungs-Miner und teilweise in Scanner für weitere Ziele. Die Forschenden nannten die Kampagne Canto Incognito. Sie erreichte internetseitig erreichbare KI-Dienste ebenso wie einen PDF-Konverter und eine Entwicklungsplattform. Für Betreiber liegt die Lehre aus dieser Mischung darin, dass der exponierte Dienst und seine Konfiguration wichtiger sind als das KI-Etikett.

Lumen veröffentlichte seine Untersuchung zu PoeLLM am 7. Oktober, wie zeitnahe Berichte von The Hacker News und The Register meldeten. Die Forschenden datieren den ersten Commit im GitHub-Repository der Kampagne auf den 13. April und geben an, dass im Mai breiteres Scannen und Ausnutzen folgten. Die Gesamtzahl zählt Server, die Lumen im Rahmen seiner Untersuchung identifiziert hat; sie ist keine Erhebung sämtlicher Installationen der genannten Produkte. Das Unternehmen sagt, die meisten beobachteten Opfer hätten offenbar verwundbare, öffentlich exponierte Dienste betrieben und sich in den USA und Westeuropa konzentriert.

Ein Gedicht als Adressbuch

PoeLLM liest ausgewählte Wörter aus einem Gedicht in einem GitHub-Repository und nutzt ein in der Malware eingebettetes Wörterbuch, um die aktuelle Command-and-Control-Adresse abzuleiten. Durch Änderungen an diesen Wörtern kann der Betreiber infizierte Systeme auf einen neuen Server ausrichten, ohne die Malware auf jedem Host zu ändern. Lumen zählte elf Änderungen am Gedicht nach dem ersten Commit. Das Gedicht diente dazu, die Infrastruktur des Betreibers zu finden; es brachte kein KI-Modell dazu, Anweisungen zu befolgen. Lumens Einschätzung, der Akteur spreche Italienisch, stützt sich auf italienischsprachige Artefakte und Netzwerkverkehr. Das ist eine Zuordnungsbewertung, keine identifizierte Person oder bestätigte Ortsangabe.

Die Forschenden berichten von XMRig- und Iron-Minern in der Malware sowie Verbindungen zur Kryptex-Mining-Infrastruktur. Außerdem beobachteten sie, wie infizierte Hosts andere exponierte Systeme scannten und angriffen. Laut Lumen verknüpfte die Netzwerktelemetrie mehr als 1.000 zusätzliche IP-Adressen mit einem frühen Command-Server. Auf dem Höhepunkt Mitte Juni beschrieb Lumen fast 2.200 betroffene Server und knapp 800, die an einem Tag aktiv waren. Die Oktober-Angabe von mehr als 3.400 ist kumulativ; die Zahlen messen zu unterschiedlichen Zeiten Verschiedenes. Später blockierte Lumen den Verkehr zu und von den identifizierten Command-Servern. The Hacker News berichtete anschließend, das Gedicht-Repository sei nicht mehr verfügbar. Diese Beobachtung allein belegt jedoch weder, dass jeder infizierte Host bereinigt wurde, noch dass der Akteur seine Aktivitäten eingestellt hat.

Das Expositionsproblem hinter der KI-Schlagzeile

Lumen nennt LiteLLM und Ollama unter den KI-bezogenen Diensten, die auf Opfer-IP-Adressen beobachtet wurden, neben Gotenberg und Gitea. Der Bericht beschreibt außerdem ein während der Untersuchung kompromittiertes Ivanti-Sentry-Gerät, behandelt eine weitergehende Zielauswahl dieses Produkts aber als Möglichkeit. Er enthält weder Opferzahlen nach Produkt noch einen vollständigen Versionsbestand oder Belege dafür, dass jede exponierte Ollama- oder LiteLLM-Instanz verwundbar war. Ein Service-Banner auf einer IP-Adresse kann bei der Identifizierung eines Systems helfen, beweist aber nicht den genauen Zugangsweg zu jedem Host.

Für einen LiteLLM-Angriffsweg liegen genauere Versionsangaben vor. Lumen fand eine Malware-Probe, die auf einen mit CVE-2026-42271 verbundenen Test-Endpunkt verwies. Die veröffentlichte Empfehlung nennt LiteLLM-Versionen ab 1.74.2 bis vor 1.83.7 als betroffen; 1.83.7 ist gepatcht. Laut Empfehlung erforderten die Test-Endpunkte einen gültigen Proxy-API-Schlüssel, verfügten aber nicht über die notwendige Rollenprüfung. Diese Bedingung ist wichtig: Die Empfehlung beschreibt authentifizierte Befehlsausführung, während Lumen die vermutete Nutzung eines Endpunkts in einer Probe schildert. Keines der Dokumente belegt, dass diese Schwachstelle jede PoeLLM-Infektion erklärt.

Gotenberg veranschaulicht ein anderes, konkretes Expositionsproblem. Sein Installationsleitfaden empfiehlt, den PDF-Konvertierungsdienst hinter einer Firewall zu betreiben. Er warnt auch, dass veröffentlichte Docker-Ports von außen erreichbar sein können, und zeigt die Bindung des Dienstes an localhost. Die Konfigurationsreferenz dokumentiert optionale Basisauthentifizierung und OIDC; beide sind in den aufgeführten Einstellungen standardmäßig deaktiviert. Betreiber sollten die tatsächlich eingesetzte Version und Bereitstellungsweise prüfen, bevor sie sich auf eine Einstellung verlassen.

The big change

Das gemeldete Ausmaß von PoeLLM macht die Internet-Exposition unterstützender Werkzeuge zu einer dringenden Inventarfrage für KI-Teams. Die Kampagne überschritt Produktkategorien, weil der Betreiber erreichbare, verwundbare Dienste suchte und infizierte Hosts wiederverwendete, um weitere Ziele zu finden. Das Gedicht erleichterte Änderungen am Command-Server, doch die dokumentierte Reaktion für Betreiber ist herkömmlich: exponierten Dienst finden, Version und Zugriffskontrollen feststellen und nach Kompromittierungsanzeichen suchen. Lumens Telemetrie stützt die Darstellung der Kampagne; sie belegt weder bestätigten Datendiebstahl noch eine Kompromittierung aller Installationen der genannten Produkte.

Eine gezielte Prüfung für Betreiber

  1. Erfassen Sie internetseitig erreichbare LiteLLM-, Ollama-, Gotenberg- und Gitea-Instanzen einschließlich temporärer Bereitstellungen. Prüfen Sie die tatsächliche Bindeadresse, Firewall- und Gateway-Regeln sowie die Frage, ob ein Zugriff aus dem öffentlichen Internet erforderlich ist.
  2. Vergleichen Sie bei LiteLLM die installierte Version und aktivierten Endpunkte mit der Empfehlung zu CVE-2026-42271. Aktualisieren Sie betroffene Installationen und prüfen Sie, wer gültige Proxy-Schlüssel besitzt. Die Empfehlung dokumentiert auch eine Gateway-Sperre für die betroffenen Test-Endpunkte, falls eine sofortige Aktualisierung nicht möglich ist.
  3. Betreiben Sie Gotenberg gemäß seinem Installationsleitfaden innerhalb des vertrauenswürdigen Netzwerks. Prüfen Sie bei Bereitstellungen mit kontrolliertem Zugriffsbedarf die entsprechenden Authentifizierungsoptionen in der Konfigurationsdokumentation.
  4. Vergleichen Sie Netzwerk- und Host-Protokolle mit den veröffentlichten Indikatoren von Lumen und untersuchen Sie unerwartete Mining-Aktivitäten, ausgehenden Command-Verkehr oder Scans. Ein Indikator-Treffer erfordert eine Prüfung des Vorfalls; ein fehlender Treffer entlastet einen Host nicht.

Quellen und weiterführende Informationen