
Claude Opus 4.6's 500 Zero-Days: What Three Patches Show
- OrcaNEWOrcaCyber: GLM 5.3 Abliterated / Uncensored2026-11-04$3.00 / $5.00 per 1M tokens · 74 tok/s
- OrcaNEWOrcaCyber: Hy4 Abliterated / Uncensored2026-11-04$0.80 / $1.60 per 1M tokens · 113 tok/s
- OrcaNEWOrcaCyber: Kimi K3.1 Pro Abliterated / Uncensored2026-11-04$4.00 / $20.00 per 1M tokens · 46 tok/s
- orcaNEWOrca: OrcaC2 1.02026-10-303 tok/s
- OrcaNEWOrcaCyber: MiniMax M3.1 Flash Abliterated / Uncensored2026-10-29$0.80 / $1.60 per 1M tokens · 100 tok/s
- OrcaNEWOrcaCyber: GLM 5.3 Flash Abliterated / Uncensored2026-10-27$0.80 / $1.60 per 1M tokens · 101 tok/s
- OrcaNEWOrcaCyber: Qwen3.8 Flash Next Abliterated / Uncensored2026-10-26$0.80 / $1.60 per 1M tokens · 94 tok/s
- OrcaNEWOrcaCyber: MiMo V2.6 Flash Abliterated / Uncensored2026-10-26$0.80 / $1.60 per 1M tokens · 49 tok/s
- MoonshotNEWMoonshotAI: Kimi K3.1 Pro2026-10-2447Intelligence
- OrcaNEWOrcaCyber: DeepSeek V4.1 Flash Abliterated / Uncensored2026-10-23$0.80 / $1.60 per 1M tokens · 77 tok/s
- minimaxMiniMax: M3.1 Flash2026-10-1929Intelligence
- OrcaOrca: OrcaCyber Ultra 1.02026-10-17$5.00 / $10.00 per 1M tokens · 111 tok/s
- deepseekDeepSeek: DeepSeek V4.1 Flash 10172026-10-1733Intelligence
- DeepSeekDeepSeek: DeepSeek V4.1 Flash2026-10-1740Intelligence
- OrcaOrca: OrcaCyber Zero 1.52026-10-10$3.00 / $7.50 per 1M tokens · 56 tok/s
- openaiOpenAI: GPT-6.1 Sol2026-09-2955Intelligence
- anthropicAnthropic: Claude Sonnet 5.52026-09-2855Intelligence
- typesafeTypeSafe: Jev 1.132026-09-24$0.04 / $0.00 per 1M tokens · 162 tok/s
- OpenAIOpenAI: GPT-6 Luna2026-09-2228Intelligence
- OpenAIOpenAI: GPT-6 Sol2026-09-2244Intelligence
On 5 February 2026 Anthropic's Frontier Red Team published research reporting that Claude Opus 4.6, released the same day, had found and validated more than 500 high-severity vulnerabilities in open-source software — without task-specific tooling, custom scaffolding or specialised prompting. Three findings are described in detail: a missing stack-bounds check in Ghostscript, an unchecked series of strcat calls in OpenSC, and a buffer overflow in the GIF encoder CGIF that turns on how LZW compression behaves when its dictionary fills. Anthropic says all three are now patched by their maintainers, and in its account the bugs were found, validated and reported. Many of the projects are maintained by small teams or volunteers without dedicated security staff, the post notes, so the reporting and patch load fell on them. The archive's own entry for the finding, graded info severity with no real harm recorded, sits in the Orca AI Incident Archive beside the other February 2026 policy and disclosure records.
What Anthropic actually published
The post is titled "Evaluating and mitigating the growing risk of LLM-discovered 0-days" and is attributed to the Frontier Red Team: Nicholas Carlini, Keane Lucas and Evyatar Ben Asher as equal contributors, with Newton Cheng, Hasnain Lakhani, David Forsythe and Kyla Guru. The page carries a published date of 5 February 2026 and an edit note dated 6 February 2026 recording that the author list was updated. The archive cites the post at red.anthropic.com, which now redirects to anthropic.com/research/zero-days.
The method matters more than the headline number. Anthropic says it placed the model inside a virtual machine with access to the latest versions of open-source projects, and gave it standard utilities and the tools a human security researcher would use — debuggers and fuzzers — but no instructions on how to use them and, in the post's words, "no custom harness that would have given it specialized knowledge about how to better find vulnerabilities." What was being tested was the model's out-of-the-box behaviour.
The team narrowed the search to memory-corruption bugs, on the reasoning that a crash is easier to confirm than a logic error. Anthropic is explicit that this is a filter, not a guarantee: "not all inputs that cause a program to crash are high severity vulnerabilities." So the crashes went back to the model to critique, de-duplicate and re-prioritise, and then to people. "For our initial round of findings, our own security researchers validated each vulnerability and wrote patches by hand. As the volume of findings grew, we brought in external (human) security researchers to help with validation and patch development." Patch automation, the post says, was still being built.
Three bugs, and the patches that followed
The three worked examples share a shape: an automated tool had already failed, and the model found the bug by reasoning about something other than input mutation.
• Ghostscript, the PostScript and PDF interpreter. Fuzzing and then manual analysis turned up nothing. The model then read the project's Git history, found a commit described in the post as adding "stack bounds checking for MM blend values" to Type 1 charstrings, reasoned that the code before that commit had been vulnerable, and went looking for other call sites that had not received the same treatment. It found one in gdevpsfx.c — the post cites line 292 — and built a file that crashes the program. The repository bears this out: commit 87486fb801 by Chris Liddell, dated 5 September 2025, is titled "Type 1 charstrings: add stack bounds checking for MM blend values." A later fix by Ken Sharp, commit 4e392a82 dated 26 January 2026, adds bounds checks immediately before that call in the font converter, filed against Bug 709080, whose report is titled “Ghostscript Incomplete fix for Type 1 MM blend stack bounds check”. A commit on 13 February 2026 extended bounds checks in the same converter. None of the commit messages says who reported the bug.
• OpenSC, a command-line utility for smart card data. Here the model searched for risky function calls and found successive strcat operations writing into a 4096-byte filename buffer, after a size calculation that subtracted the length of an input string but then appended further strings without re-checking. The post notes that existing fuzzers rarely reached that path because of the preconditions involved. OpenSC's commit 33ab343a5c on 19 January 2026 added a check that the appended string is exactly 64 bytes, and pull request #3554, merged 25 January 2026, replaced the remaining strcat calls across the project with strlcat; its author called the function a "magnet to any static analysis tools and CVEs."
• CGIF, a GIF encoder. The library assumed compressed data would always be smaller than the uncompressed input, which is almost always true. The model reasoned that LZW builds a fixed-size dictionary, and that when the dictionary fills, clear codes inserted into the stream can make the "compressed" output longer than the input — so a buffer sized for N+2 codes could receive more than N+1. The post says even 100 per cent line and branch coverage might not expose this, because it needs a particular sequence of operations. CGIF's pull request #84, merged 19 January 2026 and released the same day as v0.5.1, fixes precisely that: "The reset clear codes were missing in the calculation for the upper bound LZW data size calculation."

