Cross-App Context Poisoning: una app de ChatGPT maliciosa puede dirigir a las demás

¿Qué es esto?

El 6 de octubre de 2025, OpenAI lanzó ChatGPT Apps, un modelo «app dentro de app» en el que aplicaciones de terceros se ejecutan dentro de ChatGPT y comparten un único contexto de conversación — con el usuario y con todas las demás apps conectadas a la misma conversación. El ecosistema creció rápido, de 122 apps en diciembre de 2025 a 888 en mayo de 2026, pero su seguridad permanecía en gran medida sin investigar.

Un preprint de arXiv de junio de 2026, «Confused ChatGPT: Cross-App Context Poisoning via First-Party APIs» de Chao Wang, Somesh Jha y Zhiqiang Lin (arXiv:2606.00485), es el primer análisis sistemático de esa superficie. Nombra una nueva clase de ataque: el cross-app context poisoning (XACP), una variante de la inyección de prompt indirecta propia de los asistentes multi-app que comparten una misma ventana de contexto.

Cómo funciona

El XACP se distingue de una inyección indirecta clásica por tres propiedades, todas derivadas del contexto compartido:

1. Persistencia. El contenido inyectado se escribe en el contexto compartido y permanece allí de un turno a otro, no solo durante una llamada a una herramienta.
2. Emergencia entre apps. El efecto malicioso no se dispara en la app que lo plantó. Reaparece más tarde, cuando el usuario invoca una app co-residente distinta y el modelo consulta el contexto ya envenenado.
3. Entrega first-party. La inyección no se oculta en un documento ni en una página web. Llega a través de las API first-party que OpenAI expone a cada app conectada — las mismas API que las apps usan legítimamente para dialogar con la conversación.

Los autores hallaron varias API capaces de escribir contenido controlado por la app en el contexto compartido, siendo sendFollowUpMessage el canal más directo y potente. El resultado es un ataque de diputado confundido (confused deputy) de manual: una app maliciosa envenena el contexto compartido y, cuando el modelo actúa después en nombre de una app benigna co-residente, consulta ese contexto y se deja dirigir hacia acciones que la app benigna nunca pretendió.

Aquí no se reproduce ningún payload, y ninguno hace falta para captar la lección. El punto estructural es que un contexto compartido sin procedencia por app implica que las escrituras de cualquier app son leídas como confiables por todas las demás — la frontera entre apps ha desaparecido de hecho en la visión que el modelo tiene de la conversación.

Por qué importa

Los asistentes multi-app ya no son una curiosidad; el salto a casi 900 ChatGPT Apps en cinco meses muestra que el patrón se está generalizando, y la misma idea de contexto compartido aparece en otras plataformas de agentes. Cada app que el usuario conecta amplía la superficie: una sola app de baja reputación, una vez instalada, puede quedarse en silencio y sesgar el comportamiento del modelo hacia las apps de mayor valor en las que el usuario confía — pago, correo, archivos, productividad.

Esta es la tríada letal vista desde el lado de la plataforma. Los datos privados y las acciones sensibles son accesibles a través de apps de confianza; el contenido no confiable llega por las escrituras de API de una app co-residente; y el contexto compartido es el canal que conecta ambos. También encaja de lleno en la lectura por integridad contextual de la inyección de prompt: cuando instrucciones y datos comparten un flujo indiferenciado, el filtrado por sí solo no puede decir de forma fiable de quién es cada contenido. La misma clase se demostró contra asistentes de código a principios de 2025 como cross-origin context poisoning; ChatGPT Apps generaliza el riesgo a un marketplace de apps de consumo.

Defensas

La causa raíz es la ausencia de procedencia en un contexto compartido, así que las correcciones duraderas son arquitectónicas, no basadas en filtrado:

• Atribuir y aislar las contribuciones al contexto. La plataforma debería etiquetar cada entrada de contexto con la app que la produjo, y el modelo debería tratar las escrituras de otra app como entrada no confiable, no como instrucciones. Un contexto compartimentado o con espacios de nombres por app es más robusto que un único búfer plano.
• Restringir las API de escritura en el contexto. Canales como sendFollowUpMessage, que permiten a una app inyectar contenido que otras apps leerán, deberían ser de mínimo privilegio por defecto, con límite de tasa e idealmente invisibles a las apps co-residentes salvo que el usuario las conecte explícitamente.
• Condicionar las acciones entre apps a una confirmación. Cuando una acción para la app B se ve influida por contenido originado en la app A, exigir una confirmación explícita del usuario que nombre ambas apps — el mismo principio de «humano en el bucle donde el radio de impacto es grande» que limita el daño de los agentes en otros lugares.
• Desarrolladores: no traten el contexto compartido como autoritativo. Revaliden los parámetros sensibles contra su propio estado antes de actuar, en lugar de confiar en lo que la conversación contiene ahora.
• Usuarios: conecten las menos apps posibles, prefieran editores reputados y recuerden que una app instalada puede afectar sus interacciones con otras apps — no solo las suyas.

Estado

Elemento	Valor
Identificador	arXiv:2606.00485 («Confused ChatGPT»)
Afectado	Ecosistema ChatGPT Apps de OpenAI (app dentro de app, contexto compartido)
Clase	Cross-app context poisoning — inyección de prompt indirecta / diputado confundido
Vector	API first-party que escriben en el contexto (p. ej. sendFollowUpMessage)
Impacto	Manipulación entre apps, secuestro de acciones vía contexto envenenado
Divulgación	Junio de 2026 (preprint de arXiv)
Parche	No documentado en el artículo; ningún estado de corrección confirmado a la fecha
En entornos reales	Solo prueba de concepto de investigación; sin explotación observada