pith. sign in

arxiv: 2606.00485 · v1 · pith:ODJM7YU6new · submitted 2026-05-30 · 💻 cs.CR

Confused ChatGPT: Cross-App Context Poisoning via First-Party APIs

Pith reviewed 2026-06-28 18:54 UTC · model grok-4.3

classification 💻 cs.CR
keywords context poisoningprompt injectionChatGPT Appsmulti-app securityLLM securityconfused deputy attackfirst-party APIsshared context
0
0 comments X

The pith

ChatGPT Apps share one persistent flat context that lets any app poison the LLM's memory for attacks on co-resident apps.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper shows that ChatGPT's app ecosystem stores all user and app messages in a single untagged, persistent context visible to every connected app. This design allows one app to write content that later influences the LLM when the user invokes a different app. The authors demonstrate the attack using first-party APIs such as sendFollowUpMessage together with two undocumented parameters that enable silent, high-priority writes. A reader cares because the same shared context that enables cross-app features also removes the isolation that every prior multi-tenant platform required before allowing third-party code. The root cause is therefore architectural rather than a simple implementation flaw.

Core claim

The LLM's context is a persistent, flat, untagged data store shared by the user and every connected app, with no isolation boundaries. First-party APIs including sendFollowUpMessage can write app-controlled content into this store; the undocumented parameters systemPrompt and isVisible further allow silent system-priority writes. These writes persist across conversation turns and are consulted by any co-resident app the user later invokes, enabling a confused-deputy attack in which a malicious app manipulates the LLM's behavior against benign apps.

What carries the argument

The shared, persistent, flat, untagged chat context that serves as a single data store for user and all apps without isolation or tagging.

If this is right

  • Any app can persistently alter the context that the LLM consults on behalf of any other app.
  • The same first-party APIs used for normal app composition become the delivery channel for cross-app attacks.
  • Fixing the issue requires changing the context architecture rather than patching individual APIs.
  • The attack works across the six evaluated ChatGPT models because they all inherit the same shared-context design.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • Other LLM platforms that expose similar first-party APIs for multi-app composition will face the same isolation gap unless they add explicit boundaries.
  • Developers of individual apps cannot protect themselves; the defense must be enforced at the platform level.
  • Adding per-app tags or separate context namespaces would break the cross-app composition the feature was built to provide.

Load-bearing premise

The undocumented parameters systemPrompt and isVisible are accepted by the runtime, produce silent system-priority writes, persist in the shared context, and are read by other apps exactly as described.

What would settle it

Run a benign app after a malicious app has used sendFollowUpMessage with systemPrompt set to true; if the benign app's responses are unaffected and the hidden writes are never visible to the LLM, the poisoning claim is false.

Figures

Figures reproduced from arXiv: 2606.00485 by Chao Wang, Somesh Jha, Zhiqiang Lin.

