ChatGPT Artifactory Flaw Let Researchers Access Gmail Across Sessions, Now Fixed

This was a researcher demonstration, not a confirmed wave of attacks. It still deserves attention from anyone who administers AI tools in a Microsoft 365, Teams or GitHub shop. The lesson is about permission boundaries, and it applies well beyond this one bug.

What actually happened​

Check Point Research said a single instruction planted in a ChatGPT conversation could make ChatGPT quietly work for an attacker while still answering the user's question as usual. The researchers did not break into Gmail directly. They also did not find a way to read another user's chat. They found a shared service that two otherwise walled-off sessions could both reach.

Check Point's explanation runs as follows:

• ChatGPT spins up isolated containers for tasks that need code execution. Those containers sometimes need to install software packages.
• To avoid giving containers direct internet access, OpenAI routes package requests through an internal JFrog Artifactory instance.
• Containers from different accounts can't talk to each other directly, but every container can reach that same internal service.
• The service's item-management feature let any container attach text or binary properties to a repository item, and let any container read them back.
• Credentials already present inside each container were enough to do both.

Check Point confirmed the gap directly. A property written from one account's container was readable from a different account's container moments later. Data too big for one property could be split into chunks and reassembled. Package metadata effectively became a shared clipboard between sessions that were supposed to be strangers.

How the attack was delivered​

The attacker's session could write a task into that shared storage. A planted instruction then had to get the victim's session to check the storage during its next ordinary reply. Check Point lists three delivery routes:

1. A malicious prompt pasted into a chat.
2. A shared conversation link.
3. A custom GPT carrying a hidden instruction.

If a task was waiting, the victim's session would carry it out using whatever access that session already had. It then wrote the result back to shared storage and answered the visible question as if nothing had happened. Reporting from The Register describes a victim asking for a simple temperature chart. ChatGPT completed that request, but it also accessed the victim's connected Gmail account and sent the email data to the attacker's account through the hidden channel.

What could be reached, and what was proven​

The reach depended entirely on what the victim's session was already authorized to touch. Check Point lists the following:

• Conversation history and files in the affected chat.
• Data from connected apps such as Gmail, Google Drive, Microsoft Teams and GitHub.

Gmail is the only service Check Point actually demonstrated. The other services describe potential reach, and only where the victim had connected them. The headline phrase "steal Gmail data" is accurate for the proof of concept. It would be wrong to read it as every ChatGPT user's inbox having been exposed.

One independent summary, from Vibe Graveyard, is explicit that the September 8 disclosure describes a researcher demonstration, with customer exploitation unconfirmed.

Why the victim noticed nothing​

Check Point says ChatGPT's default connected-app setting automatically approves read actions it judges low risk, with no separate confirmation step. The only trace the researchers saw was a small "Talked to Gmail" label attached to the answer. It was logged after the read had already happened. It recorded the action but gave the user no chance to stop it.

This describes the default setting Check Point tested. It shouldn't be generalized to every configuration, plan or connector.

Is it still exploitable?​

Check Point says no. It disclosed the finding to OpenAI, which confirmed the specific internal Artifactory instance had been decommissioned. The Register adds a wrinkle: by the time Check Point reported the issue, OpenAI had already decommissioned the instance because of the Hugging Face incident.

Check Point is careful to separate the two events. Its proof of concept was working before the activity that eventually led to the Hugging Face compromise OpenAI disclosed. The two were not the same attack and did not use the same technique. They did share the same internal infrastructure. Don't read this as the Gmail demonstration causing, or being part of, the Hugging Face incident.

Reporting also indicates the research was published on September 8, 2026. According to Technobezz, the researcher was Alexey Bukhteyev, who found the channel independently in June 2026. I couldn't confirm further disclosure or remediation dates, and I found no CVE identifier in the material I reviewed.

Don't confuse it with the March DNS report​

Check Point published a separate ChatGPT finding on March 30, 2026. That one involved DNS tunneling out of the code-execution runtime to an attacker-controlled server. The cross-account Artifactory channel is a different mechanism. OpenAI said the fix for the DNS issue was fully deployed on February 20, 2026. That date has nothing to do with the Artifactory channel.

The two findings share a theme, though. In both cases the code-execution sandbox looked locked down, and a side path nobody had thought to treat as a data channel got around it.

What it means for IT admins​

Check Point calls the pattern a "coerced insider." The model needn't be malicious. It only needs to be persuaded, by text it should never have trusted, to use access that was legitimately granted. That is Check Point's characterization, not a formal vulnerability class. It is still a useful way to think about the risk.

A vendor with an AI security product to sell wrote the guidance below, so weigh it accordingly. It is nonetheless sensible. Check Point recommends three things:

• Know which AI tools staff use and what they are connected to. Unsanctioned use is where blind spots start.
• Deploy runtime protection that detects manipulation attempts and stops sensitive data moving where it shouldn't.
• Govern and monitor what connected AI agents are allowed to do. Reviewing only their text outputs isn't enough.

My own practical takeaways, from general security practice rather than Check Point's findings:

• Audit which connectors users have enabled (mail, drive, chat, code hosting) and remove any they don't need.
• Treat shared conversation links and third-party custom GPTs like untrusted attachments.
• Where your plan allows, prefer confirmation prompts for connected-app actions over silent auto-approval.
• Remember that a read-only grant can still be a data-exfiltration path when an AI model sits in the middle.

None of these is a guaranteed fix for this class of problem, and Check Point doesn't claim they would have stopped this demonstration. The specific path is closed. The architectural lesson is that shared infrastructure behind AI agents becomes a target in its own right. With assistants now wired into Teams, GitHub and mailboxes, the permissions you grant them matter as much as the prompts you type.