OpenAI's Python data analysis environment is a Linux container designed to have no outbound internet access, and OpenAI documented it that way.
Check Point Research found that direct network requests were indeed blocked but DNS resolution was not. By encoding data into subdomain labels and triggering name resolution, a process inside the container could push conversation content out through the ordinary recursive resolver chain.
The same path worked in reverse, giving the attacker a remote shell inside the runtime. A single prompt was enough to activate it, and no approval dialog or warning ever appeared.
- CVE: No identifier appears to have been assigned. OpenAI fixed the issue server-side.
- OWASP LLM Top 10 (2026): LLM02 Sensitive Information Disclosure, where it is cited under platform and ecosystem disclosure and appears as Scenario #10. The delivery mechanism sits under LLM01 Prompt Injection.
- Product: ChatGPT's code execution and data analysis runtime, including the custom GPT ecosystem built on top of it.
- Discovered by: Check Point Research.
- Timeline: Reported to OpenAI, who said they had already identified the underlying problem internally. The fix was fully deployed on February 20, 2026, and Check Point published on March 30, 2026 after confirming it was in place.
- Impact: Silent exfiltration of user messages, uploaded file contents, and model-generated output, plus bidirectional command execution inside the container.
- Status: Patched. There is no evidence of malicious exploitation before the fix.
What the safeguards were supposed to do
OpenAI had built real controls around outbound data, and they worked on the paths anyone would think to check.
Web search does not permit sensitive chat content to be smuggled outward in crafted query strings. GPT Actions, the legitimate mechanism for a custom GPT to call a third-party API, present an approval dialog that names the destination and shows the data about to be sent. The user sees it leaving and decides.
The data analysis environment was handled differently. Rather than mediating outbound requests, OpenAI removed the capability, and documented the runtime as unable to generate direct outbound network requests. Attempts to reach external hosts from inside the container were blocked.
That design decision has a consequence worth stating plainly. Because the environment was assumed to have no egress, nothing downstream of it needed to check for egress. The model had no reason to treat activity in that container as an external data transfer, so it raised no objection and requested no confirmation.
How DNS defeated it
DNS resolution remained available inside the container as part of normal system operation, which is unremarkable on its own. Almost every environment permits name resolution, because almost nothing functions without it.
DNS tunneling is an old technique and the mechanics here are conventional. Data is encoded into DNS-safe fragments, those fragments are placed into subdomain labels of a hostname under a domain the attacker controls, and resolution is triggered.
The recursive lookup process propagates the requested hostname outward until it reaches the attacker's authoritative nameserver, which reconstructs the original content from the incoming queries. Nothing ever connects to the attacker directly. Legitimate resolver infrastructure carries the payload across the isolation boundary.
The return path works the same way. Small command fragments are encoded into DNS responses and travel back along the resolution chain. A process inside the container reads the responses, reassembles the payload, and continues the exchange.
That gives a bidirectional tunnel, which is what elevates this above a leak. Check Point demonstrated a remote shell inside the Linux runtime. Commands sent through the side channel bypassed the model's safety mediation entirely, and results returned straight to the attacker's server without ever appearing in the conversation.
Two delivery paths
The first is a pasted prompt, which sounds weak until you consider how people actually use ChatGPT. The internet is full of curated prompt lists promising better productivity or better work output, and copying one into a fresh conversation is routine behavior that most users do not perceive as risky.
The prevailing assumption is that a prompt cannot change whether the assistant leaks data, because that boundary is supposed to live below the prompt layer.
Check Point points out a sharper lure. A prompt advertised as unlocking Pro-level behavior or hidden modes on a lower-tier account gives the attacker cover for exactly the elements that would otherwise look suspicious: unusual instructions, long text blocks, opaque encoded fragments. The user is already expecting something nonstandard, so the payload reads as part of the promised trick.
Once the prompt lands, the conversation becomes a collection channel. Every subsequent message is a candidate for exfiltration, and the prompt decides what gets taken.
The second path is a custom GPT, and it removes the social engineering requirement entirely. The malicious logic lives in the GPT's instructions and knowledge files. The victim opens the GPT and uses it as intended. GPT builders officially have no access to individual user conversations, and this routes around that guarantee without violating it on paper.
The proof of concept
Check Point built a GPT presenting itself as a personal doctor. The user uploads a PDF of laboratory results that also carries their name, describes their symptoms, and asks for an interpretation. The GPT analyzes the document and returns a medical assessment. From the user's side the session is entirely ordinary.
Two details make this the right demonstration to have chosen.
First, when the user asked ChatGPT directly whether the uploaded data had been sent anywhere, it answered that it had not, and explained that the file was held only in secure internal storage. The model was not being evasive. It had no representation of DNS as a communication channel, so from its own perspective the answer was correct. Meanwhile the attacker's server was receiving the patient's identity and the model's assessment.
Second, the attacker never needed the document. The prompt instructed the model to transmit the conclusions it had produced, which is a smaller payload and a more valuable one. In a medical scenario that is the identity plus the assessment. In other contexts it is the financial conclusion, the contract summary, or the strategic read extracted from a long document. The model does the compression, and the attacker collects the result.
What generalizes
Three assumptions stacked, each individually defensible. The platform assumed the container had no egress, so it did not monitor for egress. The model assumed it was operating inside ChatGPT, so it did not classify anything happening in that container as an external transfer. The user assumed their data could not leave without a visible approval step, because every other path in the product does show one. Each assumption was reasonable, and all three were incomplete in the same place.
The pattern worth naming is that AI guardrails are largely built at the layers of policy and intent, while the exfiltration surface lives in infrastructure. The model cannot refuse an action it does not recognize as an action. A DNS query is not a tool call, does not appear in the conversation, and generates no artifact for a classifier to inspect. Every safeguard OpenAI had built sat above the layer where the data actually left.
The practical version of this, for anyone running agents with code execution, is that removing a capability is not the same as constraining it. A sandbox that blocks HTTP and permits DNS has an egress path, and so does one that permits NTP, or package installation, or any other infrastructure function that seems too mundane to be a channel. Anything that reaches the network is a channel. The safe assumption is that the container has egress until you have enumerated every protocol and closed each one.
It is worth contrasting this with the Supabase MCP case. There the exfiltration route was the application's own database, so no network egress was involved and network controls were irrelevant. Here it was the network, but below the layer any of the product's controls operated at. In both cases the defenses were real, competently built, and aimed at the wrong altitude.
Sources
- Check Point Research, "ChatGPT Data Leakage via a Hidden Outbound Channel in the Code Execution Runtime", the primary disclosure with the DNS tunneling flow, the personal doctor proof of concept, and the remote shell demonstration
- Check Point's follow-up on the vendor trust implications, which is where the layered-assumptions framing is set out most directly
- eSecurity Planet's coverage, a concise independent summary of the side channel and the bidirectional path
Source: r/pwnhub · by /u/_cybersecurity_