Menschlicher Angreifer nutzt Marimo-RCE aus und erreicht SSH-Bastion in acht Sekunden

Ein menschlicher Angreifer nutzte eine kritische Authentifizierungsschwachstelle in der Marimo-Python-Notebook-Plattform aus, extrahierte Cloud-Zugangsdaten, beschaffte sich einen privaten SSH-Schlüssel und verschaffte sich innerhalb von acht Sekunden Zugriff auf einen Bastion-Host.

Sysdig beobachtete während eines etwa neun Stunden dauernden Eindringens mehr als 850 interaktive Befehle. Statt ein bekanntes Exploit-Framework oder einen KI-Agenten einzusetzen, erstellte und debugte der Angreifer eigene Python-Skripte direkt in der kompromittierten Umgebung.

Die Schwachstelle für den initialen Zugriff, CVE-2026-39987, betrifft CoreWeave-Marimo-Versionen vor 0.23.0. Sie ist bereits im Katalog der bekannten ausgenutzten Schwachstellen der US-amerikanischen Cybersecurity and Infrastructure Security Agency enthalten. Damit ist bestätigt, dass die Schwachstelle über einen theoretischen Proof of Concept hinaus ausgenutzt wird.

Nicht authentifizierter WebSocket öffnete vollständige Shell

Marimo ist eine reaktive Python-Notebook-Anwendung. In verwundbaren Versionen kann der WebSocket-Endpunkt /terminal/ws einem nicht authentifizierten Remote-Benutzer eine vollständige Pseudo-Terminal-Shell bereitstellen.

Das zugrunde liegende Problem ist eine fehlende Authentifizierung und als CWE-306 klassifiziert. Der Endpunkt überprüft den Betriebsmodus von Marimo sowie, ob die Plattform die angeforderte Terminalfunktion unterstützt. Die Authentifizierungskontrolle, die auf andere WebSocket-Routen wie /ws angewendet wird, fehlt jedoch.

Eine aus dem Internet erreichbare Instanz kann es einem Angreifer dadurch ermöglichen, ohne Zugangsdaten oder Benutzerinteraktion beliebige Betriebssystembefehle auszuführen.

Der beobachtete Angreifer verband sich von 172.236.12[.]17 mit /terminal/ws. Die Aktivitäten dauerten von 12:52 Uhr bis 21:50 Uhr an, das Kalenderdatum des Eindringens wurde jedoch nicht veröffentlicht.

NVD weist der Schwachstelle einen CVSS-v3.1-Score von 9,8 mit folgendem Vektor zu:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Diese Bewertung beschreibt eine über das Netzwerk erreichbare Schwachstelle mit geringer Angriffskomplexität, ohne erforderliche Berechtigungen und ohne Benutzerinteraktion. Mögliche Auswirkungen auf Vertraulichkeit, Integrität und Verfügbarkeit sind schwerwiegend. Ein separater Bericht nennt für die Schwachstelle einen Score von 9,3. Die Definition der betroffenen Versionen durch NVD ist jedoch genauer: CoreWeave-Marimo-Versionen vor 0.23.0.

Marimo 0.23.0 enthält die Fehlerbehebung.

Vom Notebook-Zugriff zur Bastion in Sekunden

Der Angreifer führte nicht sofort ein ausgereiftes Payload aus. Während des Eindringens schrieb, testete und korrigierte er wiederholt Python-Code und reduzierte den Ablauf schließlich auf einen einzigen im Hintergrund gestarteten python3-Befehl.

Dieser Befehl automatisierte eine fünfstufige Weiterleitung:

1. Zugangsdaten auslesen, die in der kompromittierten Marimo-Umgebung verfügbar waren.
2. Die erbeuteten AWS-Zugangsdaten verwenden, um AWS Secrets Manager abzufragen.
3. Einen gespeicherten privaten SSH-Schlüssel abrufen.
4. Den Schlüssel im lokalen Dateisystem speichern.
5. Sich bei einem SSH-Bastion-Host authentifizieren.

