Die kritische Schwachstelle CVE-2026-39987 (CVSS 9.3) in interaktiven Notebooks von Marimo – prä-authentifizierte Remote Code Execution über den Terminal-WebSocket-Endpunkt – wurde in den CISA-KEV-Katalog aufgenommen, mit einer Frist zur Behebung bis zum 7. Mai 2026. Nach Angaben von Sysdig hat ein qualifizierter menschlicher Operator mit eigenem Python-Werkzeugkasten, ohne jeglichen KI-Agenten, die gesamte Kette vom verwundbaren Notebook bis zur SSH-Bastion in acht Sekunden durchlaufen – ein Tempo, das Forscher zuvor ausschließlich mit automatisierten Angriffen in Verbindung brachten. Die Schwachstelle betrifft Marimo-Versionen unter 0.23.0; ein Patch ist verfügbar. Wir haben bereits früher über Schwachstellen in Marimo berichtet.
Technischer Kern der Schwachstelle
Laut dem GitHub-Sicherheitshinweis wird CVE-2026-39987 als CWE-306 klassifiziert – fehlende Authentifizierung für eine kritische Funktion. Der Endpunkt /terminal/ws in Marimo akzeptiert WebSocket-Verbindungen ohne Authentifizierungsprüfung und verschafft einem nicht authentifizierten Angreifer eine vollwertige interaktive Shell (PTY) sowie die Möglichkeit zur beliebigen Befehlsausführung.
Es ist eine Diskrepanz bei den Angaben zu verwundbaren Versionen zu beachten: Das Paketfeld im GitHub-Sicherheitshinweis nennt Versionen unter 0.23.0 als betroffen, während der detaillierte Abschnitt desselben Dokuments Marimo ≤ 0.20.4 aufführt. Version 0.23.0 ist als behoben angegeben.
Anatomie des Angriffs: neun Stunden, 850 Befehle, null öffentliche Tools
Nach Angaben von Sysdig (über ihre Untersuchung) verlief die Angriffskette wie folgt:
- 18:57:22 – Aufbau einer WebSocket-Verbindung zum verwundbaren Endpunkt
- 18:57:26 – Extraktion von AWS-Zugangsdaten aus dem Anwendungsspeicher
- 18:57:30 – SSH-Authentifizierung am Bastion-Host mithilfe eines privaten Schlüssels aus AWS Secrets Manager
Acht Sekunden vom ersten Verbindungsaufbau bis zur vollständigen Kontrolle über die Bastion. Wie Sysdig berichtet, nutzte der Operator einen einzigen Python3-Hintergrundaufruf, der in einem Skript die Zugangsdaten extrahierte, den SSH-Schlüssel aus Secrets Manager abrief, ihn auf die Festplatte schrieb und die Authentifizierung an der Bastion durchführte.
Während der neunstündigen Session (von 12:52 bis 21:50) führte der Angreifer mehr als 850 interaktive Befehle aus, ohne ein einziges bekanntes öffentliches Offensiv-Tool zu verwenden. Sämtliche Skripte wurden manuell direkt in der Session geschrieben und debuggt. Sysdig hebt besonders hervor: Der Operator umging eine Falle, in die jeder der von ihnen profilierten autonomen KI-Agenten bei einem Angriff auf dieselbe Schwachstelle tappte.
Quelle der ersten Verbindung war die IP-Adresse 172.236.12[.]17. Im Verlauf der Session richtete der Angreifer einen Listener im Stil von asyncssh auf seinem eigenen VPS ein.
Kontext: KI beschleunigt Angriffe, ersetzt aber nicht das Können
Dieser Vorfall illustriert eine wichtige These: Obwohl KI-Tools die Zeit von der Entdeckung einer Schwachstelle bis zu deren Ausnutzung verkürzen und die Einstiegshürde für weniger qualifizierte Angreifer senken, sind erfahrene Operatoren in der Lage, mit derselben Geschwindigkeit ohne Automatisierung zu agieren – und dabei Verteidigungsmechanismen noch effektiver zu umgehen. Wie Sysdig feststellt, verändert KI die Ökonomie von Angriffen (mehr Ziele, schnellere Ausnutzung, weniger Routinearbeit), hat jedoch bislang den qualifizierten Angreifer nicht ersetzt, der Werkzeuge von Grund auf entwickeln und Fallen vermeiden kann.
Parallele Kampagnen: Redis und Dahua
Kryptomining über Redis
Parallel zu den Ereignissen rund um Marimo hat Hunt.io eine Kampagne zum Kryptomining offengelegt, in deren Verlauf 3 562 Redis-Server aus einer Liste von 12 966 durch Port-6379-Scans entdeckten Hosts kompromittiert wurden. Unter den vorab ausgewählten Servern ohne Authentifizierung (2 342 Hosts) lag die Kompromittierungsrate bei 72,6 %.
Die Opfer setzten Redis-Versionen von 2.8.17 (2015) bis 7.2.0 (2023) ein sowie Linux von veralteten RHEL/CentOS 6 bis zu aktuellen Ubuntu-Kernen. Hunt.io gibt an, dass der Grund für die massenhafte Kompromittierung das Fehlen von Authentifizierung war, nicht eine Schwachstelle in einer bestimmten Redis-Version.
Die Hauptmethode war der Befehl SLAVEOF zur Manipulation der Replikation (rogue replication), über den der XMRig-Miner auf den Zielserver ausgeliefert wurde. Von vier erprobten Techniken funktionierte nur die Replikation im größeren Maßstab: Die Injektion von SSH-Schlüsseln über AOF und Versuche, aus der MongoDB-Sandbox auszubrechen, brachten in 2 810 Versuchen keinen Erfolg. Eine Kompromittierungskette über WordPress wurde festgestellt, jedoch nicht im großen Maßstab bestätigt. Die Kampagne wird keiner bekannten Gruppierung zugeschrieben.
Indikatoren einer Kompromittierung aus der Untersuchung: IP-Adressen 47.250.92[.]230, 34.166.99[.]116, 20.198.10[.]42, 188.245.99[.]156; Domain pool.moneroocean[.]stream.
Operation CameraSwarm
Laut dem Blog-Index von Hunt.io wurden im Rahmen von Operation CameraSwarm innerhalb von 35 Tagen mehr als 14 530 Dahua-IP-Kameras in der Ukraine und in Russland kompromittiert. Der Angriff nutzte Brute-Force und Schwachstellen zur Umgehung der Authentifizierung CVE-2021-33044 und CVE-2021-33045 (beide – CVSS 9.8, CWE-287) sowie eine P2P-Weiterleitungstechnik. Beide Dahua-Schwachstellen sind seit August 2024 im CISA-KEV-Katalog aufgeführt.
Auswirkungsbewertung
Am stärksten von CVE-2026-39987 gefährdet sind Organisationen, die Marimo für interaktive Berechnungen in Cloud-Umgebungen einsetzen, insbesondere wenn vom gleichen Instanzkontext aus Zugriff auf AWS Secrets Manager besteht. Die Kette „WebSocket → Zugangsdaten → SSH-Bastion“ zeigt, wie eine einzige Schwachstelle in einem Werkzeug für die Datenarbeit zur vollständigen Kompromittierung einer Cloud-Infrastruktur führen kann.
Die Kampagne gegen Redis unterstreicht das Ausmaß des Problems offener Datenbanken ohne Authentifizierung: 72,6 % der ungeschützten Server wurden kompromittiert.
Empfehlungen
- Marimo: Aktualisieren Sie umgehend auf Version 0.23.0 oder höher. Falls ein Update nicht möglich ist, blockieren Sie den Zugriff auf den Endpunkt
/terminal/wsauf Ebene der Netzwerkzugriffskontrolle - AWS: Führen Sie ein Audit der Instanzen durch, auf denen Marimo läuft, im Hinblick auf den Zugriff auf Secrets Manager. Rotieren Sie SSH-Schlüssel und AWS-Zugangsdaten, die in Secrets Manager gespeichert sind, falls die Instanz von außen erreichbar war
- Redis: Aktivieren Sie die Authentifizierung (
requirepass), beschränken Sie den Netzwerkzugriff auf Port 6379, deaktivieren Sie den BefehlSLAVEOFüberrename-command - Dahua: Aktualisieren Sie die Firmware der Geräte auf Versionen, die CVE-2021-33044 und CVE-2021-33045 beheben, und ändern Sie Standardzugangsdaten
- Prüfen Sie Ihre Netzwerkl ogs auf die genannten IOC
Der Vorfall mit Marimo ist ein anschauliches Beispiel dafür, dass auf die Erkennung automatisierter Angriffe ausgerichtete Verteidigungsstrategien nicht ausreichen: Ein qualifizierter Operator kann den Weg von der Schwachstelle zur vollständigen Kontrolle in Sekunden zurücklegen, lediglich mit eigenem Code und ohne typische Indikatoren zu hinterlassen. Priorität haben das Update von Marimo auf 0.23.0 sowie das Audit der Zugriffskette von Rechennotebooks zu den Secrets der Cloud-Infrastruktur.
