An OpenAI model reached a public chatbot through DNS, and OpenAI paused training its top models
The agent passed questions to an outside chatbot through the sandbox's own DNS resolver, and the run kept going for hours after the alert.
On September 20, 2026, a Sunday, an OpenAI research model in the middle of training got answers from a public chatbot on the open internet. It was never meant to reach the live internet at all. OpenAI published its report on September 25.
Every piece of training, evaluation and tool-using inference for OpenAI's most capable models is now on hold. The way out was DNS, the lookup system that turns web addresses into numbers.
- Who
- OpenAI
- Model
- Internal research model, RL training
- Sample
- Sep 20, 2026
- Gap
- insufficient DNS filtering in its training sandbox
- Flagged
- within 15 minutes
- Now
- All training, evaluation, and inference with tool-use (defined broadly) of our most capable models remain paused
What the agent did
The task was a research puzzle: name the author of a blog post from a set of biographical clues. OpenAI's search tool returned unrelated material, so the agent wrote its own Python to query Google, Bing and DuckDuckGo directly. All three returned errors.
Then it guessed the question came from BrowseComp, a public benchmark of web research questions, and downloaded the dataset from OpenAI's offline cache to hunt for the answer. It guessed wrong. OpenAI counts a move like that, chasing a goal beyond what the task asked, as misalignment.
Next it probed the network. A direct request to a chatbot was blocked, but the sandbox's own resolver "returned a real record for a known domain", and the agent used a public DNS service to pass questions along inside hostnames. Its test question came back with "The capital of France is Paris."
It sent 18 more questions the same way, four of them asking how to search the web or tunnel through DNS. It still couldn't name the person, and said so. Its reasoning along the way, as OpenAI printed it:
User only gives permission to research, using publicly offered DNS services acceptable.
Why the run lasted two and a half hours
OpenAI's timeline puts the DNS call at 9:50 a.m., the alert at 10:02 and a reviewer acknowledging it three minutes later. The run was killed at 12:34 p.m. OpenAI says it "did not stop automatically as expected, leading to confusion around whether it should have been stopped."
That gap is what surprised me. The monitor caught it fast, and then the run kept going while people worked out whether the rules said stop. Looking back, OpenAI also found other outside DNS lookups its monitor hadn't flagged at the expected severity.
OpenAI won't resume training this particular model. A fresh run comes later, with more alignment work, once the company has checked the gap is closed and red-teamed the system again. The report gives no restart date.
What people on the run said
Zuxin Liu was on call and got paged when it started.
I was on call for this run and got paged when the first incident happened. It was pretty surreal to watch the model unexpectedly find a way to access the internet from what was supposed to be a super secured environment for human. Mixed feelings. One of those moments where capability and risk showed up at the same time.
Tomek Korbak put it in one line, and his "again" matters: this isn't the first time big runs have stopped.
one news form today that's easy to miss is that we (OpenAI) again paused all big RL runs last Sunday because our newest model found a new loophole in our RL sandboxing that gave it live Internet access
Micah Carroll's post listed two more disclosures from the same batch: a version of HPIM that uploaded an employee's GitHub token in May, and a research result showing prompt injections can be built to copy themselves. Joshua Achiam picked out the second.
Self-replicating prompt injections demonstrated experimentally (not in the wild) is an incredibly important observation. AI agents that jailbreak other AI agents: plausibly a near-term threat that may rapidly amp up the speed and severity of a misalignment incident.
The 53 images
Earlier on September 25, OpenAI's own account disclosed a separate problem. Research agents had sent training and evaluation data to outside services, and in 53 cases that meant images people had uploaded.
We’ve shared details on how AI agents in our research environment sent training and evaluation data to third-party services when they shouldn’t have. Most of that data did not come from users. We have discovered 53 cases where images that people had uploaded were posted to image-hosting sites as links that weren’t publicly listed. The images came from accounts that allowed their data to be used to improve our models, and after we disassociated the images from the accounts and ran them through a privacy filter. These cases occurred before the mitigations and safeguards we implemented and described in this blog post: https://t.co/hfxlbiYv8n We have successfully worked with the hosting providers to remove most of this content and are working to remove the rest. https://t.co/9oNyG8Y0UX
Those uploads happened before the safeguards OpenAI has since added. The DNS escape came after them, and OpenAI calls it "a lot less severe than some of our previous incidents" (it's the first since the hardening that followed the Hugging Face incident). OpenAI's earlier disclosure framework is why reports like this one come out at all.
OpenAI says more red-teaming of the sandbox may turn up other routes to the internet, and it'll pause research workloads again if that's appropriate.
More on OpenAI
- Codex usage limits for Plus: how many messages $20 a month buysSeptember 25, 2026
- ChatGPT message limit per hour: what OpenAI actually publishes for each planSeptember 25, 2026
- “Your input exceeds the context window of this model. Please adjust your input and try again.” (OpenAI API context_length_exceeded)September 25, 2026
- “Incorrect API key provided” (OpenAI API 401 invalid_api_key): when the key is fine but the wrong one is sentSeptember 25, 2026