CISA hat CVE-2025-62593, eine Code-Injection-Schwachstelle im Ray-KI-Framework, am 17. August 2026 in den Katalog der Known Exploited Vulnerabilities aufgenommen. Das Ray-Projekt erklärt, dass Versionen vor 2.52.0 betroffen sind und Version 2.52.0 die Schwachstelle behebt. Das Advisory beschreibt einen browserbasierten DNS-Rebinding-Pfad, der zur Ausführung beliebigen Codes über einen lokalen Ray-Dienst eines Entwicklers führen kann.
Dies ist ein aktuelles Ausnutzungssignal für eine ältere Offenlegung, aber kein Beleg dafür, dass jede Ray-Installation exponiert ist. Das Hersteller-Advisory wurde am 26. November 2025 veröffentlicht und beschreibt ausdrücklich einen Pfad mit Firefox oder Safari, einer schädlichen Website und einem lokal laufenden Ray-Entwicklungsdienst. Teams müssen prüfen, ob diese Bedingungen in ihrer eigenen Umgebung vorliegen, bevor sie die Auswirkungen bewerten.
Was CISA über die Schwachstelle im Ray-KI-Framework sagt
Der CISA-Katalog bezeichnet CVE-2025-62593 als Ray Code Injection Vulnerability. Der Eintrag vom 17. August besagt, dass die Schwachstelle Remotecodeausführung ermöglichen kann, und nennt den 20. August 2026 als Frist für die von der einschlägigen CISA-Direktive erfassten US-Bundesbehörden. Beim Feld zur bekannten Nutzung durch Ransomware steht unknown. Unbekannt bedeutet nicht ausgeschlossen. Es bedeutet, dass der Katalog in diesem Feld keine bekannte Nutzung durch Ransomware zuordnet.
Die Aufnahme in den Katalog bedeutet, dass CISA Belege für eine Ausnutzung in realen Umgebungen hat. Der öffentliche Eintrag nennt weder Opfer noch Umfang, Angreifer oder Kampagne. Solche Einzelheiten dürfen nicht aus dem Katalogstatus abgeleitet werden. Für Organisationen außerhalb des Bundesbereichs der Direktive ist das Fälligkeitsdatum ein Dringlichkeitssignal, aber keine allgemeine gesetzliche Frist.
Wie der Pfad vom Browser zum lokalen Dienst funktioniert
Das Sicherheits-Advisory des Ray-Projekts erläutert den technischen Umfang. Nach Angaben des Ray-Projekts kann ein Angreifer DNS-Rebinding von einer schädlichen Website nutzen, damit Browseranfragen einen Ray-Dienst auf dem Rechner eines Entwicklers erreichen. Das Advisory nennt Firefox und Safari als Browser im nachgewiesenen Expositionspfad. Bei erfolgreicher Ausnutzung kann der Angreifer Aufgaben an Ray übermitteln und Code mit den Berechtigungen des Dienstes ausführen.
Das ist relevant, weil ein scheinbar lokaler Dienst dennoch über eine vom Browser vermittelte Anfrage erreichbar sein kann. Wer die Loopback-Grenze als ausreichende Authentifizierung behandelt, lässt eine Lücke, wenn Browser- und DNS-Verhalten einer nicht vertrauenswürdigen Quelle den Zugriff auf den Dienst ermöglichen. Der NVD-Eintrag enthält den öffentlichen CVE-Datensatz und verweist Verteidiger auf das Hersteller-Advisory und weitere Referenzen.
Die Voraussetzungen sind entscheidend. Das Advisory belegt nicht, dass jeder Produktionscluster, jeder verwaltete Ray-Dienst oder jeder Browser auf dieselbe Weise anfällig ist. Die Exposition hängt von der Ray-Version, einem laufenden und erreichbaren Dienst, dem Browserverhalten, der Netzwerkkonfiguration und den Berechtigungen des Ray-Prozesses ab. Laut Advisory ist Chrome von dem nachgewiesenen Pfad nicht betroffen. Teams sollten ihre konkreten Browserversionen und Konfigurationen dennoch testen.
Warum dies ein Governance-Thema für KI-Infrastruktur ist
Ray wird zur Verteilung von Python- und KI-Arbeitslasten eingesetzt. Ein kompromittierter lokaler Ray-Dienst kann sich daher in unmittelbarer Nähe zu Quellcode, Modellartefakten, Datensätzen, Cloud-Zugangsdaten, Notebooks und Entwicklerberechtigungen befinden. Das unmittelbare Problem ist Codeausführung. Die Governance-Folge ist jedoch ein Vertrauensverlust darin, wer eine Arbeitslast gestartet hat, welche Daten sie berührt hat und ob die resultierenden Artefakte vertrauenswürdig sind.
Eine belastbare Reaktion beginnt mit einem Inventar. Sicherheitsteams müssen wissen, wo Ray installiert ist, welche Versionen vorhanden sind, wer lokale Dienste startet, welche Browserpfade zulässig sind und auf welche Zugangsdaten oder Speicher diese Prozesse zugreifen können. Maetras Leitfaden zum Aufbau eines Inventars für KI-Agenten bietet ein nützliches Modell, um Verantwortliche, Umgebungen, Berechtigungen und Abhängigkeiten zu dokumentieren, statt nur eine Paketliste zu pflegen.
Operative Reaktion für Sicherheits- und Plattformteams
Die folgenden Kontrollen gelten für Entwicklerrechner, Notebooks, Build-Umgebungen, Forschungssysteme und gemeinsam genutzte KI-Plattformen:
- Ray-Installationen und laufende Dienste erfassen sowie Version, Host, verantwortliche Person, Startmethode und Zweck der Umgebung dokumentieren.
- Betroffene Installationen unter Beachtung des Hersteller-Advisory und der üblichen Änderungskontrollen auf Ray 2.52.0 oder neuer aktualisieren.
- Wenn ein Upgrade nicht sofort möglich ist, den Dienst anhalten oder die vom Hersteller empfohlene Gegenmaßnahme anwenden sowie Ausnahmeverantwortlichen und Ablaufdatum dokumentieren.
- Prüfen, ob lokale Ray-Dienste den Netzwerkstandort als einzige Vertrauensgrenze verwenden. Für die Umgebung angemessene Authentifizierungs-, Bindungs-, Firewall- und Browser-Origin-Kontrollen ergänzen.
- Zugangsdaten rotieren und einschlägige Protokolle prüfen, wenn ein exponierter Dienst Zugriff auf Quellcode-Repositories, Cloud-Token, Datensätze oder Modellartefakte hatte.
- Browser- und DNS-Pfad in einer isolierten Umgebung testen. Nicht annehmen, dass eine Konfiguration allein durch die Adressierung über localhost geschützt ist.
- Für jedes relevante System Nachweise über gepatchte Version, Neustart, Expositionstest und Prüfentscheidung erfassen.
- Ray-Aufgaben, Prozesserstellung, Werkzeugnutzung und ausgehende Verbindungen auf Verhalten überwachen, das nicht zum genehmigten Zweck des Systems passt.
Der letzte Schritt bleibt auch nach dem Patch wichtig. Maetras Leitfaden zum Monitoring riskanten Verhaltens von KI-Agenten zeigt, wie folgenreiche Aktionen mit einer verantwortlichen Person, einer Richtlinienentscheidung und einem prüfbaren Datensatz verbunden werden.
Maetra-Analyse: Lokale KI-Dienste brauchen klare Vertrauensgrenzen
Die allgemeinere Lehre lautet, dass lokale KI-Infrastruktur nicht automatisch ein geringes Risiko darstellt. Entwicklungsdienste verbinden oft leistungsfähige Codeausführung mit bequemen Standardeinstellungen und weitreichendem Zugriff auf die Umgebung des Benutzers. Ein Browser kann zu einer unerwarteten Brücke zwischen einer nicht vertrauenswürdigen Website und dieser lokalen Fähigkeit werden.
Teams sollten die Vertrauensgrenze jedes KI-Dienstes anhand von Identität, Quelle, Netzwerkpfad, Prozessberechtigung, Datenzugriff und beobachtbaren Aktionen definieren. Der Patch-Status ist eine Kontrolle in diesem Modell. Er ersetzt weder die Prüfung von Zugangsdaten noch minimale Berechtigungen, Protokollierung oder den Nachweis, dass der exponierte Pfad geschlossen ist.
Als konkreten nächsten Schritt sollten Teams Ray-Dienste in das KI-Systeminventar aufnehmen, jeden Eintrag mit dem Schwachstellen- und Patchnachweis verknüpfen und vom jeweiligen Verantwortlichen die aktuelle Version und erreichbaren Schnittstellen bestätigen lassen. Anschließend können sie Maetras Secure-Workflow verwenden, um Werkzeug- und Aktionsgrenzen zu untersuchen, während die Infrastrukturbehebung dem etablierten Sicherheitsprozess folgt.
Quellen
- CISA: Known Exploited Vulnerabilities Catalog JSON, CVE-2025-62593 am 17. August 2026 aufgenommen.
- Ray-Projekt: Sicherheits-Advisory GHSA-q279-jhrf-cc6v, veröffentlicht am 26. November 2025.
- NIST National Vulnerability Database: CVE-2025-62593, öffentlicher Schwachstelleneintrag.