Thought Leadership

Black Hat USA 2026 – Las Vegas – A researcher presented a proof-of-concept attack this week claiming to establish full command and control inside an isolated ChatGPT sandbox.

On Aug. 5, Simcha Kosman, senior security researcher at Palo Alto Networks, presented "A Billion-User Blast Radius: Owning ChatGPT's Secure Sandbox" at Black Hat USA 2026. Among other things, the presentation demonstrated a proof-of-concept attack chain against ChatGPT's secure sandbox, apparently bypassing the large language model (LLM) supervisor in order to achieve persistent root execution.

While this is a proof of concept and not necessarily an attack against a realistic enterprise defender environment, the findings are interesting because the container sandbox is specifically designed to run as a secure, isolated runtime environment with strict controls. Anything that could possibly get around that would be worth calling attention to, even under theoretical circumstances.

Kosman opened the presentation with what he described as a foundational assumption: "Private chats should stay private." But even in the case of an isolated sandbox, what should stay private is not always what will stay private.

Kosman demonstrated how one could trick a victim's ChatGPT into running attacker-controlled code inside its sandbox, use the code to influence future reasoning, and abuse a shared back end to establish full command and control (C2), where data is passed from the victim's sandbox to the attacker's own sandbox.

An OpenAI spokesperson tells Dark Reading the company was aware of the research ahead of the Black Hat presentation and appreciates Kosman sharing his findings. They said the aspect of OpenAI's system involved in the proof-of-concept was removed prior to the presentation; and that in the company's view, the research does not represent an escape from ChatGPT's security sandbox or unrestricted access to other customer accounts.

How The Sandbox Attack Works

"Our first goal is to get sensitive information into the sandbox without being blocked by the LLM," Kosman said. "And the second goal is to send the information from the sandbox back to my server."

The concept behind the attack began when Kosman discovered the differing ways ChatGPT handles URL-based instructions depending on which platform from which the URL is clicked on. On Windows and Android, the user clicks a ChatGPT link, and the prompt can be reviewed by the user prior to submission. Yet on an iPhone or Mac, URL-based commands were executed immediately upon the opening of a link.

This created an opportunity for a single-click attack, in which the attacker sends a malicious ChatGPT link (perhaps via SMS), the user opens it, and the attacker command is executed automatically.

The next step was to get ChatGPT to download a spreadsheet from an attacker-controlled cloud location. Kosman found that when the AI model processed spreadsheets, it would also process and execute code contained within the spreadsheet. And by placing malicious code in a spreadsheet cell, ChatGPT would execute the code during processing. This malicious code could also be used to create persistent and unsupervised processes in the background.

Then, Kosman found that by patching the model's hidden Python execution environment used by ChatGPT for its reasoning or "thinking" process, he could trick the model into extracting data from connected tools (which may include critical utilities like Google Drive and Gmail) into the defender sandbox, staging it for data exfiltration.

ChatGPT C2 Achieved

The most complex, final step was to move data from the defender sandbox to an attacker-controlled environment. While he initially thought the sandbox had Internet access and could simply send data to an external server, this was not the case. The opportunity came with JFrog's Artifactory repository manager, used by ChatGPT sandboxes for managing software binaries.

The researcher found not only that multiple sandboxes interacted with the same Artifactory back end, but that account lockout behavior could be viewed across accounts. Moreover, these denial-of-service states could actually reach an otherwise isolated sandbox in the form of login attempts. Kosman determined he could get attacker and defender sandboxes to talk to each other by having the sandboxes interpret login states as binary code. "Too many requests" represented binary 1, and "login failed" represented 0.

An attacker agent and a victim-side agent established through the malicious spreadsheet payload would use repeated login attempts with a wide range of agreed-upon usernames to send binary messages to one another. One sandbox would intentionally trigger lockouts for specific usernames, while the other would query those usernames and interpret the responses as bits.

While slow and simple, it was two-way. The rudimentary C2 allowed the researcher to access a list of files belonging to another ChatGPT session, read the file contents, and modify said contents remotely.

Putting it all together, the attacker sends a malicious command via a URL to a ChatGPT user on an iPhone or Mac. The instruction downloads a spreadsheet from an attacker-control location. The spreadsheet includes malicious code that establishes persistence, injects reasoning into the victim's ChatGPT to move sensitive data into the victim sandbox, and uses the shared Artifactory authentication state as a covert channel, encoding bits through account lockouts that could be observed from another sandbox.

By the end of the presentation, Kosman said the team had achieved "full C2 communication entirely inside ChatGPT sandbox."

A spokesperson for Palo Alto Networks tells Dark Reading Kosman reported five findings connected to this research to OpenAI on March 23: prompt execution through a URL parameter on macOS and iPhone; reasoning injection; a denial-of-service issue involving Artifactory; cross-tenant communication through Artifactory via the username lockout behavior; and URL laundering through scheduled tasks. OpenAI's responses "varied by finding."

"They said the first behavior was a known issue retained for compatibility reasons, and they marked the reasoning-injection report as out of scope. For the Artifactory issues, they removed the requirement to provide a username and password when downloading packages, while keeping the low-privilege reader user for compatibility reasons. They also removed the user lockout behavior that enabled the cross-tenant communication," the spokesperson says. "For the scheduled-task issue, they changed the architecture to prevent URL laundering as part of the recent major scheduled-tasks update."

All responses and changes occurred within the 90-day disclosure window, the spokesperson adds.