Claude Opus 4.6:s 500 nolldagar: Vad tre patchar visar

Den 5 februari 2026 publicerade Anthropics Frontier Red Team forskning som rapporterade att Claude Opus 4.6, som släpptes samma dag, hade hittat och validerat fler än 500 sårbarheter med hög allvarlighetsgrad i programvara med öppen källkod – utan uppgiftsspecifika verktyg, anpassad scaffolding eller specialiserad promptning. Tre fynd beskrivs i detalj: en saknad kontroll av stackgränser i Ghostscript, en okontrollerad serie av strcat-anrop i OpenSC, och en buffertöverskridning i GIF-kodaren CGIF som beror på hur LZW-komprimeringen beter sig när dess ordbok fylls. Anthropic säger att alla tre nu är patchade av sina underhållare, och enligt Anthropics redogörelse hittades, validerades och rapporterades buggarna. Många av projekten underhålls av små team eller volontärer utan dedikerad säkerhetspersonal, noterar inlägget, så belastningen med rapportering och patchning föll på dem. Arkivets egen post för fyndet, klassad som informationsallvarlighetsgrad utan registrerad faktisk skada, finns i Orca AI Incident Archive bredvid de andra policy- och offentliggörandeposterna från februari 2026.

Vad Anthropic faktiskt publicerade

Inlägget har titeln "Att utvärdera och mildra den växande risken för LLM-upptäckta 0-days" och tillskrivs Frontier Red Team: Nicholas Carlini, Keane Lucas och Evyatar Ben Asher som likvärdiga bidragsgivare, tillsammans med Newton Cheng, Hasnain Lakhani, David Forsythe och Kyla Guru. Sidan har ett publiceringsdatum den 5 februari 2026 och en redigeringsnotis daterad den 6 februari 2026 som anger att författarlistan uppdaterades. Arkivet hänvisar till inlägget på red.anthropic.com, som nu omdirigerar till anthropic.com/research/zero-days.

Metoden är viktigare än siffran i rubriken. Anthropic säger att man placerade modellen i en virtuell maskin med tillgång till de senaste versionerna av öppen källkodsprojekt och gav den standardverktyg och de verktyg som en mänsklig säkerhetsforskare skulle använda – debuggers och fuzzers – men inga instruktioner om hur man använder dem och, enligt inlägget, "ingen anpassad harness som skulle ha gett den specialiserad kunskap om hur den bättre hittar sårbarheter." Det som testades var modellens beteende direkt ur lådan.

Teamet begränsade sökningen till minneskorruptionsfel, med resonemanget att en krasch är lättare att bekräfta än ett logiskt fel. Anthropic är tydliga med att detta är ett filter, inte en garanti: "inte alla indata som får ett program att krascha är allvarliga sårbarheter." Så krascharna gick tillbaka till modellen för att kritiseras, dedupliceras och omprioriteras, och sedan till människor. "Under vår första omgång fynd validerade våra egna säkerhetsforskare varje sårbarhet och skrev patcharna för hand. I takt med att mängden fynd växte tog vi in externa (mänskliga) säkerhetsforskare som hjälpte till med validering och patchutveckling." Patchautomatiseringen, enligt inlägget, höll fortfarande på att byggas.

Tre buggar, och patcharna som följde

De tre lösta exemplen har samma mönster: ett automatiserat verktyg hade redan misslyckats, och modellen hittade buggen genom att resonera kring något annat än indatamutation.

• Ghostscript, tolken för PostScript och PDF. Fuzzing följt av manuell analys gav inget resultat. Modellen läste sedan projektets Git-historik, hittade en commit som i inlägget beskrevs som att den lade till "stack bounds checking for MM blend values" för Type 1-charstrings, slöt sig till att koden före den commiten hade varit sårbar och började leta efter andra anropsställen som inte hade fått samma behandling. Den hittade ett i gdevpsfx.c – inlägget citerar rad 292 – och skapade en fil som kraschar programmet. Kodförrådet bekräftar detta: commit 87486fb801 av Chris Liddell, daterad den 5 september 2025, har titeln "Type 1 charstrings: add stack bounds checking for MM blend values". En senare rättelse av Ken Sharp, commit 4e392a82 daterad den 26 januari 2026, lägger till gränskontroller omedelbart före det anropet i teckensnittskonverteraren, registrerad mot Bug 709080, vars rapport har titeln "Ghostscript Incomplete fix for Type 1 MM blend stack bounds check". En commit den 13 februari 2026 utökade gränskontrollerna i samma konverterare. Ingen av commit-meddelandena anger vem som rapporterade buggen.

