El 17 de agosto de 2026, CISA metió a CVE-2025-62593 en su catálogo de Vulnerabilidades Explotadas Conocidas (KEV) y le dio a las agencias federales de EE.UU. un plazo brutal: tres días para parchear, en lugar de los catorce habituales. La falla vive en Ray, el framework de cómputo distribuido que mueve buena parte de las cargas de IA en Python, y lo inquietante no es solo que sea una RCE crítica: es que una botnet ya la estaba explotando dos días antes de que el CVE existiera.
CVE-2025-62593 es una vulnerabilidad crítica de ejecución remota de código (RCE), con CVSS 9.4, en el dashboard y la API de Ray —el motor de cómputo distribuido de Anyscale para escalar aplicaciones de IA y Python— en todas las versiones anteriores a la 2.52.0. Combina DNS rebinding con un bypass del control de User-Agent para ejecutar código en la máquina de un desarrollador que corre Ray localmente y visita un sitio malicioso. Se corrige actualizando a Ray 2.52.0.
¿Qué es Ray y por qué una RCE en su dashboard es tan grave?
Ray es el framework open source que usás cuando una carga de entrenamiento, inferencia o tuning ya no entra en una sola máquina. Reparte tareas de Python sobre un clúster, expone un dashboard web y una API HTTP para lanzar y monitorear jobs, y es infraestructura básica en el mundo de la IA: según los datos citados por The Hacker News, ronda el millón de usuarios activos mensuales y lo usa cerca del 60% de las empresas Fortune 500.
El problema es que ese dashboard y esa API nacieron para correr dentro de una red de confianza. Los endpoints que lanzan trabajos —/api/jobs, /api/job_agent/jobs/— no piden autenticación: si podés hablarles, podés hacer que el clúster ejecute código arbitrario. Ahí está el nudo: cualquier cosa que logre alcanzar tu API local de Ray ya tiene, de hecho, una shell.
¿Cómo funciona el ataque de DNS rebinding contra Ray?
El ataque convierte una visita web en ejecución de código sin que vos hagas nada más que abrir una página. Ray sabía que el navegador era un vector y puso una defensa: rechazaba peticiones cuyo header User-Agent empezara con Mozilla, asumiendo que así bloqueaba el tráfico originado en un browser. La trampa es que esa barrera se esquiva.
La cadena, según la reconstrucción técnica publicada en Mallory, encaja dos piezas:
- Bypass del guard de User-Agent. Firefox y Safari permiten que un script modifique el header
User-Agentvía la Fetch API. El atacante lo reescribe para que no arranque conMozillay la validación de Ray lo deja pasar. El bypass del fetch lo descubrió Avi Lumelsky, investigador de Oligo Security. - DNS rebinding para llegar a localhost. Un sitio malicioso empieza resolviendo su dominio a su propia IP y, tras la primera carga, lo re-resuelve a
127.0.0.1. Para el navegador sigue siendo el "mismo origen", así que el JavaScript de la página termina hablándole a tu Ray local. Esta pieza la aportó el investigador Jonathan Leitschuh.
Con las dos combinadas, alcanza con que un dev que corre Ray visite un sitio trucho —o que le sirvan un aviso publicitario malicioso— en Firefox o Safari para que se ejecute shellcode en su máquina. No hay clic en un adjunto, no hay instalador: es el navegador el que dispara la RCE.
¿Quién es RondoDox y por qué explotó el bug antes del CVE?
RondoDox es una botnet de DDoS que sumó CVE-2025-62593 a su arsenal el 24 de noviembre de 2025, dos días antes de que el CVE se publicara oficialmente el 26 de noviembre. El dato viene de un informe de Bitsight de marzo de 2026, recogido por Security Affairs, y la conclusión de los investigadores es incómoda: los operadores no esperaron al CVE, estaban siguiendo la investigación pública de vulnerabilidades y armaron el exploit apenas apareció el material.
Es el patrón que se está normalizando y que un developer debería internalizar: la ventana entre "se conoce la técnica" y "hay una botnet pegándole" se mide en horas, no en semanas. Confiar en que un bug recién divulgado "todavía no lo explota nadie" es, cada vez más, una apuesta perdida. Para RondoDox, un clúster de Ray comprometido no es un fin en sí mismo: es capacidad de cómputo y ancho de banda gratis para sumar a sus campañas.
¿Por qué CISA dio solo 3 días para parchear?
Porque la explotación es activa y el objetivo son máquinas de desarrolladores, no servidores anónimos. Al incluir CVE-2025-62593 en el KEV el 17 de agosto de 2026, CISA fijó el 20 de agosto como fecha límite para las agencias civiles federales (FCEB), según reportó The Register. Ese plazo de 72 horas —contra los 14 días estándar del programa— es la señal de que el riesgo se considera inmediato.
El detalle que lo hace peor: una RCE en la workstation de un dev suele ser un mejor punto de entrada que un servidor de producción. Esa máquina tiene claves SSH, tokens de cloud, credenciales de repos y, muchas veces, una VPN abierta a la red corporativa. Comprometerla es comprometer la cadena entera.
¿Ray no tenía autenticación? La sombra de ShadowRay
No, y esa es una historia vieja en Ray. La postura del proyecto siempre fue que el clúster debe vivir en una red controlada, no que la API deba autenticar por defecto. En 2024, Oligo Security bautizó "ShadowRay" a CVE-2023-48022 (CVSS 9.8), una falta de autorización en la Jobs API que estuvo bajo explotación activa durante meses contra empresas de salud, educación y analítica de video.
Lo llamativo: Anyscale disputó ese CVE. Sostuvo que la documentación deja claro que Ray no debe exponerse fuera de un entorno de red controlado y que ese comportamiento es una característica del producto, no un bug —por eso CVE-2023-48022 quedó marcado como "disputado" y sin parche durante mucho tiempo. La consecuencia de esa filosofía "seguro solo si lo aislás vos" es que millones de instalaciones quedaron sin ninguna barrera cuando el aislamiento fallaba. CVE-2025-62593 es la evolución del mismo problema: ahora ni siquiera hace falta exponer Ray a internet, alcanza con el navegador del propio dev.
Con la 2.52.0, Anyscale finalmente introdujo autenticación por token en Ray. La letra chica, según The Register, es que viene deshabilitada por defecto y el proyecto sigue recomendando el despliegue en redes controladas.
¿Qué podés hacer hoy si usás Ray?
La tarea inmediata es concreta: encontrá toda instalación de Ray anterior a la 2.52.0 y actualizala. Después, endurecé el resto.
- Actualizá a Ray 2.52.0 o superior, ya. Es la versión que corrige CVE-2025-62593. Revisá los entornos que solés olvidar: notebooks locales, imágenes de Docker viejas, entornos virtuales de proyectos parados, runners de CI.
- Prendé la autenticación por token. La 2.52.0 la trae pero apagada; activala explícitamente. No dejes que la única defensa sea "asumo que nadie llega a mi API".
- Bindeá el dashboard a localhost o a una interfaz privada. Nunca expongas el puerto del dashboard (por defecto
8265) ni la API a internet. Si necesitás acceso remoto, hacelo por túnel SSH o VPN, no publicando el puerto. - Aislá el clúster en una red controlada. Es la recomendación de siempre de Anyscale y sigue vigente: corré Ray dentro de una subred privada, detrás de un firewall, en tu propio cloud server, sin ruta directa desde el exterior.
- Auditá exposición hacia afuera. Buscá cualquier puerto de Ray accesible desde internet en tu infraestructura. Un dashboard expuesto es una RCE esperando ocurrir, con o sin este CVE.
- Cuidá la máquina del dev. Mientras corras Ray localmente, tené el navegador al día y considerá no navegar sitios de dudosa procedencia en la misma sesión. El vector de este CVE es, literalmente, tu browser.
Preguntas frecuentes
¿Qué versión de Ray corrige CVE-2025-62593?
Ray 2.52.0. Todas las versiones anteriores son vulnerables, así que la mitigación es actualizar a la 2.52.0 o superior.
¿Estoy en riesgo si mi clúster de Ray no está expuesto a internet?
Sí, y ese es el giro de este CVE. El ataque no necesita que tu API esté publicada: usa DNS rebinding para que el navegador de un desarrollador que corre Ray en su propia máquina alcance la API local en 127.0.0.1. Alcanza con visitar un sitio malicioso en Firefox o Safari.
¿Qué navegadores permiten este ataque?
Firefox y Safari. Ambos permiten que un script modifique el header User-Agent mediante la Fetch API, que es lo que se usa para saltear la validación de Ray. Ese bypass es la pieza que habilita el resto de la cadena.
¿Qué es RondoDox y qué hace con un clúster comprometido?
RondoDox es una botnet de DDoS que integró CVE-2025-62593 a su arsenal antes incluso de la publicación del CVE. Con un clúster de Ray comprometido, suma capacidad de cómputo y ancho de banda para sus campañas de ataque.
¿Por qué CISA dio solo 3 días en vez de los 14 habituales?
Por la explotación activa y por el tipo de objetivo. Una RCE en la workstation de un desarrollador da acceso a credenciales, claves y VPNs, lo que la vuelve un punto de entrada especialmente valioso. CISA fijó el 20 de agosto de 2026 como límite para las agencias federales.
¿Alcanza con actualizar o tengo que hacer algo más?
Actualizar a 2.52.0 cierra la vulnerabilidad, pero conviene además prender la autenticación por token (viene apagada por defecto), bindear el dashboard a localhost o una red privada y verificar que ningún puerto de Ray quede expuesto a internet.
Si querés seguir el hilo de este tipo de fallas en infraestructura de contenedores y clústeres, te pueden interesar nuestras notas sobre MCPocalipsis: 30 CVEs en 60 días y tus claves en la mira y CVE-2026-24512: un path de Ingress que da RCE en Kubernetes, que atacan el mismo patrón desde otro ángulo. Para el fondo técnico de este caso, las referencias son el análisis de Mallory y la cobertura de The Hacker News.
Cloud Serversby Donweb
Todo el poder de la nube a tus proyectos y aplicaciones.
Alojamiento ultra rápido, escalable y con alta disponibilidad.
- Performance que te sorprenderá
- Rápida escalabilidad y sin limitaciones
- Arquitectura de alta disponibilidad
- Soporte experto y ejecutivos de cuenta
- Pagos en tu moneda y facturación local
