Cross-App Context Poisoning: a rogue ChatGPT app can steer the others
A June 2026 arXiv study shows a malicious ChatGPT app can write into the chat context shared by every connected app through first-party APIs, turning the model into a confused deputy against benign apps.
What is this?
On October 6, 2025, OpenAI launched ChatGPT Apps, an “app-in-app” model in which third-party applications run inside ChatGPT and share a single chat context — with the user and with every other connected app in the same conversation. The ecosystem grew quickly, from 122 apps in December 2025 to 888 by May 2026, but its security went largely unstudied.
A June 2026 arXiv preprint, “Confused ChatGPT: Cross-App Context Poisoning via First-Party APIs” by Chao Wang, Somesh Jha and Zhiqiang Lin (arXiv:2606.00485), is the first systematic look at that surface. It names a new attack class: cross-app context poisoning (XACP), a variant of indirect prompt injection that is specific to multi-app assistants sharing one context window.
How it works
XACP is distinguished from ordinary indirect injection by three properties, all flowing from the shared-context design:
- Persistence. The injected content is written into the shared chat context and stays there across turns, not just for a single tool call.
- Cross-app surfacing. The malicious effect does not fire in the app that planted it. It surfaces later, when the user invokes a different co-resident app and the model consults the now-poisoned context.
- First-party delivery. The injection is not smuggled through a document or a web page. It is delivered through first-party APIs that OpenAI exposes to every connected app — the same APIs apps legitimately use to talk to the conversation.
The authors found multiple APIs capable of writing app-controlled content into the shared context, with sendFollowUpMessage identified as the most direct and potent channel. The result is a textbook confused-deputy attack: a malicious app poisons the shared context, and when the model later acts on behalf of a benign co-resident app, it consults that context and is steered into actions the benign app never intended.
No payload is reproduced here, and none is needed to grasp the lesson. The structural point is that a shared context with no per-app provenance means any app’s writes are read as trusted by every other app — the boundary between apps has effectively been erased inside the model’s view of the conversation.
Why it matters
Multi-app assistants are no longer a curiosity; the jump to nearly 900 ChatGPT Apps in five months shows the pattern is going mainstream, and the same shared-context idea is appearing across agent platforms. Every app a user connects widens the blast radius: a single low-reputation app, once installed, can sit quietly and bias the model’s behaviour toward the higher-value apps the user trusts — payment, email, file, or productivity integrations.
This is the lethal trifecta seen from the platform side. Private data and capable actions are reachable through trusted apps; the untrusted content arrives through a co-resident app’s API writes; and the shared context is the channel that connects the two. It also lands squarely in the contextual-integrity framing of prompt injection: when instructions and data share one undifferentiated stream, filtering alone cannot reliably tell whose content is whose. The same class was shown against AI coding assistants in early 2025 as cross-origin context poisoning; ChatGPT Apps generalise the risk to a consumer app marketplace.
Defenses
The root cause is missing provenance in a shared context, so the durable fixes are architectural rather than filter-based:
- Attribute and isolate context contributions. The platform should tag every context entry with the app that produced it, and the model should treat another app’s writes as untrusted input, not as instructions. App-scoped or namespaced context is stronger than one flat shared buffer.
- Constrain context-writing APIs. Channels like
sendFollowUpMessagethat let an app inject content other apps will read should be least-privilege by default, rate-limited, and ideally invisible to co-resident apps unless the user explicitly bridges them. - Gate cross-app actions behind confirmation. When an action for app B is influenced by content originating in app A, require an explicit user confirmation that names both apps — the same “human in the loop where the blast radius is large” principle that limits agent damage elsewhere.
- Developers: do not treat the shared context as authoritative. Re-validate security-relevant parameters against your own state before acting, rather than trusting whatever the conversation now contains.
- Users: connect as few apps as possible, prefer reputable publishers, and remember that an installed app can affect your interactions with other apps — not just its own.
Status
| Item | Value |
|---|---|
| Identifier | arXiv:2606.00485 (“Confused ChatGPT”) |
| Affected | OpenAI ChatGPT Apps ecosystem (app-in-app, shared context) |
| Class | Cross-app context poisoning — indirect prompt injection / confused deputy |
| Delivery | First-party context-writing APIs (e.g. sendFollowUpMessage) |
| Impact | Cross-app manipulation, action hijacking via poisoned shared context |
| Disclosed | June 2026 (arXiv preprint) |
| Patch | Not documented in the paper; no fixed status confirmed at time of writing |
| In the wild | Research proof-of-concept only; no observed exploitation |