Die entscheidende Sequenz dauerte acht Sekunden. Um 18:57:22 stellte der Angreifer eine neue WebSocket-Verbindung her. Um 18:57:26 lieferte eine Abfrage den in der Anwendung gespeicherten AWS-Schlüssel zurück. Die SSH-Authentifizierung am Bastion-Host folgte um 18:57:30.

Dieses Timing ist aus operativer Sicht relevant. Verteidiger, die sich auf manuelle Prüfungen oder langsame Batch-Analysen verlassen, hätten nach dem ersten sichtbaren WebSocket-Ereignis kaum Gelegenheit gehabt, den Übergang zu unterbrechen. Prävention, die Isolierung von Zugangsdaten und eine automatisierte Eindämmung sind daher zuverlässiger, als darauf zu hoffen, dass ein Analyst während der Weiterleitung rechtzeitig reagiert.

Der Angreifer experimentierte außerdem mit einer Listener-Konfiguration im Stil von asyncssh, die einen von ihm kontrollierten virtuellen privaten Server einbezog. In der Befehlshistorie wurde kein erkennbares öffentliches Offensive-Toolkit identifiziert.

Schnelle Automatisierung ohne KI-Agenten

Das Eindringen ähnelt aufgrund seiner Geschwindigkeit agentenbasierten Aktivitäten. Die Beweise sprechen jedoch dafür, dass ein Mensch die individuelle Automatisierung steuerte.

Mehr als 850 interaktive Befehle sowie die sichtbare Entwicklung und Fehlerbehebung an Skripten zeigen, dass der Angreifer den Angriff aktiv verfeinerte. Sobald die erforderlichen Schritte funktionierten, fasste er sie zu einem kompakten Python-Prozess zusammen, der die Kette von den Zugangsdaten bis zur SSH-Verbindung mit Maschinengeschwindigkeit ausführen konnte.

Sysdig hatte auch automatisierte oder agentenbasierte Angreifer beobachtet, die dieselbe Schwachstelle angriffen. Diese Angreifer stießen auf eine defensive Falle, die ihren Ablauf stoppte oder störte; der menschliche Angreifer vermied sie.

Dieser Gegensatz macht eine Einschränkung von Kontrollen sichtbar, die auf vorhersehbare Automatisierung ausgelegt sind. KI-Agenten und standardisierte Tools wiederholen möglicherweise erkennbare Sequenzen, vertrauen irreführenden Antworten oder scheitern, wenn sich Annahmen über die Umgebung ändern. Ein erfahrener Mensch kann das System untersuchen, ungewöhnliches Verhalten erkennen und den Ausführungspfad ändern.

Das bedeutet nicht, dass menschliche Angreifer grundsätzlich schneller sind als autonome Systeme. Es zeigt vielmehr, dass ein Mensch nach dem Verständnis des Ziels Automatisierung vorbereiten und starten kann und dabei anpassungsfähige Einschätzungen mit nahezu sofortiger Ausführung kombiniert.

CISA hatte die Schwachstelle bereits als ausgenutzt eingestuft

CISA nahm CVE-2026-39987 am 23.04.2026 in ihren Katalog der bekannten ausgenutzten Schwachstellen auf. Die Frist zur Behebung für betroffene US-Bundesbehörden endete am 07.05.2026.

Erforderlich ist, die Maßnahmen des Herstellers anzuwenden, die für Cloud-Dienste geltenden Vorgaben des BOD 22-01 zu befolgen oder die Nutzung des Produkts einzustellen, falls keine geeigneten Maßnahmen verfügbar sind.

Der KEV-Status bedeutet, dass exponierte verwundbare Installationen nicht lediglich als potenzielles Risiko betrachtet werden dürfen. Die Ausnutzung ist dokumentiert, und der nun gemeldete Vorfall zeigt einen Weg von der Kompromittierung eines Notebooks zu sensiblen Cloud-Secrets und interner SSH-Infrastruktur.

Den verfügbaren Informationen zufolge ist keine weitere aktuelle Marimo-Schwachstelle im KEV-Katalog aufgeführt. Die unmittelbare Priorität liegt daher auf CVE-2026-39987 und allen Zugangsdaten, die über verwundbare Notebook-Instanzen offengelegt wurden.

