Une évasion de sandbox dans Skyvern, l’agent auto-hébergé qui pilote un navigateur web à partir d’étapes générées par LLM, a reçu le numéro CVE-2026-82447 et a été publiée dans la GitHub Advisory Database le 29 août 2026 à 15:30:19 UTC. Le correctif qu’elle décrit a été intégré au dépôt le 6 juillet à 21:44:03 UTC — soit 53 jours plus tôt.

Ce qu’était réellement le bug

TextPromptBlock de Skyvern rendait chaque prompt deux fois. Le premier passage transitait par SandboxedEnvironment de Jinja, comme prévu. Le second faisait passer la même chaîne influencée par un attaquant dans un moteur de rendu non sandboxé, ce qui suffit à exécuter du code sous le compte du processus serveur. Le correctif, le commit d723de6, est une suppression : trois lignes ajoutées et onze supprimées dans block.py, en retirant le second rendu et l’argument parameter_values qui l’alimentait. Le reste du commit concerne des tests.

Là où la présentation déraille

Deux affirmations reviennent souvent à propos de ce type d’avis, et elles sont fausses ici. La première est qu’il s’agissait d’un correctif en silence. Ce n’est pas le cas : les notes de version de v1.0.45, publiées le 7 juillet à 22:19:18 UTC, contiennent bien le mot « SSTI ». Mais il ne s’agit que d’un point dans un corps de version d’environ 190 lignes, sans avis de sécurité du fournisseur, sans CVE à l’époque, et sans rien qui le distingue d’un changelog routinier. La seconde est l’idée qu’une année de CVE vous indique quand vous étiez exposé. Ce n’est pas le cas — le CVE a été attribué par VulnCheck en tant qu’autorité de numérotation tierce, et non par le projet.

Ce qui casse les outils

L’enregistrement de l’avis affiche un score CVSS 3.1 de 8,8 et un score CVSS 4.0 de 8,7, et il est classé CWE-1336. Mais son tableau structuré vulnerabilities est vide. La plage affectée — 0.2.1 jusqu’à, sans l’inclure, 1.0.45 — n’existe que sous forme de texte sur la page de VulnCheck. Tout scanner qui lit les données structurées de l’avis GitHub et vérifie une dépendance skyvern figée par rapport à celles-ci ne signalera absolument rien.

Pourquoi cette forme revient sans cesse

La voie d’exploitation n’a rien d’exotique. Un paramètre de workflow, ou la sortie d’un bloc en amont, est du texte produit ou ingéré par l’agent lui-même ; il atteint un moteur de rendu de template ; il devient du code sur l’hôte de l’agent. C’est le pont entre injection de prompt et exécution dans sa forme la plus simple, et il est structurel dans les outils qui laissent la sortie d’un modèle piloter une couche de templating.