Die CVE-Welle 2026: Warum Ihr selbstgehosteter KI-Stack Patch-Management braucht

Die Entscheidung für einen selbstgehosteten KI-Stack fällt fast immer aus demselben Grund: Die Daten sollen im Haus bleiben. Das ist richtig, und es funktioniert. Nur wird dabei regelmäßig eine zweite Rechnung übersehen. Wer On-Premise betreibt, übernimmt nicht nur die Datenhoheit, sondern auch die Betriebsverantwortung – und die heißt bei Software, die im Wochentakt Sicherheitslücken meldet, schlicht Patch-Management.

2026 hat gezeigt, wie ernst das gemeint ist. Nicht in Form eines einzelnen spektakulären Vorfalls, sondern als Kadenz: Langflow zweimal im KEV-Katalog der US-Behörde CISA binnen vier Monaten, Open WebUI mit zwei Sammel-Batches innerhalb von zwei Wochen, kritische Remote-Code-Execution in gleich mehreren Agenten-Frameworks im Juli. Dieser Artikel ordnet die Lage ein, liefert eine Versionsmatrix zum Abgleich und beschreibt einen Patch-Prozess, der zu KI-Komponenten passt.

Zwei KEV-Einträge in vier Monaten: der Fall Langflow

Langflow ist ein visueller Flow-Builder für LLM-Anwendungen – man klickt Ketten aus Prompt-Bausteinen, Tools und Modellen zusammen, statt sie zu programmieren. Genau das macht ihn beliebt für Prototypen und genau das ist die Angriffsfläche: Ein System, dessen Kernfunktion die Ausführung nutzerdefinierter Logik ist, muss diese Ausführung sauber einsperren.

CVE-2026-33017 zeigt, was passiert, wenn das nicht gelingt. Über POST /api/v1/build_public_tmp/{flow_id}/flow landen angreiferkontrollierte Flow-Daten ungesandboxed in einem exec()-Aufruf. Keine Authentifizierung erforderlich. CVSS v3.1: 9.8, CVSS v4: 9.3. Betroffen sind alle Versionen bis einschließlich 1.8.2.

Bemerkenswert ist weniger die Lücke selbst als die Geschwindigkeit danach. Das Advisory erschien am 17.03.2026 um 20:05 UTC. Die erste beobachtete Ausnutzung in freier Wildbahn erfolgte am 18.03.2026 um 16:04 UTC – rund 20 Stunden später, und zu einem Zeitpunkt, an dem noch kein öffentlicher Proof-of-Concept existierte. In den Stunden 20 bis 21 nach Veröffentlichung waren vier unterschiedliche Quell-IPs mit automatisierten nuclei-Payloads unterwegs, ab Stunde 24 kamen Operatoren mit eigenen Python-Skripten dazu.

Am 25.03.2026 nahm die CISA die Schwachstelle in den KEV-Katalog auf; die Patch-Frist für US-Bundesbehörden nach BOD 22-01 lief bis zum 08.04.2026. Rund 7.000 aus dem Internet erreichbare Langflow-Instanzen wurden zu diesem Zeitpunkt identifiziert, mehrheitlich in Nordamerika.

Post-Exploitation: es geht um Ihre Schlüssel

Das beobachtete Muster nach erfolgreicher Ausnutzung war über die Kampagnen hinweg konsistent: Shell-Befehl über Pythons os.popen() ausführen, Ausgabe per HTTP exfiltrieren. Ziel waren Umgebungsvariablen und KI-Service-Credentials – OpenAI-, Anthropic- und AWS-Keys. Der Flow-Builder war nicht das Ziel, sondern das Sprungbrett in die verbundene Cloud-Infrastruktur. Wer seinen On-Premise-Stack für einzelne Aufgaben mit externen APIs verbindet, exportiert über einen kompromittierten Host also genau die Bindeglieder, die er eigentlich schützen wollte.

Die Patch-Falle: 1.8.2 war nicht gepatcht

