Badanie 1Password dotyczące poprawek AI: 26% czystych poprawek, a następnie riposta

6 sierpnia 2026 r. Off-by-1 Labs należące do 1Password opublikowało 55-stronicowe badanie dotyczące tego, czy czołowe agenty kodujące potrafią łatać rzeczywiste luki bezpieczeństwa. ChatGPT 5.5, uruchomiony z zabezpieczeniami Trusted Access for Cyber od OpenAI przy średnim wysiłku, oraz Claude Opus 4.8, uruchomiony z zabezpieczeniami Cyber Verification Program od Anthropic przy wysokim wysiłku, wygenerowały 6480 prób łatania sześciu niedawno ujawnionych błędów obejmujących wiele plików. Kontrola pod kątem oszustw wykluczyła 400 z nich, wychodząc z założenia, że model poszukiwał poprawki upstream; spośród 6080 pozostałych, 26,0% zamknęło lukę bez zmiany zachowania, a 53,8% pozostawiło otwartą ścieżkę wykorzystania, wprowadziło nową wadę lub zrobiło jedno i drugie. Żaden system nie został naruszony i żadne dane użytkowników nie zostały ujawnione — współczynnik defektów dotyczy samych łat, dlatego archiwum klasyfikuje ten wpis na poziomie ważności info i nie odnotowuje żadnych szkód. Sam wpis, wraz z oceną pewności i cytowanymi źródłami, jest skatalogowany w Orca AI Incident Archive, który indeksuje udokumentowane incydenty i luki bezpieczeństwa związane z AI.

Sześć błędów i dlaczego właśnie te sześć

Cele dobrano tak, by były nieprzyjazne. Każdy musiał znajdować się w kodzie open source, który agent mógł przeczytać; powodować poważne naruszenie poufności, integralności lub dostępności; być już załatany upstream, przy czym łatka została ukryta przed agentem i służyła wyłącznie jako podstawa oceny; zostać ujawniony na tyle niedawno, by poprawka raczej nie znajdowała się w danych treningowych modela; oraz wymagać rzeczywistej poprawki obejmującej kilka plików, funkcji lub ścieżek kodu. Najstarsze ujawnienie wśród nich miało miejsce 26 marca 2026 r., a najnowsze 12 maja.

Każdy cel otrzymał 540 prób na model: trzy tryby wykonania × dziewięć szablonów promptów × 20 próbek. Przebiegi jednorazowe nie miały powłoki ani sieci poza własnym API modelu. Przebiegi iteracyjne miały skrypty reprodukujące i do dziesięciu iteracji, z plikiem pamięci przenoszonym między nimi. Przebiegi eksploracyjne miały narzędzia, ale nie dostarczono im testu, i polecono im samodzielnie zdecydować o własnym sposobie działania. Szablony obejmowały zakres od pełnego briefu opiekuna przez zgłoszenie SAST do dwóch, które zalecały wiarygodną, lecz błędną poprawkę. Przebiegi były odizolowane w kontenerach, a historia git została ucięta na commicie bezpośrednio przed rzeczywistą poprawką.

Hipoteza robocza autorów, ustalona przy rozpoczęciu projektu 20 maja 2026 r., zakładała, że modele będą łatać z częstością powyżej 67%. Żadna pojedyncza konfiguracja — model, tryb i prompt — nie przekroczyła 50% na wszystkich celach.

26% to jedna z pięciu części skali

W artykule każdą łatkę ocenia się według pięciu wyników. S1 łagodzi wszystkie możliwe do wykorzystania ścieżki i pozostawia niepowiązane zachowanie bez zmian albo zmienia je dokładnie tak, jak robi to rzeczywista łatka upstream. S2 łagodzi podatność, ale przy tym zmienia zachowanie aplikacji — odrzucając na przykład niegroźne dane wejściowe wraz ze złośliwymi. S3 pozostawia co najmniej jedną ścieżkę wykorzystania otwartą i nie wprowadza nowej wady. S4 naprawia zgłoszony błąd i wprowadza odrębny. S5 nie spełnia żadnego z tych zadań.

We wszystkich 6 080 iteracjach nie-cheatowych artykuł podaje 26,0% S1 — 25,6% dla Claude Opus 4.8 i 26,5% dla ChatGPT 5.5 — następnie 20,1% S2, 49,3% S3, 2,3% S4 i 2,2% S5. Krążąca liczba porażek, 53,9%, to łącznie S3, S4 i S5; tabela w artykule sumuje się do 53,8% przed zaokrągleniem, a zarówno blog 1Password, jak i wiersz w archiwum podają 53,9%.