Was Marimo-Betreiber untersuchen sollten

Administratoren sollten jede betroffene Marimo-Installation auf Version 0.23.0 oder höher aktualisieren. Der Zugriff auf /terminal/ws sollte außerdem auf Netzwerk- oder Reverse-Proxy-Ebene eingeschränkt werden, insbesondere wenn Notebook-Systeme nicht öffentlich erreichbar sein müssen.

Ein Patch allein reicht nicht aus, wenn eine Ausnutzung bereits stattgefunden haben könnte. Incident-Response-Teams sollten davon ausgehen, dass Zugangsdaten, auf die der Marimo-Prozess zugreifen konnte, abgegriffen worden sein könnten.

Empfohlene Maßnahmen:

• AWS-Zugangsdaten rotieren, die auf der betroffenen Instanz gespeichert waren oder für sie zugänglich waren.
• Den Zugriff auf AWS Secrets Manager auf unerwartete Abrufe durch Notebook-Workloads prüfen.
• Private SSH-Schlüssel widerrufen und ersetzen, auf die die kompromittierte Umgebung zugreifen konnte.
• Nach privaten Schlüsseln suchen, die unerwartet im lokalen Speicher abgelegt wurden.
• Bastion-Logs auf SSH-Zugriffe untersuchen, die unmittelbar auf Marimo-WebSocket-Sitzungen folgten.
• Verbindungen mit 172.236.12[.]17 untersuchen.
• Nach im Hintergrund gestarteten Python-Prozessen und unbekannten Listenern im Stil von asyncssh suchen.
• /terminal/ws-Verbindungen mit Cloud-API-Aufrufen, dem Abruf von Secrets, Schreibvorgängen im Dateisystem und SSH-Authentifizierungen korrelieren.

Teams sollten außerdem klären, ob Notebook-Ausführungsrollen über Berechtigungen zum Abruf von produktiven SSH-Schlüsseln verfügen. Durch den Entzug dieser Berechtigung lässt sich verhindern, dass eine Notebook-Kompromittierung zu einer infrastrukturell weitreichenden Weiterleitung von Zugangsdaten führt.

Separate Kampagnen zielen auf Redis und Dahua-Kameras

In den Berichten wurden außerdem zwei separate Operationen beschrieben, die nicht dem Marimo-Angreifer zugeschrieben wurden.

Eine Cryptomining-Kampagne kompromittierte 3.562 Redis-Server, nachdem sie nach Diensten gesucht hatte, die über den TCP-Port 6379 erreichbar waren. Die Operation nutzte den Redis-Befehl SLAVEOF, um von den Angreifern kontrollierte Inhalte zu übertragen und den XMRig-Miner zu installieren.

Zu den Opfern gehörten Redis-Versionen von 2.8.17 bis 7.2.0 sowie sowohl veraltete als auch aktuelle Linux-Umgebungen. Die gemeinsame Ursache für die Exponierung scheint eine fehlende Authentifizierung gewesen zu sein und keine Schwachstelle, die ausschließlich eine bestimmte Redis-Version betrifft.

Verteidiger sollten Redis aus dem direkten Internetzugriff entfernen, eine Authentifizierung verlangen, Replikationseinstellungen prüfen und nach unerwarteten SLAVEOF-Aktivitäten, Änderungen an Append-only-Dateien, SSH-Schlüsseln und XMRig-Prozessen suchen.

Eine weitere Kampagne, Operation CameraSwarm, kompromittierte mehr als 14.000 Dahua-IP-Kameras durch Brute-Force-Angriffe, Peer-to-Peer-Weiterleitung und die Authentifizierungs-Bypass-Schwachstellen CVE-2021-33044 und CVE-2021-33045.

Beide Dahua-Schwachstellen haben einen CVSS-Score von 9,8 und stehen seit dem 21.08.2024 im KEV-Katalog von CISA. Die Frist zur Behebung durch Bundesbehörden endete am 11.09.2024. Unternehmen müssen die Maßnahmen von Dahua umsetzen oder betroffene Geräte außer Betrieb nehmen, wenn keine geeigneten Maßnahmen verfügbar sind.