WriteOut : comment un lien de prévisualisation d'agent pouvait détourner n'importe quel compte Writer AI

De quoi s’agit-il ?

Le 7 juillet 2026, l’équipe de recherche Sand Security a divulgué une vulnérabilité critique d’isolation de session, désormais corrigée, dans Writer, une plateforme d’IA générative pour l’entreprise. La faille, baptisée WriteOut, permettait une prise de contrôle de compte inter-organisations à partir d’un simple lien partagé. Un attaquant qui construisait un agent dans son propre espace Writer et partageait son lien de prévisualisation en direct pouvait détourner le compte de n’importe quel utilisateur Writer connecté ayant cliqué sur ce lien — même appartenant à une organisation totalement différente.

Selon la déclaration de Writer à The Hacker News, le problème a été signalé et corrigé en moins de 24 heures en mai 2026, aucune donnée client n’a été compromise et rien n’indique une exploitation malveillante. Le compte rendu technique a été publié le 7 juillet 2026, puis mis à jour le 9 juillet avec la réponse de Writer. La vulnérabilité est entièrement corrigée ; cet article la traite comme une leçon d’architecture défensive, et non comme un exploit actionnable.

Comment ça fonctionne

La cause racine est une erreur d’origine et de portée des cookies dans la façon de servir les prévisualisations d’agent. La fonction de prévisualisation en direct de Writer permet à un concepteur de voir un agent en cours d’exécution via un proxy. Cette prévisualisation était servie depuis la même origine que l’application principale plutôt que depuis une origine isolée — un choix fait pour résoudre des problèmes de cookies et de routage liés aux prévisualisations embarquées. Comme la prévisualisation partageait l’origine de l’application principale, le navigateur attachait le cookie de session Writer de l’utilisateur aux requêtes de prévisualisation, et le proxy transmettait ce cookie au sandbox exécutant l’agent prévisualisé.

La chaîne rapportée, à haut niveau :

# Frontiere de confiance effondrée : le "sandbox de prévisualisation" était dans l'origine de l'app

1. L'attaquant construit un agent avec prévisualisation en direct et partage le lien public.
2. Un utilisateur Writer connecté (n'importe quelle org) ouvre le lien.
3. Le navigateur attache le cookie de session Writer de la victime à la requête.
4. Le proxy de prévisualisation transmet ce cookie au sandbox contrôlé par l'ATTAQUANT.
5. Le code de l'agent de l'attaquant lit le jeton de session transmis depuis
   le processus du sandbox et l'exfiltre vers un serveur externe.
6. L'attaquant rejoue le jeton → contrôle du compte Writer de la victime
   (jusqu'à l'admin, selon le rôle de la victime).

Un second détail explique pourquoi le filtrage d’entrée n’a pas suffi. Writer disposait de garde-fous inspectant le code et les prompts soumis à la recherche de motifs manifestement malveillants, comme la lecture de variables d’environnement. Sand Security les a contournés en ne plaçant pas du tout la charge utile dans le prompt : l’agent recevait simplement l’instruction de télécharger et d’exécuter un script distant. Le garde-fou voyait une instruction anodine « télécharger et exécuter », tandis que la logique réelle n’apparaissait jamais dans le texte inspecté. Comme le résument les chercheurs, les contrôles regardaient l’instruction, pas le comportement à l’exécution.

Pourquoi c’est important

C’est un exemple net de la façon dont des échecs classiques d’isolation web réapparaissent dans les plateformes d’agents IA, avec des enjeux plus élevés. Un compte Writer peut contenir des conversations privées, des documents, des configurations d’agents, des connecteurs, des modèles privés et des identifiants de LLM — une session volée n’est donc pas une simple fuite de données, mais un point d’entrée dans la chaîne d’approvisionnement IA d’une entreprise.

Trois propriétés méritent l’étude. D’abord, la frontière de confiance : un « sandbox de prévisualisation d’agent » semble isolé, mais le servir depuis l’origine principale le plaçait discrètement dans la portée des cookies de l’application. Ensuite, la portée inter-tenant : l’attaquant et la victime n’avaient pas besoin d’appartenir à la même organisation, ce qui transforme un bug par compte en un bug à l’échelle de la plateforme. Enfin, l’angle mort des garde-fous : le filtrage des prompts au niveau du contenu ne remplace pas le contrôle de ce que le code peut réellement faire à l’exécution — un thème récurrent de la sécurité des agents en 2026, au cœur des préoccupations du Top 10 LLM de l’OWASP autour de l’agentivité excessive et du traitement non sécurisé des sorties et des outils.

Défenses

Pour les équipes qui construisent ou exploitent des plateformes d’agents et des prévisualisations :

1. Isolez l’exécution non fiable sur sa propre origine. Servez les prévisualisations, sandboxes et tout code d’agent rédigé par l’utilisateur depuis un domaine distinct, sans lien avec les cookies de session de l’application. C’est le contrôle unique qui ferme les failles de type WriteOut.
2. Ne transmettez jamais les cookies de session first-party à un sandbox. Cadrez les cookies d’authentification avec SameSite, HttpOnly, Secure et un domaine/chemin qu’un proxy de prévisualisation ne peut atteindre. Si une prévisualisation a besoin d’identité, émettez un jeton éphémère à moindre privilège propre à cette prévisualisation.
3. Traitez les liens de prévisualisation/partage comme des entrées non fiables. Supposez que tout lien qu’un utilisateur peut générer sera envoyé à un autre utilisateur ; concevez le système pour que cliquer dessus ne puisse transférer d’identifiants ni élever de privilèges.
4. Filtrez sur le comportement, pas seulement sur les mots. Le filtrage de prompts/code qui recherche des chaînes de caractères se contourne aisément par une indirection « télécharger et exécuter ». Restreignez les sorties réseau, bloquez le trafic sortant par défaut et appliquez des politiques d’appels système/permissions dans le sandbox.
5. Supposez que les jetons fuient ; limitez le rayon d’impact. Liez les sessions à des signaux d’appareil ou de client, raccourcissez la durée de vie des jetons et exigez une ré-authentification pour les actions sensibles comme modifier les connecteurs ou les réglages admin.
6. Journalisez et alertez sur les anomalies inter-tenant. Un jeton de session vu d’abord dans une organisation puis rejoué depuis un contexte sans rapport est une détection à fort signal.

Statut

Élément	Référence	Date	Notes
Divulgation WriteOut	Sand Security	2026-07-07	Faille d’isolation de session inter-tenant ; nom de code WriteOut
Correctif éditeur	Déclaration Writer via The Hacker News	2026-05	Corrigé en 24 h ; cookies retirés des prévisualisations, prévisualisations déplacées vers une origine isolée
Compte rendu mis à jour	The Hacker News	2026-07-09	Ajout de la réponse de Writer ; aucun CVE attribué
Catégorie	Top 10 LLM OWASP (2025)	2025	Agentivité excessive / traitement non sécurisé des outils et sorties

Aucun CVE n’a été attribué. Le bug est corrigé, mais le schéma se généralise : toute plateforme exécutant des agents rédigés par des utilisateurs dans un « sandbox » servi depuis sa propre origine devrait revérifier que les identifiants de session ne peuvent pas franchir cette frontière.