Der eigentlich lehrreiche Teil kommt danach. JFrog Security Research zeigte am 26.03.2026, dass die als behoben gemeldete Version 1.8.2 weiterhin ausnutzbar war – der öffentliche PoC funktionierte sowohl auf PyPI- als auch auf Docker-Installationen. Sowohl die NVD als auch die GitHub Advisory Database führten 1.8.2 fälschlich als „fixed". Den echten Fix enthielt erst 1.9.0 beziehungsweise langflow-base 0.9.0.

Am 07.07.2026 folgte der zweite KEV-Eintrag: CVE-2026-55255, Authorization Bypass through User-Controlled Key (IDOR), CVSS 6.1. Ein authentifizierter Angreifer kann beliebige Flows anderer Nutzer ausführen. Die Frist für Bundesbehörden endete bereits am 10.07.2026. Die zugehörige Kampagne lief vom 22. bis 25.06.2026, wurde als „opportunistisch und finanziell motiviert" eingestuft und zielte erneut auf LLM-Provider- und AWS-Keys. Ein CVSS-Wert von 6,1 klingt harmlos – im KEV-Katalog steht er trotzdem, weil er nachweislich ausgenutzt wurde. Priorisierung allein nach Score hätte diese Lücke liegen lassen.

Ergänzend meldete Tenable am 27.03.2026 mit CVE-2026-5027 eine Path-Traversal-Schwachstelle (CWE-22) im Endpunkt POST /api/v2/files über einen unsanitisierten filename-Parameter, CVSS 8.8 – hier allerdings mit erforderlichen niedrigen Rechten (PR:L), also nicht unauthentifiziert.

Open WebUI: zwei Sammel-Batches in zwei Wochen

Open WebUI ist für viele Mittelständler das Gesicht der internen KI: die Chat-Oberfläche vor dem lokalen Modellserver, oft mit RAG-Anbindung und Nutzerverwaltung. Entsprechend viel Angriffsfläche steckt in ihr – Datei-Uploads, Web-Loader, Terminal-Integration, OAuth, Realtime-Verbindungen.

Am 24.07.2026 erschien ein erster Sammel-Batch von rund zehn CVEs im Bereich CVE-2026-59212 bis CVE-2026-59225, behoben in Version 0.10.0. Ein instruktives Beispiel ist CVE-2026-59221 (CVSS 7.7), ein Path Traversal im Terminal-Proxy: Die Sanitisierung dekodiert die URL wiederholt, bricht aber nach acht unquote()-Durchläufen ab. Eine neunte Encoding-Schicht überlebt die Prüfung und erreicht den Terminal-Server dekodiert. Solche Fehler entstehen nicht aus Schlamperei, sondern aus einem falschen Modell davon, wie oft ein Angreifer kodieren darf.

Am 04.08.2026 folgte der zweite Batch: 16 CVEs, CVE-2026-70479 bis CVE-2026-70494, alle behoben in Open WebUI 0.11.0. Darin unter anderem:

• CVE-2026-70482 (High): Account-Takeover über den OAuth-Token-Exchange.
• CVE-2026-70486 (High): XSS in der Terminal-Komponente, eskalierbar zum Account-Takeover.
• CVE-2026-70492 (High): Stored XSS über einen KaTeX-Render-Fehler – ein präparierter Formelausdruck genügt.
• CVE-2026-70479 (High): SSRF ins interne Netz über den Playwright-Web-Loader.
• CVE-2026-70485 (High): Zugriff auf interne Ziele über NAT64-kodierte URLs – ein klassischer Bypass jeder naiven SSRF-Blockliste.
• CVE-2026-70487 (CVSS 5.3): Cross-User-Dateizugriff über inline definierte Modelle mit fremder Knowledge-Referenz; betroffen 0.8.8 bis 0.10.x.

Zwei Batches in zwei Wochen bedeuten in der Praxis zwei Pflicht-Upgrades: erst auf 0.10.0, dann auf 0.11.0. Wer sein Wartungsfenster auf ein Quartal legt, hat dazwischen elf Tage lang eine Version betrieben, die zu diesem Zeitpunkt bereits als anfällig dokumentiert war.

Dify und Open WebUI: wo die Mandantengrenze fällt

