Warum agentische KI jetzt zur Angriffsflache fuer Ransomware wird

Agentische KI ist nicht deshalb sicherheitskritisch, weil sie neu klingt. Sie wird kritisch, sobald ein System nicht nur antwortet, sondern Werkzeuge ausfuehrt, Dateien liest, Zugangsdaten findet und auf interne Dienste zugreifen darf. Genau das macht den aktuellen Fall rund um Langflow fuer Unternehmen relevant.

Agentische KI macht aus bekannten Angriffen eine neue Angriffskette

Kurz gesagt sind hier drei Dinge wichtig. Erstens berichtet SecurityWeek ueber einen Angriff, bei dem eine exponierte Langflow-Instanz ueber eine kritische Schwachstelle missbraucht wurde, um einen mehrstufigen Ransomware-Ablauf zu starten. Zweitens ist daran weniger die einzelne Plattform neu als die beobachtete Logik: Ein LLM-Agent kombinierte bekannte Exploit- und Post-Exploitation-Schritte mit laufender Anpassung an die Umgebung. Drittens lautet die naechste sinnvolle Prueffrage fuer jedes Team mit Agenten-Workflows: Welche echten Rechte haben unsere Agenten bereits heute auf Tools, Secrets, Daten und interne Systeme?

Der Langflow-Fall in drei Saetzen

SecurityWeek beschreibt am 3. Juli 2026 einen von Sysdig beobachteten Angriff, bei dem eine internet-erreichbare Langflow-Instanz ueber CVE-2025-3248 kompromittiert wurde. Laut Bericht fuehrte die Schwachstelle zu beliebiger Python-Codeausfuehrung auf dem Host. Danach nutzte der Angreifer den Agenten nicht nur fuer einzelne Befehle, sondern fuer Aufklaerung, Secret-Suche, interne Netzwerkerkundung, Persistenz und spaetere seitliche Bewegung bis hin zu einer Ransomware-artigen Verschluesselung von Nacos-Konfigurationen.

Der entscheidende Punkt fuer B2B-Leser ist deshalb nicht nur „Es gab einen Angriff auf Langflow“. Wichtiger ist: Ein Agent konnte mehrere bekannte Angriffsbausteine zu einer laufend angepassten Kette zusammensetzen. Damit verschiebt sich die Sicherheitsfrage weg vom einzelnen Prompt hin zur gesamten Ausfuehrungsumgebung.

Warum Agenten Angriffe anders zusammensetzen

Klassische Automatisierung ist meist fest verdrahtet. Ein Skript bekommt definierte Eingaben und fuehrt definierte Schritte aus. Ein Chatbot beantwortet Fragen, aber er handelt ohne Zusatzschicht normalerweise nicht selbst. Ein agentisches System liegt dazwischen und darueber: Es bekommt ein Ziel, greift auf Tools zu, liest Kontext, trifft Zwischenentscheidungen und versucht Hindernisse zu umgehen oder Alternativen zu finden.

Genau deshalb kann ein Agent fuer Angreifer attraktiv werden. Er muss keine neue Magie beherrschen. Es reicht oft schon, dass er bekannte Techniken schneller verknuepft: erst Zugang bekommen, dann Dateien und Umgebungsvariablen durchsuchen, dann Konfigurationsdatenbanken auslesen, dann interne Dienste testen, dann ein guenstiges Sprungbrett fuer spaetere Verschluesselung suchen.

Im SecurityWeek-Bericht wird genau diese Kette sichtbar. Der Agent soll laut den beobachteten Payloads Secrets aus verschiedenen Dateitypen extrahiert, erreichbare interne Adressen gescannt, Zugangsdaten weiterverwendet und seine Schritte an Fehler oder neue Hinweise angepasst haben. Das ist wichtig, weil hier nicht nur „Automatisierung“ gemeint ist, sondern situatives Vorgehen innerhalb eines technischen Rahmens.

Fuer Unternehmen ist das die eigentliche Warnung. Wenn ein Agent auf dieselben Schnittstellen zugreifen darf wie ein interner Operator oder ein DevOps-Workflow, dann entsteht eine neue Angriffsoberflaeche an der Stelle, an der Modell, Tool-Aufruf und Infrastruktur zusammentreffen. Wer den Aufbau solcher Verbindungen besser verstehen will, findet die Grundlagen in API einfach erklaert: So verbinden sich Tools.

OWASP behandelt diese Entwicklung inzwischen nicht mehr nur als Randthema. Die Agent Security Initiative, die Agentic Skills Top 10 und die Uebersicht zu agentischen Bedrohungen drehen sich alle um denselben Kern: Nicht nur das Modellverhalten, sondern die Faehigkeiten des Systems muessen abgesichert werden. Dazu gehoeren Tool-Missbrauch, unnoetige Privilegien, unsaubere Speicher- und Kontextuebergaben sowie schwach kontrollierte externe oder interne Aufrufe.

Uebersetzt in Alltagssprache heisst das: Gefaehrlich wird ein Agent nicht erst dann, wenn er „besonders intelligent“ ist. Gefaehrlich wird er, wenn er zu viel darf, zu wenig beaufsichtigt wird und zu tief in echte Systeme eingreifen kann.

Wo agentische KI zur Angriffsflache wird

Der Langflow-Fall ist deshalb uebertragbar, auch wenn nicht jedes Team Langflow nutzt. Das Muster betrifft grundsaetzlich jede Agenten- oder Orchestrierungsplattform, die mehrere der folgenden Eigenschaften zusammenbringt:

• Zugriff auf Shells, Datenbanken, Dateisysteme oder Admin-Tools
• gespeicherte API-Keys, Cloud-Credentials oder Service-Tokens
• Erreichbarkeit interner Dienste aus derselben Laufzeitumgebung
• automatische Folgeaktionen ohne menschliche Freigabe
• schwaches oder lueckenhaftes Logging auf Prompt-, Tool- und Netzwerkebene

