Viele Unternehmen haben in den letzten zwölf Monaten interne KI-Werkzeuge schneller ausgerollt, als ihre Sicherheitsprozesse nachgezogen haben. Ein Langflow-Server für Prototypen, ein paar API-Keys für Modellanbieter, ein Test-Connector zu AWS oder einer Datenbank, vielleicht noch ein öffentlich erreichbarer Demo-Endpunkt: Für das Produktteam ist das „nur ein AI-Builder“. Für Angreifer ist es ein Server mit Codeausführung, Credentials und oft direkter Nähe zu Produktivsystemen.
Genau dieses Muster wird gerade sichtbar. SecurityWeek und The Hacker News berichten unter Berufung auf VulnCheck, dass Angreifer CVE-2026-0768 in Langflow aktiv ausnutzen. Langflow ist eine Low-Code-Plattform zum Bau von KI-Anwendungen, Agenten und Workflows. Die konkrete Schwachstelle ist nicht neu veröffentlicht worden; neu ist die beobachtete Ausnutzung. VulnCheck meldete zunächst mehr als 50 Detektionen innerhalb weniger Stunden am 30. August 2026, später rund 360 Versuche gegen Canary-Systeme. Die beobachteten Anfragen suchten nicht nach Aufmerksamkeit, sondern nach Werten: Umgebungsvariablen, Langflow-Admin-Konfiguration, OpenAI-API-Keys, AWS-Zugangsdaten, SSH-Zugriff und Shell-Historie.
Was technisch passiert
CVE-2026-0768 ist eine kritische Code-Injection-Schwachstelle in Langflow. Die Zero Day Initiative veröffentlichte den Advisory ZDI-26-034 bereits am 9. Januar 2026. Laut ZDI liegt der Fehler in der Verarbeitung eines code-Parameters am Validate-Endpunkt: Eine vom Nutzer kontrollierte Zeichenkette werde nicht ausreichend geprüft, bevor sie zur Ausführung von Python-Code verwendet wird. Der Advisory stuft die Lücke mit CVSS 9.8 ein. Authentication ist für die Ausnutzung nicht erforderlich; erfolgreicher Missbrauch kann Code im Kontext des Root-Nutzers ausführen. ZDI nennt als zentrale Sofortmaßnahme, Interaktionen mit dem Produkt zu beschränken.
Das ist für Sicherheitsverantwortliche wichtiger als die einzelne CVE-Nummer. Ein Validate-Endpunkt klingt nach Entwicklerkomfort. In einer AI-Workflow-Plattform kann er aber zur Grenze zwischen „Prompt ausprobiert“ und „Shell auf dem Host“ werden. Wenn dieser Host zusätzlich Schlüssel für Modellanbieter, Cloud-Dienste oder Datenbanken im Prozessumfeld hält, ist die Ausnutzung nicht nur ein Applikationsproblem, sondern ein Identitäts- und Cloud-Risiko.
Die aktuellen Zahlen und Quellen
Die aktuelle Freshness kommt aus der Exploitation-Telemetrie. The Hacker News zitiert VulnCheck mit mehr als 50 Detektionen „within a few hours“ am 30. August und 360 bis Montag. SecurityWeek berichtet gleichlautend, dass die Angriffe vor allem von Russland ausgingen und bisher VulnCheck-Canaries im Vereinigten Königreich trafen. Beide Quellen nennen als beobachtete Ziele der Abfragen unter anderem LANGFLOW_SUPERUSER, OPENAI_API*, AWS_ACCESS*, AWS_SECRET*, /root/.cache/langflow/secret_key, .ssh-Zugriff und .bash_history.
Der größere Kontext stammt ebenfalls von VulnCheck. In einem eigenen Bericht zur Langflow-Angriffsfläche schreibt das Unternehmen, dass vor 2026 nur eine in freier Wildbahn ausgenutzte Langflow-Schwachstelle bekannt gewesen sei. Inzwischen habe VulnCheck elf zusätzliche Langflow-Schwachstellen als in-the-wild ausgenutzt oder gezielt angegriffen gesehen. Über bestätigte Angriffe gegen VulnCheck-Canaries hinweg seien mehr als 15.000 erfolgreiche Versuche gegen CVE-2026-0769, CVE-2025-3248 und CVE-2026-5027 beobachtet worden. Diese Zahl bezieht sich nicht auf CVE-2026-0768 allein, zeigt aber, dass Langflow für Angreifer kein exotisches Randziel mehr ist.
Wichtig ist die Einordnung: Canary-Telemetrie ist kein vollständiger Blick auf das Internet. Sie zeigt Aktivität, Absicht und Payload-Muster, aber keine globale Opferzahl. Ebenso bedeutet ein Suchtreffer auf OpenAI- oder AWS-Variablen nicht automatisch, dass ein konkretes Unternehmen kompromittiert wurde. Für Priorisierung reicht die Beobachtung dennoch aus: Angreifer suchen aktiv nach AI-Stack-Hosts, die Secrets und laterale Wege preisgeben.
Warum gerade AI-Builder attraktiv sind
Langflow und ähnliche Werkzeuge sitzen an einer ungünstigen Schnittstelle. Sie sind nah an Entwicklern, Experimenten und Modellanbietern; gleichzeitig werden sie oft wie klassische interne Tools behandelt. In der Praxis enthalten solche Umgebungen häufig API-Schlüssel für LLMs, Vektor- oder Dokumentendatenbanken, Object Stores, Git-Zugänge, Cloud-Rollen, Service-Accounts und Testdaten. Manche Instanzen werden kurzfristig öffentlich erreichbar gemacht, damit ein Team, ein Kunde oder ein Partner einen Agenten ausprobieren kann.
Damit entsteht ein Sicherheitsprofil, das eher an ein produktives Cloud-Control-Plane-System erinnert als an ein harmloses Laborwerkzeug. Ein kompromittierter AI-Builder kann Prompts und Workflows lesen, Secrets abziehen, Tools missbrauchen, interne Endpunkte scannen oder als Sprungbrett in CI/CD- und Datenumgebungen dienen. Die Angreifer in der aktuellen VulnCheck-Beobachtung scheinen genau das zu prüfen: Welche Schlüssel liegen herum, welcher Nutzer ist konfiguriert, welche SSH-Spuren existieren, welche Historie verrät Arbeitsabläufe?
Konkrete Implikationen für Unternehmen
Erstens: Inventarisieren Sie AI-Entwicklungsplattformen separat. Langflow, Flowise, LiteLLM, vLLM-Gateways, Notebook-Server, interne Agenten-UIs und MCP-nahe Dienste gehören in das gleiche Exposure-Management wie VPN, Git, CI/CD und Admin-Portale. Fragen Sie nicht nur „läuft Langflow irgendwo?“, sondern: Welche Version, welcher Netzwerkpfad, welche Authentifizierung, welche Secrets, welche ausgehenden Verbindungen?
Zweitens: Entfernen Sie Langflow-Instanzen aus dem öffentlichen Internet, wenn sie nicht explizit als gehärteter Service betrieben werden. ZDI empfiehlt wegen der Natur der Lücke die Beschränkung der Interaktion mit dem Produkt. Praktisch heißt das: nur über VPN oder Private Access, Reverse-Proxy-Auth, IP-Allowlisting, Segmentierung und keine offenen Validierungs- oder Codeausführungs-Endpunkte.
Drittens: Behandeln Sie Secrets nach einer möglichen Exposition als kompromittiert. Wenn ein verwundbarer Langflow-Host Zugriff auf OpenAI-, Anthropic-, AWS-, Datenbank-, Git- oder SSH-Zugangsdaten hatte, reicht ein Software-Update nicht. Tokens müssen rotiert, CloudTrail- und IAM-Aktivität geprüft, SSH-Keys bewertet, .bash_history- und Prozessumfeld-Spuren gesichert und ausgehende Verbindungen untersucht werden.
Viertens: Trennen Sie Build-, Experiment- und Produktionsidentitäten. Ein AI-Prototyp sollte keine produktiven Cloud-Adminrechte, keine breiten Datenbankpasswörter und keine langlebigen Modellanbieter-Keys im Klartextumfeld besitzen. Kurzlebige Identitäten, Secret Manager, rollenbasierte Scopes und egress-beschränkte Laufzeitumgebungen reduzieren den Schaden, wenn der Builder fällt.
Risiken und Limitierungen
Die aktuelle Berichterstattung beschreibt beobachtete Angriffe auf Canary-Systeme, nicht einen bestätigten Masseneinbruch bei realen Unternehmen. Auch die geografische Aussage „primär Russland“ beschreibt Quelltraffic, nicht automatisch Attribution. CVE-2026-0768 ist zudem seit Januar öffentlich dokumentiert; der neue Punkt ist die beobachtete aktive Ausnutzung und die Kombination aus AI-Builder, Root-Codeausführung und Credential-Harvesting.
Für Entscheider ist genau diese Kombination relevant. Viele Sicherheitsprogramme bewerten KI-Risiken noch über Modellverhalten, Prompt Injection oder Datenschutz. Die Angriffe auf Langflow zeigen eine banalere, aber gefährliche Ebene: Die Infrastruktur, auf der Agenten und Workflows gebaut werden, ist selbst ein hochwertiges Ziel. Sie muss gepatcht, isoliert, überwacht und mit minimalen Rechten betrieben werden.
Fazit
Langflow ist nicht „nur ein KI-Tool“. Sobald eine Instanz Code ausführen, Workflows testen und Secrets erreichen kann, ist sie Teil der kritischen Entwicklungs- und Cloud-Angriffsfläche. Die aktive Ausnutzung von CVE-2026-0768 macht das Thema akut: Prüfen Sie erreichbare Langflow-Instanzen, beschränken Sie Netzwerkzugriff, rotieren Sie potenziell exponierte Schlüssel und nehmen Sie AI-Builder in Ihr reguläres Patch- und Incident-Response-Modell auf. Der wichtigste Kontrollpunkt ist nicht der schönste Prompt, sondern die Frage, was ein kompromittierter AI-Workflow-Server im Rest Ihrer Umgebung darf.
Quellen: SecurityWeek, „Hackers Start Exploiting Critical Langflow Vulnerability“, 1. September 2026; The Hacker News, „Attackers Exploit Critical Langflow and Rails Flaws in Credential-Probing and C2 Activity“, 1. September 2026; VulnCheck, „Same Target, Different Playbooks: Two Attackers, Two Different Paths to Pwning the AI Stack“; Zero Day Initiative, ZDI-26-034 / CVE-2026-0768, 9. Januar 2026.