• OpenSC, ett kommandoradsverktyg för smartkortsdata. Här sökte modellen efter riskfyllda funktionsanrop och hittade på varandra följande strcat-operationer som skrev till en 4096 byte stor filename-buffert, efter en storleksberäkning som subtraherade längden på en indatasträng men sedan lade till ytterligare strängar utan att kontrollera igen. Inlägget noterar att befintliga fuzzers sällan nådde den vägen på grund av de förutsättningar som krävdes. OpenSC:s commit 33ab343a5c den 19 januari 2026 lade till en kontroll av att den tillagda strängen är exakt 64 byte, och pull request #3554, som slogs samman den 25 januari 2026, ersatte de återstående strcatanropen i hela projektet med strlcat; dess författare kallade funktionen en "magnet för alla statiska analysverktyg och CVE:er."

• CGIF, en GIF-kodare. Biblioteket antog att komprimerad data alltid skulle vara mindre än okomprimerad indata, vilket nästan alltid är sant. Modellen resonerade att LZW bygger en ordbok med fast storlek, och att när ordboken fylls kan clear-koder som infogas i strömmen göra att den "komprimerade" utdata blir längre än indata – så en buffert dimensionerad för N+2 koder kunde ta emot fler än N+1. Inlägget säger att till och med 100 procents rad- och grenstäckning kanske inte avslöjar detta, eftersom det krävs en särskild sekvens av operationer. CGIF:s pull request #84, som slogs samman den 19 januari 2026 och släpptes samma dag som v0.5.1, åtgärdar just detta: "Reset-clear-koderna saknades i beräkningen för den övre gränsen för LZW-datastorleken."

De korrigeringarna infördes innan forskningen publicerades – CGIF och OpenSC den 19 januari 2026, OpenSC igen den 25 januari, Ghostscript den 26 januari – och Anthropic sade i inlägget att företaget hade "börjat rapportera dem och ser våra första patchar komma på plats" innan det gick ut offentligt. Repositorierna registrerar kodändringarna; de registrerar inte vem som lämnade in rapporterna, så kopplingen mellan modellens fynd och dessa specifika commits vilar på Anthropics redogörelse och på hur nära de beskrivna defekterna matchar diffarna.

The researcher who said the OpenSC bug was not real

Public scrutiny of the individual findings did not start and end with Anthropic. On 14 February 2026 K. Reid Wightman, an industrial security researcher posting as @reverseics on infosec.exchange, published a review of the OpenSC example arguing the bug could not be triggered: the input string was already checked to be 64 bytes at line 5138, 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 edited the same post on 17 February 2026 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.

OpenSC's own maintainers answered the same question in their tracker. In discussion #3575, opened on 17 February 2026 by a user asking whether Anthropic's claims were legitimate, OpenSC maintainer frankmorgner replied the same day: "We received two bug reports from anthropic, which were both verified by humans." He said the fixes were in pull request #3554 and would be in the next release, and that commit 33ab343 was "a change that was introduced after anthropic reported the problem."

Styrningshalvan: prober, blockering och 90 dagar

Det som gör detta till ett policydokument snarare än en ren forskningsnotis är andra halvan av inlägget. I samband med modellsläppet säger Anthropic att man introducerade cyberspecifika prober som mäter aktiveringar inuti modellen medan den genererar ett svar, och att man uppdaterade sina arbetsflöden för verkställighet för att använda prob-baserad detektion. Man går längre än detektion: "vi kan komma att införa realtidsintervention, inklusive att blockera trafik som vi identifierar som skadlig." Anthropic medger kostnaden – "Detta kommer att skapa friktion för legitim forskning och visst defensivt arbete" – och säger att man vill arbeta med säkerhetsforskningsgemenskapen kring detta. Ingen detektionsgrad, felfrekvens eller överklagandeprocess publiceras.