Bei RCE-Lücken ist die Dringlichkeit unstrittig. Unterschätzt werden die leiseren Fehlerklassen – jene, bei denen niemand Code ausführt, sondern nur Daten sieht, die ihm nicht gehören. In einem KI-System ist das besonders heikel, weil die Wissensbasis pro Abteilung oder Mandant getrennt sein sollte und der Zugriff über Modell-, Knowledge- und Dateireferenzen erfolgt statt über klassische Dateirechte.

Für Dify, die Low-Code-Plattform für LLM-Anwendungen, wurden am 18.05.2026 zwei kritische Schwachstellen veröffentlicht: CVE-2026-41947 (Authorization Bypass) und CVE-2026-41948 (Path Traversal für authentifizierte Nutzer). Betroffen sind Version 1.14.1 und früher; die Folgeversion 1.14.2 enthält den Fix. Kein Einzelfall: Die GitHub Advisory Database führt für Dify insgesamt 31 Advisories – 4 kritisch, 6 hoch, 8 mittel, 1 niedrig – im Zeitraum März 2025 bis August 2026.

Auf der Open-WebUI-Seite gehört CVE-2026-70487 in dieselbe Kategorie: Über ein inline definiertes Modell mit einer Knowledge-Referenz, die einem anderen Nutzer gehört, ließ sich fremder Dateiinhalt lesen. CVSS 5.3 – „mittel". Für ein System, in dem Personalakten und Konstruktionsunterlagen indexiert sind, ist es das nicht. Deshalb gilt: Schweregrade aus dem CVSS-Vektor sind eine Vorsortierung, keine Risikobewertung. Die Risikobewertung kennt nur, wer weiß, was in der eigenen Wissensbasis liegt.

Kritische RCEs in Agenten-Frameworks

Ein KI-Agent ist per Definition Software, die Werkzeuge aufruft – Code ausführen, SQL absetzen, Dateien schreiben, Webseiten abrufen. Die Sicherheitsgrenze eines Agenten-Frameworks ist damit immer eine Sandbox, und Sandboxen brechen. Der Juli 2026 lieferte dafür reichlich Belege.

PraisonAI verzeichnete allein im Juli 2026 25 Advisories. Herausragend: CVE-2026-61447 (Critical), eine Remote Code Execution im CodeAgent, veröffentlicht am 11.07.2026 und betreffend alle Versionen vor 1.6.78. Dazu kamen CVE-2026-61445 (arbitrary file write) und CVE-2026-60090.

Langroid meldete am 06.07.2026 vier CVEs auf einen Schlag, drei davon kritisch:

• CVE-2026-54769: Sandbox-Escape zu RCE durch eine unvollständige Absicherung von eval().
• CVE-2026-55615: Der Neo4jChatAgent führt LLM-generierte Cypher-Queries ohne Validierung aus – Prompt Injection wird zur Datenbankmanipulation.
• CVE-2026-54760: Die Blockliste gefährlicher Funktionen im SQLChatAgent ist umgehbar.
• CVE-2026-54771 (High): handle_message() führt Tool-JSON ohne Prüfung des Absenders aus.

Zuvor waren dort bereits CVE-2026-25879 (27.05.2026, Prompt-to-SQL-Injection mit RCE) und CVE-2026-25481 (02.02.2026, WAF-Bypass zu RCE im TableChatAgent) aufgeschlagen. Bei Crawl4AI, häufig als Ingest-Komponente für RAG-Pipelines im Einsatz, sind CVE-2026-56260 (arbitrary file write im Docker-API-Server, behoben in 0.8.7) und CVE-2026-56259 (Credential-Exfiltration, behoben in 0.8.8) zu nennen – beide „High".

Auffällig ist das wiederkehrende Muster: Blocklisten statt Allowlisten, eval() mit nachträglicher Absicherung, LLM-Ausgaben, die ohne Validierung in eine Ausführungsschicht laufen. Genau das ist der Punkt, an dem Guardrails und Red-Teaming aufhören, Kür zu sein. Und es ist der Grund, warum Agenten-Frameworks in die Asset-Inventur gehören und nicht in den Zufall dessen, was ein Entwickler vor sechs Monaten per pip install in ein Image gezogen hat. Vergleichbares gilt für die MCP-Ebene, über die Agenten heute an Werkzeuge angebunden werden.

