Kann ein einziger HTTP-Header – genauer gesagt der User-Agent Ihres Browsers – ausreichen, um eine vollständige Remote Code Execution (RCE) auf Ihrem Entwicklungsrechner auszulösen? Im Fall von CVE-2025-62593, einer kritischen Schwachstelle im verteilten Computing-Framework Ray, lautet die Antwort: Ja. Was zunächst wie ein theoretisches Szenario klingt, ist längst Realität. Angreifer benötigen lediglich eine präparierte Website oder eine manipulierte Werbeanzeige, um Code auf Systemen auszuführen, auf denen Ray lokal läuft – ohne dass das Opfer eine Datei herunterladen oder auf einen verdächtigen Link klicken muss.

Die Zahlen unterstreichen die Dringlichkeit: Die National Vulnerability Database (NVD) veröffentlichte den Eintrag am 26. November 2025. Am 17. August 2026 nahm die US-Cybersicherheitsbehörde CISA die Schwachstelle in ihren Katalog der nachweislich ausgenutzten Sicherheitslücken (KEV) auf CISA Alert – mit einer Behebungsfrist von nur drei Tagen, dem 20. August 2026. Laut CISA-Bewertung ist die Schwachstelle automatisierbar und führt bei erfolgreicher Ausnutzung zu einem vollständigen Verlust von Vertraulichkeit, Integrität und Verfügbarkeit auf dem betroffenen System. Der CVSS-4.0-Score liegt bei 9,4 (Critical), der CVSS-3.1-Wert bei 8,8 (High) – laut NVD und GitHub. The Hacker News Betroffen sind alle Ray-Versionen vor 2.52.0. Die aktive Ausnutzung ist bestätigt, die Automatisierbarkeit gegeben, und die technischen Auswirkungen werden als „total“ eingestuft.

Was ist Ray und warum ist die Schwachstelle so brisant?

Ray ist ein Open-Source-Framework für verteiltes Computing, das nativ in Python geschrieben ist. Es ermöglicht Entwicklern, rechenintensive Aufgaben – etwa das Training von Machine-Learning-Modellen, Datenverarbeitungspipelines oder Reinforcement Learning – über mehrere Maschinen und GPUs hinweg zu skalieren. Mit über 43.500 GitHub-Sternen und mehr als 7.900 Forks gehört Ray zu den etabliertesten Werkzeugen im Bereich der KI-Infrastruktur. Unternehmen setzen es ein, um große Sprachmodelle zu trainieren, Echtzeit-Inferenz zu betreiben oder komplexe Simulationen zu parallelisieren.

Verbreitung in produktiven Umgebungen

Die Popularität von Ray macht die Schwachstelle besonders gefährlich. Ray wird nicht nur in isolierten Forschungsumgebungen genutzt, sondern auch in produktiven Clustern, auf Kubernetes, in Cloud-Umgebungen und auf lokalen Entwicklungs-Workstations. Viele Data-Science-Teams betreiben Ray direkt auf ihren Laptops oder in Jupyter-Notebooks, oft ohne strenge Netzwerksegmentierung. Genau diese Konstellation – Ray lokal auf einem Rechner mit aktivem Browser – ist der primäre Angriffsvektor für CVE-2025-62593.

Die Rolle von Ray in der KI-Lieferkette

Ray ist ein zentraler Baustein moderner KI-Pipelines. Wer Ray kompromittiert, erhält potenziell Zugriff auf Trainingsdaten, Modellgewichte, API-Schlüssel und interne Infrastruktur. Die Schwachstelle betrifft daher nicht nur einzelne Entwickler, sondern kann als Einfallstor in größere KI-Systeme dienen. Angesichts der zunehmenden Regulierung von KI-Systemen und der Sensibilität von Trainingsdaten ist ein solcher Angriffsvektor für Cyberkriminelle und staatliche Akteure gleichermaßen attraktiv.

Technische Analyse des Angriffs: Browser als unfreiwilliger Komplize

Die Schwachstelle CVE-2025-62593 basiert auf einer unzureichenden Prüfung des User-Agent-Headers in Ray. Konkret: Ray akzeptiert Anfragen, deren User-Agent den String „Mozilla“ enthält, als vertrauenswürdig – eine Annahme, die aus der Frühzeit des Webs stammt, als nur „echte“ Browser diesen Header sendeten. Heute kann jeder HTTP-Client diesen Header beliebig setzen. In Kombination mit DNS-Rebinding wird der Browser des Opfers zu einem „confused deputy“, der im Namen des Angreifers Anfragen an den lokal laufenden Ray-Dienst sendet.

