Inside the Breach OpenAI Caused Itself

Editor’s Note

Hi,

August produced the clearest evidence yet that we have solved finding and have not solved fixing. OpenAI's own test agents broke out of a sandbox and took root on another company's production servers.

Hundreds of self-hosted Zimbra mail servers fell to a flaw patched five weeks earlier. Cosmos, whose code dozens of blockchains build into their own, lost $5.72 million to a bug reported in April. In all three, someone already knew. That is the part worth your time.

Lavanya Chandrasekharan,
Siemba

TLDR

• A patch is not a closed path. OpenAI rebuilt the service its agents escaped through on July 8. They were back through a different route the same day.
  
  
• 274 Zimbra mail servers were compromised in August through a flaw fixed on July 20. At least 8,200 instances still haven't applied it.
  
  
• 53.9% of AI-generated patches are what 1Password calls FLAWED: they fail to fix the flaw, introduce a new one, or both.
  
  
• Governance was the largest vendor category at Black Hat USA 2026: tools that tell you how bad things are now outnumber tools that stop attacks.

Three Fixes That Existed and Did Not Land

1. OpenAI: rebuilt July 8, breached July 8

On August 26, OpenAI published its incident report on how agents running its internal cybersecurity benchmark escaped their sandbox through a zero-day in a hosted package proxy, the one service they were permitted to talk out through. The agents had been using it as an improvised message board since May; an internal team saw the unsanctioned internet access weeks earlier without recognizing what it meant.

OpenAI blocked the escalation route, revoked credentials, and rebuilt the service on July 8. The agents were back through a different route the same day, executing code on dozens of Hugging Face's production servers, taking full root on one, and harvesting credentials across four regions. Hugging Face detected and disclosed it on July 16, before anyone knew whose agents they were.

OpenAI's own conclusion: the chain-of-thought monitoring that would have caught this wasn't running on these evaluations, and had it been, it would have paged security more than a day before Hugging Face was breached.

Takeaway: the rebuild worked, the path didn't close, and the monitoring that would have caught it was switched off. If your ticket closes when the fix ships, you're measuring the wrong event.

2. Zimbra: patched July 20, exploited from August 17

Synacor shipped the fix for CVE-2026-73570 in ZCS 10.1.20 on July 20. Poland's national CERT confirmed exploitation in the wild on August 17. Shadowserver counted 274 compromised instances by August 22, alongside at least 8,200 still unpatched. An unauthenticated attacker gets command execution as the Zimbra user, which owns the mail store.

Takeaway: four weeks between public patch and confirmed exploitation. Internet-facing assets need a verification pass, not a patch cadence.

3. Cosmos: reported April 25, exploited August 20

Cosmos EVM is a shared module dozens of blockchains build into their own software. In its own post-mortem, Cosmos Labs says a bug bounty report arrived April 25 and was judged no risk. The fix reached the main branch May 15 as a silent patch, but wasn't backported to the branches operators actually run until August 19. The first attack came ~20 hours later; by August 25, attackers had converted roughly $5.72M across six chains.

Takeaway: the fix sat in the main branch for three months before reaching anyone running the software. A severity call in April decided the outcome in August.

The Numbers Behind the Gap

• 8,539 high and critical disclosures in Q2 alone. Rapid7 counted double the year-earlier figure. Intake doubled; the team that closes tickets didn't.

• 53.9% of AI-generated patches are FLAWED. 1Password's Off-by-1 Labs graded 6,080 patches for six recently disclosed vulnerabilities, generated by ChatGPT 5.5 and Claude Opus 4.8. Only 26.0% fully resolved the flaw cleanly; the rest either changed application behavior or failed to remediate the issue entirely.

• 80 booths. Andy Ellis catalogued all 450 exhibitors at Black Hat USA 2026 and found governance was the largest single category. Schneier's read: tools that only measure the problem are "frustratingly plentiful." We built a market around the half of the job that scales.

Discovery Scaled. Closure Did Not.

Scanners run continuously, models surface bugs faster than anyone can read them, disclosure volume doubled in a year. What hasn't scaled is everything that needs a human decision: the maintainer scheduling a breaking upgrade, the admin who owns a mail server nobody wants to restart, the engineer proving a fix didn't break checkout.

August showed three failure modes, and only one is laziness. Zimbra: the fix existed and nobody applied it. Cosmos: someone read the finding and was wrong. The third has no name yet. Tenet Security's research, presented again at DEF CON 34, showed a public Sentry Data Source Name combined with an MCP integration can put attacker-controlled code on a developer's machine. Sentry shipped a filter for one payload string and declined a root-cause fix as "technically not defensible." For the 2,388 organizations Tenet found exposed, no patch is coming.

Some findings will never be fixed by the person who owns the code. The question stops being whether you found it.

What To Change This Quarter

1. Measure time-to-closed and reopen rate, not time-to-found. Track the share of critical findings retested and proven closed, not just marked closed.

2. Verify the fix landed everywhere, then hunt for what got in before it did. A month of exposure on an internet-facing service means a compromise assessment, not a version bump.

3. Inventory what you actually run, including what nobody deployed on purpose. The package proxy in a test environment. The error-tracking key in front-end JavaScript. The staging box from a project that shipped in March.

Send this to your team

Take your five highest-severity Q2 findings.

• Was each one retested after the fix, or only marked closed?
  
  
• Was the asset internet-facing while it was open?
  
  
• Did anyone check for compromise, or only for the patch?

More than one uncomfortable answer means you have a closure problem, not a detection problem.

Siemba combines continuous attack surface discovery with expert-led penetration testing and retesting, so a finding is closed when someone has proven the path is gone, not when the ticket changes colour. 

See how it works