Oba modele uzyskały średnio wyniki różniące się o nie więcej niż jeden punkt procentowy, jednak niemal cała zmienność dotyczyła celów, a nie modelu. Uśrednione dla obu modeli wskaźniki czystych poprawek dla poszczególnych celów wahały się od 3,2% dla Apache ActiveMQ do 60,0% dla Exim. W przypadku samego Exima różnica między modelami wynosiła 31,6 punktu: Claude Opus 4.8 osiągnął 75,8%, a ChatGPT 5.5 — 44,2%. Autorzy interpretują to jako ostrzeżenie dla agentów do łatania w trybie plug-and-play i wyraźnie zaznaczają, że badanie nie jest bezpośrednim porównaniem obu modeli.

Dwie drugorzędne liczby znaczą więcej niż nagłówek. Spośród łatek ocenionych jako czyste poprawki 25,2% miało flagę kruchości — zamykały zgłoszony problem, ale pozostawiały bazowy prymityw na miejscu, choć niekoniecznie osiągalny. Łącznie w S1 i S2 37,5% było kruche. Osobno, w gałęziach iteracyjnych i eksploracyjnych, 9,3% iteracji sprawdzonych pod kątem oszustw uznano za takie, które odwołały się do patchu upstream, skąd wzięło się 400 wyłączeń. Koszt był skromny: 2,11 USD za próbę dla ChatGPT 5.5 i 2,81 USD dla Claude Opus 4.8, czyli 4,49 USD i 6,44 USD za czystą poprawkę po zamortyzowaniu nieudanych prób, z wyłączeniem kosztu potwierdzenia poprawki.

Jakość wskazówek wpłynęła na odsetek poprawnych napraw w większym stopniu niż wybór modelu. Przy starannie poprawnych wskazówkach dotyczących naprawy odsetek S1 wyniósł 35,9%; bez wskazówek — 24,7%; przy wskazówkach wskazujących niewłaściwą przyczynę źródłową lub kierunek naprawy — 7,4%. Autorzy wyróżniają jeden przypadek: gdy wywołania narzędzi przez samego agenta były sprzeczne z promptem człowieka, agent często mimo to podążał za promptem.

Jak faktycznie wyglądały awarie

Najbardziej oczywisty przypadek to CVE-2026-31431, błąd AF_ALG w jądrze Linux znany jako Copy Fail. Upstream naprawił prymityw uszkodzenia pamięci oparty na cross-mapping w commicie a664bf3d, przywracając przekształcenie do operacji out-of-place — i wprowadził nowy błąd off-by-one w tej samej funkcji pomocniczej, który opiekunowie poprawili jeden commit później, w 31d00156, z przypisanym CVE-2026-43078. Modele odtworzyły pośrednią wersję niemal dokładnie: 129 z 400 łat ChatGPT oznaczonych jako nie-cheat (32,2%) i 119 z 383 łat Claude (31,1%) zawierało ten off-by-one, we wszystkich trybach. Artykuł znalazł te 248 poprzez porównanie strukturalne zmienionej funkcji; automatyczny grader oznaczył tylko 14 łat ChatGPT i 10 łat Claude jako wprowadzające nową podatność.

Cichszy błąd tkwi w tym samym pliku. Przebudowa ścieżki odszyfrowywania authencesn ujawnia również zapis rozszerzonego numeru sekwencyjnego, który wykracza poza granice, gdy znacznik uwierzytelniania jest krótszy niż cztery bajty; upstream zamyka ją w 5db6ef98, odrzucając skróty o zbyt małym rozmiarze podczas tworzenia instancji. Ta wada istniała przed Copy Fail, nie wchodzi w skład commitów naprawiających CVE, a program odtwarzający nigdy jej nie testuje, ponieważ ustala długość znacznika na cztery bajty. Wszystkie 783 uczciwe iteracje pozostawiły ją bez zabezpieczenia, w tym każdą łatkę ocenioną jako czystą naprawę samego Copy Fail; jedynymi łatkami zawierającymi zabezpieczenie były cztery iteracje, które skopiowały commit upstream dosłownie.

GHSA-wpqr-6v78-jr5g, luka umożliwiająca zdalne wykonanie kodu w Gemini CLI, jest problemem dwuczęściowym: tryb headless automatycznie uznaje obszar roboczy za zaufany i wczytuje konfigurację lokalną obszaru roboczego, w tym plik .env, który inicjalizuje środowisko procesu, podczas gdy osobna flaga omija listę dozwolonych narzędzi. Średni odsetek czystych poprawek w obu modelach wyniósł 5,6%, najniższy w badaniu. W trybie jednorazowym 29,4% poprawek ChatGPT i 63,9% poprawek Claude’a przestało automatycznie uznawać obszar roboczy za zaufany, a mimo to nadal wczytywało plik .env kontrolowany przez atakującego, ponieważ wczytywanie środowiska odbywa się w innym module niż decyzja o zaufaniu. Gdy reproduktor wskazał ścieżkę .env, ramię iteracyjne zamknęło tę lukę — punktem ślepym była uwaga, a nie możliwości.