99,9 Prozent bleiben ungepatcht

Dass all das bekannt ist, heißt nicht, dass es behoben wird. Der 2026 State of AI Security Report von Orca Security erschien am 09.07.2026 (breite Fachpresse-Rezeption am 13.07.2026) und basiert auf anonymisierter Telemetrie der Orca Cloud Security Platform aus über 1.200 Produktionsorganisationen im zweiten Quartal 2026, erhoben über AWS, Azure und Google Cloud.

Kennzahl	Wert 2026	Vergleich / Kontext
KI-Schwachstellen-Alerts mit verfügbarem Fix, die ungepatcht bleiben	99,9 %	Fix liegt vor, wird nicht eingespielt
Organisationen mit KI-Paketen und mindestens einer bekannten Schwachstelle	81,2 %	2024: 62 %
Organisationen mit mindestens einem kritischen CVE	74,1 %	–
Durchschnittlicher CVSS-Score betroffener KI-Pakete	8,79	2024: 6,9
KI-Paket-Schwachstellen mit öffentlich verfügbarem Exploit	50 %	250-fache Steigerung ggü. 2024
KI-Anwender mit Agenten-Frameworks in Produktion	56 %	51,5 % bauen eigene KI-Anwendungen
Organisationen mit Vektordatenbanken	64 %	Ø 3,78 pro RAG-nutzender Organisation
KI-Workloads ohne kundenverwaltete Verschlüsselungsschlüssel	87–98 %	30 % lagern mind. einen API-Key unsicher

Die aussagekräftigste Zahl in dieser Tabelle ist nicht die 99,9, sondern der Sprung des durchschnittlichen CVSS-Scores von 6,9 auf 8,79 bei gleichzeitiger Ver-250-fachung öffentlich verfügbarer Exploits. Das Angebot an Angriffscode wächst schneller als die Fähigkeit der Betreiber, es zu neutralisieren. Ergänzend: Über die Hälfte der Organisationen betreibt vier oder mehr verschiedene KI-Dienste parallel – der Stack ist also nicht eine Komponente, sondern ein Bündel, das komplett gepflegt werden will.

Bemerkenswert ist auch, was die Zahlen nicht sagen. Kein einziger dieser Punkte beschreibt ein technisch ungelöstes Problem. Für jede der genannten Lücken gab es zum Erhebungszeitpunkt eine Fixversion. Das Problem ist organisatorisch: fehlendes Inventar, unklare Zuständigkeit, kein Wartungsfenster.

Ein KI-spezifischer Patch-Prozess

Klassisches Patch-Management deckt Betriebssystem, Datenbank und Webserver ab. KI-Komponenten fallen dort meist durch, weil sie als Container ohne Paketmanager laufen, als Python-Abhängigkeiten in einem Image stecken oder von einer Fachabteilung eingeführt wurden. Sechs Bausteine schließen die Lücke.

1. Asset-Inventur bis auf Framework-Ebene

Erfassen Sie jede Komponente mit Name, Version, Betriebsort, fachlichem Owner und technischem Owner. Das umfasst nicht nur Chat-UI und Modellserver, sondern auch Flow-Builder, Agenten-Frameworks, Web-Crawler, Gateways und die Docker-Images, in denen sie stecken. Die Faustregel: Was Code ausführt oder Netzwerkverbindungen aufbaut, gehört ins Inventar.

2. SBOM für den KI-Stack

Erzeugen Sie eine Software Bill of Materials im CycloneDX- oder SPDX-Format – automatisiert im Build, nicht per Excel. Sie muss Frameworks, Gateways, Vektordatenbank, Inferenz-Engine und die eingesetzten Modellversionen umfassen. Ohne SBOM beantworten Sie die Frage „Sind wir von CVE-2026-70487 betroffen?" mit Nachsehen statt mit Nachschlagen.

3. Versionsmatrix mit Fixversion und Prüfdatum