Figure 1
Figure 1. Figure 1: Monthly new-app registrations (bars, left axis) and cumulative catalog size [PITH_FULL_IMAGE:figures/full_fig_p005_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: Architecture of the ChatGPT Apps framework, organized as three concentric [PITH_FULL_IMAGE:figures/full_fig_p006_2.png] view at source ↗
Figure 3
Figure 3. Figure 3: Apps-SDK bridge-API adoption measured via AST analysis of 806 successfully [PITH_FULL_IMAGE:figures/full_fig_p008_3.png] view at source ↗
Figure 4
Figure 4. Figure 4: Ideal isolation model for ChatGPT Apps. Each app operates in an isolated [PITH_FULL_IMAGE:figures/full_fig_p011_4.png] view at source ↗
Figure 5
Figure 5. Figure 5: The confused deputy attack. The malicious attractions finder injects adver [PITH_FULL_IMAGE:figures/full_fig_p015_5.png] view at source ↗
Figure 6
Figure 6. Figure 6: Attack I: Conditional Context Poisoning. The malicious app poisons the [PITH_FULL_IMAGE:figures/full_fig_p018_6.png] view at source ↗
Figure 7
Figure 7. Figure 7: Conditional context poisoning. The malicious app calls [PITH_FULL_IMAGE:figures/full_fig_p018_7.png] view at source ↗
Figure 8
Figure 8. Figure 8: Attack II: Imperative Context Poisoning. The malicious app poisons the [PITH_FULL_IMAGE:figures/full_fig_p019_8.png] view at source ↗
Figure 9
Figure 9. Figure 9: Attack II imperative variant. Directed tool invocation: imperative in [PITH_FULL_IMAGE:figures/full_fig_p020_9.png] view at source ↗
Figure 10
Figure 10. Figure 10: Amplified context pollution (Listing 3, Attack I variant). The undocumented [PITH_FULL_IMAGE:figures/full_fig_p033_10.png] view at source ↗
read the original abstract

ChatGPT Apps, launched by OpenAI on Oct. 6, 2025, introduce an app-in-app paradigm in which third-party applications share a single chat context with the user and with every other connected app. The ecosystem grew from 122 apps in Dec. 2025 to 888 by May 2026, yet its security has remained uninvestigated. We identify cross-app context poisoning, a variant of indirect prompt injection distinguished by three properties: 1) the injection persists in the shared chat context across turns; 2) the effect surfaces through a different co-resident app the user later invokes; and 3) the delivery vectors are first-party APIs exposed to every connected app. We find multiple APIs capable of writing app-controlled content into the shared context, with sendFollowUpMessage as the most direct and potent channel. Two undocumented parameters that the runtime silently accepts, systemPrompt and isVisible, amplify this channel to silent, system-priority writes. Leveraging this channel, we realize a confused-deputy attack in which a malicious app poisons the context so that the LLM, consulting that context, enables manipulation against benign co-resident apps. We demonstrate two payload styles (conditional and imperative) and evaluate them across six current ChatGPT models. The root cause is architectural: the LLM's context is a persistent, flat, untagged data store shared by user and apps, with no isolation. Every mature multi-tenant platform, from Multics virtual memory to Android UIDs and iOS sandbox profiles, paid the isolation cost before admitting third parties; ChatGPT Apps did not. Fixing this requires an architectural change, not a patch. We disclosed our findings to OpenAI; the undocumented parameters remain accessible at the time of writing, and the architectural gap is by design: the shared context that enables cross-app composition is the same flat namespace that enables cross-app poisoning.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

2 major / 2 minor

Summary. The paper claims that ChatGPT Apps enable cross-app context poisoning via first-party APIs (chiefly sendFollowUpMessage) because the shared chat context is a persistent, flat, untagged store with no isolation between user and apps. Two undocumented parameters (systemPrompt, isVisible) are said to be silently accepted by the runtime and to produce system-priority writes that persist across turns and are consulted by co-resident apps, enabling confused-deputy attacks. The authors demonstrate conditional and imperative payloads across six models, conclude that the root cause is architectural (no isolation cost was paid before admitting third parties), and note that the parameters remained accessible after disclosure to OpenAI.

Significance. If the mechanism and cross-app persistence are verified, the work identifies a concrete, high-impact architectural vulnerability in a rapidly growing multi-app LLM platform. It supplies a clear analogy to prior multi-tenant isolation failures and argues that only an architectural change (not a patch) can close the channel. The disclosure to OpenAI and the explicit statement that the parameters remain usable at time of writing are useful for the community.

major comments (2)
  1. [Abstract] Abstract: The claim that systemPrompt and isVisible 'amplify this channel to silent, system-priority writes' that 'persist in the shared chat context' and are 'consulted by co-resident apps' is load-bearing for both the confused-deputy demonstration and the architectural conclusion, yet the manuscript supplies no reproduction steps, observed outputs, response logs, or controls showing that these writes receive system priority, survive turns, or produce effects on other apps that ordinary user messages do not.
  2. [Evaluation] Evaluation section (six-model demonstration): The abstract states that payloads were evaluated across six models, but provides no error bars, exclusion criteria, raw logs, or description of how cross-app reading was confirmed (i.e., which benign app was invoked after poisoning and what output it produced). This absence prevents assessment of whether the observed effects are reproducible or attributable to the claimed mechanism.
