CISA añadió CVE-2025-62593, una vulnerabilidad de inyección de código en el framework de IA Ray, a su catálogo de vulnerabilidades conocidas explotadas el 17 de agosto de 2026. El proyecto Ray indica que las versiones anteriores a la 2.52.0 están afectadas y que la versión 2.52.0 corrige el problema. Su aviso describe una ruta de DNS rebinding basada en el navegador que puede permitir la ejecución de código arbitrario contra un servicio Ray local utilizado por un desarrollador.
Se trata de una señal actual de explotación para una divulgación anterior, no de una prueba de que todos los despliegues de Ray estén expuestos. El aviso del proveedor se publicó el 26 de noviembre de 2025 y describe de forma específica una ruta que implica Firefox o Safari, un sitio web malicioso y un servicio local de desarrollo con Ray en ejecución. Los equipos deben comprobar si esas condiciones existen en su entorno antes de describir el impacto.
Qué dice CISA sobre la vulnerabilidad del framework de IA Ray
El catálogo de CISA denomina a CVE-2025-62593 Ray Code Injection Vulnerability. La entrada del 17 de agosto señala que el problema puede permitir la ejecución remota de código y registra el 20 de agosto de 2026 como fecha límite de corrección para las agencias federales estadounidenses cubiertas por la directiva aplicable de CISA. El uso conocido por ransomware figura como unknown. Desconocido no significa ausente. Significa que el catálogo no atribuye un uso conocido por ransomware en ese campo.
La inclusión en el catálogo significa que CISA tiene pruebas de explotación real. La entrada pública no identifica víctimas, volumen de explotación, identidad del atacante ni una campaña. Esos detalles no deben inferirse del estado del catálogo. Para las organizaciones fuera del ámbito federal de la directiva, la fecha límite es una señal útil de urgencia, no un plazo legal general.
Cómo funciona la ruta del navegador al servicio local
El aviso de seguridad del proyecto Ray explica el alcance técnico. Según el proyecto, un atacante puede usar DNS rebinding desde un sitio web malicioso para hacer que las solicitudes del navegador lleguen a un servicio Ray en el equipo de un desarrollador. El aviso identifica Firefox y Safari como los navegadores de la ruta de exposición demostrada. Si tiene éxito, el atacante puede enviar trabajo a Ray y ejecutar código con los permisos disponibles para ese servicio.
Esto importa porque un servicio que parece local puede seguir siendo accesible mediante una solicitud mediada por el navegador. Tratar la interfaz de bucle local como autenticación suficiente deja una brecha cuando el comportamiento del navegador y el DNS permiten que un origen no confiable se dirija al servicio. El registro de NVD ofrece la ficha pública de la CVE y remite a los defensores al aviso del proveedor y a las referencias relacionadas.
Las condiciones son importantes. El aviso no establece que todos los clústeres de producción, servicios administrados de Ray o navegadores sean vulnerables de la misma forma. La exposición depende de la versión de Ray, de si el servicio relevante se ejecuta y es accesible, del comportamiento del navegador, de la configuración de red y de los privilegios del proceso de Ray. El aviso indica que Chrome no está afectado por la ruta demostrada. Aun así, los equipos deben probar sus versiones y configuraciones.
Por qué es un problema de gobernanza de la infraestructura de IA
Ray se utiliza para distribuir cargas de Python e inteligencia artificial. Por ello, un servicio Ray local comprometido puede estar cerca del código fuente, artefactos de modelos, conjuntos de datos, credenciales de nube, notebooks y acceso de desarrollo. El problema inmediato es la ejecución de código. La consecuencia para la gobernanza es la pérdida de confianza en quién inició una carga, qué datos utilizó y si los artefactos resultantes son fiables.
Una respuesta precisa comienza con el inventario. Los equipos de seguridad necesitan saber dónde está instalado Ray, qué versiones están presentes, quién inicia los servicios locales, qué rutas del navegador se permiten y a qué credenciales o almacenamiento pueden acceder esos procesos. La guía de Maetra sobre cómo crear un inventario de agentes de IA ofrece un modelo útil para registrar propietarios, entornos, permisos y dependencias, en lugar de mantener solo una lista de paquetes.
Respuesta operativa para equipos de seguridad y plataforma
Aplique las siguientes comprobaciones a estaciones de desarrollo, notebooks, entornos de compilación, sistemas de investigación y plataformas de IA compartidas:
- Localizar instalaciones y servicios Ray en ejecución, y registrar la versión, el host, el propietario, el método de inicio y el propósito del entorno.
- Actualizar las instalaciones afectadas a Ray 2.52.0 o posterior, siguiendo el aviso del proveedor y los controles normales de cambios.
- Si la actualización no puede completarse de inmediato, detener el servicio o aplicar la mitigación recomendada por el proveedor, y documentar al responsable y la caducidad de la excepción.
- Revisar si los servicios Ray locales confían en la ubicación de red como único límite. Añadir controles de autenticación, enlace, cortafuegos y origen del navegador adecuados al entorno.
- Rotar credenciales y revisar los registros relevantes cuando un servicio expuesto se ejecutó con acceso a repositorios de código, tokens de nube, conjuntos de datos o artefactos de modelos.
- Probar la ruta del navegador y del DNS en un entorno aislado. No asumir que una configuración está protegida solo porque el servicio usa localhost.
- Conservar para cada sistema afectado evidencia de la versión corregida, el reinicio del servicio, la prueba de exposición y la decisión de revisión.
- Supervisar tareas de Ray, creación de procesos, uso de herramientas y conexiones salientes para detectar comportamientos contrarios al propósito aprobado.
El último paso sigue siendo importante después del parche. La guía de Maetra sobre cómo supervisar el comportamiento arriesgado de los agentes de IA muestra cómo conectar acciones relevantes con un responsable, una decisión de política y un registro revisable.
Análisis de Maetra: los servicios locales de IA necesitan límites de confianza explícitos
La lección general es que la infraestructura local de IA no tiene automáticamente un riesgo bajo. Los servicios de desarrollo suelen combinar una ejecución potente con valores predeterminados cómodos y un acceso amplio al entorno del usuario. El navegador puede convertirse en un puente inesperado entre un sitio no confiable y esa capacidad local.
Los equipos deben definir el límite de confianza de cada servicio de IA en términos de identidad, origen, ruta de red, privilegios del proceso, acceso a datos y acciones observables. El estado del parche es un control de ese modelo. No sustituye la revisión de credenciales, el privilegio mínimo, los registros ni la evidencia de que la ruta expuesta está cerrada.
Un siguiente paso práctico es añadir los servicios Ray al inventario de sistemas de IA, vincular cada entrada a su registro de vulnerabilidad y parche, y exigir que un propietario confirme la versión actual y las interfaces accesibles. Después, los equipos pueden usar el flujo Secure de Maetra para examinar los límites de herramientas y acciones, mientras mantienen la corrección de la infraestructura dentro de su proceso de seguridad establecido.
Fuentes
- CISA: catálogo JSON de Known Exploited Vulnerabilities, CVE-2025-62593 añadida el 17 de agosto de 2026.
- Proyecto Ray: aviso de seguridad GHSA-q279-jhrf-cc6v, publicado el 26 de noviembre de 2025.
- NIST National Vulnerability Database: CVE-2025-62593, registro público de la vulnerabilidad.