W tym poście dzielimy się szczegółami dotyczącymi pięciu łańcuchów ataków, które doprowadziły do zdalnego wykonania kodu i innych krytycznych skutków przy niewielkiej lub żadnej interakcji ze strony użytkownika. Łańcuchy te pokazują zdolność modelu do tworzenia zaawansowanych, wieloetapowych exploitów zarówno w oprogramowaniu open-source, jak i komercyjnym. Wszelkie luki w tych produktach mogą dotknąć miliardy użytkowników. Należą one również do oprogramowania o największym znaczeniu dla bezpieczeństwa na świecie, co czyni je wyznacznikiem jakości badań nad lukami i możliwościami cyberbezpieczeństwa modeli testowych.

Każdą lukę zgłosiliśmy dotkniętemu dostawcy w ramach naszej skoordynowanej polityki ujawniania luk, która daje programistom 90 dni na wprowadzenie poprawek oraz kolejne 45 dni, zanim omówimy szczegóły wykraczające poza to, co zostało już zawarte w publicznym komunikacie.

1. Zdalne wykonanie kodu jednym kliknięciem w przeglądarce Chrome

Po wstępnym zgłoszeniu Claude napisał pełny łańcuch exploitów umożliwiający atakującemu wykonanie dowolnego kodu jako użytkownik, poza piaskownicą przeglądarki. Nasza demonstracja koncepcji uruchamia aplikację Kalkulator w przeglądarce Chrome o domyślnej konfiguracji w systemie macOS w ciągu kilku sekund od załadowania strony, bez żadnej dalszej interakcji użytkownika:

Claude odkrył lukę w silniku JavaScript przeglądarki Chrome, V8, która pozwalała złośliwej stronie internetowej na uszkodzenie pamięci sterty (heap) silnika V8.

Claude odkrył drugą lukę, pozwalającą na wyrwanie się z piaskownicy regionu pamięci silnika V8 i obejście mechanizmu ASLR. Ten etap pozwolił zlokalizować kod przeglądarki Chrome w pamięci i wykorzystać łańcuch programowania zorientowanego na powrót (ROP) w celu przejęcia pełnej kontroli nad procesem renderera.

Zainfekowany renderer był ograniczony przez piaskownicę procesową przeglądarki Chrome. Następnie Claude odkrył warunek wyścigu w module CacheStorage. Zainfekowany renderer wykorzystał ten warunek wyścigu do odczytania pamięci poza piaskownicą i poznania układu pamięci uprzywilejowanego procesu przeglądarki.

Wreszcie Claude odkrył lukę typu „use-after-free” w module FedCM, czyli funkcji zalogowania federacyjnego przeglądarki Chrome, która umożliwiła exploitowi wykonanie dowolnego kodu poza piaskownicą.

Zgłosiliśmy nasze ustalenia firmie Google: przypisano 62 numery CVE, które zostały załatane w przeglądarce Chrome w wersji 156; wszystkie z nich zostały sklasyfikowane jako krytyczne lub o wysokim poziomie zagrożenia. Wśród nich znajduje się 13 przypadków ucieczki z piaskownicy oraz 21 luk, które mogłyby zostać wykorzystane do przejęcia kontroli nad rendererem.

2. Łańcuch exploitów uruchamiany jednym kliknięciem w przeglądarce Safari

Po wstępnym zgłoszeniu Claude napisał łańcuch exploitów, który pozwalał kodowi JavaScript dowolnej strony internetowej całkowicie ominąć zasadę tego samego pochodzenia (SOP). Exploit mógł uzyskać dostęp do historii przeglądarki Safari użytkownika, plików cookie i innych wrażliwych danych, a także wysyłać uwierzytelnione żądania HTTP do innych domen i odczytywać odpowiedzi. Na przykład, jeśli użytkownik jest zalogowany na swoje konto e-mail, atakujący może teraz odczytać jego wiadomości; jeśli jest zalogowany na konto bankowe, atakujący może wyświetlić salda kont lub próbować wykonać przelewy.

Aby to osiągnąć, Claude pokonał kilka warstw zabezpieczeń wbudowanych w przeglądarkę Safari:

