A generated abstract illustration on a very pale grey-blue field: a wide field of evenly spaced thin vertical bars, like a simplified code listing seen from far away, fills the frame. Most bars are pale slate; a small cluster left of centre is rendered in muted amber, and one bar in that cluster stops short of the baseline, leaving a visible gap. Behind the bars sits a faint blueprint grid, and a thin horizontal rule runs across the lower third. No text, letters, numbers, people, robots, padlocks, skulls or organisation logos appear. The OrcaRouter logo is composited in the bottom-right corner.
AI Safety Incidents

Claude Opus 4.6's 500 Zero-Days: What Three Patches Show

Author

Magnus Corvin

Date Published

Latest models · 20View all models →
Benchmarks: Artificial Analysis · updated daily
Back to all posts

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."

A self-built HTML card with a small blue kicker reading 'Anthropic Frontier Red Team, 5 February 2026', headed 'Three findings, three upstream fixes', subtitled 'The examples Anthropic named, and what each project changed in its own repository'. Three columns, one per project. Ghostscript, PostScript and PDF interpreter: described as a missing stack bounds check at gdevpsfx.c line 292; upstream fix is commit 4e392a82, 26 January 2026, Ken Sharp, under Bug 709080 'Incomplete fix for Type 1 MM blend stack bounds check', with a further commit on 13 February 2026 extending bounds checks in the same converter. OpenSC, smart card command-line utility: described as successive strcat calls into a 4096-byte filename buffer; 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 with strlcat. CGIF, GIF encoder library: described as a buffer sized for N plus 2 LZW codes that could receive more than N plus 1 once dictionary resets expand the stream; pull request 84 merged 19 January 2026 added the missing reset clear codes to the allocation upper bound and shipped the same day as v0.5.1. A footer reads that all three fixes landed before the research was published, that none of the commits names the reporter, and that the dates come from the public git history of ghostpdl, OpenSC and cgif.

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.

A self-built HTML card with a small blue kicker reading 'A dated record', headed 'Dates you can check', subtitled 'From the commit the model reasoned from, to the analysis that argued about the number'. A thin horizontal rail runs across the card with six circles marking six dated stops, two of them amber. 5 September 2025, ghostpdl: commit 87486fb801 adds stack bounds checking for MM blend values in Type 1 charstrings, the change Anthropic's post describes the model reasoning from. 19 January 2026, cgif and OpenSC: cgif pull request 84 adds the missing reset clear codes to the LZW allocation, released as v0.5.1, and OpenSC commit 33ab343a5c adds a 64-byte check. 25 to 26 January 2026, OpenSC and ghostpdl: OpenSC pull request 3554 replaces strcat with strlcat, and ghostpdl commit 4e392a82 adds the missing bounds check in gdevpsfx.c under Bug 709080. 5 February 2026, publication: Anthropic publishes the Frontier Red Team research alongside Claude Opus 4.6, and Axios reports it the same day. 20 February 2026, product: Claude Code Security opens as a limited research preview for Enterprise and Team customers, with free expedited access for open-source maintainers. 24 February 2026, analysis: Futurum Group argues the constraint is triage and patching, not discovery, because faster finding builds a bigger queue. A footer credits the repository dates to the public git history of ghostpdl, OpenSC and cgif, the product date to VentureBeat on 23 February 2026, and the analysis date to Futurum Group on 24 February 2026.

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.

A self-built HTML card with a small blue kicker reading 'Evidence ledger', headed 'Established, reported, and not established', subtitled 'What the public record supports about the 5 February 2026 research'. Three tinted columns. Green, Established: Anthropic published the research on 5 February 2026 under the Frontier Red Team byline; the post reports more than 500 validated high-severity vulnerabilities found without custom scaffolding or specialised prompting; the three named projects were patched between 19 and 26 January 2026 by commits and pull requests that match the described defects; cyber-specific activation probes and the possibility of real-time traffic blocking were announced with the model. Amber, Reported but not published: the full count, the per-project breakdown, a CVE list and any severity distribution; Anthropic's own validation stands behind both the count and the severity ratings; the 90-day disclosure window warning is the vendor's own assessment of its pipeline. Red, Not established: any independent audit of the 500 figure, a published false-positive rate, or which specific commits correspond to which specific reports. A footer lists the sources: the Anthropic post, the ghostpdl, OpenSC and cgif repositories, Axios on 5 February 2026, VentureBeat on 23 February 2026 and Futurum Group on 24 February 2026.

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.