OpenAI Ships GPT-5.6-Cyber for Vulnerability Hunting

1.5% versus 95%. The first number is how often OpenAI's general model, GPT-5.6 Sol, engages with sensitive cybersecurity questions. The second is how often the model announced on August 10 does. That gap is not an accident; it is the product.

GPT-5.6-Cyber is built for vulnerability research, exploit development and security analysis, with the usual refusals deliberately relaxed. For comparison, OpenAI's defensive model Daybreak Blue sits at 2%, and last year's GPT-5.5-Cyber managed 57.3%. The company also reports that the new model beats every predecessor on ExploitGym.

Its first real find was in Chrome

Benchmarks age badly, so the more interesting result is field work: the model surfaced two previously unknown vulnerabilities in Chrome, one of which is now tracked as CVE-2026-15903.

OpenAI's stated reasoning is a race it believes defenders are losing. The company argues that threat actors are moving toward fully autonomous attacks and that the window for defenders to prepare is closing. The bet is that a capable finder in vetted hands closes holes faster than an equivalent finder opens them.

The door is narrow on purpose

Access runs through the Daybreak Red program, and the vetting is heavier than usual: identity verification, account security requirements, and a signed legal attestation. From September 1, 2026, a hardware security key becomes mandatory. OpenAI also recommends running the model inside isolated sandbox environments.

Internally the model is rated "High" risk under the company's preparedness framework, short of the "Critical" threshold that would trigger tighter handling. Read together, capability is going up while distribution is going down.

Where the logic strains

Releasing this model concedes something. If the same capability can already be reproduced privately, withholding it from vetted defenders buys little. But identity checks and security keys filter out the careless attacker, not the funded one. A group willing to buy stolen credentials and stand up a shell company is not stopped by an attestation form.

There is also an asymmetry nobody has solved. A defender who finds a flaw waits weeks for a patch to ship and install. An attacker who finds the same flaw uses it that afternoon. When both sides run comparable tooling, the difference in clock speed decides who benefits.

The trend line is its own warning. Going from 57.3% to 95% in roughly a year suggests that next year's ordinary release will do what today's restricted-access model does. Treating this as a niche announcement about a program you can't join misses the point.

What to do if you'll never get access

Most organisations will never touch this model, and won't need to. The consequence reaches them anyway, because vulnerability discovery is becoming cheap and both sides are getting faster.

The variable that matters is patch latency. "Who would bother targeting us" was always a weak defence, and it stops working entirely when scanning costs almost nothing. An unpatched plugin or an outdated library used to survive because nobody looked; automated discovery doesn't triage targets by how interesting they are.

Three unglamorous steps cover most of the exposure. Move critical updates from a monthly manual chore to an automated pipeline. Inventory every service you expose to the internet, including the ones a former employee set up. Name an owner for each. None of that requires new spending, only the decision to stop deferring it. Priced against a ransomware negotiation, it is the cheapest work on the list.

Sources: TechCrunch, The Decoder