Ray 2.58.0 se publicó a las 05:42 UTC del 23 de agosto. Entre las entradas de la sección de correcciones de Ray Serve hay una sola línea: corregir que la réplica de Serve ASGIService eludía la autenticación por token. No hay ningún aviso de seguridad adjunto, no se pidió un CVE y no se indica ninguna severidad.
Lo que dice la pull request
La PR #65189 es considerablemente más explícita que el changelog. El servidor gRPC interno en las réplicas de Serve “estaba construido con un grpc.aio.server() sin procesar y enlazado con add_insecure_port”, lo que lo convertía, en palabras del autor, en el único servidor gRPC del lado de Python en Ray que omitía ambos controles de transporte de Ray. Bajo RAY_AUTH_MODE=token, el servicio aceptaba solicitudes sin credenciales válidas y llegaba a pickle.loads(request.pickled_request_metadata) antes de realizar cualquier validación. Bajo RAY_USE_TLS=1, donde los demás servidores gRPC de Python de Ray usan mTLS, este puerto seguía sin cifrar.
Llegar a pickle.loads antes de la validación es todo el problema
Deserializar un pickle suministrado por un atacante es ejecución arbitraria de código por diseño: la propia documentación de Python lo dice. El orden es lo que importa aquí: la carga no confiable se deserializaba primero y se autenticaba después, lo que hace que la autenticación sea irrelevante en esa ruta y no solo débil.
La distorsión: no es un nuevo agujero, sino una brecha de cinco versiones
Ray introdujo la autenticación por token, descrita como aplicable a todos los componentes de Ray, en la versión 2.52.0. Este puerto no estaba cubierto por ella. Cualquiera que haya activado RAY_AUTH_MODE=token confiando en esa nota de versión ha estado ejecutando desde entonces un punto final de deserialización sin autenticación en cada réplica de Serve. La corrección no añade protección; cierra la distancia entre lo que se documentó y lo que era cierto.
La corrección precede al lanzamiento en dieciocho días
La PR #65189 se fusionó el 5 de agosto. Llegó a los operadores el 23 de agosto, cuando se publicó la 2.58.0. Durante esos dieciocho días, el parche permaneció legible en un repositorio público sin que ninguna versión lo incorporara: el coste habitual de corregir un problema de seguridad en abierto sin embargo, y la razón por la que la línea del changelog importa más de lo que su ubicación sugiere.
Qué deberían comprobar los operadores
La exposición depende del alcance de red, ya que el puerto se enlaza a través de interfaces en un puerto efímero. Los clústeres que importan son aquellos en los que las réplicas de Serve están en una red accesible para llamantes no confiables. La actualización mueve tanto el cliente como el servidor a los ayudantes gRPC compartidos de Ray, que aplican los interceptores y los ajustes TLS que el resto de Ray ya utilizaba.