Błąd Chromium, CVE-2026-8512, to use-after-free w obserwatorze plików macOS. Poprawka upstream zastępuje surowy wskaźnik kontekstem z licznikiem referencji, który trzeba utrzymać przy życiu w dwóch miejscach: w miejscu instalacji i ponownie wewnątrz samego wywołania zwrotnego. Spośród poprawek, które przyjęły architekturę opartą na licznikach referencji, 41,9% od ChatGPT i 38,5% od Claude zachowało pierwszą referencję, a porzuciło drugą, co przenosi use-after-free w inne miejsce, zamiast go usuwać.

Te przykłady łączy pewna właściwość, która ma znaczenie dla każdego, kto planuje zautomatyzować pętlę: oceniający często nie był w stanie dostrzec porażki. Zautomatyzowane oceny modeli zgadzały się z ludzkimi recenzentami co do wyniku pięcioklasowego w 65,9% przypadków, co do tego, czy pierwotny błąd został poprawiony — w 87,7% przypadków, a co do tego, czy pojawił się nowy błąd — w 70,5% przypadków. Dwaj walidatorzy modelowi nie zgadzali się ze sobą co do 36,8% poprawek, a zagregowane oceny pokazują, że Claude oceniał łagodnie każdego, kto napisał poprawkę, podczas gdy ChatGPT oceniał surowo.

Co według 1Password powinno wydarzyć się dalej

Keith Hoodlet, który kieruje Off-by-1 Labs, powiedział eSecurity Planet, że „wygenerowanie poprawki to nie to samo co naprawienie luki” oraz że „kluczowy pozostaje przegląd dokonany przez ekspertów, aby zweryfikować, że poprawka jest zarówno skuteczna, jak i bezpieczna”. Konkluzja artykułu jest węższa niż w większości relacji: sukces zależy w dużej mierze od dokładnych informacji o błędzie o wysokiej wartości sygnałowej, a porządkowanie tych informacji to zadanie dla inżynierów, którzy znają bazę kodu.

Opinia Anthropic, przytoczona na blogu, jest taka, że generowanie poprawek wyprzedziło ich weryfikację, że weryfikacja powinna opierać się na wykonaniu, a nie na inspekcji, oraz że eksperci dziedzinowi powinni pozostać ostatecznymi recenzentami przy obecnych możliwościach modeli. 1Password udostępniło zestaw narzędzi o nazwie flawed oraz wszystkie 6480 poprawek, aby inni mogli sprawdzić, które kontrole wychwyciłyby błędy. 26 października blog zaktualizowano o informacje zwrotne po publikacji: ograniczenia wybrane przez zespół „mogły ograniczyć to, co mogły wygenerować narzędzia do agentowego generowania poprawek”, a kwestię, czy silniejsza weryfikacja zmienia wyniki, opisano jako istotne kolejne pytanie.

W zapisie znajduje się także drugie badanie, które nie jest tym samym testem.

Jeden wiersz archiwum zawiera dwa zestawy liczb, a japońska Information-technology Promotion Agency jest dokumentem, który zestawia je obok siebie: jej sierpniowy biuletyn bezpieczeństwa AI z 2026 r., opublikowany 7 września, podsumowuje oba badania w jednym wpisie datowanym na 6 sierpnia. Drugie badanie należy do Checkmarx: zlecił je Checkmarx, a przeprowadził Ilya Kabanov, dyrektor generalny The Weather Report, który ponownie uruchomił dwa opublikowane benchmarki na czterech modelach w ich własnych agentach wiersza poleceń — Claude Opus 4.8, GPT-5.5, Gemini 3.1 Pro i Gemini 3.5 Flash. Tekst Kabanova jest datowany na 6 lipca 2026 r., post Checkmarx na 26 lipca, a doniesienia branżowe ukazały się między tymi dwiema datami. Benchmark na poziomie repozytorium, SusVibes, obejmuje 200 zadań funkcjonalnych w dużych repozytoriach open source, z których każde opiera się na podatności, jaką człowiek już znalazł i naprawił; agent ma zaimplementować daną funkcjonalność, a sukces wymaga odtworzenia zabezpieczenia wprowadzonego przez człowieka, mimo że nie zostało mu ono pokazane.

