CVE-2025-62593: CISA añade el fallo de Ray AI Compute al KEV y da tres días a las agencias federales
El 17 de agosto de 2026, la Agencia de Ciberseguridad y Seguridad de Infraestructura de EE.UU. (CISA) añadió una única vulnerabilidad a su catálogo de Vulnerabilidades Explota das Conocidas (KEV): CVE-2025-62593, una falla de inyección de código en Ray, el motor de cómputo distribuido open source que sustenta una proporción muy grande de la infraestructura de entrenamiento e inferencia de machine learning en producción. La fecha límite de remediación para las agencias de la Rama Ejecutiva Civil Federal fue el 20 de agosto de 2026 — tres días. La línea de tiempo comprimida refleja BOD 26-04, "Priorización de actualizaciones de seguridad basadas en riesgo", que reemplazó el reloj plano de catorce días de remediación KEV con un modelo escalonado por riesgo. Las vulnerabilidades en activos públicamente expuestos que otorgan control total del activo tras la explotación reciben los plazos más cortos. Ray califica en ambos frentes.
Este artículo recorre qué es CVE-2025-62593, por qué CISA actuó tan rápido, cómo funciona el ataque a nivel técnico y qué deben hacer en respuesta los equipos de plataforma, seguridad e infraestructura de IA.
Qué es realmente CVE-2025-62593
CVE-2025-62593 afecta a versiones de Ray anteriores a 2.52.0 y lleva una puntuación CVSS de 9.4. Es un fallo de protección contra ataques basados en navegador al dashboard y API de Ray. El mecanismo merece leerse con cuidado, porque es un pequeño error arquitectónico con un radio de impacto inusualmente grande.
Ray se distribuye con un dashboard y un conjunto de endpoints HTTP API pensados para correr en una workstation de desarrollador, un cluster de investigación o un entorno productivo interno. Dos de esos endpoints —`/api/jobs` y `/api/job_agent/jobs/`— aceptan envíos de jobs y son el mecanismo principal a través del cual los workloads entran al cluster. En las versiones vulnerables, esos endpoints no requieren autenticación.
El dashboard tenía una verificación basada en User-Agent pensada para evitar que los navegadores enviaran peticiones con cambio de estado. La verificación estaba incompleta: un atacante que pudiera construir una petición HTTP con una cabecera User-Agent no de navegador podía enviar jobs directamente a esos endpoints. Esa decisión arquitectónica —endpoints críticos alcanzables sin autenticación, con una verificación de User-Agent como única protección— es la superficie que CVE-2025-62593 explota. El atacante combina la ausencia de autenticación con un ataque de DNS rebinding que permite a una página web maliciosa en el navegador de la víctima alcanzar el servicio de Ray en su localhost.
Cómo funciona el ataque de extremo a extremo
El ataque requiere cuatro condiciones, cada una realista en un entorno de desarrollo: la víctima tiene un dashboard o API de Ray corriendo en su workstation accesible en `localhost` o la red local, visita una página maliciosa en Firefox o Safari (o recibe un anuncio malicioso), la página inicia un ataque de DNS rebinding que resuelve un nombre DNS controlado por el atacante a `127.0.0.1` después de una resolución inicial al servidor del atacante, y la página envía un job al endpoint de Ray en la dirección rebindeada.
El paso de DNS rebinding es el truco clave. La política same-origin típica trata dos URLs como mismo-origen si tienen el mismo esquema, host y puerto. Controlando la resolución DNS de un dominio que el atacante posee, puede hacer que el navegador cargue inicialmente contenido desde un servidor que controla, y luego rebindee el dominio a `127.0.0.1` para peticiones posteriores. El navegador sigue tratando las peticiones al dominio como mismo-origen mientras las peticiones se envían realmente al servicio de Ray en la propia máquina de la víctima. La verificación de User-Agent era sorteable porque el atacante puede construir una petición fetch con User-Agent personalizada o usar una funcionalidad del navegador que permita cabeceras no estándar. El resultado es que una página maliciosa puede enviar un job arbitrario a un cluster de Ray en la misma máquina que el navegador, ejecutando código controlado por el atacante con el privilegio del proceso Ray.
Línea de tiempo de divulgación y crédito
La vulnerabilidad tiene un historial de crédito estratificado. Los mantenedores de Ray publicaron un aviso en noviembre de 2025 que describía el problema de diseño y acreditaba a investigadores por trabajo relacionado. La cadena de ataque específica que produce RCE vía DNS rebinding fue desarrollada y divulgada por el investigador de Oligo Security Avi Lumelsky, con el crédito de la técnica de DNS rebinding correspondiendo al investigador independiente Jonathan Leitschuh. El parche fue liberado en Ray 2.52.0, recomendándose 2.52.1 para despliegues productivos.
El registro CVE y la adición al KEV llegaron varios meses después, el 17 de agosto de 2026, después de que CISA confirmara explotación activa. La elección de añadir este CVE en lugar de otro CVE distinto de Ray refleja el perfil de riesgo operacional: inyección de código, dirigida por navegador, sin autenticación requerida en endpoints críticos, explotable contra workstations de desarrollador, con PoC publicado.
Explotación activa en la naturaleza
La adición al KEV no es una precaución. CISA añadió el CVE después de confirmar explotación activa. BitSight reportó en marzo de 2026 que los operadores del botnet RondoDox habían incorporado CVE-2025-62593 a su toolkit antes de la divulgación pública, con un exploit PoC disponible para acelerar la integración. Oligo reportó por separado una campaña bautizada como ShadowRay 2.0 que apunta a clusters de Ray sin parchear equipados con GPUs NVIDIA, con el objetivo de convertir sistemas infectados en botnets auto-replicantes de minería de criptomonedas.
La campaña ShadowRay 2.0 es particularmente preocupante porque Ray es el estándar de facto para workloads distribuidos de GPU en AI/ML, y un cluster de Ray infectado tiene acceso tanto a cómputo significativo como a las credenciales cloud que el cluster usa para extraer datos y enviar jobs de entrenamiento. Un compromiso exitoso puede resultar en robo de datos de entrenamiento, robo de artefactos de modelo, robo de código fuente, abuso del cómputo de GPU para cryptomining y pivot al entorno cloud con el que el cluster está integrado.
Para organizaciones que ejecutan Ray en entornos AI/ML productivos, el modelo de amenaza es ahora "esperar compromiso" para cualquier despliegue de Ray que no haya sido parcheado a 2.52.0 o posterior, que no haya tenido autenticación por token habilitada y que no haya tenido reducida su exposición de red.
La respuesta federal y BOD 26-04
El plazo federal de remediación de tres días refleja el modelo BOD 26-04 escalonado por riesgo, que reemplazó el reloj plano de catorce días de remediación KEV. La directiva asigna los plazos más cortos a vulnerabilidades que otorgan control total del activo tras la explotación y que afectan a activos públicamente expuestos. Ray califica en ambos frentes: un exploit exitoso le da al atacante ejecución de código arbitraria como el proceso Ray, y muchos despliegues de Ray están pensados para ser alcanzables desde workstations de desarrollador, lo que hace que la superficie sea efectivamente pública desde la perspectiva de cualquier usuario con acceso a la red local.
La línea de tiempo comprimida no es arbitraria. El análisis de CISA, documentado en la entrada KEV y en la guía de soporte, concluye que el riesgo operacional de dejar CVE-2025-62593 sin parchear en un entorno federal es lo bastante alto como para justificar una ventana de tres días. Las agencias federales que no parchearon antes del 20 de agosto de 2026 están ahora en violación de BOD 26-04 y deben reportar su estado a CISA.
Para organizaciones no federales, la línea de tiempo federal comprimida es una señal útil. Si CISA cree que tres días es la ventana apropiada para la rama ejecutiva civil federal, esa es evidencia fuerte de que cualquier organización que ejecute Ray debería tratar el parche como urgente y no debería esperar a la próxima ventana regular de mantenimiento.
Mitigación y remediación
El playbook de mitigación para CVE-2025-62593 es directo, pero la disciplina operacional requerida no lo es.
1. **Actualizar Ray a 2.52.0 o posterior, preferentemente 2.52.1.** Esta es la mitigación primaria. La actualización debe aplicarse a cada despliegue de Ray, incluyendo workstations de desarrollador, clusters de investigación, entornos productivos internos y cualquier despliegue externo expuesto. 2. **Habilitar autenticación por token en cada cluster de Ray.** La autenticación por token se introdujo en Ray 2.52.0 y es la línea base recomendada para cualquier despliegue que no se asiente detrás de un límite de red estrictamente aislado. La documentación de Ray describe los pasos para generar un token de larga duración y configurar el cluster para requerirlo. 3. **Restringir el acceso de red a las interfaces de gestión de Ray.** Los endpoints de dashboard y API de Ray no deben estar expuestos a internet pública. No deben estar expuestos a la red corporativa más allá del conjunto de usuarios que genuinamente necesitan acceso. Donde el dashboard deba ser alcanzable, debe estar detrás de una VPN, un broker de zero-trust network access o un proxy reverso autenticado. 4. **Investigar los sistemas afectados en busca de signos de compromiso.** Cualquier despliegue de Ray que haya sido alcanzable entre la publicación del aviso de noviembre de 2025 y el momento del parcheo debe tratarse como potencialmente comprometido. Cosas específicas a buscar: jobs inesperados en el historial, procesos Python o shell inesperados lanzados por el proceso Ray, conexiones salientes a direcciones conocidas de pools de minería de criptomonedas, llamadas API cloud inesperadas desde el cluster, y cualquier modificación al código fuente de Ray, configuración o paquetes Python instalados. 5. **Revisar la cadena de suministro en busca de despliegues shadow de Ray.** Ray es fácil de instalar vía `pip install ray` y frecuentemente se añade a entornos de machine learning por desarrolladores individuales sin revisión formal. Un primer paso práctico es consultar tu herramienta de endpoint management o EDR en busca de instalaciones del paquete Python `ray` y procesos del dashboard de Ray.
Ingeniería de detección
Las señales de detección para un exploit activo de CVE-2025-62593 son razonablemente distintivas, porque el ataque involucra un envío dirigido por navegador a una API local. Cosas específicas a cazar:
- Conexiones de red desde un proceso de navegador a un puerto local que esté ejecutando Ray (puertos por defecto 8265 para el dashboard, 10001 para el client server y 8076 para el agent). - Envíos de jobs a un cluster de Ray desde una cadena User-Agent que no coincida con los patrones esperados de las librerías cliente comunes de Ray. - Entradas en el historial de jobs de Ray con nombres, líneas de comando o directorios de trabajo que no coincidan con el workload legítimo del propietario del cluster. - Procesos del cluster Ray que lancen procesos hijo inesperados, particularmente subprocesos Python o shell. - Conexiones salientes desde el cluster Ray a direcciones de pools de minería de criptomonedas o a dominios que no formen parte del workload legítimo.
Para organizaciones con cobertura EDR en workstations de desarrollador, una señal de alta fidelidad es un proceso Ray en una workstation que lanza un proceso hijo que hace conexiones de red salientes a un destino no allowlisteado. Para organizaciones con tooling de detección cloud-native, la señal equivalente es un cluster Ray corriendo en una VM cloud que hace llamadas IAM API que no forman parte del workload esperado.
Una detección inmediata práctica es alertar sobre cualquier despliegue de Ray que esté escuchando en una interfaz de red públicamente alcanzable. La configuración por defecto de Ray escucha en `0.0.0.0`, lo que significa que el dashboard es alcanzable desde cualquier red en la que esté el host. Para workstations en una red corporativa, eso significa que el dashboard es alcanzable desde cualquier otra workstation en el mismo segmento de red. La detección de un dashboard Ray escuchando en una interfaz pública es un indicador fuerte de que el despliegue está expuesto más allá de lo operacionalmente necesario.
La lección más amplia: localhost no es un límite de seguridad
CVE-2025-62593 pertenece a una clase de vulnerabilidades en las que la confianza depositada en `localhost` como límite de seguridad resulta no garantizada. El dashboard de Ray está pensado para ser alcanzado desde la misma máquina que lo ejecuta, asumiendo que la única persona que puede alcanzar `localhost:8265` es el desarrollador sentado frente al teclado. El ataque de DNS rebinding rompe esa asunción al permitir a un atacante remoto hacer peticiones HTTP que se originan en el navegador del desarrollador pero se dirigen a `localhost`. El patrón aparece repetidamente en herramientas de desarrollador —dashboards, plugins de IDE, frameworks de ML— que asumen que el único modelo de atacante es alguien sentado frente al teclado. La realidad en 2026 es que el navegador es la nueva superficie de ataque para estas herramientas, y cualquier herramienta que ejecute un servicio HTTP sin autenticar en localhost es candidata para la misma clase de bug. La lección arquitectónica es que las herramientas de desarrollador deberían requerir autenticación por defecto, vincularse a direcciones de host específicas en lugar de a `0.0.0.0`, requerir consentimiento explícito antes de vincularse a una interfaz accesible por red, y advertir en voz alta cuando una configuración por defecto se cambia de manera que expone el servicio más allá de localhost. Los mantenedores de Ray han progresado en estos defaults en la línea 2.52.x; el ecosistema más amplio tiene un largo camino por delante.
Qué hacer en las próximas 48 horas
Para cualquier organización que ejecute Ray, las próximas 48 horas son para cerrar la brecha entre la disponibilidad del parche y la realidad operacional. La secuencia: inventariar cada despliegue de Ray usando endpoint management o EDR, parchear cada uno a 2.52.0 o posterior (donde no sea posible, desactivar el dashboard y bloquear los puertos a nivel de red), habilitar autenticación por token en cada cluster, auditar los últimos 90 días de actividad buscando jobs, procesos o conexiones salientes inesperados, y comunicar el estado de la remediación al liderazgo ejecutivo. La pregunta a nivel de consejo es si la organización tiene algún despliegue sin parchear; si la respuesta es sí, ha aceptado el riesgo de dejar sin abordar una vulnerabilidad KEV activamente explotada.
Cierre
CVE-2025-62593 es el tipo de vulnerabilidad que la comunidad de seguridad lleva una década advirtiendo: infraestructura crítica, autenticación ausente, accesible por navegador, código de exploit público, explotación activa confirmada. La línea de tiempo comprimida de BOD 26-04 es la señal correcta: tres días es la ventana apropiada para una vulnerabilidad de este perfil. Las organizaciones que tarden más en parchear deberían tratar la brecha como un riesgo operacional a nivel ejecutivo, no como un elemento pendiente del backlog de TI.
Las fuentes verificadas incluyen la entrada KEV de CISA del 17 de agosto de 2026, el write-up técnico de Resecurity sobre DNS rebinding, el reporte de BitSight de marzo de 2026 sobre RondoDox, la cobertura de Hacker News, el análisis de Compliance Hub Wiki sobre BOD 26-04 y las notas de Oligo Security sobre ShadowRay 2.0.