Claude odkrył lukę typu „use-after-free” (UAF) w JavaScriptCore, silniku JavaScript przeglądarki Safari, napisanym w języku C++. Niektóre operacje na TypedArray zapisywały dane poprzez nieaktualne wskaźniki do zwolnionej pamięci, nadpisując metadane TypedArray.

Mechanizm Gigacage w WebKicie ogranicza tego typu ataki poprzez izolowanie danych TypedArray w oddzielnym obszarze pamięci. Claude odkrył, że niektóre zmienne w tym obszarze były wykorzystywane do indeksowania innych obszarów, co dawało mu możliwość dowolnego odczytu i zapisu poza obszarem Gigacage.

Cały kod JavaScript stron internetowych działa w piaskownicy WebContent, która zapobiega przedostawaniu się błędów, takich jak UAF, do wrażliwych danych przeglądarki przechowywanych na dysku. Claude odkrył lukę w mechanizmie IPC piaskownicy, która pozwalała exploitowi odczytywać z dysku historię przeglądarki Safari, pliki cookie oraz bazy danych sesji.

Wreszcie Claude wykorzystał lukę UAF do nadpisania zmiennej w pamięci i wyłączenia zasady SOP (SOP), umożliwiając stronie atakującego odczyt danych z dowolnego innego źródła.

Łańcuch ten jest interesujący, ponieważ jest to atak oparty wyłącznie na danych, który nigdy nie opiera się na wykonaniu dowolnego kodu. Zamiast tego wykorzystuje pełny dostęp do odczytu i zapisu w pamięci procesu przeglądarki w celu modyfikacji flagi bezpieczeństwa, rozmiaru obiektu oraz adresu URL. Kilka z tych słabości nie stanowi samo w sobie luk w zabezpieczeniach, ale jest zamierzonymi zachowaniami, które stają się podatne na wykorzystanie w połączeniu.

Firma Apple potwierdziła otrzymanie naszego zgłoszenia tego samego dnia, w którym je przesłaliśmy, i niezwłocznie wdrożyła poprawkę. Poprawka ta jest już dostępna dla użytkowników.

3. Ominięcie ekranu blokady w systemie Android

Po otrzymaniu pierwszego zlecenia Claude napisał exploit, który pozwalał atakującemu na wyodrębnienie zdjęć i innych danych osobowych ze skradzionego telefonu z systemem Android bez konieczności jego odblokowywania. Praca ta łączyła trzy metody: analizę kodu źródłowego otwartych komponentów systemu Android, inżynierię odwrotną i usunięcie zaciemnień z plików binarnych usług Google Play oraz testy na żywo na fizycznym egzemplarzu telefonu Google Pixel 9. Pozwoliło to wykryć szeroki zakres luk w zabezpieczeniach zarówno w komponentach otwartych, jak i zastrzeżonych. Następnie Claude połączył trzy z nich w ostateczny exploit.

System Android posiada kilka warstw ochrony przed tym atakiem. Claude znalazł sposób na obejście każdej z nich:

Zablokowany telefon z systemem Android jest zaprojektowany tak, aby nie przesyłać danych przez USB. Claude odkrył, że host USB z określonym ustawieniem pozwala to obejść.
Protokół przesyłania danych między urządzeniami odrzuca polecenia dotyczące danych od nieautoryzowanych urządzeń. Claude znalazł sposób na pominięcie kontroli autoryzacji i rozpoczęcie procesu parowania.
Parowanie jest chronione przez uwierzytelniane uzgadnianie klucza, które wymaga od użytkownika zweryfikowania sześciocyfrowego kodu. Claude znalazł lukę, która pomijała tę weryfikację i działała tak, jakby użytkownik kliknął „Zezwól”.
Transfery USB nie powinny przenosić treści plików, co jest egzekwowane przez wbudowaną kontrolę. Claude odkrył mechanizm awaryjny, który wysyłał surowe bajty przez USB i nie był objęty tą kontrolą. Eksploit za jego pośrednictwem żądał treści plików.

Problem ten został rozwiązany przez Google.

4. Zdalne odmówienie usługi w systemie Windows

