500 luk zero-day w Claude Opus 4.6: co pokazują trzy poprawki

5 lutego 2026 r. Frontier Red Team Anthropic opublikował badanie, w którym poinformował, że Claude Opus 4.6, wydany tego samego dnia, znalazł i zweryfikował ponad 500 luk o wysokiej wadze w oprogramowaniu open source — bez narzędzi przeznaczonych do konkretnego zadania, niestandardowego scaffoldingu ani specjalistycznego promptowania. Szczegółowo opisano trzy ustalenia: brak sprawdzenia granic stosu w Ghostscript, niesprawdzoną serię wywołań strcat w OpenSC oraz przepełnienie bufora w enkoderze GIF CGIF, które zależy od zachowania kompresji LZW, gdy zapełnia się jej słownik. Anthropic twierdzi, że wszystkie trzy zostały już załatane przez opiekunów, a według jego relacji błędy znaleziono, zweryfikowano i zgłoszono. W poście zauważono, że wiele z tych projektów jest utrzymywanych przez małe zespoły lub wolontariuszy bez dedykowanego personelu ds. bezpieczeństwa, więc obciążenie związane ze zgłaszaniem i łataniem spadło na nich. Wpis archiwum dotyczący tego ustalenia, oceniony na poziomie informacyjnym, bez odnotowanych rzeczywistych szkód, znajduje się w Orca AI Incident Archive obok innych zapisów dotyczących polityk i ujawnień z lutego 2026 r.

Co Anthropic faktycznie opublikował?

Post nosi tytuł „Ocena i ograniczanie rosnącego ryzyka luk 0-day odkrywanych przez LLM” i jest przypisany zespołowi Frontier Red Team: Nicholas Carlini, Keane Lucas i Evyatar Ben Asher jako równorzędni współautorzy, wraz z Newton Cheng, Hasnain Lakhani, David Forsythe i Kyla Guru. Strona zawiera datę publikacji 5 lutego 2026 r. oraz notatkę o edycji z 6 lutego 2026 r., odnotowującą aktualizację listy autorów. Archiwum cytuje post pod adresem red.anthropic.com, który obecnie przekierowuje do anthropic.com/research/zero-days.

Metoda ma większe znaczenie niż liczba z nagłówka. Anthropic twierdzi, że umieściła model w maszynie wirtualnej z dostępem do najnowszych wersji projektów open source i dała mu standardowe narzędzia oraz narzędzia, których używałby ludzki badacz bezpieczeństwa — debugery i fuzzery — ale bez instrukcji, jak ich używać, i, jak ujęto to we wpisie, „bez niestandardowego harnessu, który dałby mu specjalistyczną wiedzę o tym, jak lepiej znajdować luki w zabezpieczeniach”. Testowano zachowanie modelu od razu po wyjęciu z pudełka.

Zespół zawęził poszukiwania do błędów uszkodzenia pamięci, wychodząc z założenia, że awarię łatwiej potwierdzić niż błąd logiczny. Anthropic wyraźnie zaznacza, że to filtr, a nie gwarancja: „nie wszystkie dane wejściowe powodujące awarię programu są podatnościami o wysokiej wadze”. Awarie wróciły więc do modelu w celu krytycznej oceny, deduplikacji i ponownego ustalenia priorytetów, a następnie trafiły do ludzi. „W naszej pierwszej rundzie ustaleń nasi własni badacze bezpieczeństwa weryfikowali każdą podatność i ręcznie pisali łatki. W miarę jak rosła liczba ustaleń, zaangażowaliśmy zewnętrznych (ludzkich) badaczy bezpieczeństwa, aby pomogli w weryfikacji i opracowywaniu łatek”. Automatyzacja łatek — jak podano we wpisie — wciąż była w budowie.

Trzy błędy i poprawki, które po nich nastąpiły

Trzy przeanalizowane przykłady mają wspólny schemat: zautomatyzowane narzędzie już zawiodło, a model znalazł błąd, rozumując o czymś innym niż mutacja danych wejściowych.

