Two ChatGPT sessions belonging to two different accounts could pass messages to each other without either user seeing a thing. Not through the model: through the package repository they shared. Check Point Research found it and The Register covered it. The hole is already closed, but the pattern is common enough to be worth a careful look.
What they found
When ChatGPT runs code, it does so in isolated containers. Those containers can't reach the public internet — if they could, they'd leak user data or find exposed credentials and break into other people's servers — so they have exactly one door: an internal JFrog Artifactory instance proxying the package repositories.
That door had two flaws which, together, add up to an incident:
- The instance exposed item property management. In other words, you could attach text to a repository item — including binary data encoded in Base64 — and a container running under another account could read it.
- The credentials handed to the container, meant for reading, allowed both read and write. And code launched by ChatGPT could authenticate against the storage endpoint without pulling out a separate secret or escalating privileges.
That's shared memory between tenants. The attacker's session writes a task; the victim's session reads it and runs it with the victim's permissions.
The demo uses a shared conversation. The hidden instruction was as simple as asking for a list of emails through the Gmail connector. The victim opens the link and asks something perfectly normal — a chart of average monthly temperatures in New York. ChatGPT delivers the chart, and along the way queries their Gmail and returns the results to the attacker through the hidden channel. Nothing about the email appears in the visible answer. The only clue, per the report, was the small "Talked to Gmail" label above it.
And it doesn't stop at email: any connector the victim's session had authorised — history, files, Drive, Teams, GitHub and the rest — is fair game.
Some context: Check Point disclosed this to OpenAI in late June, the same day OpenAI's own agents exploited a zero-day in that very Artifactory to reach the internet and eventually break into Hugging Face. It isn't the same attack; they share the component. OpenAI replied that the instance had already been decommissioned. The Register got no comment.
Why this touches you even if you're not OpenAI
The artefact proxy is perimeter, not plumbing
If your sandbox has no internet but does have a package proxy, that proxy is your attack surface. And a modern artefact proxy doesn't just serve files: it serves writable metadata, properties, tags, custom checksums. Every one of those fields is a mailbox between runs.
What I'd do differently from today: set the proxy to genuinely read-only and verify it with a real write request, not by reading the docs. Disable the properties API if you don't use it. One short-lived token per session, not a single token shared across the whole container fleet.
"Read-only" is the name of the role, not the effective permission
This is the failure I see most often in other people's setups: someone creates a user called reader and nobody ever checks what it can actually do. Add a test to your suite that tries to write using the sandbox credentials and fails if the write succeeds. Twenty lines, and it saves you this entire article.
A covert channel doesn't need internet access
Here's the useful generalisation. If two runs belonging to different users can touch the same byte, you have a channel. Artifactory is incidental: a shared package cache will do, or a temporary bucket, a state table, a queue, a volume mounted on the CI runner, a working directory reused between jobs. Isolation breaks in the place nobody thinks of as a "service".
The visible answer is not the activity log
The text the user sees is not an audit trail. If your agent calls tools, you need traces of those calls outside the model, per session, recording who asked for what against which credential. Here the only signal to the user was a tiny label nobody looks at. An LLM can answer your question and do something else at the same time without lying about the result: the conversation is not the log.
Connectors are the blast radius
Each authorised connector isn't a permission you grant the model for that moment: it's a standing permission that any instruction, from wherever it arrives, can use. Review which connectors are live, who authorised them, and whether they belong in a personal account or in a governed workspace. And treat shared conversation links as what they are: third-party content.
Check Point's best line on the problem, condensed:
The model works inside the trust boundary — it uses credentials, runs code, reaches internal services — and text directs it. That makes it a coerced insider.
What doesn't change
Now the counterweights, because this can be told worse than it is.
- The hole is closed. The internal instance had already been decommissioned before the report even landed. There's nothing for you to patch in ChatGPT today.
- It's a research proof of concept. There's no evidence anyone used it against real users. "ChatGPT was leaking your Gmail" is a false headline.
- It isn't the Hugging Face incident. Same component and same disclosure day, different attack.
- It isn't classic prompt injection. It's a multi-tenant isolation failure, and that's the good news: you fix it with well-understood architecture — per-session credentials, effective permissions, nothing shared — not by politely asking the model to ignore strange instructions.
- We only have one side. OpenAI hasn't commented publicly on the finding.
If you've got agents running code on your infrastructure, this week's question is short: which writable resource is shared between two runs belonging to two different customers? Any questions, tell me and we'll go through it.
Best, Vicente.