Po otrzymaniu wstępnej wskazówki Claude napisał exploit, który umożliwiłby atakującemu zdalne spowodowanie awarii dowolnego komputera z systemem Windows, który odpowiada na żądania HTTP/3 przy użyciu natywnej implementacji tego protokołu w systemie Windows. Trudność w tym przypadku polegała przede wszystkim na zidentyfikowaniu samej luki. Po otrzymaniu tej wstępnej wskazówki zgłosiliśmy tę lukę bezpośrednio firmie Microsoft, która ją usunęła i przypisała jej numer CVE-2026-33096.

Luka zidentyfikowana przez Claude'a polegała na odczycie poza granicami pamięci w implementacji protokołu QUIC w jądrze systemu Windows. Atakujący mógłby zdalnie, przez sieć, dotrzeć do podatnej ścieżki kodu i wysłać kilka pakietów danych do nasłuchującego serwera, aby spowodować awarię i ponowne uruchomienie komputera. Poprzez wielokrotne wysyłanie takich żądań możliwe jest ciągłe powodowanie awarii serwera, co skutkuje utratą dostępu do serwera dla wszystkich użytkowników. Szacujemy, że w Internecie prawdopodobnie znajduje się kilka milionów takich serwerów pozostających w trybie nasłuchu.

Claude odkrył tę lukę poprzez analizę plików binarnych. Przekazaliśmy modelowi kopię pliku wykonywalnego systemu Windows i poprosiliśmy Claude’a o przeprowadzenie inżynierii odwrotnej w celu zbadania działania oprogramowania przy użyciu istniejących narzędzi do inżynierii odwrotnej (takich jak Ghidra), napisanie w pełni opisanego programu w języku C, który odtwarza istotne funkcje, porównanie zachowania odtworzonego programu z plikiem binarnym w celu zapewnienia poprawności, a następnie przeanalizowanie kodu pod kątem luk w zabezpieczeniach. Kiedy poprosiliśmy Claude’a o zidentyfikowanie potencjalnie bardziej ryzykownych problemów, ujawnił on tę lukę, którą można wykorzystać zdalnie.

5. Zdalne wykonanie kodu typu „zero-click” w systemie Linux

Chociaż niniejszy wpis skupia się na produktach innych firm, kontynuowaliśmy nasze prace nad oprogramowaniem open source. Dzięki Claude’owi odkryliśmy luki umożliwiające lokalne podwyższenie uprawnień w systemach OpenBSD, FreeBSD i Linux; szereg przypadków ucieczki z piaskownicy w popularnej infrastrukturze piaskownicowej; oraz liczne luki w ważnych aplikacjach internetowych. Odkryliśmy również luki umożliwiające zdalne (zero-click) wykonanie dowolnego kodu w stosie sieciowym jądra systemu Linux, które zostały już załatane w kodzie źródłowym i publicznie ujawnione. Jeden z takich przykładów opisujemy szczegółowo poniżej.

Po wstępnym zleceniu Claude napisał exploit, który pozwala zdalnemu atakującemu wysyłać pakiety do serwerów z systemem Linux wyposażonych w wielścieżkowy odbiornik TCP w celu uruchomienia dowolnych poleceń z uprawnieniami roota, bez konieczności podawania danych uwierzytelniających ani interakcji użytkownika. Podstawową luką jest błąd UAF spowodowany sytuacją wyścigu w stosie sieciowym jądra. Pełne wykorzystanie luki składa się z dwóch kluczowych etapów:

W pierwszym etapie atakujący zdalnie omija mechanizm KASLR. Wykorzystuje on sytuację wyścigu warunkowego, aby zmusić jądro do odczytania kontrolowanego przez atakującego pola długości, skopiowania dodatkowych bajtów i odesłania ich z powrotem do atakującego; wystarczy, że jeden taki nadmierny odczyt zawiera w odpowiedzi wskaźnik jądra, a atakujący poznaje układ przestrzeni adresowej jądra.
W drugim etapie atakujący przejmuje kontrolę nad przepływem sterowania. Wykorzystuje tę samą lukę typu UAF do przepełnienia bufora i nadpisania wskaźnika wywołania zwrotnego adresem ładunku, który atakujący wcześniej umieścił w pamięci jądra za pomocą zwykłej funkcji protokołu. Gdy jądro wywołuje wywołanie zwrotne, ładunek uruchamia łańcuch wywołań istniejących funkcji jądra, kończący się wybranym przez atakującego poleceniem powłoki uruchamianym z uprawnieniami roota.