Wyniki: sukces funkcjonalny na poziomie 83–95%, w porównaniu z 44–61% pokolenie wcześniej, ale sukces jednocześnie pod względem bezpieczeństwa i funkcjonalności wyniósł tylko 24–36%. Od 65% do 75% poprawek, które zadziałały, odtworzyło słabość, którą usunęli ludzie — Checkmarx nazywa to zombie CVE, ponieważ ponownie wprowadzona luka nie ma porady bezpieczeństwa ani wersji, którą można podbić. Przykładem, który wymienia Checkmarx, jest CVE-2023-29159, błąd path traversal w frameworku Starlette dla Pythona, znaleziony i naprawiony w 2023 r., a w 2026 r. odtworzony przez agenta.

Środki zaradcze są równie wymowne jak nagłówek. Ogólna instrukcja, by stosować się do najlepszych praktyk bezpieczeństwa, dodała od 1 do 8 punktów. Zwiększony wysiłek wnioskowania nie dodał bezpieczeństwa i zmniejszył o połowę liczbę działających rozwiązań. Etap modelowania zagrożeń przed kodowaniem osiągnął 43–49% rozwiązań bezpiecznych i funkcjonalnych; przegląd bezpieczeństwa po fakcie osiągnął 47–56%, przy odpowiednio około dwukrotnym i dwuipółkrotnym koszcie tokenów. Nawet najlepszy wariant badania pozostawił około połowy zadań niebezpiecznych, a w przypadkach porażek agenci czasami wymieniali właściwe zabezpieczenie we własnych notatkach i mimo to dostarczali podatny kod.

Zarówno Kabanov, jak i Checkmarx opatrują liczbę 65–75% zastrzeżeniami: zadania dobrano, ponieważ zbudowanie funkcji w naturalny sposób ponownie wprowadza tę wadę, więc odsetek w zwykłym kodzie jest prawdopodobnie niższy — jednocześnie przekonując, że prawdziwe bazy kodu są pełne dokładnie takich funkcji, i właśnie stamtąd w pierwszej kolejności biorą się CVE.

Tych dwóch badań nie należy łączyć. Pierwsze pyta, czy agent potrafi napisać poprawkę dla konkretnie wskazanego, już naprawionego błędu. Drugie pyta, czy agent wdrażający funkcję uniknie odtworzenia błędu, o którym nikt mu nie powiedział. 26,0% i 24–36% to odsetki przy różnych mianownikach, a żaden z nich nie jest odsetkiem dla łatania przez AI w ogóle.

Trail of Bits: nagłówek mierzy niewłaściwą konfigurację

15 września 2026 r., sześć tygodni po wydaniu 1Password, czterech badaczy z Trail of Bits — Anish Naik, Dan Guido, Benjamin Samuels i Marcelo Morales — opublikowało odpowiedź polemiczną, argumentując, że liczba 26% nie opisuje zwykłego łatania. Ich argumenty, wyrażone ich własnymi liczbami: dwa prompty każą agentom zastosować niewłaściwą poprawkę, a prompty te odpowiadają za 22% danych; jeden tryb ewaluacji uniemożliwia agentom budowanie lub uruchamianie kodu i odpowiada za 36%; sześć luk wybrano, ponieważ ich poprawki były złożone, a wyniki dla poszczególnych celów wynosiły od 3% do 60%, przy nieujawnionym błędzie standardowym wynoszącym około dziewięciu punktów dla średniej z sześciu celów; oraz oba modele działały w ustawieniach domyślnych, a nie z maksymalnym wysiłkiem.

Atakują również system oceniania. Twierdzą, że reguła zatrzymania i kryteria oceniania są sprzeczne; zamierzone zmiany zachowania ukarano jako regresje w 8% werdyktów ActiveMQ; a zautomatyzowany sędzia zgadzał się z ludzkimi recenzentami co do pełnego wyniku w pięciu kategoriach tylko w 65,9% przypadków. Przywołują 248 poprawek „Copy Fail”, które zawierały pośredni upstreamowy błąd off-by-one, w porównaniu z 24 wychwyconymi przez oceniającego, oraz przypadek Chromium, w którym oceniający zaakceptował poprawki nadal pozostawiające use-after-free w callbacku. Te liczby pochodzą od samego 1Password; spór dotyczy tego, co z nich wynika.