User-Agent-Check und DNS-Rebinding im Detail

Der Angriff läuft typischerweise wie folgt ab: Ein Entwickler besucht eine bösartige Website oder eine Seite mit manipulierter Werbung. Diese Seite führt JavaScript aus, das per DNS-Rebinding die Same-Origin-Policy des Browsers umgeht. Der Browser wird dazu gebracht, Anfragen an localhost oder an eine interne IP-Adresse zu senden, auf der Ray läuft. Da der Browser automatisch einen User-Agent-Header mit „Mozilla“ sendet – etwa bei Firefox oder Safari – akzeptiert Ray die Anfrage als legitim. Der Angreifer kann so beliebige API-Aufrufe an Ray senden, einschließlich solcher, die zur Ausführung von beliebigem Code führen.

Ausweitung auf netzwerkadjazente Instanzen

Die Forscher Avi Lumelsky von Oligo und Jonathan Leitschuh dokumentierten, dass sich der Angriff nicht auf lokale Instanzen beschränkt. Über DNS-Rebinding kann der Browser auch Anfragen an andere Hosts im internen Netzwerk senden. Wenn Ray auf einem Server im selben Netzwerksegment läuft und keine zusätzliche Authentifizierung konfiguriert ist, kann der Angreifer auch diese Instanz erreichen. Damit wird aus einer lokalen Schwachstelle ein netzwerkweites Risiko – insbesondere in flachen Netzwerken ohne Mikrosegmentierung.

Auswirkungen und aktive Bedrohungslage

Die Aufnahme in den CISA-KEV-Katalog am 17. August 2026 bestätigt, dass die Schwachstelle aktiv ausgenutzt wird. Die CISA-Bewertung „exploitation active“ und „automatable yes“ bedeutet, dass Angreifer die Lücke ohne manuelle Interaktion in großem Maßstab ausnutzen können. Die technischen Auswirkungen werden als „total“ eingestuft – ein vollständiger Verlust von Vertraulichkeit, Integrität und Verfügbarkeit auf dem betroffenen System.

RondoDox und ShadowRay 2.0: Botnetze und Krypto-Mining

Bereits zwei Tage vor der offiziellen Veröffentlichung der Schwachstelle hatte das DDoS-Botnetz RondoDox die Lücke in sein Arsenal aufgenommen. Das zeigt, wie schnell Cyberkriminelle neue Schwachstellen in ihre Angriffsinfrastruktur integrieren. Parallel dazu wurde die ShadowRay-2.0-Kampagne beobachtet, eine Krypto-Mining-Operation, die gezielt Ray-Instanzen mit NVIDIA-GPUs ins Visier nimmt. Die Kombination aus ungepatchten Ray-Instanzen und leistungsstarken GPUs macht diese Systeme zu lukrativen Zielen für Krypto-Miner, die die Rechenleistung für das Schürfen von Kryptowährungen missbrauchen.

Gefährdung von Entwickler-Workstations

Besonders kritisch ist die Gefährdung von Entwickler-Workstations. Viele Data Scientists und ML-Ingenieure führen Ray lokal aus, um Modelle zu testen oder kleinere Jobs zu verarbeiten. Diese Rechner sind oft nicht in das zentrale Patch-Management eingebunden und verfügen über weitreichende Zugriffsrechte auf interne Systeme, Git-Repositories und Cloud-Ressourcen. Ein erfolgreicher Angriff auf eine solche Workstation kann als Sprungbrett für laterale Bewegungen im gesamten Netzwerk dienen. Ähnliche Muster wurden bereits bei anderen Schwachstellen beobachtet, etwa bei der wp2shell WordPress Core RCE oder der FortiBleed-Kampagne.

Betroffene Versionen und Patches

Alle Ray-Versionen vor 2.52.0 sind von CVE-2025-62593 betroffen. Der Patch wurde mit Version 2.52.0 veröffentlicht; Details dazu bietet die GitHub Security Advisory. Die CISA setzt eine Behebungsfrist bis zum 20. August 2026 – für Bundesbehörden in den USA eine verbindliche Frist, für alle anderen Organisationen eine dringende Empfehlung. Angesichts der aktiven Ausnutzung und der Automatisierbarkeit des Angriffs sollten Unternehmen nicht bis zur Frist warten, sondern sofort patchen.

