The Invisible Spy inside ChatGPT: How a Hidden Channel Exposed Victims’ Gmail Accounts

Enterprises are connecting AI assistants to more of their real infrastructure every month, from inboxes to file drives to internal tools, on the assumption that the isolation between users and accounts holds. Check Point Research just tested that assumption against ChatGPT and found a way to break it.

Using an internal service that was never meant to carry user data at all, CPR opened a working channel between two completely separate ChatGPT accounts and used it to hand one victim’s session a task from a total stranger, all while the victim’s own conversation looked entirely normal. 

Key Takeaways 

• Check Point Research found a hidden channel that let a ChatGPT session under one account send tasks to a completely separate session under another account, running through an internal service neither user could see. 

• The channel worked through an internal package delivery service that ChatGPT’s code execution containers were all allowed to reach. It was supposed to keep those containers isolated from each other, but it let any container write and read shared data that separate accounts should never have been able to share. 

• In a live demonstration, an attacker’s session pulled data straight out of a victim’s connected Gmail account. The victim sent one ordinary message and saw nothing but a normal answer. 

• Triggering it took almost nothing from the victim, a malicious prompt, a shared conversation link, or a custom GPT were all enough. OpenAI has since confirmed the specific vulnerability is fixed. 

• The bigger lesson applies well beyond ChatGPT. Any AI assistant with credentials, tool access, and connected apps can be turned into what CPR calls a coerced insider, carrying out an attacker’s instructions using permissions the victim already granted in good faith. 

What did Check Point Research actually find? 

CPR discovered a covert, two-way channel between the code execution containers of two separate ChatGPT conversations running under different accounts. A crafted instruction could make a victim’s ChatGPT session quietly process a second stream of tasks alongside the conversation the victim could actually see. The visible answer looked completely ordinary. The hidden task, and its result, moved through a channel the victim had no way of noticing. 

Figure 1 – ChatGPT process a second stream of tasks alongside the visible conversation. 

How did the attack actually work? 

ChatGPT spins up isolated containers to handle tasks that need code execution, and those containers sometimes need to install software packages. To support that without giving containers direct internet access, OpenAI routes package requests through an internal JFrog Artifactory instance. Containers from different accounts cannot talk to each other directly, but every container can reach that same internal service. 

CPR found that the service exposed an item management feature letting any container attach text or binary properties to a repository item, and letting any container read those properties back.

The reader credentials already available inside every container were enough to use both operations. CPR confirmed the isolation gap directly: a property written from one account’s container was fully readable from a different account’s container moments later, with data too large for one property simply split into chunks and reassembled on the other end. The package delivery metadata effectively became a shared clipboard between containers that were supposed to be walled off from one another. 

From there, an attacker’s session could write a task into that shared storage. A single planted instruction, delivered through a malicious prompt, a shared conversation, or a custom GPT, was enough to get a victim’s session checking that same storage during its next ordinary reply. If a task was waiting, ChatGPT would carry it out using whatever the victim’s own session already had permission to do, write the result back to the shared storage, and answer the victim’s real question as if nothing else had happened. 

Figure 2 – ChatGPT processes a visible user request and a hidden task during the same turn, then returns the results through separate channels. 

What data could an attacker actually reach? 

The reach of the attack depended entirely on what the victim’s own session was already authorized to access. That included the conversation history and files inside the affected chat, plus anything available through the victim’s connected apps such as Gmail, Google Drive, Microsoft Teams, or GitHub. In CPR’s demonstration, ChatGPT retrieved the victim’s email data through their connected Gmail account and delivered it to the attacker’s session, all within a single ordinary turn. 

Figure 3 – ChatGPT plugins. 

Would the victim have noticed anything? 

Barely. ChatGPT’s default connected app setting automatically approves read actions it considers low risk, without a separate confirmation step. The only trace CPR observed was a small “Talked to Gmail” label attached to the answer, logged after the read had already happened. It recorded what occurred. It did not give the victim a chance to stop it. 

Is this still exploitable today? 

No. CPR disclosed the finding to OpenAI, who confirmed the specific internal Artifactory instance identified during the research has been decommissioned. That closes this particular path, though the architectural pattern behind it is worth every security team’s attention regardless of which platform they use. 

How does this connect to the Hugging Face incident? 

Through the same piece of internal infrastructure. CPR had already found this issue in Artifactory and had a fully working proof of concept in hand before the activity that eventually led to the Hugging Face compromise took place, activity that OpenAI has since described publicly. The two are not the same attack and did not use the same technique, but they both took root in the same shared service behind ChatGPT, which says something bigger than either finding on its own.

When AI agents run on shared internal infrastructure, that infrastructure becomes worth attacking in its own right, and this research is one more data point showing why. 

Why does this matter beyond one vulnerability in one product? 

Any AI assistant that operates inside an organization’s trust boundary, holding credentials, running code, and reaching connected services, can become what CPR calls a coerced insider. The model itself does not need to be malicious. It only needs to be persuaded, through text it was never meant to trust, to use access that was granted for entirely legitimate reasons. As more employees connect their assistants to more of the systems they rely on every day, the amount an attacker could reach through a channel like this one only grows. 

What should security teams do about it? 

Three things matter most. Know which AI tools your people are actually using and what those tools are connected to, since shadow AI usage is where blind spots start. Put runtime protection in place to detect manipulation attempts and prevent sensitive data from moving where it should not. And govern what  AI tools and agents are actually allowed to do, treating their actions, not just their outputs, as  something that needs to be monitored and controlled.

This is the security gap Check Point AI Security is built to address: visibility into AI usage and connections across the organization, runtime protection against threats such as prompt injection and data leakage, and governance over what connected AI systems can access and act on. 

Research like this is also part of why Check Point works closely with OpenAI. The partnership is built around supporting the AI transformation happening across enterprises today, making AI itself more secure through disclosures like this one, and using AI to make our own security solutions sharper in turn.