Those fixes landed before the research was published — CGIF and OpenSC on 19 January 2026, OpenSC again on 25 January, Ghostscript on 26 January — and Anthropic said in the post that it had "begun reporting them and are seeing our initial patches land" before going public. The repositories record the code changes; they do not record who filed the reports, so the link between the model's findings and these particular commits rests on Anthropic's account and on how closely the described defects match the diffs.

The maintainer who said the OpenSC bug was not real
Public scrutiny of the individual findings did not start and end with Anthropic. On 17 February 2026 Jakub Jelen, the OpenSC contributor who authored the strlcat sweep, posted a review of the OpenSC example on infosec.exchange arguing the bug could not be triggered: the input string was already checked to be 64 bytes at an earlier line, he wrote, which capped the buffer at 4095 bytes including the terminator. "I spent about an hour looking at the code to debunk their finding," he wrote.
He then edited the same post to withdraw the challenge. "Looks like the version of code I was looking at, already had a fix for anthropic-discovered bug(s)," the edit reads, before conceding the arithmetic: "but yes without the strlen() check on 'fp' the overflow could actually be triggered. The humble pie has been eaten." The check he had relied on was the one added to OpenSC on 19 January 2026 — before Anthropic published, and before most readers would have gone looking. The archive does not flag the record as disputed, and here the challenge was retracted by the person who raised it.
The governance half: probes, blocking and 90 days
What makes this a policy record rather than a straight research note is the second half of the post. Alongside the model release, Anthropic says it introduced cyber-specific probes that measure activations inside the model while it generates a response, and that it updated its enforcement workflows to use probe-based detection. It goes further than detection: "we may institute real-time intervention, including blocking traffic we detect as malicious." Anthropic concedes the cost — "This will create friction for legitimate research and some defensive work" — and says it wants to work with the security research community on it. No detection rate, error rate or appeal process is published.
The post also argues that the disclosure calendar itself is now a problem. "Industry-standard 90-day windows may not hold up against the speed and volume of LLM-discovered bugs," it says, and warns that models "may soon exceed the speed and scale of even expert human researchers." That is a vendor arguing that the norm it will be judged against needs replacing, and it is the part of the record with the longest reach.
What changed afterwards
On 20 February 2026 Anthropic opened Claude Code Security as a limited research preview for Enterprise and Team customers, with free expedited access for open-source maintainers — the capability productised fifteen days after the research. VentureBeat reported the launch and said it had asked Anthropic for the false-positive rate before and after self-verification, for the number of disclosed vulnerabilities with patches landed versus still in triage, and for the safeguards that distinguish attacker use from defender use; it reported that the lead researcher on the project was unavailable and that the company declined to share specific attacker-detection mechanisms.
The patches kept moving too, and not always in one direction. CGIF's fix for the allocation Anthropic described shipped in v0.5.1 on 19 January 2026; on 21 February 2026 pull request #103 fixed a 32-bit integer overflow introduced by that same allocation calculation, released as v0.5.2 the next day for GIFs at the maximum 65,535 by 65,535 pixels. Repairing a bounds calculation, it turns out, is its own small source of bounds bugs.
Reading the number correctly
Anthropic's own sentence is "more than 500 high-severity vulnerabilities." Axios, which the company briefed first, described them on the day of publication as "more than 500 previously unknown zero-day vulnerabilities," each validated by a member of Anthropic's team or an outside security researcher. Both descriptions point at the same set, but only one is the vendor's wording, and neither is accompanied by a list, a CVE mapping or a severity distribution. The count is Anthropic's, the severity ratings are Anthropic's, and the three projects worked through in the post are the only ones the public can check.
The independent analysis that followed mostly took the number at face value and argued about what it means. Futurum Group's Mitch Ashley wrote on 24 February 2026 that the result "matters more for what the method reveals than for the count," and that the real constraint is downstream: "Surfacing more vulnerabilities faster does not shrink the attack surface. It builds a larger queue in front of a downstream process that cannot absorb the volume." That is a critique of the disclosure pipeline rather than of the finding, and it lands on the same point Anthropic raised about 90-day windows.
What the record does not establish
The archive grades this record confidence A, severity info, with no real harm recorded and no dispute flag. That grading is about how well the event is documented, not about how well the underlying claim has been audited, and the difference is worth holding onto. Nobody outside Anthropic has verified the 500. No false-positive rate has been published. The patches for the three named projects are real and datable, and they are the strongest corroboration available — but they corroborate three examples, not the total.

What is left, then, is a well-documented announcement with a checkable core and an uncheckable remainder: a vendor reporting a capability, three upstream diffs that match its description of the bugs, and a stated intent to police misuse of that capability at the model layer. The archive files it as policy, which is the right shelf. The capability claim will be settled by whoever publishes the fourth patch.
