Cross-App Context Poisoning : une app ChatGPT malveillante peut piloter les autres

De quoi s’agit-il ?

Le 6 octobre 2025, OpenAI a lancé ChatGPT Apps, un modèle « app-in-app » dans lequel des applications tierces s’exécutent à l’intérieur de ChatGPT et partagent un unique contexte de conversation — avec l’utilisateur et avec toutes les autres apps connectées à la même conversation. L’écosystème a grossi vite, passant de 122 apps en décembre 2025 à 888 en mai 2026, mais sa sécurité était restée largement inexplorée.

Un preprint arXiv de juin 2026, « Confused ChatGPT: Cross-App Context Poisoning via First-Party APIs » de Chao Wang, Somesh Jha et Zhiqiang Lin (arXiv:2606.00485), est la première analyse systématique de cette surface. Il nomme une nouvelle classe d’attaque : le cross-app context poisoning (XACP), une variante de l’injection de prompt indirecte propre aux assistants multi-apps partageant une même fenêtre de contexte.

Comment ça marche

Le XACP se distingue d’une injection indirecte classique par trois propriétés, toutes héritées du contexte partagé :

1. Persistance. Le contenu injecté est écrit dans le contexte partagé et y demeure d’un tour à l’autre, et pas seulement le temps d’un appel d’outil.
2. Émergence inter-apps. L’effet malveillant ne se déclenche pas dans l’app qui l’a planté. Il refait surface plus tard, quand l’utilisateur invoque une autre app co-résidente et que le modèle consulte le contexte désormais empoisonné.
3. Livraison first-party. L’injection n’est pas dissimulée dans un document ou une page web. Elle passe par les API first-party qu’OpenAI expose à chaque app connectée — les mêmes API que les apps utilisent légitimement pour dialoguer avec la conversation.

Les auteurs ont trouvé plusieurs API capables d’écrire du contenu contrôlé par l’app dans le contexte partagé, sendFollowUpMessage étant identifié comme le canal le plus direct et le plus puissant. Le résultat est une attaque de député confus (confused deputy) d’école : une app malveillante empoisonne le contexte partagé, et lorsque le modèle agit ensuite pour le compte d’une app bénigne co-résidente, il consulte ce contexte et se laisse orienter vers des actions que l’app bénigne n’a jamais voulues.

Aucun payload n’est reproduit ici, et aucun n’est nécessaire pour saisir la leçon. Le point structurel est qu’un contexte partagé sans provenance par app signifie que les écritures de n’importe quelle app sont lues comme fiables par toutes les autres — la frontière entre apps a de fait disparu dans la vision qu’a le modèle de la conversation.

Pourquoi c’est important

Les assistants multi-apps ne sont plus une curiosité ; le bond à près de 900 ChatGPT Apps en cinq mois montre que le modèle se généralise, et la même idée de contexte partagé apparaît sur d’autres plateformes d’agents. Chaque app connectée par l’utilisateur élargit la surface : une seule app de faible réputation, une fois installée, peut rester discrète et biaiser le comportement du modèle vers les apps de plus grande valeur auxquelles l’utilisateur fait confiance — paiement, e-mail, fichiers, productivité.

C’est la triade létale vue côté plateforme. Les données privées et les actions sensibles sont accessibles via des apps de confiance ; le contenu non fiable arrive par les écritures d’API d’une app co-résidente ; et le contexte partagé est le canal qui relie les deux. Cela s’inscrit aussi pleinement dans la lecture par intégrité contextuelle de l’injection de prompt : quand instructions et données partagent un flux indifférencié, le filtrage seul ne peut pas dire de façon fiable à qui appartient quel contenu. La même classe avait été démontrée contre les assistants de code début 2025 sous le nom de cross-origin context poisoning ; ChatGPT Apps généralise le risque à une marketplace d’apps grand public.

Défenses

La cause racine est l’absence de provenance dans un contexte partagé ; les correctifs durables sont donc architecturaux, et non basés sur le filtrage :

• Attribuer et isoler les contributions au contexte. La plateforme devrait étiqueter chaque entrée de contexte avec l’app qui l’a produite, et le modèle devrait traiter les écritures d’une autre app comme une entrée non fiable, pas comme des instructions. Un contexte cloisonné ou « namespacé » par app est plus robuste qu’un unique buffer plat.
• Restreindre les API d’écriture dans le contexte. Les canaux comme sendFollowUpMessage, qui laissent une app injecter du contenu que d’autres apps liront, devraient être en moindre privilège par défaut, limités en débit, et idéalement invisibles aux apps co-résidentes tant que l’utilisateur ne les relie pas explicitement.
• Conditionner les actions inter-apps à une confirmation. Quand une action destinée à l’app B est influencée par un contenu provenant de l’app A, exiger une confirmation explicite de l’utilisateur nommant les deux apps — le même principe du « humain dans la boucle là où le rayon d’impact est grand » qui limite les dégâts des agents ailleurs.
• Développeurs : ne traitez pas le contexte partagé comme faisant autorité. Revalidez les paramètres sensibles contre votre propre état avant d’agir, plutôt que de faire confiance à ce que la conversation contient désormais.
• Utilisateurs : connectez le moins d’apps possible, privilégiez les éditeurs réputés, et rappelez-vous qu’une app installée peut affecter vos interactions avec d’autres apps — pas seulement les siennes.

Statut

Élément	Valeur
Identifiant	arXiv:2606.00485 (« Confused ChatGPT »)
Affecté	Écosystème ChatGPT Apps d’OpenAI (app-in-app, contexte partagé)
Classe	Cross-app context poisoning — injection de prompt indirecte / député confus
Vecteur	API first-party écrivant dans le contexte (ex. sendFollowUpMessage)
Impact	Manipulation inter-apps, détournement d’actions via contexte empoisonné
Divulgation	Juin 2026 (preprint arXiv)
Correctif	Non documenté dans le papier ; aucun statut corrigé confirmé à ce jour
Exploitation	Preuve de concept de recherche uniquement ; aucune exploitation observée