Ray Sicherheitslücke CVE-2025-62593: KI-Cluster über den Browser angegriffen

Die Ray Sicherheitslücke CVE-2025-62593 ist seit dem 17. August 2026 offiziell als aktiv ausgenutzt eingestuft. Die US-Behörde CISA hat die Schwachstelle im verteilten Rechen-Framework Ray in ihren KEV-Katalog aufgenommen; US-Bundesbehörden müssen bis morgen, den 20. August 2026, nachgebessert haben. Das Besondere daran: Der Angriff läuft nicht über einen offen erreichbaren Server, sondern über den Browser des Entwicklers.

Wie die Ray Sicherheitslücke funktioniert

Ray ist ein quelloffenes, Python-nahes Framework, mit dem KI- und Machine-Learning-Lasten über mehrere Rechner verteilt werden. Das Projekt zählt rund 43.500 GitHub-Sterne (Stand August 2026) und ist in der KI-Entwicklung entsprechend verbreitet. Kritische Endpunkte wie /api/jobs und /api/job_agent/jobs/ besitzen von Haus aus keine Authentifizierung – eine bewusste Designentscheidung des Projekts, die laut Advisory schon mehrfach zu Schwachstellen geführt hat.

Newsletter

Klartext ins Postfach

KI, Security & Crypto – die wichtigsten Analysen, kein Spam. Jederzeit abbestellbar.

E-Mail-Adresse *

Vorname

Nachname

Als Schutz gegen Zugriffe aus dem Browser prüfte Ray lediglich, ob der User-Agent mit „Mozilla” beginnt; in diesem Fall antwortet der Dienst mit HTTP 405. Diese Hürde lässt sich umgehen, weil die Fetch-Spezifikation die Manipulation des Headers erlaubt. Kombiniert man das mit einem DNS-Rebinding-Angriff, hält der Browser den Server des Angreifers und die lokale Ray-Instanz für dieselbe Herkunft – und führt Anfragen an die lokale API aus.

Es genügt also, dass jemand mit laufender Ray-Instanz eine präparierte Website besucht oder eine bösartige Anzeige ausgeliefert bekommt. Danach kann beliebiger Code auf dem Rechner ausgeführt werden. Betroffen sind laut Advisory Firefox und Safari; Chrome bleibt außen vor, weil Chromium an dieser Stelle von der Fetch-Spezifikation abweicht. Der Angriff lässt sich zudem auf benachbarte Ray-Instanzen im Firmennetz ausdehnen – der Browser dient dann als Mittelsmann in ein Netz, das von außen gar nicht erreichbar wäre.

Die Bewertung liegt bei CVSS 9,4 (Version 4.0). Behoben ist das Problem ab Ray 2.52.0. Gefunden haben es Avi Lumelsky von Oligo Security (Umgehung der User-Agent-Prüfung) und Jonathan Leitschuh von Socket (DNS-Rebinding).

Was über die Ausnutzung wirklich bekannt ist

CISA nennt keine Details, und der KEV-Eintrag führt den Einsatz durch Ransomware-Gruppen als „unbekannt”. Es lohnt sich deshalb, zwei häufig vermischte Geschichten sauber zu trennen.

RondoDox. Laut einem Bitsight-Bericht vom März 2026 hatten die Betreiber dieses DDoS-Botnets die Schwachstelle bereits am 24. November 2025 im Arsenal – zwei Tage vor der öffentlichen Veröffentlichung am 26. November, möglich durch einen früh verfügbaren Proof-of-Concept. Die Pointe: Ihr Exploit setzt den User-Agent auf „Mozilla/5.0 (rondo2012@atomicmail[.]io)”. Damit läuft er nach Bitsights Einschätzung direkt in die 405-Sperre, die er eigentlich umgehen soll. Die Gruppe verfolgt Veröffentlichungen also aufmerksam, hat den Angriff hier aber schlicht falsch implementiert.

ShadowRay 2.0. Diese Kampagne wird oft im selben Atemzug genannt, betrifft aber eine andere Lücke: CVE-2023-48022, von Oligo im November 2025 beschrieben. Dabei kapert die Gruppe IronErn440 im Internet exponierte Ray-Cluster über die Jobs-API und macht sie zu einem sich selbst verbreitenden Botnet für Krypto-Mining, Datendiebstahl und DDoS. Für diese ältere Schwachstelle gibt es keinen Patch – sie gilt als „disputed”, weil das Projekt sie als Designentscheidung einstuft. Oligo zählte zuletzt rund 230.000 exponierte Ray-Umgebungen. ShadowRay 2.0 belegt also nicht die Ausnutzung von CVE-2025-62593, zeigt aber sehr deutlich, wie attraktiv Ray-Cluster als Ziel sind.

