Ray 2.58.0 est sorti à 05:42 UTC le 23 août. Parmi les entrées de la section des correctifs de Ray Serve figure une seule ligne : correction de ASGIService du réplica Serve qui contournait l'authentification par jeton. Aucun avis de sécurité n'est associé, aucune CVE n'a été demandée, et aucun niveau de gravité n'est indiqué.

Ce que dit la pull request

La PR #65189 est nettement plus explicite que le changelog. Le serveur gRPC interne des réplicas Serve « was built with a raw grpc.aio.server() and bound with add_insecure_port », ce qui en faisait, selon l'auteur, le seul serveur gRPC côté Python dans Ray à contourner les deux contrôles de transport de Ray. Sous RAY_AUTH_MODE=token, le service acceptait des requêtes dépourvues d'identifiants valides et atteignait pickle.loads(request.pickled_request_metadata) avant toute validation. Sous RAY_USE_TLS=1, où les autres serveurs gRPC Python de Ray utilisent mTLS, ce port restait non chiffré.

Atteindre pickle.loads avant la validation est tout le problème

Désérialiser un pickle fourni par un attaquant équivaut, par conception, à une exécution de code arbitraire — la documentation de Python le dit elle-même. Ici, c'est l'ordre qui compte : la charge utile non fiable était désérialisée d'abord et authentifiée ensuite, ce qui rend l'authentification sans effet sur ce trajet plutôt que simplement faible.

La distorsion : non pas une nouvelle faille, mais un écart de cinq versions

Ray a introduit une authentification par jeton censée couvrir tous les composants Ray dans la version 2.52.0. Ce port n'était pas couvert. Toute personne ayant activé RAY_AUTH_MODE=token en se fiant à cette note de version a, depuis, fait tourner un point de désérialisation non authentifié sur chaque réplica Serve. Le correctif n'ajoute pas de protection ; il comble l'écart entre ce qui était documenté et ce qui était réel.

Le correctif précède la sortie de dix-huit jours

La PR #65189 a fusionné le 5 août. Elle est parvenue aux opérateurs le 23 août, lors de la publication de 2.58.0. Pendant ces dix-huit jours, le correctif est resté consultable dans un dépôt public sans qu'aucune version ne l'intègre — le coût habituel de la correction ouverte d'un problème de sécurité sans embargo, et la raison pour laquelle la ligne du changelog compte davantage que sa place ne le suggère.

Ce que les opérateurs doivent vérifier

L'exposition dépend de la portée réseau, puisque le port se lie à travers les interfaces sur un port éphémère. Les clusters concernés sont ceux où les réplicas Serve se trouvent sur un réseau accessible par des appelants non fiables. La mise à niveau fait passer client et serveur sur les assistants gRPC partagés de Ray, qui appliquent les intercepteurs et les paramètres TLS déjà utilisés par le reste de Ray.