La puerta silenciosa de Ray: cómo CVE-2025-62593 permite ejecutar código a través del navegador
Cuando el equipo de investigación de Anthropic liberó Ray como framework de código abierto para escalar cargas de trabajo de Python e inteligencia artificial, tomó una decisión arquitectónica que ha vuelto a aparecer como vulnerabilidad crítica tres veces en apenas dos años: los endpoints más poderosos de un cluster de Ray nunca requerirían autenticación. El endpoint /api/jobs, el que se usa para enviar y gestionar trabajos distribuidos, ha permanecido abierto desde las primeras versiones del proyecto. En agosto de 2026, esa decisión se convirtió en un incidente federal.
El CVE-2025-62593 fue incorporado al catálogo de Vulnerabilidades Explotadas Conocidas (KEV) de CISA el 17 de agosto de 2026, con fecha límite de remediación del 20 de agosto de 2026 para las agencias federales. La puntuación base CVSS 3.1 es de 9,4. La clasificación SSVC de CISA, actualizada el mismo día de la publicación, marca la explotación como "activa", automatizable como "no" e impacto técnico como "total". Es la tercera vez en veinticuatro meses que la ausencia de autenticación en los endpoints de envío de trabajos de Ray produce un CVE crítico, y la primera vez que el vector de explotación se desplaza desde la red hacia el navegador.
La cadena, paso a paso
El CVE-2025-62593 no es una vulnerabilidad de corrupción de memoria. Es la convergencia de tres debilidades que se entienden bien por separado, pero que nunca se habían combinado de esta forma contra un framework de desarrollo.
La primera debilidad es el endpoint sin autenticación. Los endpoints /api/jobs y /api/job_agent/jobs/ de Ray aceptan envíos de trabajo desde cualquier cliente que pueda alcanzar el puerto HTTP del dashboard. Por defecto es el 8265, pero en despliegues personalizados los puertos de servicio (6379, 10001) quedan frecuentemente expuestos. La API de envío de trabajos recibe una especificación de entorno de ejecución; el Raylet del nodo destino la procesa; en versiones anteriores a la 2.52.0, ese camino de procesamiento incluía validación insuficiente de qué campos se honraban cuando la petición llegaba con un User-Agent de navegador.
La segunda debilidad es el manejo del User-Agent. Según el propio aviso del equipo mantenedor de Ray, el problema nace de "controles insuficientes contra ataques basados en navegador, específicamente en escenarios donde la cabecera User-Agent puede ser modificada". El camino de código de Ray para el envío de trabajos no distinguía adecuadamente entre un cliente real de Ray, que usa un runtime personalizado y emite una huella distintiva, y una petición originada desde una página web maliciosa ejecutándose en Firefox o Safari.
La tercera debilidad es el DNS rebinding. Los navegadores modernos implementan distintos grados de protección contra DNS rebinding: Chrome ancla y rechaza los intentos de rebinding contra localhost, Firefox tiene controles más débiles, Safari históricamente el más débil. El ataque funciona sirviendo un hostname que inicialmente resuelve a un servidor controlado por el atacante, y luego cambia la respuesta DNS después de que el navegador ha cacheado la resolución original. Cuando el rebinding tiene éxito, la página maliciosa puede hacer peticiones a 127.0.0.1 en cualquier puerto, saltándose la política de mismo origen que normalmente impide a una página web hablar con servicios locales.
La cadena se desarrolla así: un desarrollador que ejecuta Ray en su workstation visita una página maliciosa o recibe un anuncio malicioso. La página inicia un ataque de DNS rebinding contra localhost:8265. Cuando el rebinding tiene éxito, la página envía un trabajo a la API de Ray con un payload que embebe comandos de shell en la especificación del entorno de ejecución. El cluster de Ray ejecuta esos comandos con los privilegios del usuario que corre el proceso de Ray.
Quién está expuesto
Las víctimas primarias son desarrolladores que ejecutan Ray en entornos de desarrollo y pruebas: ingenieros de machine learning iterando sobre entrenamientos, científicos de datos explorando datasets, equipos de plataforma corriendo Ray sobre infraestructura compartida para experimentación. El diseño de Ray como framework orientado a desarrolladores hace que los despliegues en producción sean menos comunes, pero la superficie de exposición en entornos de desarrollo es enorme.
El riesgo se amplifica con los patrones de despliegue típicos de las cargas de ML. Los clusters de Ray se levantan con frecuencia en instancias cloud con el puerto del dashboard expuesto para acceso remoto desde un portátil. Los desarrolladores que corren Ray en su workstation suelen tener código fuente, secretos en variables de entorno, claves SSH para sistemas de producción y credenciales para APIs cloud en el mismo contexto. Un RCE exitoso le da al atacante no solo la máquina local, sino un pivote hacia toda la infraestructura a la que el desarrollador puede llegar.
Los pipelines de CI y CD merecen atención particular. Muchos equipos integran Ray en sus pipelines de entrenamiento, ejecutando Ray a menudo en instancias de larga vida que custodian credenciales de object storage, registros de contenedores y repositorios de artefactos de modelos. La vulnerabilidad no exige que el atacante conozca la ubicación en red del cluster; el DNS rebinding opera contra localhost, y cualquier navegador ejecutándose en la misma máquina que un proceso Ray es un objetivo viable.
Para los clusters de Ray alojados en cloud, la situación es más matizada. Si el puerto del dashboard del cluster queda expuesto mediante una IP pública, un patrón habitual para que desarrolladores remotos se conecten desde sus portátiles, entonces el CVE-2025-62593 es explotable en remoto sin necesidad del componente de DNS rebinding. El ataque basado en navegador es la novedad, pero el endpoint sin autenticación subyacente ha sido explotable en remoto sobre clusters mal configurados durante años.
Parcheo y particularidades de versión
El CVE-2025-62593 afecta a versiones de Ray anteriores a la 2.52.0. El arreglo se commiteó upstream y se publicó como versión 2.52.0. El parche aborda el manejo del User-Agent en los endpoints afectados y añade validación adicional al camino de procesamiento del entorno de ejecución.
Para equipos que corren Ray sobre Kubernetes vía KubeRay, la actualización depende de la versión del operador. KubeRay 1.14.0 y posteriores soportan Ray 2.52.0. Hay que verificar que el chart de Helm o el despliegue del operador permita el override de imagen y luego actualizar el tag de la imagen de Ray. Se admiten reinicios progresivos.
Para equipos que corren Ray directamente sobre máquinas virtuales o bare metal, el upgrade es un reinicio de proceso. El head node y los workers de Ray deben reiniciarse para cargar el nuevo binario. No existe un parche in-place.
Para entornos donde un upgrade inmediato no es viable, cuatro mitigaciones reducen la superficie de ataque sin eliminar la vulnerabilidad.
Los controles a nivel de red son lo primero. Restringe el puerto del dashboard de Ray a rangos IP conocidos. Sobre infraestructura cloud, asegúrate de que los grupos de seguridad no exponen 8265, 6379, 10001 ni otros puertos de servicio de Ray al internet público. Esta es la mitigación de mayor impacto y debería ser práctica estándar independientemente del estado del CVE.
Un proxy inverso con autenticación es la segunda palanca. Coloca un proxy inverso que requiera autenticación frente al dashboard. nginx, Envoy o Caddy pueden terminar TLS y exigir un bearer token válido antes de reenviar al cluster de Ray. Esto aborda tanto el CVE-2025-62593 como la categoría amplia de problemas de endpoints sin autenticación.
Desactivar el acceso basado en navegador es la tercera opción. Equipos que no requieren acceso por navegador al dashboard de Ray pueden mitigar el CVE-2025-62593 específicamente asegurando que el dashboard solo se acceda mediante clientes programáticos con User-Agents que no sean de navegador. Esto es parcial, el problema de endpoint sin autenticación de fondo persiste, pero elimina el vector de ataque concreto.
Las protecciones de DNS rebinding a nivel de navegador son la cuarta tirita. Los usuarios de Firefox pueden habilitar network.dns.disableIPv6 y network.dns.disablePrefetch. Los usuarios de Safari deben asegurarse de correr la última versión. Todo esto reduce la ventana de rebinding pero no la elimina.
Lo que esto dice sobre el modelo de seguridad de Ray
El aviso de los mantenedores de Ray es inusualmente franco sobre la causa raíz: "Due to the longstanding decision by the Ray Development team to not implement any sort of authentication on critical endpoints, like the /api/jobs & /api/job_agent/jobs/, has once again led to a severe vulnerability that allows attackers to execute arbitrary code against Ray." La frase "una vez más" es significativa. CVE-2022-1525, CVE-2023-0706 y CVE-2023-48022 siguieron el mismo patrón. Cada vez la causa raíz era idéntica. Cada vez el arreglo fue un endurecimiento específico del endpoint o un parche temporal que dejaba intacto el problema arquitectónico.
Ray no es único en hacer esta compensación. Muchas herramientas orientadas a desarrolladores se envían con defaults permisivos asumiendo que el usuario opera en un entorno confiable. Kubernetes exige autenticación en su API server pero los permisos de la service account por defecto son amplios y el kubelet ha tenido históricamente autenticación más débil que el plano de control. Los sockets del daemon de Docker son una superficie de ataque desde los inicios del proyecto. El problema con Ray no es que haya tomado una única mala decisión; es que la decisión se institucionalizó y se defendió como feature en lugar de reconocerse como pasivo.
Para equipos que evalúan Ray para uso en producción, el CVE-2025-62593 es un marcador. No es razón para evitar Ray, porque las capacidades del framework para cargas de ML distribuido siguen siendo inigualables en el ecosistema open source, pero sí es razón para tratar cualquier despliegue de Ray con la misma disciplina operativa aplicada a cualquier servicio crítico de producción. Eso significa autenticación en el borde de red, monitorización del puerto del dashboard para accesos anómalos y un camino de upgrade documentado que se pueda ejecutar en horas cuando se publique un CVE crítico.
Detección y hunting
Los equipos blue team que buscan signos de explotación deben enfocarse en tres fuentes de telemetría.
Los logs del cluster de Ray son la primera. Envíos de trabajo desde fuentes inesperadas, particularmente con cadenas User-Agent de navegador u originadas desde direcciones IP no asociadas a clientes conocidos, son una alerta roja inmediata. El logging de Ray captura los metadatos de envío de trabajo incluido el User-Agent, y el cliente legítimo de Ray usa una huella distintiva que no coincide con ningún navegador mainstream.
La telemetría de ejecución de procesos en hosts que corren Ray es la segunda fuente. Una cadena de RCE exitosa vía CVE-2025-62593 hace que el proceso de Ray genere un proceso hijo para ejecutar el payload del atacante. En Linux esto se manifiesta como un hijo del proceso Python de Ray invocando una shell (/bin/sh, /bin/bash) o una utilidad de red (curl, wget, nc). Los productos EDR deben marcar procesos hijos del runtime de Ray que no encajen con el perfil esperado de trabajo de entrenamiento, especialmente los que aparecen poco después de una resolución DNS saliente hacia un dominio recién registrado.
Los patrones de resolución DNS son la tercera. Los ataques de DNS rebinding se apoyan en que el servidor DNS del atacante devuelve una segunda respuesta con una dirección IP distinta de la primera. Monitoriza patrones de consulta DNS con TTL cortos a hostnames que luego resuelven a direcciones RFC1918 o a localhost. La mayoría de resolvers corporativos registran estas transiciones; la dificultad está en correlacionarlas con actividad del lado del navegador, lo que típicamente requiere telemetría de endpoint.
La foto completa
El CVE-2025-62593 es un caso de estudio útil porque combina múltiples clases de vulnerabilidad, incluyendo endpoints sin autenticación, superficies de ataque basadas en navegador y primitivas de DNS rebinding, en un único RCE de alto impacto. Cada componente se ha estudiado extensamente por separado. Juntos producen una cadena que evade las defensas típicas en las que confían los desarrolladores para sus herramientas locales.
La lección no es nueva pero merece repetirse: las herramientas orientadas a desarrolladores que son fáciles de usar localmente también son fáciles de atacar localmente. Las mismas características que hacen agradable iterar trabajos de entrenamiento con Ray (exposición automática de puertos, defaults permisivos, sin requisitos de autenticación) lo convierten en objetivo. Conforme más infraestructura de AI y ML se mueve a entornos de producción, el límite de seguridad entre herramientas locales de desarrollador e infraestructura de producción seguirá difuminándose. El CVE-2025-62593 es un anticipo del tipo de incidente que produce esa difuminación.
Para los equipos de plataforma, la conclusión práctica es directa: inventaría cada despliegue de Ray en tu organización, verifica la versión, aplica el upgrade a 2.52.0 o superior y asegúrate de que el dashboard no esté expuesto más allá del borde de red donde opera el desarrollador. Para los desarrolladores, la lección es asumir que cualquier herramienta que corre en tu workstation con exposición de red forma parte de tu superficie de ataque, porque lo es. Trata los servicios locales con el mismo escepticimo que aplicarías a un endpoint público de producción, y el próximo CVE de esta categoría se convierte en una revisión de configuración en lugar de una respuesta a incidente.
Obligaciones de cumplimiento y reporte
Para organizaciones sujetas a reportes regulatorios, el CVE-2025-62593 acarrea obligaciones específicas que vale la pena anotar. Bajo la Binding Operational Directive 22-01 de CISA, las agencias federales deben remediar las vulnerabilidades listadas en el catálogo KEV dentro del plazo prescrito; la fecha límite del 20 de agosto de 2026 para este CVE fue de tres días desde la publicación. Las organizaciones que operan bajo PCI-DSS, HIPAA o SOC 2 deben tratar los CVEs listados en KEV como hallazgos prioritarios para sus propios SLA internos de parcheo, aunque esos marcos no referencien directamente el catálogo KEV. Las aseguradoras cibernéticas exigen cada vez más evidencia de remediación KEV dentro de la ventana mandada por CISA como condición de cobertura, y la falta de parcheo dentro de esa ventana se ha citado en disputas post-incidente como evidencia de negligencia.
Si tu organización corre Ray y descubres indicadores de explotación, el playbook de respuesta a incidentes debe tratarlo como compromiso de workstation o de runner de CI, no como evento de un único host. Las credenciales accesibles al usuario que corría Ray en el momento de la explotación deben considerarse expuestas; los secretos en variables de entorno, claves SSH, credenciales cloud y tokens de repositorios de código necesitan rotación. El análisis forense debe enfocarse en el árbol de procesos de Ray, la cuenta de usuario propietaria del proceso de Ray y cualquier conexión de red saliente iniciada por procesos hijos del runtime de Ray en los días próximos a la ventana de compromiso sospechada.
La lección mayor para los equipos de seguridad es dejar de tratar las workstations de desarrolladores como entornos confiables. El incidente de Ray es uno más de una categoría creciente en la que una vulnerabilidad en una herramienta de desarrollador produce un camino hacia infraestructura de producción. El mismo patrón aparece en vulnerabilidades de IDE, compromisos de runners de CI y cadenas de escape de contenedores desde hosts de build. Cada una de esas categorías comparte un tema común: el entorno de desarrollador está en el camino crítico hacia producción, pero su postura de seguridad rara vez se mide con el mismo estándar que el entorno de producción. El CVE-2025-62593 es un recordatorio de que esta brecha tiene costos, y esos costos están cayendo ahora sobre los mismos equipos de respuesta a incidentes a los que se les dijo que las herramientas locales no eran su problema.