minor comments (2)
  1. [Abstract] The abstract and introduction would benefit from a brief citation to prior indirect-prompt-injection literature to situate the 'cross-app' variant.
  2. [Main text] Notation for the undocumented parameters (systemPrompt, isVisible) should be introduced with an explicit example API call in the main text rather than only in the abstract.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for their thorough review and constructive feedback. We address each major comment below and agree that additional details are needed to support the claims.

read point-by-point responses
  1. Referee: [Abstract] Abstract: The claim that systemPrompt and isVisible 'amplify this channel to silent, system-priority writes' that 'persist in the shared chat context' and are 'consulted by co-resident apps' is load-bearing for both the confused-deputy demonstration and the architectural conclusion, yet the manuscript supplies no reproduction steps, observed outputs, response logs, or controls showing that these writes receive system priority, survive turns, or produce effects on other apps that ordinary user messages do not.

    Authors: We agree that the abstract's claims on system priority, persistence, and cross-app consultation require explicit supporting evidence. The manuscript provides API examples and attack demonstrations, but lacks dedicated reproduction steps, sample outputs, and controls. We will add a new subsection with step-by-step reproduction instructions, observed outputs, response log excerpts, and comparisons to ordinary user messages. revision: yes

  2. Referee: [Evaluation] Evaluation section (six-model demonstration): The abstract states that payloads were evaluated across six models, but provides no error bars, exclusion criteria, raw logs, or description of how cross-app reading was confirmed (i.e., which benign app was invoked after poisoning and what output it produced). This absence prevents assessment of whether the observed effects are reproducible or attributable to the claimed mechanism.

    Authors: We concur that the evaluation lacks sufficient methodological detail for assessing reproducibility. The manuscript describes the payloads and models tested but omits error bars, exclusion criteria, confirmation of cross-app reading, and raw logs. We will expand the evaluation section to include these elements, specifying the benign apps invoked, their outputs, and verification methods. revision: yes

Circularity Check

0 steps flagged

No circularity: empirical attack demonstration with no derivations or self-referential reductions

full rationale

The paper presents an empirical security analysis based on API observations and attack demonstrations against ChatGPT Apps. It contains no equations, fitted parameters, mathematical derivations, or load-bearing self-citations. The central claim (architectural root cause of cross-app poisoning due to shared flat context) rests on direct observation of first-party APIs like sendFollowUpMessage and undocumented parameters, plus payload evaluation across models. No step reduces a prediction or result to its own inputs by construction, nor does any uniqueness theorem or ansatz get smuggled via self-citation. This is a standard non-circular empirical paper; the reader's assigned score of 1.0 aligns with the absence of any of the enumerated circularity patterns.

Axiom & Free-Parameter Ledger

0 free parameters · 0 axioms · 0 invented entities

Empirical security analysis with no mathematical model, fitted parameters, or new postulated entities; relies on direct observation of runtime behavior and attack construction.

pith-pipeline@v0.9.1-grok · 5879 in / 1209 out tokens · 23477 ms · 2026-06-28T18:54:13.801549+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

