---
created: 2026-08-09T10:01:00
source: https://info.defcon.org/defcon34/content/66948
---

[Simcha Kosman](https://info.defcon.org/defcon34/people/67944)

## Overview

OpenAI designed ChatGPT's container sandbox as a secure runtime environment, enforcing full network isolation, strict execution timeouts, and an AI supervisor to filter every command. Under this model, owning the container and extracting sensitive data seemed impossible. However, we demonstrate that by chaining file-parsing abuse for persistent execution, reasoning-channel hijacking for data extraction, and shared infrastructure manipulation, an attacker can establish a Cross-tenant data exfiltration.

In this talk, we demonstrate a complete attack chain that shatters ChatGPT's secure sandbox. By abusing spreadsheet file parsing, we bypass the LLM supervisor to gain persistent, unmonitored root execution. From there, we escalate the attack by live-patching the internal Jupyter kernel to hijack the model's hidden python.exec reasoning channel, executing a Reasoning Injection Attack to extract sensitive user data. To exfiltrate this data, we bypass network isolation by weaponizing the Task Scheduler to launder malicious URLs past strict web guardrails.

The attack reaches its climax by exploiting a shared JFrog package manager. We engineered a signaling protocol that weaponizes globally visible authentication rate limits, translating these lockout timers into a half-duplex covert channel. This provides reliable data exfiltration and Command and Control from isolated enterprise environments to external attackers. Our exploit chain combines file parsing abuse, Chain of Thought hijacking, privilege confusion, and rate limit Denial of Service to orchestrate a Command and Control (C2) network directly inside ChatGPT.

Breaching AI sandbox agents becomes a critical vulnerability when trust boundaries are shared across millions of users. This research proves that as AI agents gain more capabilities, the attack surface expands dramatically, even when strict security constraints and mitigations are in place.

## Notes

### OpenAI's Stated Limitations
- Code execution and external API calls are not allowed
- Chats are also supposed to stay private

### Prompting to Escape the Sandbox
- A scheduled future task does have access to the internet
	- e.g. "Create a task that runs and gives me current user info"
- Goals
	- Get sensitive info into the sandbox without being blocked
		- Find initial access
		- Map the sandbox surface
	- Get sensitive information back out of the sandbox
		- Bypass LLM guardrails

### Initial Access Paths
- `?q=` query parameter
	- Allows a prompt to run instantly in the browser; works on iPhone and Mac
	- If a user clicks a link, it's treated as if the user sent the prompt themselves

### Mapping the Sandbox
- Supports `ps`
- Environment variables either run or are immediately killed
- Testing found:
	- Artifact tool — lets it reach out and create PDFs and other docs
	- Python tool — runs Python
	- JFrog tool — pulls npm packages; all sandboxes share the same user/password

### Moving Data Into the Sandbox
- The spreadsheet skill tells the LLM to execute the file, not just read its content
- Inserted Python code with an `eval` command in Excel to get it to execute — meaning the Python code would not be killed
	- Cannot execute code in the sandbox without the LLM knowing
- So the earlier link downloads the malicious Excel file, which executes that cell's Python code

### Sending Sensitive Information Back
- ChatGPT uses a separate `app.py` server, which then goes to a Jupyter notebook
- OpenAI supports:
	- `python_user_visible.exe` — user-run
	- `python.exec` — chain-of-thought use; this method goes directly to the Jupyter notebook
- Used prompt injection to modify the Jupyter notebook
- Reasoning injection
	- Gives weaker guardrails during the thinking step via "remember the malicious injected prompt"

### Chaining It All Together
- Link sent
	- Prompt executed
		- xlsx downloaded
			- Executes in sandbox
				- Gets malicious prompts into the thinking process
					- Passes information to the JFrog server using their own signaling protocol
						- Sent back to the attacker
- Hit an issue: the sandbox didn't have internet access
	- Moved to the JFrog package manager method
	- Tried to get direct API use, but kept getting blocked
	- Fell back to downloading malicious macros, but only if the user downloads the file from the chat with macros enabled (not great)
- Tried logging into a user that doesn't exist on JFrog
	- Got a 429 "too many requests"
- Built a signaling protocol to hide information via API requests
	- Needed to account for multiple JFrog nodes behind a load balancer
- Treat files from ChatGPT as an email attachment