Ich ponowna analiza uwzględnia tylko próby, w których agenci mogli wykonywać kod i nie poinformowano ich o niewłaściwej naprawie, a odrzuca przebiegi uznane za takie, w których konsultowano poprawkę upstream. W tym podzbiorze 2634 z 3067 łatek — 86% — blokowało dostarczony exploit. Autorzy zachowują ostrożność w interpretacji tego wyniku: zablokowanie konkretnego exploita nie jest dowodem na kompletną naprawę wolną od regresji. Jako punkt odniesienia dla ludzi wskazują 2265 pierwszych poprawek w 236 ich własnych ocenach z lat 2024–2026, z których 283 (12,5%, 95-procentowy przedział ufności od 10,5% do 14,5%) nie rozwiązały problemu w pełni. Liczą również 186 pull requestów w swoim programie Patch the Planet: 126 scalono, z czego 33 (26,2%) wymagało zmian istotnych z punktu widzenia bezpieczeństwa. Przyznają też jeden przypadek, w którym krytyka ich własnej łatki ze strony 1Password była słuszna — w freenginx ich poprawka i niezależna poprawka maintainera wprowadziły tę samą awarię podczas sprzątania.

Ich najważniejszy wniosek jest dosadny: „Obrońcy nie powinni traktować głównego wskaźnika 1Password poważnie jako miary zdolności AI do łatania”. 1Password nie odniosło się do nich imiennie. W blogu stwierdzono, że zespół jest otwarty na krytykę swoich metod i ustaleń, a aktualizacja z 26 października przyznaje, że wybrane ograniczenia mogły nadmiernie ograniczyć to, co narzędzia mogły wytworzyć. Japoński biuletyn IPA, w którym podano 26,0% i 53,9% bez zastrzeżeń, opublikowano 7 września — osiem dni przed ripostą.

Co jest ustalone, a co jest przedmiotem argumentacji

• Ustalono: badanie istnieje, ze wskazanymi autorami — Axelem Mierczukiem, Spencerem Michaelsem i Keithem Hoodletem — opatrzone datą 6 sierpnia 2026 r., a jego liczby 6480 prób, 400 wykluczeń i 6080 ocenionych poprawek pojawiają się w artykule, na blogu 1Password i w podsumowaniu IPA.

• Ustalono: rozkład wyników – 26,0% czystych, 20,1% zmieniających zachowanie, 49,3% nierozwiązanych i 4,5% wprowadzających nową wadę – to własna ocena autorów, sporządzona przez dwóch walidatorów modelowych, których werdykty uśredniono i zweryfikowano krzyżowo względem przeglądu ludzkiego na próbie 1052 łatek, z 65,9% zgodnością w pięciostopniowej ocenie.

• Ustalono: konkretne regresje — 248 łatek Copy Fail z pośrednim błędem przesunięcia o jeden w upstreamie, 783 iteracji pozbawionych zabezpieczenia ESN, wzorzec .env w Gemini CLI, brakująca druga referencja w Chromium — są twierdzeniami autorów dotyczącymi ich własnych danych, z opisaną metodą wykrywania i detektorem sprawdzonym względem ręcznej weryfikacji na 253 iteracjach.

• Argument: czy 26% to uczciwe przedstawienie tego, co potrafi łatanie za pomocą AI. Trail of Bits twierdzi, że jej własne filtry pozwalają osiągnąć na tych samych łatkach 86% blokowania exploitów i że to rozwiązanie nie jest zwykłym łataniem; 1Password twierdzi, że z zadowoleniem przyjmuje krytykę i że jej ograniczenia mogły być zbyt ciasne. Obie strony analizują te same 6,080 łatek; spór dotyczy tego, które filtry są uzasadnione, i żadna ze stron nie opublikowała replikacji akceptowanej przez drugą.

• Nie twierdzi się: że którakolwiek z tych rzeczy spowodowała szkody w rzeczywistych warunkach. Archiwum nie odnotowuje żadnych rzeczywistych szkód i klasyfikuje wpis na poziomie informacyjnym. Sześć luk w zabezpieczeniach załatano po stronie źródłowej przed uruchomieniem testów, a badane łatki były kandydatami utworzonymi w kontenerach, a nie kodem zintegrowanym z tymi projektami.

Dla obrońcy użyteczne pytanie nie brzmi, której stronie wierzyć. Brzmi ono: czego dotyczy ten odsetek — 26% celowo trudnych błędów w warunkach celowo mieszanych informacji czy 86% wykonalnych prób, w których dostarczony exploit został zablokowany. Obie liczby pochodzą z tego samego zestawu danych i żadna z nich nie jest specyfikacją zamówienia. Co obie strony uznają, to zastrzeżenie, które sam 1Password zamieszcza w artykule — „wygenerowana poprawka jest kandydatem, a nie dowodem, że luka została naprawiona” — i właśnie ta część nie wymaga rozstrzygania.