Une faille dans l'interpréteur Python permet à un modèle de langage trafiqué de sortir du bac à sable de Jinja
Des chercheurs de RunSybil ont exécuté du code sur un serveur de modèles grâce à un modèle de conversation falsifié, mais l'équipe de sécurité de Python ne voit pas de vulnérabilité dans CPython.
La société de sécurité RunSybil a exploité une erreur de mémoire dans CPython, l'implémentation de référence de Python, pour contourner l'environnement protégé du langage de gabarits Jinja. Selon CSO Online et InfoWorld, le problème réside dans la manière dont Python met en cache les types génériques. Après une modification effectuée via une fonction de rappel, un index invalide peut être renvoyé, et un contrôle qui l'intercepterait est désactivé dans les versions publiées. Du code peut ainsi atteindre des objets que le bac à sable devait justement masquer.
Pour illustrer le risque, les chercheurs ont modifié le petit modèle Qwen2.5-0.5B-Instruct avec un gabarit de conversation falsifié. Chargé via un serveur d'inférence comme vLLM, ce modèle permettait à l'attaquant d'exécuter son propre code dans le processus du serveur. Le danger concerne surtout les hébergeurs qui laissent leurs clients téléverser leurs propres modèles, car un attaquant pourrait ainsi atteindre l'infrastructure d'autres clients.
Un correctif figure depuis le 14 août dans la branche principale de CPython et, selon FOSS Linux, a été reporté le 8 septembre dans Python 3.13 et 3.14, mais comme simple correction de bogue et non comme mise à jour de sécurité. Il n'existe pas de correctif public pour Python 3.12, livré notamment avec Ubuntu 24.04. La Python Security Response Team reconnaît l'erreur, mais estime que s'échapper d'un bac à sable relève des concepteurs de ce bac à sable. Le Pallets Project, qui maintient Jinja, a quant à lui renvoyé les chercheurs vers CPython. RunSybil conseille aux hébergeurs de ne pas considérer les gabarits et les bacs à sable comme une véritable barrière de sécurité.