Patch-Verfügbarkeit und Update-Empfehlung

Der Patch ist über die offiziellen Ray-Kanäle verfügbar. Entwickler sollten pip install --upgrade ray ausführen oder ihre Container-Images und Helm-Charts entsprechend aktualisieren. Für produktive Cluster empfiehlt sich ein rollierendes Update, um Ausfallzeiten zu minimieren. Da die Schwachstelle bereits aktiv ausgenutzt wird, ist ein sofortiges Update die einzig wirksame Maßnahme gegen die bekannten Angriffsvektoren.

Schutzmaßnahmen und Workarounds

Neben dem unverzichtbaren Update auf Ray 2.52.0 gibt es mehrere Maßnahmen, um das Risiko zu reduzieren – insbesondere für Organisationen, die nicht sofort patchen können. Die wichtigste Empfehlung lautet: Ray niemals ungeschützt auf einem System betreiben, das gleichzeitig für das Surfen im Internet genutzt wird. Die Trennung von Entwicklungs- und Browser-Umgebungen ist eine grundlegende Sicherheitsmaßnahme, die viele Angriffe dieser Art verhindert.

Netzwerksegmentierung und Zugriffskontrolle

Ray-Instanzen sollten in isolierten Netzwerksegmenten betrieben werden, die keinen direkten Zugriff aus dem Internet oder von Arbeitsplatzrechnern erlauben. Firewall-Regeln sollten den Zugriff auf Ray-Ports (standardmäßig 8265 für das Dashboard, 6379 für den GCS, 10001 für den Object Store) auf autorisierte Hosts beschränken. In Kubernetes-Umgebungen sollten NetworkPolicies den Traffic zwischen Pods und externen Clients strikt regeln. Ähnliche Prinzipien wurden auch bei der Absicherung von KI-Agenten-Plattformen wie Langflow empfohlen.

Monitoring und Erkennung

Organisationen sollten ihre Ray-Instanzen auf ungewöhnliche Aktivitäten überwachen. Dazu gehören unerwartete API-Aufrufe, verdächtige Job-Submissions, ungewöhnliche Netzwerkverbindungen und auffällige CPU- oder GPU-Auslastung – letzteres insbesondere im Zusammenhang mit Krypto-Mining. Logs sollten zentral gesammelt und auf Anomalien analysiert werden. Die Integration von Ray-Logs in bestehende SIEM-Systeme ermöglicht eine frühzeitige Erkennung von Angriffsversuchen. Auch die regelmäßige Überprüfung von Sicherheitslücken in der Infrastruktur ist essenziell.

Was Administratoren jetzt tun müssen: ein 72-Stunden-Plan

Die CISA-Behebungsfrist vom 20. August 2026 mag für viele Unternehmen außerhalb der USA keine rechtliche Verpflichtung sein, doch sie ist ein brauchbarer Maßstab für die eigene Reaktionsgeschwindigkeit. Wer Ray in Produktion oder auf Entwickler-Workstations betreibt, sollte binnen 72 Stunden drei Dinge umsetzen: Bestandsaufnahme, Absicherung und Überwachung.

Schritt 1: Bestandsaufnahme und Priorisierung

Der erste Schritt ist die vollständige Erfassung aller Ray-Installationen. Dazu gehören nicht nur produktive Cluster, sondern auch lokale Entwicklungsumgebungen, Jupyter-Notebooks, Container-Images und CI/CD-Pipelines, in denen Ray als Abhängigkeit enthalten ist. Tools wie pip list, Container-Image-Scanner oder Software-Bill-of-Materials (SBOM) helfen, betroffene Versionen zu identifizieren. Jede Instanz mit Ray < 2.52.0 erhält die höchste Priorität, insbesondere wenn sie aus dem erreichbaren Netzwerk zugänglich ist oder auf Maschinen läuft, die gleichzeitig für Browsing genutzt werden.

Schritt 2: Sofort-Patch und temporäre Kompensationsmaßnahmen

