WriteOut : quand un sandbox d'IA transmet le cookie de session de l'utilisateur

De quoi s’agit-il ?

Le 7 juillet 2026, l’équipe de recherche Sand Security a divulgué une faille critique, désormais corrigée, d’isolation de session dans Writer, une plateforme d’IA générative pour l’entreprise. Ils l’ont baptisée WriteOut, et elle a été relayée le jour même par The Hacker News. La faille permet une prise de contrôle de compte inter-organisations « en un clic » : un attaquant crée un agent dans son propre compte, partage le lien d’aperçu, et tout utilisateur Writer connecté qui ouvre ce lien peut voir son compte détourné — administrateurs compris, et y compris s’il appartient à une autre organisation.

L’impact est large. Une session Writer volée donne accès aux conversations privées, aux documents, aux configurations d’agents, aux modèles privés, aux connecteurs et aux identifiants LLM stockés. Comme l’attaquant et la victime n’ont pas besoin de partager la même organisation, la faille brise l’isolation multi-locataire (tenant isolation) que les clients d’entreprise supposent au fondement d’un SaaS multi-tenant. Writer a depuis corrigé le problème. Nous le traitons car la cause racine est une erreur de conception générale : faire confiance à un sandbox managé avec un identifiant utilisateur qu’il n’aurait jamais dû voir.

Comment ça marche

Le Framework de Writer propose un aperçu en direct (live preview) pour tester un agent en cours de développement. Cet aperçu exécute le code de l’agent dans un sandbox managé par Writer, atteint via un proxy d’aperçu. L’erreur portait sur la manière dont la requête vers ce sandbox était authentifiée.

La chaîne d’exploitation rapportée, d’après Sand Security et The Hacker News :

1. L'attaquant crée un agent avec aperçu en direct et partage son lien public.
2. Une victime connectée ouvre le lien. Son navigateur joint son cookie
   de session Writer à la requête (same-site, elle est connectée).
3. Le proxy d'aperçu transmet ce cookie dans le sandbox de L'ATTAQUANT.
4. Le code de l'agent de l'attaquant lit le jeton transmis dans la mémoire
   du processus sandbox et l'envoie vers un serveur qu'il contrôle.
5. L'attaquant rejoue le jeton et contrôle le compte de la victime.

L’étape pivot est la n°3 : l’identifiant de la victime se retrouve dans un runtime entièrement contrôlé par l’attaquant. À partir de là, le relire est trivial — il se trouve dans le processus où l’attaquant est déjà autorisé à exécuter du code.

Writer n’était pas sans défense. Un filtrage en entrée tentait de bloquer les requêtes lisant des variables d’environnement ou soumettant du code « manifestement malveillant ». Mais ces contrôles inspectaient l’instruction, pas le comportement à l’exécution. Selon Sand Security, le contournement consistait simplement à ne pas coller de charge utile en clair mais à demander à l’agent de télécharger et d’exécuter un script distant : le filtre voyait une requête anodine « télécharger et exécuter », et la logique d’exploitation réelle n’apparaissait jamais dans le prompt. C’est la leçon de leur précédent article “votre sandbox n’est pas votre sécurité” — un sandbox qui exécute du code non fiable n’est pas, à lui seul, une frontière de confiance.

Pourquoi c’est important

Les cookies de session sont des jetons au porteur ; tout ce qui peut en lire un devient l’utilisateur. Un cookie de session Writer suffit à être la victime. Le transmettre dans un sandbox qui exécute du code fourni par l’attaquant lui cède cette identité en bloc. Il ne s’agit pas d’un comportement d’IA exotique, mais d’une erreur classique de portée d’identifiant, amplifiée parce que le sandbox est une fonctionnalité conçue pour exécuter, par nature, du code utilisateur arbitraire.

Les fonctions « aperçu » et « playground » des agents IA sont une surface d’attaque en forte croissance. Le schéma — laisser l’utilisateur écrire et exécuter instantanément du code d’agent dans un sandbox hébergé — est désormais partout. Chacune de ces fonctions est un endroit où du code non fiable s’exécute près des rouages internes de la plateforme. Si un secret lié à l’utilisateur (cookie, jeton d’API, identifiant cloud) y est accessible, une commodité produit devient une compromission inter-locataires.

Un filtrage par prompt ou par liste d’autorisation qui lit l’intention n’est pas un contrôle à l’exécution. Le contournement dépasse le cas Writer : un filtre qui analyse l’instruction peut être vaincu en déplaçant la logique malveillante hors de l’instruction (« télécharge et exécute cette URL »). Le comportement doit être contraint là où il s’exécute — par des limites de sortie réseau, l’isolation mémoire et le moindre privilège — et non par la reconnaissance de motifs dans ce que l’utilisateur a saisi.

Défenses

Le bug précis est corrigé : Writer empêche désormais totalement la transmission du cookie de session de l’utilisateur vers les aperçus de sandbox, et sert ces aperçus depuis une origine isolée. Les leçons générales valent pour quiconque construit des fonctions d’aperçu ou d’exécution de code d’agent.

1. Ne jamais laisser un identifiant utilisateur entrer dans un runtime non fiable. Les sandboxes exécutant du code utilisateur ou tiers doivent s’authentifier avec leurs propres jetons éphémères et à portée étroite — jamais le cookie de session de l’utilisateur final. Retirez et régénérez les identifiants à la frontière.

2. Servir l’exécution non fiable depuis une origine isolée. Placez aperçus, playgrounds et sorties d’agents rendues sur une origine distincte (et une portée de cookie distincte), afin que les règles same-site du navigateur ne joignent pas les cookies de session first-party à ces requêtes. C’est exactement le correctif appliqué par Writer.

3. Imposer le comportement à l’exécution, pas l’intention en entrée. Supposez que les filtres d’entrée seront contournés par indirection (téléchargement distant, encodage, charges par étapes). Contrôlez ce que le sandbox peut réellement faire : bloquez ou mettez en liste d’autorisation la sortie réseau, restreignez l’accès au système de fichiers et à la mémoire, retirez les capacités inutiles.

4. Restreindre et faire tourner les secrets du sandbox selon le rayon d’impact acceptable. Si un runtime doit détenir un secret, gardez-le par session, par locataire et éphémère, afin qu’une fuite depuis un aperçu ne puisse être rejouée ailleurs ni plus tard.

5. Traiter l’isolation multi-locataire comme un invariant testé. Les contrôles inter-locataires ont leur place dans votre suite de tests de sécurité : un artefact créé par le locataire A peut-il faire exécuter du code — ou faire circuler des identifiants — dans le contexte du locataire B ? Auditez spécifiquement les chemins d’aperçu et de partage.

Statut

Élément	Référence	Date	Notes
Divulgation de WriteOut	Sand Security	2026-07-07	Faille critique d’isolation de session inter-locataires dans Writer
Reprise indépendante	The Hacker News	2026-07-07	Confirme la chaîne d’attaque et l’impact
Correctif éditeur	Writer (via Sand Security)	Rapporté le 2026-07-07	Cookie non transmis au sandbox ; aperçus déplacés vers une origine isolée

En une phrase : un sandbox d’IA managé a reçu le cookie de session de la victime, et une fonction censée prévisualiser des agents est devenue une prise de contrôle de compte en un clic, entre locataires. La leçon durable ne concerne pas seulement Writer : un runtime conçu pour exécuter du code non fiable ne doit jamais recevoir un identifiant qui désigne l’utilisateur.