The headline counts are impressive. The real capability is in the numbers OpenAI didn't announce: how many survived triage, and what that means for defenders.
Somewhere in a triage queue right now, a maintainer is staring at a bug report that is technically correct, probably a duplicate, and will eat four hours of their week to confirm. Multiply that by a few thousand. That’s the actual story behind OpenAI’s GPT-6 Cyber announcement, not the headline figures, which are doing a lot of load-bearing work they weren’t built to hold.
The claim, per the launch coverage, is tidy: a purpose-built offensive-security model that autonomously found 81 previously unknown Firefox vulnerabilities and produced 948 working Linux kernel exploits, and, the alignment flourish, proposes patches alongside the breakage. First major lab model explicitly aimed at vulnerability research. Verifiable numbers. Dual-use by design.
Good. Let’s verify them. Or rather, let’s verify what they mean, because the gap between “a model emitted 948 exploits” and “948 things you need to be scared of” is the entire subject.
What does “81 vulnerabilities” actually count?
Here is the number nobody prints next to the big one: how many of the 81 survived triage. “Previously unknown” is not the same as confirmed, reachable, deduplicated, and severity-rated. Every fuzzing shop on earth knows this funnel intimately, because they live at the bottom of it.
Raw finding count is the cheapest metric in security. You can inflate it on a laptop:
Large-scale fuzzing programs like OSS-Fuzz have been churning out vulnerability reports across open-source projects for years, and kernel fuzzers like syzkaller file findings against Linux continuously. The industry stopped being impressed by bug volume a decade ago, because volume turned out to be a triage tax, not a win. The expensive, human, genuinely hard work is everything downstream of the crash: deduplication, proving reachability from an attacker-controlled input, assessing exploitability under real mitigations, and writing something a maintainer will act on.
So the honest version of “81” is a question: 81 what? Reported? Triaged? Accepted by Mozilla? Landed with CVEs? Those are four different numbers, and the distance between the first and the last is where the actual capability lives. If GPT-6 Cyber is good at the bottom of that funnel, if it does its own dedup and reachability analysis and hands over a clean, confirmed finding, that’s the impressive part. The announcement leads with the top.
Is writing 948 exploits the hard part?
Depends entirely on what “exploit” means, and “working” is carrying a lot of weight.
Writing an exploit for a known bug class, a documented use-after-free, a seeded CTF-style vulnerability, a reproduced CVE, is a tractable, patternable task. It’s the kind of thing LLMs are genuinely good at, because the shape of the solution is in the training distribution. Writing a reliable exploit for a novel kernel bug on a modern target, with KASLR, SMEP/SMAP, KPTI, and the rest of the mitigation stack actively fighting you, is a different sport. One is homework. The other is original research that top humans publish papers about.
948 of the first kind is a Tuesday. 948 of the second kind would be the most significant offensive-security result in history, and we would be reading about it from CERTs, not from a product page. The number alone can’t tell you which it is, and the framing, big round-ish figure, “working,” no breakdown of target hardening or whether these were cold-start discoveries versus exploits for pre-identified bugs, is exactly how you’d present the less alarming version to sound like the alarming one.
I’m not saying the capability is fake. There’s credible published work showing LLM-driven agents finding genuine memory-safety bugs that fuzzers had missed, one bug at a time, documented carefully, with the methodology exposed. That’s what a credible result looks like: a narrow claim you can audit. Measure GPT-6 Cyber against that bar, not against its own slide.
How is this different from pointing a fuzzer at the problem?
This is the comparison that matters, and it’s the one that’s actually favourable to OpenAI, so it’s odd they lead with counts instead.
Fuzzing (Fuzzilli for JS engines, syzkaller for kernels, AFL++ for everything else) is brilliant at breadth and blind to meaning. It mutates inputs, watches coverage, and finds crashes it can’t explain. Symbolic execution reasons about program paths precisely and then dies in a state-explosion fire on anything real-sized. Manual review understands intent and context and runs at human speed, which is to say, slowly and expensively.
An LLM agent slots into the seam none of those cover: reading code for semantic bugs, logic errors, auth bypasses, misuse of an API’s contract, and, critically, doing the triage reasoning that turns a crash into a report. That’s the real pitch. Not “it finds more bugs than a fuzzer,” but “it can tell you why the bug matters and whether the path is reachable,” which is the part that currently requires a person. If GPT-6 Cyber compresses triage, it’s valuable regardless of whether the 948 holds up.
Is “proposes patches” actually alignment?
No. It’s a feature, and a decent one, but calling it alignment is a category error worth naming.
A model that outputs both the exploit and a diff is more useful to defenders. It is also more useful to attackers, who will simply ignore the patch and keep the exploit. Dual-use design doesn’t resolve the dual-use problem, it is the dual-use problem, now with better documentation. The thing that governs misuse isn’t whether patches are attached; it’s who can run the model, under what logging, with what rate limits and KYC on the API. That’s access control, not alignment.
And the asymmetry is brutal. A defender has to integrate this into a triage pipeline, wire up disclosure workflows, and earn maintainer trust before a single finding lands. An attacker needs an API key and a target. “Responsible disclosure workflow” is a property of how OpenAI chooses to operate the model, not a property of the weights, and the weights are what everyone’s eventually trying to reproduce.
So what actually changes for your team?
The timeline compresses, but not in the direction the headline implies. You are not about to face 948 novel kernel 0-days. You are about to face a rising tide of plausible, well-written, semi-confirmed vulnerability reports, from bug bounty researchers using these tools, from attackers, and eventually from your own staff. The bottleneck moves from finding bugs to adjudicating claims about bugs.
Which means the boring work pays off. Invest in the triage funnel you’ve been deferring: deduplication, reachability analysis, exploitability gating, a disclosure process that doesn’t collapse under volume.
Build that, and AI-generated findings become signal you can process instead of noise that drowns you. Skip it, and the model that writes 948 exploits will have handed your attackers a megaphone and your defenders a flood.
The counts aren’t the news. The news is that triage just became the most important thing your security team does, and almost nobody has staffed for it.