Cechą charakterystyczną tej sytuacji wyścigu jest to, że przegrany wyścig powoduje jedynie niepowodzenie uzgodnienia, nie powodując awarii całego systemu, więc zdeterminowany atakujący może ponawiać próby w nieskończoność, aż do osiągnięcia sukcesu. W naszym dowodzie koncepcyjnym wyciek wskaźnika jądra zajmuje 48 minut, a kolejne pięć minut zajmuje dotarcie do etapu wykonania polecenia powłoki. Ta luka (CVE-2026-98432) została załatana w kodzie źródłowym i przeniesiona do wszystkich utrzymywanych stabilnych gałęzi jądra.

Czego się nauczyliśmy

W trakcie wykorzystywania Claude’a do tych prac związanych z bezpieczeństwem zidentyfikowaliśmy szereg spostrzeżeń, które ukształtowały nasze podejście. Uważamy, że dwa z nich są szczególnie istotne.

Skalowanie mocy obliczeniowej w czasie testów oraz różnorodność skanerów znacznie zwiększają liczbę wykrywanych luk. Stworzyliśmy platformę, która uruchamia równolegle dużą liczbę agentów skanujących, ocenia każdy skaner na podstawie liczby dodatkowych luk, które wnosi do zbioru, oraz dynamicznie śledzi pokrycie, tak aby skanery przetwarzały całą bazę kodu.

Strategie obejmują zarówno czysty zasięg (czy w tej funkcji występuje luka?), jak i podejście oparte na celach (czy ta aplikacja ujawnia coś, co mogłoby narazić dane klientów?) oraz oparte na modelu zagrożeń (czy coś w tej aplikacji omija jej udokumentowany model zagrożeń?). Wykorzystaliśmy również Claude do przeprowadzenia automatycznej analizy wariantów każdego potwierdzonego wyniku. Wszystkie wyniki przechodzą przez ustandaryzowany proces weryfikacji i oceny ryzyka, dzięki czemu możemy swobodnie eksperymentować z nowymi skanerami bez obniżania poprzeczki jakościowej.

Naprawienie istniejących zaległości rozwiązuje tylko połowę problemu; druga połowa polega na zmniejszeniu tempa, w jakim nowe luki w zabezpieczeniach pojawiają się w kodzie źródłowym.

W tym celu zalecamy skanowanie w momencie tworzenia pull requestów. Wbudowaliśmy wytyczne dotyczące bezpieczeństwa bezpośrednio w nasz proces programowania za pomocą wtyczki Claude Code, którą udostępniliśmy publicznie.

Co to oznacza dla osób odpowiedzialnych za ochronę

Modele Frontier potrafią wykrywać i łączyć wiele luk w zabezpieczeniach w działający exploit. Umiejętności te historycznie należały do nielicznych wyspecjalizowanych zespołów posiadających wiedzę na temat tych celów. Obecnie jest to coś, co modele potrafią wykonać przy niewielkim udziale człowieka, a następnie udowodnić, tworząc działający exploit, który każdy może uruchomić i zweryfikować.

Wyposażenie osób odpowiedzialnych za ochronę w potężne modele ma kluczowe znaczenie dla zapewnienia im przewagi w łataniu systemów, zanim zrobią to atakujący. Niedawno udostępniliśmy rozszerzoną wersję naszego programu Cyber Verification Program, który udostępnia kwalifikującym się specjalistom ds. bezpieczeństwa zaawansowane możliwości cyberbezpieczeństwa oraz klasyfikatory o zmniejszonej skłonności do blokowania.

Obejmuje on dostęp do naszych najwydajniejszych modeli, w tym Claude Opus 5.5, Claude Sonnet 5.5, Claude Mythos 5.1 oraz innych nowych modeli, które pojawią się w przyszłości. Nasza rada dla osób odpowiedzialnych za ochronę pozostaje niezmienna: skanowanie własnego kodu jest ważniejsze niż kiedykolwiek.