Gdy słyszymy, że model znalazł luki w Firefoxie, łatwo odruchowo popłynąć w jedną z dwóch stron. Pierwsza to zachwyt w stylu „okej, to już po zawodzie security researchera”. Druga to znużenie: „znowu marketing AI i znowu nic z tego nie wynika”. Tym razem prawda leży dużo bliżej środka, ale właśnie dlatego ten przypadek jest tak ciekawy.
Mozilla opisała współpracę z red teamem Anthropic, który przyszedł nie z luźnymi podejrzeniami, tylko z weryfikowalnymi raportami i minimalnymi testami. Inżynierowie Firefoksa potwierdzili wyniki, szybko dowieźli poprawki i finalnie mówimy o 14 błędach wysokiej wagi i 22 nadanych CVE. To już nie jest poziom „model zasugerował dziwną ścieżkę wykonania”. To jest materiał, z którym zespół bezpieczeństwa może pracować bez przepalania dni na zgadywanie, czy zgłoszenie w ogóle ma sens.
Co dokładnie pokazało Anthropic
Z publikacji Anthropic wiemy coś jeszcze ważniejszego: Claude Opus 4.6 nie tylko wskazał podatności, ale w jednym z eksperymentów poszedł krok dalej i zbudował exploit dla błędu oznaczonego jako CVE-2026-2796. To brzmi bardzo grubo, ale trzeba od razu dodać zimną wodę. Sam Anthropic zaznacza, że exploit działał w środowisku testowym, z wyłączoną częścią zabezpieczeń nowoczesnej przeglądarki. To nie był pełny, gotowy łańcuch ataku pozwalający wyrwać się z sandboxa i zrobić realną krzywdę użytkownikowi końcowemu.
Ta ostrożność jest kluczowa, bo bez niej łatwo wypaczyć wniosek. Najciekawsze nie jest to, że AI „już potrafi exploit development”, tylko że coraz lepiej radzi sobie z dojściem do granicy, za którą wcześniej potrzebny był naprawdę mocny człowiek od silników, pamięci i zachowania runtime’u. Anthropic napisał wprost, że model dostał setki prób. To nie był pojedynczy olśniewający strzał z biodra. Ale nawet z tym zastrzeżeniem kierunek jest ewidentny.
Dlaczego ten case jest ważny dla AppSec, a nie tylko dla PR-u
W większości dojrzałych zespołów bezpieczeństwa największym kosztem nie jest dziś brak narzędzi. Problemem jest raczej to, że sygnał bywa zakopany pod toną szumu. Fuzzery znajdują jedną klasę problemów, skanery statyczne inną, manualny review jeszcze inną, a do tego dochodzi chroniczny brak czasu na sensowny triage. Właśnie tutaj ten case robi różnicę.
Mozilla podkreśliła, że raporty Anthropic miały reprodukowalne testy i dało się je szybko potwierdzić. To zmienia ekonomię pracy. Jeśli model nie tylko mówi „tu może być bug”, ale jeszcze daje minimalny przypadek testowy, to przestaje być generatorem pomysłów, a zaczyna być akceleratorem procesu. Nie zastępuje seniora od exploita, ale wyraźnie przyspiesza etap „pokaż mi miejsca, gdzie naprawdę warto wejść głębiej”.
To też ważny sygnał dla projektów open source. Przez ostatnie dwa lata maintainerzy regularnie narzekali, że fala „AI-assisted reports” daje głównie śmieci: fałszywe alarmy, opisy bez reprodukcji, bugi zmyślone przez model albo takie, które istnieją wyłącznie na papierze. W opisie Mozilli wyraźnie widać, że tu było inaczej. Dostarczony materiał był używalny. W praktyce to jest o wiele większy przełom niż sam nagłówek o liczbie CVE.
Gdzie kończy się hype
Nie warto jednak wyciągać z tego złych wniosków. Ten case nie oznacza, że można wstawić model w miejsce reviewera i iść na kawę. Nadal potrzebna jest walidacja po stronie ludzi, potrzebne są poprawki, potrzebne jest zrozumienie architektury, priorytetów i ryzyka biznesowego. Sam Anthropic bardzo uczciwie zaznacza, że mówimy o wczesnym sygnale i rosnącej zdolności, a nie o końcu gry.
Warto też pamiętać, że Firefox nie jest byle projektem testowym. To jeden z najbardziej analizowanych i hartowanych kodowo produktów na rynku. Jeśli właśnie tam dało się znaleźć tyle sensownych błędów, to dla bezpieczeństwa oznacza to dwie rzeczy naraz. Po pierwsze, AI-assisted analysis rzeczywiście dojrzewa. Po drugie, prawdopodobnie istnieje całkiem duży zapas błędów w innych, gorzej przeglądanych systemach, które do tej pory nie były łatwo wykrywalne standardowym zestawem narzędzi.
Co z tego wynika dla zespołów technicznych
Najbardziej rozsądny wniosek na dziś jest prosty: modele nie są jeszcze autonomicznymi łowcami zero-dayi, ale stają się bardzo sensownymi współpracownikami w defensywnym security. Szczególnie tam, gdzie liczy się cierpliwe szukanie anomalii, budowanie małych testów, porównywanie ścieżek wykonania i iteracyjne zawężanie hipotez.
Gdybym miał wskazać najbardziej praktyczne zastosowanie już teraz, powiedziałbym tak: AI nie zastępuje exploit developera, ale może bardzo mocno skrócić drogę do miejsca, w którym ekspert wchodzi do gry z pełnym kontekstem. I to jest zmiana, której nie warto lekceważyć.
W marcu 2026 najciekawsze w security nie jest więc hasło „AI znalazło lukę”, tylko to, że po raz pierwszy mamy publicznie opisany, wiarygodny i potwierdzony przypadek, w którym model dostarczył realną wartość w jednym z najtrudniejszych środowisk, jakie można sobie wyobrazić. To już nie wygląda jak eksperyment na slajdach. To zaczyna wyglądać jak nowa warstwa warsztatu security.