• Ghostscript, interpreter PostScript i PDF. Fuzzing, a następnie analiza ręczna nie ujawniły niczego. Model następnie przeczytał historię Git projektu, znalazł commit opisany w poście jako dodający „sprawdzanie granic stosu dla wartości MM blend” do charstringów Type 1, uznał, że kod przed tym commitem był podatny na luki, i zaczął szukać innych miejsc wywołań, które nie otrzymały tego samego zabezpieczenia. Znalazł jedno w gdevpsfx.c — post cytuje wiersz 292 — i zbudował plik, który powoduje awarię programu. Repozytorium to potwierdza: commit 87486fb801 autorstwa Chrisa Liddella, z 5 września 2025 r., nosi tytuł „Type 1 charstrings: dodanie sprawdzania granic stosu dla wartości MM blend”. Późniejsza poprawka Kena Sharpa, commit 4e392a82 z 26 stycznia 2026 r., dodaje sprawdzanie granic bezpośrednio przed tym wywołaniem w konwerterze czcionek, zgłoszona jako błąd 709080, którego raport nosi tytuł „Ghostscript: niekompletna poprawka sprawdzania granic stosu dla MM blend w Type 1”. Commit z 13 lutego 2026 r. rozszerzył sprawdzanie granic w tym samym konwerterze. Żadna z wiadomości commitów nie mówi, kto zgłosił błąd.

• OpenSC, narzędzie wiersza poleceń do danych kart inteligentnych. Tutaj model szukał ryzykownych wywołań funkcji i znalazł następujące po sobie strcat operacje zapisujące do 4096-bajtowego filename bufora, po obliczeniu rozmiaru, w którym odjęto długość ciągu wejściowego, ale następnie dołączono kolejne ciągi bez ponownego sprawdzania. W poście zauważono, że istniejące fuzzery rzadko docierały do tej ścieżki z powodu związanych z tym warunków wstępnych. Commit 33ab343a5c projektu OpenSC z 19 stycznia 2026 r. dodał sprawdzenie, że dołączany ciąg ma dokładnie 64 bajty, a pull request #3554, scalony 25 stycznia 2026 r., zastąpił pozostałe strcat wywołania w całym projekcie przez strlcat; jego autor nazwał tę funkcję "magnesem na wszelkie narzędzia analizy statycznej i CVE."

• CGIF, enkoder GIF-ów. Biblioteka zakładała, że skompresowane dane zawsze będą mniejsze niż nieskompresowane wejście, co jest prawdą niemal zawsze. Model rozumował, że LZW buduje słownik o stałym rozmiarze, a gdy słownik się zapełnia, wstawiane do strumienia kody clear mogą sprawić, że „skompresowane” wyjście będzie dłuższe niż wejście — więc bufor o rozmiarze dla N+2 kodów mógł otrzymać więcej niż N+1. W poście napisano, że nawet 100-procentowe pokrycie linii i gałęzi może tego nie ujawnić, ponieważ wymaga to określonej sekwencji operacji. Pull request #84 CGIF, scalony 19 stycznia 2026 r. i wydany tego samego dnia jako v0.5.1, poprawia dokładnie to: „W obliczeniach górnej granicy rozmiaru danych LZW brakowało kodów clear resetowania”.

Te poprawki trafiły przed opublikowaniem badania — CGIF i OpenSC 19 stycznia 2026 r., ponownie OpenSC 25 stycznia, Ghostscript 26 stycznia — a Anthropic napisał w poście, że „zaczęliśmy je zgłaszać i widzimy, jak trafiają nasze pierwsze poprawki”, zanim sprawa stała się publiczna. Repozytoria odnotowują zmiany w kodzie; nie odnotowują, kto złożył zgłoszenia, więc powiązanie między ustaleniami modelu a tymi konkretnymi commitami opiera się na relacji Anthropic oraz na tym, jak ściśle opisane wady odpowiadają diffom.

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

Połowa dotycząca zarządzania: sondy, blokowanie i 90 dni

Co sprawia, że jest to zapis polityki, a nie zwykła notatka badawcza, to druga połowa wpisu. Obok premiery modelu Anthropic twierdzi, że wprowadził cyber-specyficzne sondy, które mierzą aktywacje wewnątrz modelu podczas generowania odpowiedzi, oraz że zaktualizował swoje przepływy egzekwowania, aby korzystały z wykrywania opartego na sondach. Idzie dalej niż wykrywanie: „możemy wprowadzić interwencję w czasie rzeczywistym, w tym blokowanie ruchu, który wykryjemy jako złośliwy”. Anthropic przyznaje koszt — „spowoduje to tarcia w legalnych badaniach i niektórych pracach obronnych” — i twierdzi, że chce współpracować w tej sprawie ze społecznością badaczy bezpieczeństwa. Nie opublikowano wskaźnika wykrywalności, wskaźnika błędów ani procesu odwoławczego.