Sobald die betroffenen Systeme bekannt sind, folgt das Update auf Ray 2.52.0. Ist ein sofortiges Patchen nicht möglich – etwa wegen Abhängigkeiten zu Trainings-Pipelines oder laufenden Experimenten – müssen temporäre Kompensationsmaßnahmen greifen. Dazu zählen die Deaktivierung des Dashboards auf öffentlich erreichbaren Interfaces, die Restriktion von Ray-Ports auf localhost oder autorisierte Subnetze sowie die Blockierung ausgehender DNS-Anfragen aus Browsern an interne Dienste. Diese Maßnahmen reduzieren das Angriffsfenster, bis das Update flächendeckend eingespielt ist.

Schritt 3: Forensische Triage und dauerhafte Überwachung

Da CISA für KEV-Einträge ausdrücklich eine forensische Triage empfiehlt, sollten Organisationen prüfen, ob Anzeichen einer Kompromittierung vorliegen. Relevante Indikatoren sind unbekannte Job-Submissions, neue Python-Prozesse mit ungewöhnlichen Argumenten, Verbindungen zu externen Mining-Pools oder unerklärliche GPU-Auslastung. Zusätzlich empfiehlt sich die Integration von Ray-Logs in SIEM-Systeme und die Definition von Alerting-Regeln für Dashboard-Zugriffe von nicht autorisierten Quellen.

Langfristige Absicherungsstrategie für Ray-Umgebungen

Neben dem kurzfristigen Patch sollten Unternehmen ihre Architektur so gestalten, dass ähnliche Schwachstellen künftig weniger Schaden anrichten. Dazu gehört die konsequente Trennung von Browser- und Entwicklungsumgebungen, der Einsatz dedizierter Jump-Hosts für den Zugriff auf Ray-Dashboards sowie die Verwendung von Authentifizierung und TLS für alle Ray-Komponenten. Auch regelmäßige Schwachstellen-Scans und Dependency-Checks in CI/CD-Pipelines helfen, betroffene Versionen frühzeitig zu erkennen. Wer diese Prinzipien bereits beim Langflow-Fall oder bei Credential-Stuffing-Angriffen beherzigt hat, erkennt die Parallelen: KI- und Netzwerkinfrastruktur benötigen Zero-Trust-Segmentierung, nicht nur Perimeter-Sicherheit.

Fazit und Handlungsempfehlung

CVE-2025-62593 zeigt eindrücklich, wie eine scheinbar harmlose Designentscheidung – die Prüfung des User-Agent-Headers – in Kombination mit modernen Browser-Techniken wie DNS-Rebinding zu einer kritischen Remote-Code-Execution-Schwachstelle werden kann. Die aktive Ausnutzung durch Botnetze wie RondoDox und Krypto-Mining-Kampagnen wie ShadowRay 2.0 unterstreicht die Dringlichkeit. Wer Ray einsetzt, sollte unverzüglich auf Version 2.52.0 aktualisieren und die oben genannten Schutzmaßnahmen umsetzen.

Für IT-Administratoren und CISOs gilt: Prüfen Sie, ob Ray in Ihrer Umgebung eingesetzt wird – auch auf Entwickler-Workstations, in Jupyter-Notebooks oder in isolierten Testumgebungen. Die Schwachstelle betrifft nicht nur zentrale Cluster, sondern gerade auch dezentrale Installationen, die oft übersehen werden. Die CISA-Frist vom 20. August 2026 ist keine Empfehlung, sondern eine dringende Handlungsaufforderung. Angesichts der bestätigten aktiven Ausnutzung und der Automatisierbarkeit des Angriffs ist jedes ungepatchte System ein potenzielles Einfallstor. Zusätzlich sollten Unternehmen die Nutzung von Browsern auf Entwickler-Workstations, auf denen Ray läuft, einschränken oder zumindest den lokalen Ray-Dashboard-Zugriff auf vertrauenswürdige Interfaces beschränken.

Die Ereignisse rund um CVE-2025-62593 reihen sich ein in eine Serie von Sicherheitsvorfällen im KI- und Open-Source-Ökosystem. Ähnlich wie beim Microsoft Patch Tuesday August 2026 zeigt sich, dass Angreifer zunehmend Schwachstellen in Infrastruktur-Komponenten ausnutzen, die für KI-Workloads unverzichtbar sind. Die Kombination aus aktiver Exploitation, hoher Verbreitung und einfacher Automatisierbarkeit macht CVE-2025-62593 zu einem der kritischsten Sicherheitsvorfälle des Jahres 2026.