Die Behörde CISA hat am 2. September 2026 sieben Schwachstellen in den Katalog Known Exploited Vulnerabilities (KEV) aufgenommen und damit deren aktive Ausnutzung bestätigt. Zu den betroffenen Produkten gehören SonicWall SMA 1000, Sangoma Switchvox, JFrog Artifactory, Kestra OSS, Starlette und BerriAI LiteLLM. Zwei Schwachstellen erhielten die maximale CVSS-Bewertung von 10,0, und das Gesamtbild der Angriffe zeigt einen systemischen Wandel: Komponenten der AI-Infrastruktur – Gateways, Orchestratoren, Modell-Proxys – werden zu vorrangigen Zielen für Credential-Diebstahl, den Einsatz von Kryptominern und die Etablierung in der Infrastruktur des Opfers. Organisationen, die eines der genannten Produkte einsetzen, müssen verfügbare Patches umgehend einspielen.
Schwachstellen mit bestätigter Ausnutzung: SonicWall SMA 1000
Am verlässlichsten sind die Informationen zu zwei Schwachstellen in Geräten der Serie SonicWall SMA 1000. Laut offiziellem Herstellerhinweis hat das Unternehmen die aktive Ausnutzung beider Schwachstellen bestätigt:
- CVE-2026-83548 (CVSS 10.0) — eine SSRF-Schwachstelle (Server-Side Request Forgery), die es einem entfernten, nicht authentifizierten Angreifer erlaubt, auf kritische Funktionalität zuzugreifen und unautorisierte Aktionen auszuführen.
- CVE-2026-83549 (CVSS 7.8) — eine Schwachstelle zum Einschleusen von Betriebssystembefehlen nach der Authentifizierung, durch die ein Administrator beliebige OS-Befehle ausführen und damit Remote Code Execution erreichen kann.
Betroffen sind die Firmware-Versionen 12.4.3-03453 und 12.5.0-02835. Korrekturen stehen in den Versionen 12.4.3-03526 bzw. 12.5.0-02952 zur Verfügung. Angesichts der bestätigten Ausnutzung und der maximalen CVSS-Bewertung für die erste Schwachstelle muss das Firmware-Update für SMA 1000 höchste Priorität haben.
AI-Infrastruktur unter Beschuss: Kestra, LiteLLM, Starlette
Drei der sieben Schwachstellen betreffen Komponenten, die weitverbreitet in AI-Infrastruktur eingesetzt werden, und genau hier zeigt sich die beunruhigendste Tendenz.
Kestra OSS: vom Workflow zum Kryptominer
CVE-2026-49869 (CVSS 10.0) — eine OS Command Injection-Schwachstelle in Kestra OSS, die es einem nicht authentifizierten Angreifer ermöglicht, beliebige Workflows (workflows) ohne Credentials zu erstellen und auszuführen. Betroffen sind Versionen vor 1.0.45 sowie von 1.1.0 bis 1.3.20; behoben wurde die Schwachstelle in den Versionen 1.0.45 und 1.3.21.
Dem Bericht von Microsoft zufolge nutzten Angreifer diese Schwachstelle Ende Juni 2026 für eine vollständige Angriffskette mit vier Wirkungsrichtungen:
- Ausführung von Shell-Befehlen über die Workflow-Engine
- Erkundung der Containerumgebung über Zugriff auf den Docker-Socket
- Kapern der Host-Ressourcen durch Deployment eines Kryptominers
- Datensammlung durch Ausführung von Workflow-Aufgaben unter Nutzung der eingebauten Key-Value-Schnittstelle von Kestra
Bemerkenswert ist, dass die Angreifer eine curl-pipe-shell-Konstruktion einsetzten, um die gesammelten Daten zu kodieren und sie über die eigene Kestra-API zu speichern, wodurch die Erstellung von Datei-Artefakten auf dem Datenträger minimiert wurde – ein Ansatz, der die Erkennung durch File-Monitoring-Lösungen erschwert.
LiteLLM: Verwundbarkeitskette zum Umgehen der Authentifizierung
CVE-2026-59822 (CVSS 8.8) — eine Schwachstelle fehlerhafter Authentifizierung in BerriAI LiteLLM an der Model Context Protocol (MCP) Streamable HTTP-Endpoint, die es ermöglicht, eine authentifizierte MCP-Sitzung mit einem beliebigen Bearer-Token aufzubauen. Betroffen sind Versionen vor 1.84.0.
Diese Schwachstelle ist besonders interessant im Kontext einer Exploit-Kette. Bereits im Juni 2026 wurde die verwandte Schwachstelle CVE-2026-42271 (CVSS 8.8 nach NVD v3.1) offengelegt, die authentifizierten Nutzern das Ausführen beliebiger Befehle über Test-Endpunkte von MCP stdio erlaubt. Diese Schwachstelle wurde bereits am 8. Juni 2026 in den KEV-Katalog aufgenommen.
Microsoft hat die konkreten Schritte der Angreifer bei der Kompromittierung von LiteLLM-Gateways dokumentiert: Deployment eines XMRig-Miners über eine ELF-Binärdatei, vorheriges Profiling des Hosts, Beenden konkurrierender Mining-Prozesse, Zugriff auf PostgreSQL-Tabellen (LiteLLM_ProxyModelTable und LiteLLM_VerificationToken) zur Extraktion von Provider-Schlüsseln, Model-Konfigurationen und virtuellen Proxy-Schlüsseln. Zur Persistenz wurde die Datei ~/.ssh/authorized_keys modifiziert.
Laut Telemetrie der Honeypots von Wiz wurden Versuche zur Ausnutzung von CVE-2026-59822 beobachtet, bei denen einbuchstabige Bearer-Tokens verwendet wurden, um Modell-Enumerations-Endpunkte wie /v1/models zu sondieren.
Starlette: Abschwächung der Authentifizierungsgrenze
CVE-2026-48710 (CVSS 6.5) — eine HTTP Request Smuggling-Schwachstelle in Starlette in Versionen bis einschließlich 1.0.0. Verfälschte Host-Header ermöglichen es, Pfade in den Host-Teil der URL einzuschleusen, was zu einem Authentifizierungs-Bypass in Systemen führt, die sich auf den rekonstruierten URL-Pfad verlassen. Behoben wurde das Problem in Version 1.0.1. Microsoft beschreibt diese Schwachstelle als potenziellen Faktor zur Abschwächung der Authentifizierungsgrenze in Angriffsketten auf LiteLLM, bestätigt jedoch nicht, dass bei jedem beobachteten Einbruch beide CVEs genutzt wurden.
Weitere Schwachstellen im Katalog
CVE-2026-9586 (CVSS 9.3) — eine SQL injection-Schwachstelle in Sangoma Switchvox SMB Edition 8.3 (Build 104997), die es einem nicht authentifizierten Angreifer ermöglicht, beliebige SQL-Abfragen gegen den PostgreSQL-Server auszuführen, einschließlich Remote Code Execution.
CVE-2026-82329 (CVSS 9.8) — eine Schwachstelle fehlerhafter Authentifizierung in JFrog Artifactory, die es in der Standardkonfiguration erlaubt, ohne Authentifizierung administrative Privilegien zu erlangen.
Nach Angaben von Forschern wurden bei beiden Schwachstellen das Ausrollen von Reverse Shells und die Erstellung administrativer Tokens beobachtet, um anschließend Benutzer, Gruppen und Topologien föderierter Zugriffe zu enumerieren. Die ursprünglichen Berichte von Horizon3.ai und watchTowr, auf die sich das Ausgangsmaterial bezieht, wurden jedoch nicht unabhängig verifiziert.
Indikatoren einer Kompromittierung
Microsoft und Wiz haben folgende IOC veröffentlicht, die mit Angriffen auf AI-Infrastruktur in Zusammenhang stehen:
- IP-Adressen: 45.150.109.151, 135.125.10.56:19888, 172.232.38.92:32991, 47.86.197.116, 194.213.18.133
- Domänen: 45.150.109.151.sslip[.]io, auto.c3pool[.]org, gobygo[.]net, oast[.]me, oast[.]pro, oast[.]fun
- Hashes: f64b88e9318bdf23f2dd119a0ce1dd1bdb3c8cd2e0e1e23ba3ef2e19072b79cc, 49fdcf32bfe837899a84e8938f0d07ae96ddd218a280a09eb60df8d64597bd8f
- Ziel-Endpunkte: /v1/models, /mcp/, /mcp-rest/test/connection
Praktische Empfehlungen
- SonicWall SMA 1000: Firmware umgehend auf die Versionen 12.4.3-03526 oder 12.5.0-02952 aktualisieren. Logs auf Anzeichen unautorisierten Zugriffs über SSRF prüfen.
- Kestra OSS: Update auf Version 1.0.45 oder 1.3.21 durchführen. Einen Audit der erstellten Workflows auf unautorisierte Einträge durchführen. Den Zugriff auf den Docker-Socket aus Kestra-Containern einschränken.
- LiteLLM: Update auf Version 1.84.0 (für CVE-2026-59822) und 1.83.7 (für CVE-2026-42271). Die Tabellen LiteLLM_ProxyModelTable und LiteLLM_VerificationToken auf unautorisierte Zugriffe prüfen. Alle Provider-API-Schlüssel rotieren.
- Starlette: Update auf Version 1.0.1.
- Allgemeine Maßnahmen: AI-Workloads wie Komponenten der Control Plane und nicht als isolierte Applikationen überwachen. Dateien
~/.ssh/authorized_keysauf unautorisierte Änderungen prüfen. Die aufgeführten IOC in Erkennungsregeln integrieren.
Dieses Update des KEV-Katalogs markiert einen qualitativen Wandel in der Angriffslandschaft: Komponenten der AI-Infrastruktur – Modell-Proxys, Workflow-Orchestratoren, MCP-Server – werden nach denselben Mustern ausgenutzt wie traditionelle Webapplikationen, bieten Angreifern aber zusätzlich Zugriff auf API-Schlüssel großer LLM-Provider. Patch-Priorität: SonicWall SMA 1000 und Kestra OSS (CVSS 10.0, bestätigte Ausnutzung), danach LiteLLM und JFrog Artifactory, anschließend Starlette. Für Organisationen, die nicht sofort aktualisieren können, ist es entscheidend, betroffene Services vom externen Zugriff zu isolieren und die Netzkommunikation auf das absolut Notwendige zu begrenzen.