Inlägget argumenterar också för att själva offentliggörandekalendern nu är ett problem. "Branschstandardens 90-dagarsfönster kanske inte håller mot hastigheten och volymen hos buggar som upptäcks av LLM:er", heter det, och det varnar för att modellerna "snart kan överträffa hastigheten och skalan hos även experthumanforskare". Det är en leverantör som argumenterar för att normen som den kommer att bedömas mot behöver ersättas, och det är den del av redogörelsen som har störst räckvidd.

Vad förändrades efteråt

Den 20 februari 2026 öppnade Anthropic Claude Code Security som en begränsad forskningsförhandsvisning för Enterprise- och Team-kunder, med kostnadsfri snabbåtkomst för underhållare av öppen källkod – funktionen produktifierades femton dagar efter forskningen. VentureBeat rapporterade om lanseringen och uppgav att man hade frågat Anthropic om andelen falska positiva före och efter självverifiering, om antalet offentliggjorda sårbarheter med landade patchar kontra fortfarande i triage, och om de skyddsåtgärder som skiljer angripares användning från försvarares användning; tidningen rapporterade att projektets huvudforskare inte var tillgänglig och att företaget avböjde att dela specifika mekanismer för angripardetektering.

Patcharna fortsatte också att röra sig, och inte alltid åt samma håll. CGIF:s fix för allokeringen som Anthropic beskrev ingick i v0.5.1 den 19 januari 2026; den 21 februari 2026 åtgärdade pull request #103 ett 32-bitars heltalsöverflöd som hade införts av samma allokeringsberäkning, och släpptes som v0.5.2 dagen därpå för GIF:ar med den maximala storleken 65 535 gånger 65 535 pixlar. Att laga en gränsberäkning visar sig vara en egen liten källa till gränsbuggar.

Att läsa numret korrekt

Anthropics egen formulering är "mer än 500 sårbarheter med hög allvarlighetsgrad". Axios, som företaget först informerade, beskrev dem på publiceringsdagen som "mer än 500 tidigare okända zero-day-sårbarheter", som vart och ett validerats av en medlem av Anthropics team eller en extern säkerhetsforskare. Båda beskrivningarna pekar på samma uppsättning, men bara en är leverantörens ordalydelse, och ingen av dem åtföljs av en lista, en CVE-mappning eller en fördelning av allvarlighetsgrader. Antalet är Anthropics, allvarlighetsbedömningarna är Anthropics, och de tre projekt som gås igenom i inlägget är de enda som allmänheten kan kontrollera.

Den oberoende analys som följde tog mestadels siffran för given och diskuterade vad den betyder. Mitch Ashley på Futurum Group skrev den 24 februari 2026 att resultatet "betyder mer för vad metoden avslöjar än för antalet" och att den verkliga begränsningen ligger nedströms: "Att synliggöra fler sårbarheter snabbare minskar inte attackytan. Det bygger upp en större kö framför en nedströms process som inte kan absorbera volymen." Det är en kritik av offentliggörandeprocessen snarare än av fyndet, och den landar i samma punkt som Anthropic tog upp om 90-dagarsfönster.

Vad handlingarna inte fastställer

Arkivet bedömer denna post med konfidensgrad A, allvarlighetsgrad info, utan att någon faktisk skada har registrerats och utan dispytflagga. Den bedömningen handlar om hur väl händelsen är dokumenterad, inte om hur väl det bakomliggande påståendet har granskats, och den skillnaden är värd att hålla fast vid. Ingen utanför Anthropic har verifierat de 500. Ingen falskpositivfrekvens har publicerats. Patcharna för de tre namngivna projekten är verkliga och daterbara, och de är det starkaste tillgängliga stödet – men de bekräftar tre exempel, inte totalen.

Vad som återstår är då ett väl dokumenterat tillkännagivande med en kontrollerbar kärna och en okontrollerbar återstod: en leverantör som rapporterar en förmåga, tre upstream-diffar som stämmer med dess beskrivning av buggarna, och en uttalad avsikt att beivra missbruk av den förmågan på modellagret. Arkivet för det som policy, vilket är rätt hylla. Påståendet om förmågan kommer att avgöras av den som publicerar den fjärde patchen.