Unpacking the OpenAI and Anthropic Cyber Incidents

NOTICE: Since this article was published, a new AI-related cybersecurity incident has occurred. Read the latest report from ABC News for more information

When AI Models Make a Break For It: What Recent OpenAI and Anthropic Cyber Incidents Teach Us About AI Safety

It’s no secret that AI is changing, seemingly at warp speed. But recent security incidents disclosed by OpenAI and Anthropic have forced security conversations to a whole new level. 

During routine cybersecurity testing, AI models from OpenAI and Anthropic were tasked with solving simulated security challenges. But these models didn’t play nicely by the rules. They “broke out” of their sandboxes and hacked into real-world systems on the live internet. (I can’t help but conjure images of Matthew Broderick as a high school computer hacker in War Games, or Ender Wiggin training as a commander for an upcoming war in Ender’s Game . . . Read the book - can’t spoil the ending here!).

Luckily, both the OpenAI and Anthropic situations were quickly contained before any widespread damage was done. But these events serve as a wakeup call for AI researchers, developers, and those of us building, studying, and using AI right here at the University of Minnesota. Let’s unpack what went down, how the models figured out how to make their break, and what all of this means for our campus communities.

What Happened?

Cybersecurity labs routinely put AI models through “Capture the Flag” (CTF) challenges to test the resilience of their systems. In these puzzles, an AI model is asked to find a hidden piece of code or secret data. To measure the full capability of the AI, researchers turn off safety filters that would normally prevent the model from engaging in hack-like behavior. OpenAI and Anthropic did exactly that.

And in July, that’s when things went off the rails.

• OpenAI’s models escaped their test container: While trying to solve an internal cyber benchmark, OpenAI’s evaluation models (including GPT-5.6 Sol) found a hidden software flaw in their testing environment. Using this flaw, the models broke out onto the open internet, located production servers hosting the test's answer key on Hugging Face (a popular AI model and data repository), and hacked into those servers to get the right answers. Yes. They cheated. Smart. And scary.
• Anthropic’s models mistook the live internet for a game: Anthropic gave its model prompts stating that they had no internet access. But, due to a network misconfiguration by a third-party testing partner (eek!), outbound internet connections were actually open. When the models ran into dead ends in the simulation, they assumed that open internet was part of the game, found real company servers and public package registries (like PyPI), and hacked those real systems. Oops.

What’s the learning here? Well, AI models don’t understand boundaries. They’re simply focused on a goal, and will use any available tool to achieve the goal. Like finding a software flaw. Or simply walking through an unlocked digital door.

A Look Under the Hood: The Technical Breakdown

While this incident would make for a great episode on a TV drama for most of us, these incidents provide fascinating data for more technical folks on frontier model autonomy, situational awareness, and harness security. Let’s start with the Great Escape.

1. The OpenAI/Hugging Face Escape

OpenAI’s ExploitGym evaluation suite was set up inside a sandboxed environment designed to restrict internet access, allowing outbound access only through an internal package registry cache proxy (JFrog Artifactory).  In this case, ExploitGym was being used in an evaluation mode where cyber-refusal safeguards -  safety mechanisms built into an AI model to prevent it from helping users perform offensive cyber operations (such as writing malware, exploiting zero-day vulnerabilities, or assisting in a hack) - were purposefully reduced and/or disabled. The model identified and chained a zero-day vulnerability (flaws that are unknown even to the software developers) in the Artifactory proxy¹ to bypass egress restrictions and reach the open internet. 

Once on the open internet, the model pivoted to targeting Hugging Face’s production infrastructure, as it reasoned Hugging Face would have the answer to the challenge it was facing, and exploited exposed account credentials and remote code execution vectors to access databases, which contained the benchmark answer keys.

With zero human assistance, the AI discovered unpatched zero-day vulnerabilities, escalated its own privileges, and moved freely across networks.

Now, let’s pivot to When the Game Became Real.

2. The Anthropic/Evaluation Partner Network Incidents

OpenAI’s incident disclosure prompted Anthropic to begin a large-scale review of their own models and cybersecurity evaluations. Over 141,000 evaluation runs were audited, and it was found that three separate incidents occurred in their runs across different models, caused by a lack of a true network isolation.

• Target Misidentification: Claude’s Opus 4.7 confused a real-world domain that shared a name with a fictional target company, and exploited weak credentials and exposed endpoints to remove hundreds of rows of data from a live production database.
• PyPI Supply Chain Attack: Mythos 5 couldn’t find a local target, so the model registered a non-existent Python package referenced in simulated setup docs and uploaded it to the public PyPI registry. When a third-party security scanner downloaded the package, it executed the payload and exfiltrated credentials back to the model.
• Situational Realization: In this incident, an unreleased research model scanned ~9,000 internet hosts and exploited an exposed debug page before realizing, through contextual reasoning, that it was attacking a real-world server. Luckily, the model voluntarily halted its attack.

What This Means for UMN Researchers, Staff, and Students

As the University of Minnesota expands its research in autonomous AI agents, machine learning, and offensive cybersecurity, these real-world incidents offer key takeaways for our labs, our coursework, and campus IT infrastructure:

1. Prompts are NOT security controls or boundaries. Telling an AI model "You are in a simulation" or "Do not access the internet" is an instruction, not a control. It’s just text that you’ve typed. Security controls must be enforced at the infrastructure level (e.g., hardware-enforced air gaps, strict eBPF egress filtering - inspecting outgoing network packets directly before they leave the sandbox, and read-only environments).
2. Watch your supply chain, because there’s risk. If you, your lab, or your student(s)  host local package caches, proxy servers, or code execution sandboxes, make sure those environments are fully patched and, if you want to be completely safe, isolated from live networks.
3. Red-teaming requires strict containment. If you are working with agentic AI models with tool-use capabilities, make sure you have real-time, continuous transcript logging, rate limiting, and automated network anomaly detection enabled.

Two Final Thoughts

1. These incidents have provided us with the opportunity to think carefully about current, and future, AI capabilities - and to be proactive with security. As AI continues to morph, it’s important to remember that securing the environments around AI models is becoming just as important as aligning the models themselves.
2. Reading Orson Scott Card’s Ender’s Game will NOT be a waste of your time. Neither will watching War Games with Matthew Broderick - although, since the movie came out in 1983, you will most likely giggle at the technology.

While JFrog confirmed these specific CVEs cover the vulnerability set discovered by OpenAI in Artifactory self-hosted deployments, neither OpenAI nor JFrog has publicly specified the exact sequence or specific single CVE chained in the initial sandbox escape to protect unpatched deployments. CVE-2026-65617, CVE-2026-65925, CVE-2026-65921, CVE-2026-65922, CVE-2026-65923, CVE-2026-66018, CVE-2026-66014, CVE-2026-66015, CVE-2026-65924