ChatGPT flaw lets attackers pull Gmail data across accounts via a hidden channel – csoonline.com

A flaw in OpenAI’s ChatGPT allowed attackers to extract data from a victim’s connected Gmail account by passing hidden instructions between separate user sessions, according to research from Check Point.
In a proof-of-concept, Check Point demonstrated that a victim’s ChatGPT session could retrieve email data and relay it to an attacker-controlled session within a single, seemingly normal interaction.
“Check Point Research discovered a covert cross-account command channel through which an attacker could use a victim’s ChatGPT session to execute hidden tasks with the tools, data, and connected apps available to that session,” Check Point researcher Alexey Bukhteyev wrote in the report. “In our proof of concept, ChatGPT retrieved email data from the victim’s connected Gmail account and relayed it to the attacker.”  
OpenAI has since fixed the issue, according to the report, confirming that the internal service involved has been decommissioned.
Check Point described this as a “coerced insider” scenario, where the AI system itself is not compromised but can be manipulated into performing unintended actions within the organization’s trust boundary.
The attack’s reach extended to anything the victim’s session was already authorized to access, including Google Drive, Microsoft Teams and GitHub connectors, not just Gmail, the report added.
The vulnerability stemmed from ChatGPT’s code execution environment, where tasks run inside isolated containers tied to individual user accounts.
To support software installation inside those containers, OpenAI routes package requests through an internal service based on JFrog Artifactory, according to the report.
While containers are not supposed to communicate with each other, Check Point found that each container could write and read metadata in that shared service.
“The package delivery metadata effectively became a shared clipboard between containers that were supposed to be walled off from one another,” the report said.
By writing instructions into that shared metadata, an attacker’s session could pass tasks to a victim’s session. “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,” Check Point said in the report.
In its demonstration, Check Point showed that the hidden task could instruct ChatGPT to retrieve data from a victim’s connected Gmail account and return it to the attacker.
“The visible answer looked completely ordinary,” the report said, even as the hidden task executed in parallel.
The scope of the attack depended on what the victim’s session was authorized to access, including email, files, and other connected applications such as cloud storage or collaboration tools, according to Check Point.
User awareness was minimal. The only indication observed was a small label ‘Talked to Gmail’ showing that an external service had been accessed, logged after the action had already taken place, the report said.
Check Point Research said its proof of concept was already working before a separate chain of activity on the same Artifactory instance led into the Hugging Face compromise that OpenAI has since disclosed publicly. The two incidents used different techniques but trace back to the same shared internal service.
Shilpi Handa, associate research director at IDC, said a repeat isolation failure on the same infrastructure changes how enterprises should weigh vendor risk.
“Can one tenant’s container read or write data another tenant’s container can also access?” is a question CIOs should be putting directly to AI vendors, Handa said, since the answer isn’t something customers can verify independently.
Handa said enterprises should also ask vendors how many isolation-boundary findings they have logged over the past 12 months and what changed structurally after each one.
OpenAI did not immediately respond to a request for comment.
Handa said enterprises don’t need to wait on vendor answers to reduce exposure. She recommended authorizing connected apps narrowly rather than by default, granting a calendar connector without also enabling Gmail and Drive access.
A limited grant “narrows what any container-level leak can expose,” Handa said.
She also recommended routing connected-app traffic through DLP or CASB inspection to catch regulated data before it leaves the pipeline, and requiring an API or webhook that logs every connected-app read and write, with timestamp and data category, exported to the enterprise’s own SIEM.
Without that logging, Handa said, “you can’t detect this class of leak even post-patch.” She said admin consoles at some vendors let customers override default risk-tiering on reads involving Gmail or Drive, forcing explicit approval rather than automatic access. That override is worth applying specifically to confidential or regulated data sources such as legal, HR, or finance systems, she said.
Gyana Swain is a seasoned technology journalist with over 20 years’ experience covering the telecom and IT space. He is a consulting editor with VARINDIA and earlier in his career, he held editorial positions at CyberMedia, PTI, 9dot9 Media, and Dennis Publishing. A published author of two books, he combines industry insight with narrative depth. Outside of work, he’s a keen traveler and cricket enthusiast. He earned a B.S. degree from Utkal University.

source
This is a newsfeed from leading technology publications. No additional editorial review has been performed before posting.