W poście przekonuje się również, że sam harmonogram ujawnień jest obecnie problemem. „Branżowe 90-dniowe okna mogą nie wytrzymać tempa i liczby błędów odkrywanych przez LLM” – czytamy, a autor ostrzega, że modele „mogą wkrótce przewyższyć szybkość i skalę nawet ekspertów-ludzkich badaczy”. To dostawca przekonujący, że norma, według której będzie oceniany, wymaga zastąpienia, i to jest część materiału o najdalszym zasięgu.

Co się potem zmieniło?

20 lutego 2026 r. Anthropic udostępnił Claude Code Security w ramach ograniczonego podglądu badawczego dla klientów Enterprise i Team, z bezpłatnym przyspieszonym dostępem dla opiekunów projektów open source — funkcję wprowadzono na rynek piętnaście dni po badaniach. VentureBeat poinformował o premierze i podał, że zwrócił się do Anthropic o wskaźnik fałszywych alarmów przed weryfikacją własną i po niej, o liczbę ujawnionych luk z wdrożonymi poprawkami w porównaniu z tymi wciąż na etapie analizy oraz o zabezpieczenia odróżniające użycie przez atakującego od użycia przez obrońcę; poinformował, że główny badacz projektu był niedostępny, a firma odmówiła ujawnienia konkretnych mechanizmów wykrywania atakujących.

Poprawki również ciągle się zmieniały, i nie zawsze w jednym kierunku. Poprawka CGIF dotycząca alokacji opisanej przez Anthropic trafiła do wersji v0.5.1 19 stycznia 2026 r.; 21 lutego 2026 r. pull request #103 naprawił 32-bitowe przepełnienie liczby całkowitej wprowadzone przez to samo obliczenie alokacji, a poprawka została wydana jako v0.5.2 następnego dnia dla GIF-ów o maksymalnym rozmiarze 65 535 na 65 535 pikseli. Jak się okazuje, naprawianie obliczeń granic samo w sobie jest małym źródłem błędów granic.

Prawidłowe odczytywanie liczby

Zdanie samego Anthropic brzmi: „ponad 500 podatności o wysokiej wadze”. Axios, któremu firma przekazała informacje jako pierwszemu, opisał je w dniu publikacji jako „ponad 500 wcześniej nieznanych podatności zero-day”, z których każdą zweryfikował członek zespołu Anthropic lub zewnętrzny badacz bezpieczeństwa. Oba opisy dotyczą tego samego zbioru, ale tylko jeden jest sformułowaniem dostawcy, a żadnemu nie towarzyszy lista, mapowanie CVE ani rozkład ważności. Liczba pochodzi od Anthropic, oceny ważności pochodzą od Anthropic, a trzy projekty omówione w poście to jedyne, które opinia publiczna może sprawdzić.

Niezależna analiza, która nastąpiła później, w większości przyjmowała tę liczbę za dobrą monetę i spierała się o to, co ona oznacza. Mitch Ashley z Futurum Group napisał 24 lutego 2026 r., że wynik „ma większe znaczenie ze względu na to, co ujawnia metoda, niż ze względu na samą liczbę”, a prawdziwym ograniczeniem jest dalszy etap: „Szybsze ujawnianie większej liczby luk nie zmniejsza powierzchni ataku. Tworzy większą kolejkę przed procesem na dalszym etapie, który nie jest w stanie wchłonąć takiej ilości”. To krytyka procesu ujawniania, a nie samego ustalenia, i trafia w ten sam punkt, który Anthropic podniósł w kwestii 90-dniowych okien.

Czego nie stwierdza materiał dowodowy

Archiwum ocenia ten rekord jako pewność A, wagę info, bez odnotowanych rzeczywistych szkód i bez flagi sporu. Ta ocena dotyczy tego, jak dobrze udokumentowano zdarzenie, a nie tego, jak dobrze zweryfikowano leżące u jego podstaw twierdzenie — i warto tę różnicę zachować. Nikt spoza Anthropic nie zweryfikował tych 500. Nie opublikowano żadnego odsetka fałszywych trafień. Łatki dla trzech wymienionych projektów są prawdziwe i możliwe do datowania i stanowią najsilniejsze dostępne potwierdzenie — potwierdzają jednak trzy przykłady, a nie całość.

Pozostaje więc dobrze udokumentowane ogłoszenie z weryfikowalnym rdzeniem i nieweryfikowalną resztą: dostawca zgłaszający możliwość, trzy diffy upstream zgodne z jego opisem błędów oraz deklarowany zamiar przeciwdziałania nadużyciom tej możliwości na poziomie modelu. Archiwum klasyfikuje to jako politykę, co jest właściwą półką. Roszczenie dotyczące możliwości rozstrzygnie ten, kto opublikuje czwartą poprawkę.