Eine Tabelle pro Komponente: eingesetzte Version, bekannte Fixversion, zugehörige CVE, Datum der letzten Prüfung. Sie ist der Kern des Prozesses, weil sie den Zustand einfriert und Verantwortung sichtbar macht.

Komponente	Betroffen bis	Fixversion	Leit-CVE
Langflow	≤ 1.8.2 (auch 1.8.2!)	1.9.0 / langflow-base 0.9.0	CVE-2026-33017 (9.8, KEV)
Open WebUI (Batch 1)	< 0.10.0	0.10.0 (24.07.2026)	CVE-2026-59221 (7.7)
Open WebUI (Batch 2)	< 0.11.0	0.11.0 (04.08.2026)	CVE-2026-70479 … 70494
Dify	≤ 1.14.1	1.14.2	CVE-2026-41947 / -41948
PraisonAI	< 1.6.78	1.6.78	CVE-2026-61447 (Critical)
Langroid	Stand vor 06.07.2026	aktuelle Release-Linie	CVE-2026-54769 / -55615 / -54760
Crawl4AI	< 0.8.7 bzw. < 0.8.8	0.8.8	CVE-2026-56260 / -56259

4. Zwei Geschwindigkeiten: Regelfenster und Notfallregel

Legen Sie ein festes monatliches Patch-Fenster fest – planbar, mit Testinstanz und Rollback-Pfad. Daneben braucht es eine Notfallregel: Sobald eine eingesetzte Komponente im KEV-Katalog auftaucht oder ein öffentlicher Exploit existiert, gilt eine Frist von 72 Stunden bis zum Patch oder zur Abschaltung des betroffenen Dienstes. Die 20 Stunden zwischen Langflow-Advisory und erster Ausnutzung zeigen, dass „nächstes Quartal" keine Antwort ist.

5. Verifikation statt Vertrauen

Nach dem Update prüfen Sie, ob der Fix greift – über die Release Notes des Herstellers, den zugehörigen Commit und, wo möglich, einen kontrollierten Test gegen den bekannten PoC. Der Fall 1.8.2 ist der Beleg dafür, dass ein grüner Scanner-Report kein Beweis ist. Ein KI-Pentest nach größeren Stack-Änderungen deckt genau diese Lücke zwischen Meldung und Wirkung ab.

6. Schadensbegrenzung: Segmentierung und Admission Control

Setzen Sie voraus, dass ein Patch einmal zu spät kommt. Dann entscheidet die Architektur über den Schaden: KI-Dienste in ein eigenes Netzsegment, ausgehende Verbindungen per Allowlist, Secrets nicht als Umgebungsvariablen im Container, sondern aus einem Secret-Store zur Laufzeit, dazu in Kubernetes-Umgebungen Admission Control gegen unsignierte oder nicht freigegebene Images. Genau das hätte die Exfiltration von Cloud-Keys nach der Langflow-Ausnutzung erheblich erschwert. Wie Sie offene Inferenz-Endpunkte zusätzlich absichern, behandeln wir ausführlich unter KI-Sicherheit.

Kuratierter Stack statt zusammengegoogeltem Compose

Der häufigste Weg zum eigenen KI-Stack führt über eine docker-compose.yml aus einem Blogartikel. Das funktioniert erstaunlich gut – bis zu dem Tag, an dem eine der sieben darin referenzierten Komponenten eine kritische Lücke meldet und niemand sagen kann, welche Version eigentlich läuft.

Ein kuratierter Stack unterscheidet sich in vier Punkten:

1. Feste, getestete Versionsstände. Keine latest-Tags in Produktion. Ein latest-Tag bedeutet, dass ein beliebiger Neustart die Anwendungsversion ändern kann – nach oben wie, bei einem zurückgezogenen Release, nach unten. Beides ist im Störungsfall nicht rekonstruierbar. Pinnen Sie auf Digest, nicht nur auf Tag.
2. Wartungsvertrag mit definiertem Patch-Fenster. Zuständigkeit, Reaktionszeit und Eskalationsweg schriftlich – inklusive der Frage, wer nachts um zwei entscheidet, ob ein Dienst abgeschaltet wird.
3. Testinstanz und Rollback-Pfad vor jedem Produktivupdate. Eine zweite, kleinere Instanz mit demselben Versionsstand kostet wenig und verhindert, dass ein Sicherheitsupdate zum Produktionsausfall wird. Rollback heißt konkret: vorheriger Image-Digest verfügbar, Datenbank-Migration reversibel oder gesichert.
4. Reduzierte Komponentenzahl. Jede zusätzliche Komponente ist eine zusätzliche CVE-Quelle. Wenn ein Agenten-Framework nur für einen einzigen Workflow im Einsatz ist, ist die ehrliche Frage, ob 200 Zeilen eigener Code nicht weniger Angriffsfläche bedeuten als ein Projekt mit 25 Advisories im Monat.

Der Punkt ist nicht, dass Open Source unsicher wäre – die Transparenz dieser Projekte ist der Grund, warum wir überhaupt über konkrete CVE-Nummern sprechen können statt über Gerüchte. Der Punkt ist, dass Transparenz nur dann Sicherheit erzeugt, wenn jemand die Advisories liest und handelt. Wer einen On-Premise-KI-Server als Appliance betreibt, kauft im Kern genau das: eine definierte Zusammenstellung, für die diese Arbeit vertraglich zugeordnet ist.

Die Betriebsverantwortung verschwindet nicht dadurch, dass man sie nicht wahrnimmt. Sie wird nur unsichtbar – bis zu dem Zeitpunkt, an dem ein automatisierter Scanner sie sichtbar macht. Wenn Sie unsicher sind, wie Ihr Stack im Abgleich mit der Versionsmatrix oben dasteht, ist das der beste Zeitpunkt für eine Bestandsaufnahme.

Quellen & Primärbelege

Alle Zahlen, Fristen und Produktangaben in diesem Beitrag wurden vor der Veröffentlichung gegen die folgenden Primaerquellen geprüft.

1. labs.cloudsecurityalliance.org csa research note langflow rce cve 2026 33017 ai infrastruct
2. research.jfrog.com langflow latest version was not fixed
3. csoonline.com attackers exploit critical langflow rce within hours as cisa sounds alarm
4. thehackernews.com cisa adds 4 actively exploited adobe
5. bleepingcomputer.com cisa orders feds to patch actively exploited langflow rce flaw
6. NIST National Vulnerability Database CVE 2026 5027
7. tenable.com tra 2026 26
8. GitHub advisories
9. advisories.gitlab.com CVE 2026 70487
10. advisories.gitlab.com CVE 2026 59221
11. GitHub advisories
12. GitHub advisories

Häufig gestellte Fragen zu KI-Stack-Sicherheit

Betrifft mich das, wenn mein KI-Stack nicht aus dem Internet erreichbar ist?

Das Risiko sinkt deutlich, verschwindet aber nicht. Mehrere der Lücken sind aus dem internen Netz oder über präparierte Inhalte ausnutzbar. Netzsegmentierung ersetzt kein Patch-Management, sie kauft nur Zeit.

Was ist der CISA-KEV-Katalog und warum ist er relevant?

Der Katalog listet Schwachstellen, für die eine Ausnutzung in freier Wildbahn belegt ist. Eine Aufnahme bedeutet: Es wird nicht theoretisch angegriffen, sondern real – und Patchen ist keine Priorisierungsfrage mehr.

Wie halte ich einen KI-Stack aktuell, ohne ständig Produktionsausfälle zu riskieren?

Mit festen Versionsständen, einer Testinstanz und einem definierten monatlichen Patch-Fenster plus Notfallregel für KEV-Einträge. „Latest"-Tags in Produktion sind die häufigste Ursache für ungeplante Ausfälle.

Brauche ich eine SBOM für KI-Komponenten?

Ja. Ohne Inventar wissen Sie bei einer neuen CVE nicht, ob Sie betroffen sind. Die SBOM sollte Frameworks, Gateways, Vektordatenbank, Inferenz-Engine und die eingesetzten Modellversionen umfassen.