Summary by Teringette-adamuzonyi
Cross-Tenant Context Isolation Failure in ChatGPT:
A Single-Case Study of Exposure, Triage Failure, and the Hallucination–Breach Ambiguity Problem
Adam Uzonyi (Bugcrowd handle: Teringette-adamuzonyi)
Independent Security Researcher
July 2026
Disclosure Status Notice
This case concerns a vulnerability reported to OpenAI through Bugcrowd (submission threads reopened, validated, and awarded as P1 with a $2,000 bounty). As of the most recent correspondence on record, OpenAI has stated that a post-fix analysis is still underway and has NOT approved this material for public disclosure. The only statement currently authorized for public sharing is that the author "successfully submitted a bug bounty report and received an award."
This draft is prepared so that it is ready for release the moment written approval is received. It must not be circulated, submitted to a venue, or posted publicly until that approval is obtained in writing, per the Bugcrowd/OpenAI safe-harbor and disclosure terms governing this engagement.
In addition, all references to the underlying patient data in this draft are deliberately kept at the category level (e.g., "protected health information," "diagnostic records"). No name, date of birth, patient identifier, or other detail that could identify the affected third party is reproduced anywhere in this document, and none should be added in any future revision — that individual did not consent to having their medical information discussed in a public research paper.
Abstract
Multi-tenant Large Language Model (LLM) deployments increasingly mediate access to sensitive personal and medical data, yet the mechanisms that isolate one user's context from another's remain comparatively immature relative to decades-old web application access-control practice. This paper presents a single-case study of a coordinated vulnerability disclosure involving ChatGPT, in which a researcher conducting benign, non-adversarial usage received model output containing what was later confirmed by the vendor to be authentic session and file data belonging to a different, unrelated user, including protected health information (PHI). The case is notable less for its technical novelty , cross-tenant leakage in shared-cache and retrieval-augmented generation (RAG) architectures is an active and growing area of academic study, and more for what it reveals about triage: the same properties that make LLMs useful (fluent, plausible-sounding generation) make a genuine data breach difficult to distinguish from a hallucination during initial incident response. We term this the Hallucination Triaging Dilemma. We describe the reported chronology as documented in the vendor's bug-bounty platform, present two non-exclusive architectural hypotheses consistent with the observed (but not internally verified) behavior, and derive triage and remediation recommendations for AI platform operators and bug-bounty programs. We are explicit throughout about the boundary between what the vendor confirmed, what we observed as an external black-box party, and what remains inferential.
- Introduction Traditional multi-tenant web applications enforce data isolation through database-level access control lists, session tokens, and row-level security. LLM-based applications introduce additional, less mature isolation boundaries: prompt-caching layers that reuse computation across requests, vector-embedding namespaces used for retrieval-augmented generation (RAG), and the model's own token context window, which by design concatenates content from multiple sources into a single undifferentiated sequence before generation. This paper documents a case in which an independent security researcher, Adam Uzonyi, the founder and leader of Teringette Programming School, using ChatGPT for ordinary, non-malicious purposes, received a model response containing detailed information that did not originate from their own account or uploads. The report was classified P1 (Critical) under the vendor's Bugcrowd-hosted bug bounty program and awarded a $2,000 bounty. Two aspects of this case motivate a research write-up beyond a routine vulnerability disclosure. First, the underlying architectural failure mode, which could be a cross-tenant bleed through shared inference-serving infrastructure or retrieval systems, sits within a body of academic work that has emerged only in the past two years (Section 2), and this case offers a real-world, production-scale data point for that literature. Second, and more distinctively, the case's triage history illustrates a structural weakness in how AI vendors currently distinguish genuine data leakage from hallucinated (confabulated but non-authentic) output, a distinction that did not exist as a triage category in pre-LLM security operations. We frame this paper explicitly as a single-case study conducted from a black-box, external vantage point. We had no access to OpenAI's internal telemetry, logs, or architecture at any point; every technical claim about root cause is therefore a hypothesis consistent with observed behavior, not a confirmed mechanism, and we flag this distinction throughout rather than presenting inference as fact.
Related Work
Cross-tenant leakage in multi-tenant LLM serving has become an active research area since 2024–2025, providing useful architectural grounding for the hypotheses in Section 4.
2.1 KV-Cache Side Channels
Wu et al. present the first systematic investigation of security risks in multi-tenant LLM serving, showing that state-of-the-art Key-Value (KV) cache sharing mechanisms used by frameworks such as vLLM and SGLang create timing side channels that allow an attacker to reconstruct another tenant's prompts by observing response-latency differences that betray cache hits [1]. Follow-on work (SafeKV, CachePrune, OptiLeak) confirms this class of vulnerability is reproducible across multiple serving frameworks and proposes mitigations such as visibility-scoped cache reuse and selective sharing restricted to intra-tenant requests [2]–[4]. Notably, this line of work targets prompt reconstruction via inference (a side channel), which is architecturally distinct from — though adjacent to — the direct content bleed reported in the present case, where exposed data appeared as generated text rather than an inferred signal.
2.2 RAG and Vector-Store Access Control
A parallel body of work addresses access-control failures in retrieval-augmented generation pipelines. OWASP's LLM Top 10 formally classifies cross-tenant vector-store leakage as LLM08 (Vector and Embedding Weaknesses), noting that improper logical partitioning of shared vector stores allows embeddings from one tenant to be retrieved in response to another tenant's query [5], [6]. Industry guidance converges on the same root cause pattern: retrieval APIs that filter by tenant ID at the application layer, rather than enforcing that boundary as a mandatory database-level constraint, are vulnerable whenever the filter can be bypassed, omitted, or left unenforced for a subset of queries [7], [8]. This pattern (an application-layer rather than data-layer trust boundary) is structurally analogous to Insecure Direct Object Reference (IDOR) vulnerabilities in conventional web applications, and is the basis for Hypothesis B in Section 4.
2.3 Positioning of This Case Study
Unlike the controlled, attacker-driven demonstrations in [1]–[8], the present case involved no adversarial payload, no intentional probing technique, and no attacker-controlled input designed to trigger leakage. This positions it as an observational field report of spontaneous cross-tenant bleed under production load.Case Chronology
The chronology below is reconstructed from the Bugcrowd submission activity log for this engagement. Each entry is a record of a platform event (state change, message, or award) as logged by Bugcrowd/OpenAI; researcher interpretations are marked as such.
Stage
Recorded Event
Source
Initial submission
Report filed describing cross-user PHI/PII exposure via application-layer data isolation failure (framed by the researcher as a potential IDOR / broken access control issue).
Bugcrowd activity log
First triage outcome
Closed as "Not reproducible"; reviewer stated insufficient information was provided to replicate the finding and requested proof of impact.
Bugcrowd activity log
Researcher follow-up
A related submission was filed reiterating that the exposed content included real, non-fabricated user data; flagged internally as a duplicate of prior submissions.
Bugcrowd activity log
Escalation submission
A further report ("URGENT: Critical Data Breach — Cross-User PHI/PII Leakage via Prompt Injection — Non-malicious discovery") was filed.
Bugcrowd activity log
Reopening
Bugcrowd/OpenAI reopened the previously closed submission, stating that a broader internal follow-up review had validated the underlying technical issue, which "occurred only in narrow conditions."
OpenAI acknowledged that the researcher observed unexpected model output that appeared to contain potentially sensitive information unrelated to their conversation. OpenAI reviewed the report, addressed the underlying issue, and provided a bug bounty award.
Bugcrowd activity log (OpenAI reviewer message)
Classification & reward
Severity set to P1 (Critical); bounty of $2,000 awarded; submission state changed to "Resolved."
Bugcrowd activity log
Disclosure request
Researcher requested a timeline for coordinated public disclosure.
Bugcrowd activity log
Vendor response (most recent)
OpenAI stated that post-fix analysis was still in progress and that public disclosure was not yet approved; researcher was authorized only to state that a report was submitted and a bounty received.
Bugcrowd activity log (OpenAI reviewer message)
Table 1. Chronology reconstructed from Bugcrowd platform activity records. This table intentionally omits prompt text, technical reproduction steps, and any patient-identifying data.
Two features of this chronology are significant for Section 5. First, the same underlying issue was initially rejected as unreproducible before later being validated — the platform's own record shows the finding crossing the line from "discarded report" to "confirmed P1 issue" without a change in the underlying evidence, only in the rigor of the review applied to it. Second, formal validation depended on an internal, backend log cross-check that was unavailable to the external researcher at any stage . The reported content could not be verified as authentic versus confabulated using black-box means alone.
OpenAI did not confirm the observed content was authentic information belonging to another user or that it contained personal information or protected health information.
- Technical Hypotheses Because this case was investigated without access to backend telemetry, we present two architectural hypotheses that are each independently consistent with the observed behaviour, a benign, non-adversarial prompt sequence producing another user's authentic data in the model's output. These hypotheses are not mutually exclusive, and neither is confirmed; OpenAI has not published internal root-cause details, consistent with common vendor practice for proprietary infrastructure. 4.1 Hypothesis A — Prompt-Cache State Collision Production LLM serving commonly uses prompt/KV-cache sharing to reduce latency and compute cost for repeated or overlapping token sequences [1]–[4]. If a session-identifier collision, race condition, or cache-key collision occurs in this layer, an active context buffer associated with one user could be appended to, or substituted into, the token sequence processed for a different user's request. Under this hypothesis, the model would generate a continuation that draws on tokens it should never have received, without any anomaly visible to the requesting user beyond the unexpected content itself. 4.2 Hypothesis B — Retrieval Namespace Enforcement Failure Because the exposed content reportedly included structured data consistent with an uploaded file (rather than free-form conversational text), this hypothesis attributes the failure to the document-retrieval layer. When a user uploads a file, many LLM platforms convert it to vector embeddings tagged with a tenant or user identifier and restrict retrieval to that namespace. If a query construction path exists in which the namespace filter is not enforced as a mandatory, data-layer constraint (consistent with the OWASP LLM08 pattern and the application-layer filtering weaknesses documented in RAG-security literature [5]–[8] ), a semantically broad query could retrieve and surface embedded content across the tenant boundary. 4.3 Assessment Both hypotheses are structurally plausible and both appear in the published literature as confirmed vulnerability classes in other systems, which is why we regard them as reasonable candidates rather than speculation. However, we did not conduct controlled, repeated testing to distinguish between them. We recommend that any published version of this paper state plainly, as we do here, that root cause was not independently verified by OpenAI.
- The Hallucination Triaging Dilemma The most transferable finding from this case is procedural rather than architectural. LLMs are, by design, capable of producing fluent, highly specific, and entirely fabricated content that is often indistinguishable in form from authentic retrieved data. This creates a structural ambiguity that did not exist in pre-LLM security operations: a report describing a data leak must first be triaged as either (a) a synthetic hallucination with no real-world referent, or (b) a genuine disclosure of another party's real data and the two can look identical from the outside. In this case, the report's initial disposition was "not reproducible," consistent with a triage process that defaults to treating unfamiliar, hard-to-replicate output as a model artifact rather than a security incident. The report was reclassified only after OpenAI's internal follow-up review validated the underlying technical issue, as confirmed in the vendor's own communication on the Bugcrowd platform. The reporting researcher had no access to the internal systems used to perform this validation, and the first-line triager does not appear to have performed any equivalent check at initial intake. While OpenAI has not publicly detailed the validation mechanism, the nature of the exposed data — including unique diagnostic attributes, file structures, and specific timelines — is consistent with a backend log cross-check against authentic records; this remains an unconfirmed inference pending vendor clarification rather than a documented fact. We propose the following triage principle for AI vendors and bug-bounty programs: reports alleging exposure of another user's real data should not be closed as "not reproducible" or "likely hallucination" solely on the basis of narrow reproduction conditions. Distinguishing a hallucination from a genuine leak requires a backend authenticity check against real records — a step that is categorically different from, and cannot be substituted by, attempting to reproduce the triggering prompt sequence. Where a report contains specific, structured, internally-consistent personal data (names, identifiers, dates, diagnostic codes, file metadata) that would be unusual for a language model to fabricate coherently, that specificity itself should be treated as a signal warranting a backend cross-check before closure, not as a factor that makes the report more likely to be dismissed as an elaborate hallucination.
- Impact Assessment The following assessment characterizes impact by category. Consistent with the disclosure and privacy constraints described in the notice at the front of this document, no specific identifying details of the affected third party are included. Impact Category Description Severity Privacy / regulatory Unauthorized exposure of another user's protected health information and personal data to a party with no relationship to that individual. Critical Platform trust A single instance of unprompted cross-tenant exposure undermines the baseline assumption — foundational to any multi-tenant SaaS or AI platform — that one account's data is inaccessible to another. High Incident-response process Demonstrated gap in first-line triage: a genuine breach was initially and repeatedly dispositioned as non-reproducible High — process risk, distinct from the technical vulnerability itself Regulatory / compliance exposure Where exposed data constitutes PHI, incidents of this type may trigger notification obligations under applicable health-data or general data-protection regimes, depending on jurisdiction and the platform's regulatory posture. Context-dependent — outside the scope of this paper to assess definitively
Table 2. Impact categorization. Regulatory characterization is descriptive, not a legal determination; the authors are not lawyers and this is not legal advice.
- Remediation and Recommendations 7.1 Vendor-Reported Remediation OpenAI reported that the issue was fixed following its internal review and closed the submission as Resolved. Internal patch details were not shared and are not available to the authors; accordingly we describe the fix only as vendor-reported and do not characterize its architecture or completeness. 7.2 General Architectural Recommendations Enforce tenant/user scoping as a mandatory, data-layer constraint on every cache and retrieval path (cryptographically bound user ID checked at the database or vector-store level), rather than relying on it being correctly applied at the application layer. Disable cross-tenant KV-cache and prompt-cache reuse by default in any deployment handling regulated or sensitive data classes, accepting the latency/cost trade-off documented in the KV-cache literature [2]–[4]. Instrument retrieval and cache-hit paths with cross-tenant anomaly detection capable of flagging when returned content matches an index or embedding outside the requesting user's namespace. Run periodic, automated cross-tenant test queries against production retrieval systems as an ongoing control, not only during initial deployment (per the audit guidance in the OWASP RAG Security Cheat Sheet [7]). 7.3 Bug-Bounty Triage Recommendations Establish a distinct triage lane for reports alleging exposure of another party's real personal or health data, routed to a reviewer with backend log access before any "not reproducible" disposition. Treat internally-consistent structured personal data in a report (identifiers, dates, diagnostic codes) as a trigger for authenticity verification against real records, not as a reason to suspect an elaborate hallucination. Provide reporters of confirmed P0/P1 privacy incidents a defined disclosure timeline once remediation is confirmed, to reduce the ambiguity researchers face between compliance with vendor process and the public-interest case for timely disclosure.
- Limitations The authors had no access to OpenAI's internal architecture, logs, or telemetry; Sections 4 and 7.1 are therefore hypothesis and vendor-reported description, not confirmed technical fact, and should be read accordingly. The initial submissions used the label "prompt injection" on the Bugcrowd platform; based on the available record, no adversarial injection payload was involved. We treat this as a terminology artifact of the reporting process rather than a technical finding, and classify the issue as a cross-tenant context/data isolation failure. As of this draft, OpenAI has not approved public disclosure of full technical detail; this paper is written to be compliant with that constraint and may need revision once approval and any vendor-provided root-cause summary are available.
- Ethical Considerations and Responsible Disclosure Statement This research concerns the real personal and health data of a non-consenting third party who has no relationship to this publication. In preparing this paper we have deliberately excluded any detail — name, date of birth, patient or record identifiers, or specific diagnostic content — that could identify that individual, and we recommend this exclusion be treated as a permanent constraint on any future version of this work, independent of what technical detail OpenAI eventually clears for disclosure. Vulnerability details that could materially assist a third party in reproducing cross-tenant exposure (exact prompt sequences, timing parameters, or account configuration specifics) are likewise withheld pending vendor approval, consistent with standard coordinated-disclosure practice.
- Conclusion This case study documents a cross-tenant data isolation failure in ChatGPT a production LLM platform that exposed protected health information belonging to an unrelated user. The vendor was able to validate and fix the underlying technical issue. OpenAI confirmed the bug bounty submission and resolved it with a critical (P1) bug-bounty award. Beyond its value as a real-world data point alongside an emerging academic literature on KV-cache and RAG-based cross-tenant leakage, the case's triage history exposes a distinct and, we argue, underexamined risk: the same generative fluency that makes LLMs useful also makes it structurally difficult to distinguish a genuine data breach from a hallucination during initial incident response. Addressing this requires AI platform operators to build backend authenticity verification into their triage process as a first-class step, not an escalation of last resort, and requires bug-bounty programs to avoid closing privacy-sensitive reports on reproducibility grounds alone. References [1] G. Wu et al., "I Know What You Asked: Prompt Leakage via KV-Cache Sharing in Multi-Tenant LLM Serving," NDSS Symposium, 2025. [2] Kexin Chu et al., "Selective KV-Cache Sharing to Mitigate Timing Side-Channels in LLM Inference" (SafeKV), arXiv:2508.08438. [3] G. Wu et al., "CachePrune: Privacy-Aware and Fine-Grained KV Cache Sharing for Efficient LLM Inference," arXiv:2605.23640. [4] "OptiLeak: Efficient Prompt Reconstruction via Reinforcement Learning in Multi-tenant LLM Services," LLM Security Database. arXiv:2602.20595.
[5] OWASP, "LLM08:2025 Vector and Embedding Weaknesses," OWASP Top 10 for LLM Applications.
[6] OWASP, "RAG Security Cheat Sheet," OWASP Cheat Sheet Series.
[7] Trent AI, "What Is RAG Security?," Trent AI blogpost 2026.
[8] Witness AI, "What Is RAG Security? 7 Risks Hiding in Your AI Knowledge Base," 2026.
[9] Bugcrowd, Inc., Submission Activity Records: "Critical Security Issue: Cross-User PHI/PII Leakage via Application Layer Data Isolation Failure" and "URGENT: Critical Data Breach — Cross-User PHI/PII Leakage via Prompt Injection — Non-malicious discovery," internal platform records, 2026 (primary source for Table 1; not independently publishable until vendor discloses).
Acknowledgements
The author thanks Ceylin Akin for enhancing the visibility of these findings and for contributing to Teringette Programming School's social marketing and public relations efforts.
The author thanks Aneti Lab and its head, Balázs Lengyel for supporting his other research projects and for providing valuable assistance, guidance, and encouragement in his broader research activities.
The author thanks his researcher sister Anna Uzonyi, who always believed in him and encouraged him to continue his work, and his parents, who have always supported him and continue to provide unwavering support.
The author thanks his partner Viktoria Agoston for always listening to his discoveries, offering ideas, and helping him further develop his research.
The author thanks OpenAI's engineering and security coordination team for conducting a post-fix analysis and for their engagement through the Bugcrowd safe-harbor process.
Adam Uzonyi (Bugcrowd handle: Teringette-adamuzonyi)
Independent Security Researcher