Check Point Found a ChatGPT Sandbox Flaw That Leaked Gmail Across Accounts

Your ChatGPT session doesn't need to leak your data to an obviously malicious website. Check Point Research just showed it can leak your data to a stranger's ChatGPT account — through a service you've never heard of, sitting inside OpenAI's own infrastructure, that both of your sandboxes happened to share.

The vulnerability, published by Check Point Research on September 8, 2026 as "The Shared Clipboard Inside the Sandbox," let an attacker hijack a victim's live ChatGPT session and pull data from their connected Gmail account — without the victim clicking anything suspicious, and without a visible approval prompt. OpenAI has already decommissioned the component that made it possible, but the mechanism is worth understanding if you or your team connect ChatGPT to email, cloud storage, or any other sensitive account.

TL;DR

How ChatGPT's sandbox is supposed to work

When ChatGPT runs code — analyzing a CSV, plotting a chart, installing a Python package — it does so inside a per-conversation container. These containers are isolated by design: they can't reach the open internet, and they're not supposed to be able to talk to a container spun up under a different account. That isolation is the entire security model for code execution — the same design goal behind sandboxing patterns covered in explainx.ai's MCP security guide and the Claude Desktop sandbox guide.

The catch: containers still need to install packages. To do that without full internet access, they're routed to an internal package-delivery service — in this case, a JFrog Artifactory instance sitting inside OpenAI's infrastructure. Every container, regardless of which account spun it up, could reach that same instance.

The "shared clipboard" mechanism

Check Point found that this shared Artifactory instance exposed its Item Management API without tenant isolation. Two operations mattered:

• Set Item Properties — write arbitrary string metadata onto a repository item
• Get Storage Item Information — read that metadata back

Both operations lived behind /api/storage/{repoKey}/{itemPath}, and the credentials baked into each container's environment variables were sufficient to call both. Researchers confirmed that a property one account's container set was readable by a different account's container — turning the metadata fields into an informal, unmonitored channel between environments that were never supposed to communicate. Check Point's own framing: "Mutable state on shared infrastructure needs strict tenant isolation, and management interfaces should stay out of reach from the runtime entirely."

That's the whole bug. Nothing exotic — no memory corruption, no cryptographic break. Just a management API reachable from inside a runtime it should never have touched, doing double duty as a dead-drop between tenants.

From covert channel to Gmail exfiltration

A channel between sandboxes is only interesting if it can be triggered against someone who didn't ask for it. Check Point demonstrated three delivery paths, all variations on getting hidden instructions in front of a victim's session:

1. A malicious prompt planted directly in a chat
2. A shared ChatGPT conversation link carrying hidden instructions
3. A custom GPT with covert instructions buried in its configuration

Once the victim interacted with the poisoned content, their own ChatGPT session picked up the attacker's task through the shared Artifactory channel and executed it with the victim's own permissions and connected apps — a textbook case of indirect prompt injection, except the payload traveled through infrastructure metadata instead of a webpage or document.

In the proof of concept, the hidden task was: query the victim's connected Gmail account and relay whatever comes back through the same covert channel. The victim's visible chat kept answering their actual question normally the whole time. The only observable artifact was a small "Talked to Gmail" label appearing after the query completed — no confirmation dialog, because read-only actions on connected apps fall under ChatGPT's default "Important actions" setting, which doesn't require approval.

That last detail is the part worth internalizing even now that this specific bug is closed: a "read-only" label is doing a lot of quiet work in ChatGPT's default trust model. Reading someone's inbox is not a low-stakes action just because nothing gets deleted.

Disclosure timeline and fix

OpenAI's fix was structural rather than a patch to the sandbox logic itself: it decommissioned the shared Artifactory instance responsible for the leak, which closes the cross-account channel outright rather than trying to police what gets written to it. Check Point confirms the vulnerability was no longer exploitable by the time it published. No CVE or public advisory identifier accompanies this disclosure.

What this means if you connect ChatGPT to Gmail or other apps

This exact channel is dead, but the pattern it exposes — a connected app performing a read with no approval step — is still how ChatGPT's default permission setting behaves. Three concrete things to check in your own account or team setup:

• Switch connected apps to "Always ask." ChatGPT's default "Important actions" setting waves through read-only connector calls silently. "Always ask" forces a visible approval prompt before Gmail, Drive, Calendar, or any other connector is touched — the cost is a few more clicks, the benefit is you actually see when your inbox gets queried.
• Be skeptical of shared ChatGPT conversation links and third-party custom GPTs. Both were proven delivery vectors here. A link or a GPT from someone you don't know can carry instructions your session will follow without you reading them.
• Audit your active connectors periodically. If you connected Gmail, Drive, or a CRM to ChatGPT months ago and forgot about it, that's exactly the kind of standing access an indirect-injection attack is built to abuse.

How this compares to how other agent platforms isolate credentials

The Check Point disclosure lands the same week Meta shipped Muse, a personal agent built explicitly around this failure class. Muse's Sentinel architecture runs each user's agent in its own per-user Secure VM and never lets the agent model see real OAuth credentials at all — a separate, kernel-enforced process swaps in the real credential only at the network boundary, after the request leaves the agent. That design specifically targets the risk that a compromised or injected agent session might try to reach outside its own account boundary — the same shape of failure Check Point found, just via a shared internal service instead of a credential leak.

The broader lesson for anyone building agent-connected workflows isn't "ChatGPT is uniquely unsafe" — it's that shared backend infrastructure is a recurring blind spot in agent sandbox design generally. A container boundary that stops direct network calls between tenants doesn't automatically stop indirect ones through a shared management API, a shared cache, or a shared queue. explainx.ai's MCP security guide covers the same principle for anyone standing up their own agent tooling: least-privilege access and strict tenant isolation have to extend to every piece of shared infrastructure an agent's sandbox touches, not just its obvious network egress.

It's also a close cousin of the Claude Memory Heist disclosure from July 2026, where Claude.ai's memory plus web_fetch link-following let personal data leak through GET-only URL paths with no code execution and no MCP involved at all. Different mechanism, same underlying lesson: agent platforms keep discovering new covert channels because the attack surface isn't just "can the model be tricked" — it's every piece of shared plumbing behind the model that a session touches.

The takeaway

Check Point's finding didn't require jailbreaking ChatGPT or breaking any cryptography — it required noticing that two things which shouldn't talk to each other were both allowed to write to the same metadata field on a shared internal service. That's a boring, structural class of bug, and it's exactly the kind that agent platforms will keep shipping as they race to add more code execution and more connectors: every new shared backend service is a new candidate for an unintended cross-tenant channel.

OpenAI's fix closes this specific hole. The standing advice doesn't change: treat connected-app read access as something worth an approval prompt, not something to leave on autopilot, and assume any AI agent's sandbox boundary is only as strong as the least-isolated piece of infrastructure behind it.

Vulnerability details, dates, and fix status in this post reflect Check Point Research's published disclosure as of September 9, 2026. If OpenAI publishes further advisory detail or a CVE identifier, this post will be updated.

Related reading

• What Is Indirect Prompt Injection? How Web Content Hijacks AI Agents
• Meta Launches Muse: The Personal Agent With a Sentinel Security Architecture
• MCP Security Guide 2026: How to Secure AI Agent Tool Access
• Claude Memory Heist: web_fetch Exfiltrated PII From Claude.ai Memory
• Claude Desktop: Restrict Access With a Sandbox
• Instinct + 1Password: What It Actually Means to Give an AI Agent Your Vault
• Check Point Research: The Shared Clipboard Inside the Sandbox (official disclosure)