43 extracted references · 10 canonical work pages · 7 internal anchors

  1. [1]

    Introducing the model context protocol,

    Anthropic, “Introducing the model context protocol,” https://www.anthropic.com/news/mod el-context-protocol, 2024, accessed: 03/15/2026

  2. [2]

    Tool use with Claude,

    ——, “Tool use with Claude,” https://docs.anthropic.com/en/docs/build-with-claude/tool-use, 2025, accessed: 05/10/2026

  3. [3]

    App store review guidelines,

    Apple, “App store review guidelines,” https://developer.apple.com/app-store/review/guidelin es/, 2025, accessed: 03/15/2026

  4. [4]

    Robust defenses for cross-site request forgery,

    A. Barth, C. Jackson, and J. C. Mitchell, “Robust defenses for cross-site request forgery,” in Proceedings of the ACM Conference on Computer and Communications Security (CCS), 2008

  5. [5]

    Crossfire: An analysis of Firefox extension-reuse vulnerabilities,

    A. Buyukkayhan, K. Onarlioglu, W. Robertson, and E. Kirda, “Crossfire: An analysis of Firefox extension-reuse vulnerabilities,” inProceedings of the Network and Distributed System Security Symposium (NDSS), 2016

  6. [6]

    An evaluation of the Google Chrome extension security architecture,

    N. Carlini, A. P. Felt, and D. Wagner, “An evaluation of the Google Chrome extension security architecture,” inProceedings of the USENIX Security Symposium, 2012. 28

  7. [7]

    Analyzing inter-application communication in android,

    E. Chin, A. P. Felt, K. Greenwood, and D. Wagner, “Analyzing inter-application communication in android,” inProceedings of the International Conference on Mobile Systems, Applications, and Services (MobiSys), 2011

  8. [8]

    Introduction and overview of the Multics system,

    F. J. Corbató and V. A. Vyssotsky, “Introduction and overview of the Multics system,” in Proceedings of the AFIPS Fall Joint Computer Conference, 1965, pp. 185–196

  9. [9]

    A study of android application security,

    W. Enck, D. Octeau, P. McDaniel, and S. Chaudhuri, “A study of android application security,” inProceedings of the USENIX Security Symposium, 2011

  10. [10]

    Android permissions demystified,

    A. P. Felt, E. Chin, S. Hanna, D. Song, and D. Wagner, “Android permissions demystified,” in Proceedings of the ACM Conference on Computer and Communications Security (CCS), 2011

  11. [11]

    Security analysis of emerging smart home applications,

    E. Fernandes, J. Jung, and A. Prakash, “Security analysis of emerging smart home applications,” inProceedings of the IEEE Symposium on Security and Privacy (S&P), 2016

  12. [12]

    Gemini extensions: Connect your apps to Gemini,

    Google, “Gemini extensions: Connect your apps to Gemini,” https://deepmind.google/techno logies/gemini/extensions/, 2025, accessed: 05/10/2026

  13. [13]

    Google play developer policy center,

    ——, “Google play developer policy center,” https://play.google.com/about/developer-content -policy/, 2025, accessed: 03/15/2026

  14. [14]

    RiskRanker: Scalable and accurate zero-day android malware detection,

    M. Grace, Y. Zhou, Q. Zhang, S. Zou, and X. Jiang, “RiskRanker: Scalable and accurate zero-day android malware detection,” inProceedings of the International Conference on Mobile Systems, Applications, and Services (MobiSys), 2012

  15. [15]

    Not what you've signed up for: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection

    K. Greshake, S. Abdelnabi, S. Mishra, C. Endres, T. Holz, and M. Fritz, “Not what you’ve signed up for: Compromising real-world LLM-integrated applications with indirect prompt injection,”arXiv preprint arXiv:2302.12173, 2023

  16. [16]

    Agent smith: A single image can jailbreak one million multimodal llm agents exponentially fast,

    X. Gu, X. Zheng, T. Pang, C. Du, Q. Liu, Y. Wang, J. Jiang, and M. Lin, “Agent smith: A single image can jailbreak one million multimodal llm agents exponentially fast,”arXiv preprint arXiv:2402.08567, 2024

  17. [17]

    The confused deputy: (or why capabilities might have been invented),

    N. Hardy, “The confused deputy: (or why capabilities might have been invented),” inACM SIGOPS Operating Systems Review, vol. 22, no. 4, 1988, pp. 36–38

  18. [18]

    The emerged security and privacy of llm agent: A survey with case studies,

    F. He, T. Zhu, D. Ye, B. Liu, W. Zhou, and P. S. Yu, “The emerged security and privacy of llm agent: A survey with case studies,”ACM Computing Surveys, vol. 58, no. 6, pp. 1–36, 2025

  19. [19]

    Sleeper Agents: Training Deceptive LLMs that Persist Through Safety Training

    E. Hubinger, C. Denison, J. Mu, M. Lambert, M. Tong, M. MacDiarmid, T. Lanham, D. M. Ziegler, T. Maxwell, N. Cheng, A. Jermyn, A. Askell, A. Radhakrishnan, C. Anil, D. Duvenaud, D. Ganguli, F. Barez, J. Clark, K. Ndousse, K. Sachan, M. Sellitto, M. Sharma, N. DasSarma, R. Grosse, S. Kravec, Y. Bai, Z. Witten, M. Favaro, J. Brauner, H. Karnofsky, P. Christ...

  20. [20]

    Trends and lessons from three years fighting malicious extensions,

    N. Jagpal, E. Dingle, J.-P. Gravel, P. Mavrommatis, N. Provos, M. A. Rajab, and K. Thomas, “Trends and lessons from three years fighting malicious extensions,” inProceedings of the USENIX Security Symposium, 2015. 29

  21. [21]

    Black ops 2008: It’s the end of the cache as we know it,

    D. Kaminsky, “Black ops 2008: It’s the end of the cache as we know it,” inBlack Hat USA, 2008

  22. [22]

    Testing the limits of jailbreaking defenses with the purple problem,

    T. Kim, S. Kotha, and A. Raghunathan, “Testing the limits of jailbreaking defenses with the purple problem,”arXiv preprint arXiv:2403.14725, 2024

  23. [23]

    Jailbreaking ChatGPT via Prompt Engineering: An Empirical Study

    Y. Liu, G. Deng, Z. Xu, Y. Li, Y. Zheng, Y. Zhang, L. Zhao, T. Zhang, K. Wang, and Y. Liu, “Jailbreaking ChatGPT via prompt engineering: An empirical study,”arXiv preprint arXiv:2305.13860, 2023

  24. [24]

    Formalizing and benchmarking prompt injection attacks and defenses,

    Y. Liu, Y. Jia, R. Geng, J. Jia, and N. Z. Gong, “Formalizing and benchmarking prompt injection attacks and defenses,” inProceedings of the 33rd USENIX Security Symposium, 2024

  25. [25]

    Memory and new controls for ChatGPT,

    OpenAI, “Memory and new controls for ChatGPT,” https://openai.com/index/memory-and-n ew-controls-for-chatgpt/, 2024, accessed: 03/15/2026

  26. [26]

    Apps sdk - openai,

    ——, “Apps sdk - openai,” https://developers.openai.com/apps-sdk/, 2025, accessed: 03/15/2026

  27. [27]

    Apps sdk api reference,

    ——, “Apps sdk api reference,” https://developers.openai.com/apps-sdk/reference, 2025, accessed: 03/15/2026

  28. [28]

    Chatgpt app store,

    ——, “Chatgpt app store,” https://openai.com/blog/chatgpt-app-store, 2025, accessed: 03/15/2026

  29. [29]

    Introducing chatgpt apps,

    ——, “Introducing chatgpt apps,” https://openai.com/blog/chatgpt-apps, 2025, accessed: 03/15/2026

  30. [30]

    Bug bounty: Openai - bugcrowd,

    ——, “Bug bounty: Openai - bugcrowd,” https://bugcrowd.com/engagements/openai, 2026, accessed: 03/15/2026

  31. [31]

    Ignore Previous Prompt: Attack Techniques For Language Models

    F. Perez and I. Ribeiro, “Ignore previous prompt: Attack techniques for language models,” arXiv preprint arXiv:2211.09527, 2022

  32. [32]

    The protection of information in computer systems,

    J. H. Saltzer and M. D. Schroeder, “The protection of information in computer systems,” in Proceedings of the IEEE, vol. 63, no. 9, 1975, pp. 1278–1308

  33. [33]

    Ignore this title and hackaprompt: Exposing systemic vulnerabilities of llms through a global prompt hacking competition,

    S. Schulhoff, J. Pinto, A. Khan, L.-F. Bouchard, C. Si, S. Anati, V. Tagliabue, A. Kost, C. Carnahan, and J. L. Boyd-Graber, “Ignore this title and hackaprompt: Exposing systemic vulnerabilities of llms through a global prompt hacking competition,” inProceedings of the 2023 Conference on Empirical Methods in Natural Language Processing, 2023, pp. 4945–4977

  34. [34]

    The confused deputy problem - aws identity and access management,

    A. W. Services, “The confused deputy problem - aws identity and access management,” https: //docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html, 2026, accessed: 03/15/2026

  35. [35]

    Verifying the EROS confinement mechanism,

    J. Shapiro and S. Weber, “Verifying the EROS confinement mechanism,” inProceedings of the IEEE Symposium on Security and Privacy (S&P), 2000

  36. [36]

    Gpt store mining and analysis,

    D. Su, Y. Zhao, X. Hou, S. Wang, and H. Wang, “Gpt store mining and analysis,” inProceedings of the 16th International Conference on Internetware, 2025, pp. 344–354

  37. [37]

    The Instruction Hierarchy: Training LLMs to Prioritize Privileged Instructions

    E. Wallace, K. Xiao, R. Leike, L. Weng, J. Heidecke, and A. Beutel, “The instruction hierarchy: Training LLMs to prioritize privileged instructions,”arXiv preprint arXiv:2404.13208, 2024. 30

  38. [38]

    Jekyll on iOS: When benign apps become evil,

    T. Wang, K. Lu, L. Lu, S. Chung, and W. Lee, “Jekyll on iOS: When benign apps become evil,” inProceedings of the USENIX Security Symposium, 2013

  39. [39]

    Fundamental limitations of alignment in large language models,

    Y. Wolf, N. Wies, O. Avnery, Y. Levine, and A. Shashua, “Fundamental limitations of alignment in large language models,”arXiv preprint arXiv:2304.11082, 2023

  40. [40]

    Jailbreak Attacks and Defenses Against Large Language Models: A Survey

    S. Yi, Y. Liu, Z. Sun, T. Cong, X. He, J. Song, K. Xu, and Q. Li, “Jailbreak attacks and defenses against large language models: A survey,”arXiv preprint arXiv:2407.04295, 2024

  41. [41]

    Don’t listen to me: Understanding and exploring jailbreak prompts of large language models,

    Z. Yu, X. Liu, S. Liang, Z. Cameron, C. Xiao, and N. Zhang, “Don’t listen to me: Understanding and exploring jailbreak prompts of large language models,” in33rd USENIX Security Symposium (USENIX Security 24), 2024, pp. 4675–4692

  42. [42]

    Dissecting android malware: Characterization and evolution,

    Y. Zhou and X. Jiang, “Dissecting android malware: Characterization and evolution,” in Proceedings of the IEEE Symposium on Security and Privacy (S&P), 2012

  43. [43]

    Universal and Transferable Adversarial Attacks on Aligned Language Models

    A. Zou, Z. Wang, N. Carlini, M. Nasr, J. Z. Kolter, and M. Fredrikson, “Universal and transferable adversarial attacks on aligned language models,”arXiv preprint arXiv:2307.15043, 2023. A OpenAI Legacy Connectors Table 8 enumerates the 32 OpenAI first-party connectors present in the catalog. Unlike the 856 third-party MCP connectors, these carry nocreated...