Für viele Unternehmen ist die KI-Infrastruktur schneller gewachsen als das Sicherheitsmodell darum herum. Ein Langflow-Server für interne Agenten-Prototypen, ein MinIO-Speicher mit Standardzugang, eine Nacos-Konfiguration für Microservices, eine Datenbank mit zu weit gefassten Rechten: Für sich genommen sind das bekannte, lösbare Probleme. Der aktuelle JADEPUFFER-Fall zeigt, warum die Kombination gefährlich wird. Nach Angaben des Sysdig Threat Research Team wurde eine komplette Datenbank-Erpressung nicht nur mit KI-Unterstützung vorbereitet, sondern end-to-end von einem LLM-basierten Agenten ausgeführt.
Das ist kein Anlass für Panik. Für Security-Architekten ist es aber ein deutliches Warnsignal. Die eingesetzten Techniken waren nicht neu. Neu ist, dass ein Agent bekannte Schwachstellen, Credential-Suche, laterale Bewegung, Persistenz und destruktive Datenbankaktionen zu einer geschlossenen Operation verband — schnell, iterativ und mit auffällig viel natürlicher Sprache im eigenen Angriffscode.
Der Einstieg: alter Langflow-Bug, neue Automatisierung
Der initiale Zugriff erfolgte laut Sysdig über CVE-2025-3248 in Langflow. Langflow ist ein Open-Source-Framework zum Aufbau von LLM-Anwendungen und Agenten-Workflows. Die Schwachstelle betrifft den Endpoint /api/v1/validate/code. In Versionen vor 1.3.0 konnte ein entfernter, nicht authentifizierter Angreifer dort beliebigen Python-Code ausführen. GitHub stuft die Lücke im Advisory GHSA-c995-4fw3-j39m mit CVSS 9.8 als kritisch ein. CISA nahm CVE-2025-3248 bereits am 5. Mai 2025 in den Known Exploited Vulnerabilities Catalog auf.
Genau diese Diskrepanz ist für die Praxis relevant: Die Lücke war gepatcht, bekannt und behördlich priorisiert — und trotzdem nutzbar. Viele KI-nahe Dienste starten als schnelle interne Experimente und wandern später in produktionsnahe Umgebungen. Dort enthalten sie Provider-API-Keys, Cloud-Zugangsdaten, Datenbank-Strings oder Modellartefakte, werden aber nicht wie klassische Internet-Exposures inventarisiert.
Was der Agent tat
Nach dem Einbruch untersuchte JADEPUFFER den Langflow-Host systematisch. Sysdig beschreibt eine Suche nach Provider-Schlüsseln für KI-Dienste, Cloud-Credentials, Wallet-Informationen und Datenbank-Konfigurationen. Der Agent dumpte zudem die Langflow-eigene Postgres-Datenbank, sichtete lokale Dateien und löschte temporäre Artefakte wieder.
Besonders aufschlussreich war die MinIO-Phase. MinIO ist ein S3-kompatibler Object Store, der in Cloud-nativen und ML-nahen Umgebungen häufig für Backups, Modellartefakte, Applikationsdaten oder Terraform-State genutzt wird. JADEPUFFER fand einen erreichbaren MinIO-Dienst und nutzte die Default-Credentials minioadmin:minioadmin. Danach listete der Agent Buckets und fragte gezielt Dateien wie .env oder credentials.json ab. Als ein erster Request XML statt JSON zurückgab, passte der Agent den Parser an und wiederholte die Abfrage korrekt. Das ist mehr als ein Scan. Es ist ein Plan-Observe-Adjust-Muster.
Für Persistenz legte der Agent laut Sysdig einen Cronjob an, der alle 30 Minuten zu einer Command-and-Control-Adresse beaconte. Anschließend verlagerte sich die Operation auf das eigentliche Ziel: einen separaten, internetseitig erreichbaren Server mit MySQL und Alibaba Nacos.
Nacos, Root-Zugriff und zerstörte Konfiguration
Nacos ist ein Dienst für Service Discovery und dynamische Konfiguration in Microservice-Architekturen. Im beobachteten Fall verband sich JADEPUFFER mit Root-Zugangsdaten zur MySQL-Datenbank. Sysdig betont, dass nicht beobachtet wurde, woher diese Root-Credentials stammten. Diese Einschränkung ist wichtig. Nicht jede Lücke im Ablauf ist forensisch aufgeklärt, und seriöse Ableitungen müssen diese Grenzen benennen.
Danach griff der Agent Nacos über mehrere Wege an: über bekannte Authentifizierungs-Bypass-Muster rund um CVE-2021-29441, über einen dokumentierten Default-JWT-Signing-Key und über direkte Änderungen in der Datenbank. In einem Schritt legte er einen Admin-Account an. Als die Verifikation fehlschlug, korrigierte er die Sequenz laut Sysdig innerhalb von 31 Sekunden mit einem angepassten mehrstufigen Payload. Später prüfte er MySQL-Dateiprimitiven, Container-Hinweise und mögliche UDF-Eskalation.
Der destruktive Kern war eine Datenbank-Erpressung. Der Agent verschlüsselte laut Sysdig alle 1.342 Nacos-Konfigurationseinträge, löschte Original- und History-Tabellen und hinterließ eine Ransom-Notiz in einer Tabelle namens README_RANSOM. Besonders kritisch: Der Schlüssel wurde zufällig generiert, einmal ausgegeben, aber offenbar weder gespeichert noch an den Angreifer übertragen. Selbst eine Zahlung hätte damit vermutlich keine Wiederherstellung ermöglicht. Sysdig weist außerdem darauf hin, dass die Ransom-Notiz AES-256 behauptete, MySQLs AES_ENCRYPT() standardmäßig aber AES-128-ECB nutzt, sofern der Server nicht anders konfiguriert ist.
Warum Sysdig von einem agentischen Angriff spricht
Sysdig stützt die Einordnung als agentische Ransomware auf mehrere Beobachtungen: mehr als 600 gezielte Payloads, selbstkommentierender Code mit natürlicher Sprache, schnelle spezifische Fehlerkorrekturen und die Fähigkeit, Freitext-Kontext während der Operation zu interpretieren. The Hacker News fasst die Veröffentlichung ebenfalls als ersten dokumentierten Fall einer vollständig von einem KI-Agenten ausgeführten Ransomware-Operation zusammen.
Die Aussage sollte trotzdem sauber eingegrenzt bleiben. Die Quellen liefern starke Indizien für eine LLM-gesteuerte Ausführung. Sie belegen aber nicht, welcher Agent, welches Modell oder welche Systemprompts verwendet wurden. Auch eine behauptete Datenexfiltration blieb laut Sysdig unbestätigt. Ein Kommentar im Payload ist noch kein forensischer Nachweis für abgeflossene Daten.
Was Unternehmen konkret ändern sollten
Erstens: KI-Orchestrierung gehört ins Asset- und Exposure-Management. Langflow, Flowise, LiteLLM, interne Agenten-Gateways, Notebook-Server und Experiment-APIs dürfen nicht als „nur Dev“ unsichtbar bleiben. Unternehmen sollten Internet-Erreichbarkeit, Versionen, Authentifizierung und Reverse-Proxy-Regeln prüfen. Langflow sollte mindestens auf eine Version aktualisiert werden, die CVE-2025-3248 behebt. Code-Validierungs- oder Ausführungsendpunkte gehören nicht offen ins Internet.
Zweitens: Secrets dürfen nicht im Prozessumfeld web-erreichbarer KI-Tools liegen. Provider-Keys, Cloud-Credentials, Datenbankpasswörter und Registry-Tokens sollten über Secret Manager, kurzlebige Identitäten und minimale Scopes bereitgestellt werden. Ein kompromittierter Agenten-Builder darf nicht automatisch Zugriff auf Produktivdatenbanken, Buckets, CI/CD oder Cloud-Admin-Rechte erhalten.
Drittens: Default-Credentials sind in KI-Stacks besonders riskant, weil Agenten sie billig und skalierbar ausprobieren können. MinIO mit Standardzugang, Nacos mit Default-Signing-Key, rootfähige Datenbankzugänge oder öffentlich erreichbare Admin-Ports sind keine Randprobleme mehr. Sie werden zu bevorzugten Anschlussstellen für automatisierte Angriffsketten.
Viertens: Runtime-Detection wird wichtiger. Wenn Agenten alte Schwachstellen in hoher Breite ausnutzen, reicht Patch-Geschwindigkeit allein nicht. Erkennbar sind etwa ungewöhnliche Python-One-Liner, Cronjobs mit externen Beacon-URLs, Datenbankprozesse mit Dateioperationen, massenhaftes DROP DATABASE, Zugriffe auf .env und credentials.json oder Payloads mit auffälligen LLM-Kommentaren.
Fazit
JADEPUFFER zeigt nicht, dass Ransomware plötzlich magisch neu geworden ist. Der Fall zeigt, dass bekannte Schwachstellen und schwache Basishygiene durch Agenten-Automatisierung schneller zu vollständigen Angriffsketten werden. Für Unternehmen liegt die wichtigste Lehre deshalb nicht im Modellnamen, sondern in der Architektur: KI-nahe Infrastruktur muss wie produktive Angriffsfläche behandelt werden — inventarisiert, gepatcht, segmentiert, mit minimalen Rechten und Laufzeitüberwachung.
Quellen: Sysdig Threat Research Team: „JADEPUFFER: Agentic ransomware for automated database extortion“; The Hacker News, 2. Juli 2026; CISA Known Exploited Vulnerabilities Catalog zu CVE-2025-3248; GitHub Advisory GHSA-c995-4fw3-j39m.