Was das für dich bedeutet

Hier zeigt sich ein Muster, das mir in der Praxis immer häufiger begegnet: Die KI-Werkzeugkette ist der neue blinde Fleck. Klassische Schwachstellenprozesse decken Betriebssysteme, Datenbanken und Webserver ab. Was ein Data Scientist auf seiner Workstation startet, taucht in keinem Inventar auf – läuft aber im selben Netz wie alles andere und wird von keinem Patchzyklus erfasst.

Der Angriffsweg ist zusätzlich tückisch, weil er die übliche Denkweise aushebelt. „Der Dienst hört nur auf localhost, also ist er sicher” gilt bei DNS-Rebinding schlicht nicht: Der Browser ist bereits im Netz und wird zum Werkzeug des Angreifers gemacht. Dieselbe Logik haben wir zuletzt beim Langflow-Baukasten gesehen: KI-Tools setzen bei Standardinstallationen auf Bequemlichkeit statt auf Authentifizierung.

Dazu kommt die Zielattraktivität. Ray-Cluster stehen selten allein – sie haben GPUs, Zugriff auf Trainingsdaten und meist großzügig hinterlegte Cloud-Zugangsdaten. Für Angreifer ist das eine gute Rendite pro Aufwand. Dass Krypto-Mining und DDoS die bisher sichtbarsten Anwendungsfälle sind, ist dabei der harmlose Teil der Geschichte.

Konkrete Schritte

1. Version prüfen und aktualisieren. pip show ray zeigt den Ist-Stand. Der Fix steckt in 2.52.0, aktuell ist inzwischen 2.57.0 – nimm gleich die neuere Version. Denk dabei an Container-Images und CI-Pipelines, nicht nur an die Workstation.
2. Wichtig: Das Update allein reicht nicht. Ray bringt seit 2.52.0 eine eingebaute Token-Authentifizierung mit – die ist aber standardmäßig deaktiviert. Ohne RAY_AUTH_MODE=token vor dem Start des Clusters bleiben Dashboard und Jobs-API unauthentifiziert. Genau dafür gibt es ein eigenes Advisory. Wer nur aktualisiert und das Häkchen nicht setzt, hat die halbe Arbeit gemacht.
3. Dashboard nicht offen laufen lassen. Binde es ausdrücklich an 127.0.0.1 und stelle es nur über einen authentifizierten Reverse Proxy oder einen SSH-Tunnel bereit. Ein Dashboard ohne Authentifizierung ist eine Fernwartungsschnittstelle, keine Entwicklerbequemlichkeit.
4. Nur starten, wenn gebraucht. Der Browser-Angriff funktioniert nur gegen eine laufende Instanz. Ray dauerhaft im Hintergrund laufen zu lassen, während man normal im Netz surft, ist unnötiges Risiko.
5. Schatten-KI sichtbar machen. Frag im Team konkret nach: Wer betreibt lokal Ray, Ollama, vLLM, Jupyter oder Ähnliches? Diese Liste gehört ins Asset-Inventar, sonst patcht sie niemand.
6. Ausgehenden Verkehr beobachten. Dauerhafte GPU-Last ohne zugehörigen Job oder Verbindungen zu Mining-Pools sind bei ShadowRay-artigen Angriffen das erste sichtbare Symptom.

Wer ohnehin überlegt, KI-Modelle lokal statt in der Cloud zu betreiben, findet in meinem Ratgeber zu Hardware für lokale KI und LLMs 2026 die Grundlagen – inklusive der Frage, welche Dienste dabei besser nicht ans Netz gehören. Wie leistungsfähig lokale Modelle inzwischen sind, zeigt etwa Nvidias Nemotron 3.5 Lightning.

Fazit

CVE-2025-62593 ist kein exotischer Sonderfall, sondern ein Vorgeschmack: KI-Infrastruktur wächst schneller, als die zugehörige Sicherheitsdisziplin nachzieht. Der Patch ist verfügbar und der Aufwand gering. Die eigentliche Aufgabe besteht darin, überhaupt zu wissen, wo im eigenen Umfeld Ray läuft – und danach die Authentifizierung tatsächlich einzuschalten.

Quellen

• CISA: Adds One Known Exploited Vulnerability to Catalog (17.08.2026)
• Ray Project: Security Advisory GHSA-q279-jhrf-cc6v (CVE-2025-62593)
• Advisory: Ray – New Token Authentication is Disabled By Default
• Bitsight: RondoDox Botnet – From Zero to 174 Exploited Vulnerabilities
• Oligo Security: ShadowRay 2.0 (CVE-2023-48022)
• The Hacker News: CISA Flags Actively Exploited Ray Flaw (18.08.2026)
• The Register: CISA gives feds 3 days to fix actively exploited Ray RCE bug