Dann entsteht leicht ein Dominoeffekt: Eine erste Schwachstelle ist nur der Einstieg. Die eigentliche Wirkung kommt danach durch Rechtevererbung und Kontextverknuepfung. Ein Agent, der Dateien lesen darf, findet vielleicht Secrets. Mit Secrets erreicht er weitere Systeme. Mit Zugang zu weiteren Systemen findet er neue Konfigurationen oder Datenbanken. Und wenn niemand eine Freigabeschwelle eingebaut hat, geht aus Analyse schnell Aktion hervor.

Gerade kleine und mittlere Teams unterschaetzen oft genau diesen Schritt. Sie sichern das Basissystem halbwegs ab, behandeln den Agenten aber als Produktivitaetshelfer statt als privilegierten Ausfuehrungspfad. Das ist gefaehrlich, weil sich viele Risiken nicht im Modell selbst, sondern in den verbundenen Berechtigungen verstecken.

Welche Kontrollen du jetzt pruefen solltest

Wenn ihr bereits Agenten testet oder produktiv nutzt, geht nicht zuerst auf Modellnamen oder Benchmark-Fragen. Prueft zuerst die operative Seite: Wer darf was ausfuehren, womit ist der Agent verbunden, und was passiert ohne menschliche Freigabe? Genau dort entscheidet sich, ob aus einer hilfreichen Automatisierung ein unnötiges Einfallstor wird.

Praktisch heisst das auch: Agenten gehoeren zuerst in klar getrennte, kleine Umgebungen mit moeglichst wenigen Rechten. Fuer Piloten und Staging-Setups sind abgeschirmte Testdaten und isolierte Umgebungen oft wertvoller als noch mehr Faehigkeiten. Dazu passt auch Mit Testdaten sicher testen: So bleiben echte Daten geschuetzt.

Ebenso wichtig ist der Schutz der menschlichen Konten rund um diese Systeme. Viele Agenten missbrauchen nicht nur Softwareluecken, sondern vor allem herumliegende Tokens, Passwoerter und Session-Artefakte. Eine einfache Basis dazu ist Konten besser schuetzen: So klappt der zweite Schutz.

Unternehmen, die das Thema ernster priorisieren wollen, koennen zusaetzlich ein formaleres Bewertungsmodell nutzen. OWASP AIVSS ist dafuer interessant, weil es KI-Sicherheitsprobleme nicht nur beschreibt, sondern strukturierter bewertbar machen will. Das ersetzt keine Architekturarbeit, hilft aber bei Priorisierung zwischen „ungewoehnlich, aber tolerierbar“ und „muss vor Produktivbetrieb geschlossen werden“.

Am Ende bleibt eine einfache Leitlinie: Behandle einen Agenten mit Tool-Zugriff nicht wie eine Suchbox, sondern wie einen neuen Operator mit Maschinenhaenden. Dann veraendert sich automatisch, wie du Rechte, Logs, Freigaben und Netzwerkgrenzen planst.

Warum Agenten Angriffe anders zusammensetzen

Der qualitative Unterschied zu klassischer Malware oder einfachen Skripten liegt nicht nur in Geschwindigkeit. Er liegt in der Verknuepfung von Verstehen, Auswahl und Ausfuehrung. Ein Scanner prueft Muster. Ein Skript fuehrt Anweisungen aus. Ein Agent kann innerhalb enger oder weiter Grenzen beurteilen, welcher naechste Schritt in der jeweiligen Umgebung am erfolgversprechendsten ist.

Das heisst nicht, dass das System „allwissend“ waere. Es bedeutet nur, dass bekannte Angriffstechniken flexibler orchestriert werden. Im SecurityWeek-Fall wird genau diese Dynamik beschrieben: Der Agent soll Informationen aus freiem Text verstanden, unterschiedliche Dateitypen verarbeitet, Zugangsdaten extrahiert, fehlgeschlagene Schritte angepasst und neue Ziele innerhalb des erreichbaren Netzes ausprobiert haben.

Das wirkt fuer Verteidiger so unangenehm, weil viele Sicherheitskontrollen historisch auf einzelne Schichten gebaut wurden. Patch-Management schuetzt die Einstiegsluecke. Identity Controls schuetzen Konten. Netzwerksegmente begrenzen Seitwaertsbewegung. Secrets-Management schuetzt Schluessel. Bei agentischen Systemen treffen diese Schichten jedoch in einem laufenden Workflow aufeinander. Schwache Kontrolle an einer Stelle kann mehrere andere Schichten entwerten.

OWASP beschreibt dieses Grundproblem aus verschiedenen Richtungen. Die Agent Security Initiative betrachtet den Agenten als eigenes Sicherheitsobjekt. Die Agentic Skills Top 10 fokussieren missbrauchsrelevante Faehigkeiten. Die Bedrohungs- und Mitigations-Uebersicht fuer agentische KI betont, dass Ziele, Tools, Memory, Identitaeten und Umgebungsrechte zusammengedacht werden muessen. Darum reicht es nicht, nur auf Prompt Injection oder Modellhalluzinationen zu schauen. In produktiven Agenten-Setups ist oft die Faehigkeitsschicht das eigentliche Risiko.

Fuer die Praxis bedeutet das: Ein Team kann ein gutes Modell, brauchbare Guardrails und saubere Prompts haben – und trotzdem ein gefaehrliches Setup betreiben, wenn der Agent ohne enge Grenzen an produktive Dateien, Datenbanken, Admin-Oberflaechen oder Konfigurationsdienste herankommt.