Anthropic opublikował wyniki badania, w którym Claude przeanalizował 25 projektów open source o łącznej objętości ponad 5 mln linii kodu i znalazł 493 miejsca, gdzie kod był dostępny dla atakującego bez potrzeby. Najgłośniejszy wynik dotyczy OpenSSH: około 4500 linii eksperymentalnego kodu postkwantowego ML-DSA-44 było osiągalnych dla niezalogowanego klienta nawet wtedy, gdy administrator wyraźnie wyłączył ten algorytm.
- Claude wykrył, że około 4500 linii eksperymentalnego kodu postkwantowego ML-DSA-44 w OpenSSH było osiągalnych dla niezalogowanego klienta nawet przy wyraźnym wyłączeniu tego algorytmu – poprawki wprowadzono w wersjach 10.5 i 10.6, a według Anthropic usunęły one około jednej piątej kodu OpenSSH dostępnego przed uwierzytelnieniem.
- W ramach analizy 25 projektów open source (ponad 5 mln linii kodu) Claude znalazł 162 kombinacje ustawień przyjmowane bez błędu i bez ostrzeżenia, z których 94 po cichu wyłączały zabezpieczenie, a 68 powodowało niespójności – np. blokadę dostępu, która w praktyce nie blokowała nikogo.
- Projekt OpenSSH poinformował w notach do wydań 10.5 i 10.6, że w odpowiedzi na napływ zgłoszeń generowanych przez modele AI przechodzi na częstsze wydania poprawek, zamiast zbierać je do kolejnych planowanych wersji.
Raport zespołu Frontier Red Team, którego autorem jest Chris Rohlf, ukazał się 20 października 2026 roku na stronie Anthropic. Poprawki trafiły do OpenSSH w wersjach 10.5 i 10.6, a projekt OpenSSH wprost napisał w notach wydawniczych, że przez napływ zgłoszeń generowanych z pomocą AI przechodzi na częstsze wydania.
Chcesz czytać więcej treści związanych z AI?
Dodaj AIPORT.pl do preferowanych źródeł Google
Zamiast szukać luk, Claude ogranicza kod, do którego atakujący ma dostęp
Metoda opisana przez Anthropic nie polega na wykrywaniu konkretnych błędów, tylko na mapowaniu kodu osiągalnego dla atakującego i chowaniu go za bramki, których nie powinien omijać. Anthropic nazywa to automatyczną analizą i redukcją powierzchni ataku (attack surface reduction).
Argument jest prosty: naprawienie jednej luki nic nie mówi o pozostałych, które nadal siedzą w kodzie. Jeśli natomiast fragment kodu przestaje być osiągalny przed uwierzytelnieniem, wszystkie nieznane błędy w tym fragmencie tracą na wadze, łącznie z tymi, które ktoś już po cichu wykorzystuje. Luki nie znikają, ale trudniej do nich dotrzeć.
Claude pracował w trzech trybach:
- Domyślna konfiguracja. Kod osiągalny w ustawieniach fabrycznych, choć żadna domyślna funkcja go nie używa.
- Interakcja ustawień. Pary opcji, które osobno wyglądają rozsądnie, ale razem po cichu wyłączają zabezpieczenie albo zostawiają kod aktywny mimo wyłączonej funkcji.
- Wczesna osiągalność. Złożony, wrażliwy kod uruchamiany przed uwierzytelnieniem, bez interakcji ofiary albo przed przejściem protokołu do odpowiedniego stanu.
W trakcie analizy Claude zbudował inwentarz ponad 17 000 opcji konfiguracyjnych w 25 projektach napisanych m.in. w C, C++, Javie, PHP i Pythonie. 3842 z nich dotyczyły zabezpieczeń lub funkcji istotnych dla bezpieczeństwa.
162 kombinacje ustawień, z których 94 po cichu wyłączały zabezpieczenie
Najbardziej uderzające wyniki dotyczą interakcji ustawień. Claude znalazł 162 kombinacje opcji istotnych dla bezpieczeństwa, które oprogramowanie przyjmowało bez błędu, bez ostrzeżenia i bez dokumentacji opisującej, co się wtedy dzieje. W 94 przypadkach taka kombinacja po prostu wyłączała zabezpieczenie. Pozostałe 68 to niespójności: nasłuchiwacz lub ścieżka logowania zostawały aktywne mimo wyłączenia w konfiguracji, dwa ustawienia konfliktowały ze sobą, a o tym, które wygrywa, decydowała kolejność w pliku konfiguracyjnym.
Anthropic podzielił projekty na trzy grupy: publiczne (10 projektów, obsługujące dowolnego użytkownika, np. resolver DNS), bramkowane (11, przeznaczone wyłącznie dla uwierzytelnionych użytkowników) i prywatne (4, działające w środowisku operatora). W każdym z 11 projektów bramkowanych Claude znalazł kod osiągalny bez uwierzytelnienia, choć nie powinien być:
- 93 zbędne powierzchnie dostępne przed uwierzytelnieniem w domyślnej konfiguracji,
- 37 miejsc, gdzie kod wykonywał się lub zapisywał stan przed uwierzytelnieniem,
- 61 kombinacji ustawień, które po cichu osłabiały kontrolę skonfigurowaną przez administratora.
Anthropic zaznacza, że żadne z tych znalezisk nie było samo w sobie natychmiast eksploatowalne.
Ten sam błąd w czterech niepowiązanych projektach: lista blokad, która nigdy nie blokuje
Jeden wzorzec powtórzył się niezależnie w czterech różnych projektach. Administrator zapisuje regułę dostępu dla zdalnych klientów według nazwy hosta lub wzorca z wildcardem zamiast adresu IP. Serwer porównuje regułę z nazwą hosta klienta, ale tę nazwę zna tylko wtedy, gdy włączone jest odwrotne wyszukiwanie DNS, a większość projektów ma je domyślnie wyłączone. Bez DNS serwer porównuje wzorzec nazwy hosta z adresem IP jako zwykłym tekstem. Wzorzec nigdy nie pasuje, reguła „deny” nigdy nie działa, a lista blokad przepuszcza wszystkich.
Inny przypadek: opcja wymuszająca certyfikat klienta w jednym projekcie, w połączeniu z drugą opcją, która miała tylko opóźnić sprawdzenie, w praktyce wyłączała je całkowicie. Serwer skonfigurowany tak, by przyjmować wyłącznie zaufanych klientów, akceptował każdego. Według Anthropic ten konflikt ustawień istniał w kodzie przez 21 lat.
Najciekawsze w tym badaniu nie jest to, że Claude znalazł błędy. To, że znalazł je w OpenSSH, czyli w kodzie, który przez ćwierć wieku audytowały najlepsze zespoły bezpieczeństwa na świecie, w tym Qualys, który w 2024 roku wykrył regreSSHion. Jeśli w sshd przed uwierzytelnieniem leżało 4500 linii eksperymentalnej kryptografii osiągalnej mimo wyłączenia, to w przeciętnym korporacyjnym systemie leży tego wielokrotnie więcej.
Widzę tu dwie rzeczy naraz. Pierwsza: to naprawdę praktyczne podejście do obrony, bo nie wymaga znalezienia błędu, żeby go unieszkodliwić. Druga: te same modele, które mapują kod osiągalny przed logowaniem dla obrońców, mapują go dla atakujących. OpenSSH napisał to niemal wprost w notach do wydania 10.5. Wyścig już trwa i wygra ten, kto pierwszy przepuści swój kod przez taką analizę.
Pytanie otwarte brzmi: ile organizacji w ogóle wie, jakie opcje konfiguracyjne ma włączone w oprogramowaniu, na którym stoi ich infrastruktura? 17 tysięcy opcji w 25 projektach sugeruje, że mało kto.
Piotr Wolniewicz, Redaktor Naczelny AIPORT.pl
Wypełnij formularz, a my skontaktujemy się z Tobą, aby upewnić się czego potrzebujesz.
OpenSSH: 4500 linii kodu postkwantowego osiągalnych mimo wyłączenia
Największą redukcję powierzchni ataku w stosunku do rozmiaru projektu Claude osiągnął w OpenSSH. W wydaniu 10.4 z 6 lipca 2026 roku projekt dodał eksperymentalną obsługę kompozytowego podpisu postkwantowego łączącego ML-DSA-44 z Ed25519, domyślnie wyłączoną. Claude prześledził ścieżki wejścia demona sshd i stwierdził, że około 4500 linii tego nowego kodu było osiągalnych dla niezalogowanego klienta w domyślnej konfiguracji, nawet gdy administrator wyraźnie wykluczył algorytm.
Mechanizm był następujący: sshd najpierw parsował dowolny typ klucza przysłany przez klienta (a w przypadku certyfikatów weryfikował też podpis CA), a dopiero potem sprawdzał, czy ten typ klucza jest w ogóle dozwolony. Te 4500 linii to według Anthropic około 16 proc. własnego kodu OpenSSH dostępnego przed uwierzytelnieniem w domyślnym sshd. Anthropic nazwał to kodem złożonym i niebezpiecznym pamięciowo, który nie ma powodu być osiągalny, gdy jest wyłączony.
Poprawki przechodziły przez dwa wydania:
| Wersja OpenSSH | Data wydania | Zmiana |
|---|---|---|
| 10.4 | 06.07.2026 | Eksperymentalne ML-DSA-44 + Ed25519, domyślnie wyłączone |
| 10.5 | 11.08.2026 | Sprawdzenie typu klucza przeniesione przed parsowanie (sugestia Chrisa Rohlfa z Anthropic) |
| 10.6 | 06.10.2026 | Sprawdzenie typu klucza i algorytmu podpisu CA wewnątrz parsera, przed deserializacją |
Po wydaniu 10.5 Claude wskazał dwie luki w nowej kontroli. Po pierwsze, sprawdzana była nazwa algorytmu, którą klient zadeklarował, ale parser wybierano na podstawie ciągu typu zapisanego w samym blobie klucza. Klient mógł zadeklarować ssh-ed25519, przejść kontrolę i wysłać klucz ML-DSA, który i tak zostałby sparsowany. Po drugie, przy certyfikatach (domyślnie włączonych) sshd deserializował osadzony klucz publiczny CA i wykonywał pełną weryfikację podpisu dowolnym obsługiwanym algorytmem, zanim zajrzał do konfiguracji. Anthropic zbudował proof of concept i przeszedł z opiekunami OpenSSH przez kilka iteracji poprawki.
Wersja 10.6 z 6 października umieściła kontrole wewnątrz parsera. Noty wydawnicze OpenSSH opisują tę zmianę jako sprawdzanie typów kluczy i podpisów CA względem list dozwolonych algorytmów tak wcześnie, jak to możliwe, z adnotacją o współpracy z Chrisem Rohlfem, Claude i Anthropic Research. Według Anthropic poprawka usunęła około jednej piątej kodu OpenSSH, do którego niezalogowany klient mógł wcześniej dotrzeć w domyślnej kompilacji.
„Jeśli zbędna osiągalność przetrwała tam, może przetrwać wszędzie” / „If unnecessary reachability survives there, it can survive anywhere.”, podsumowuje Anthropic.
OpenSSH przechodzi na częstsze wydania przez zgłoszenia z AI
Projekt OpenSSH zareagował na falę zgłoszeń generowanych przez modele AI zmianą cyklu wydawniczego. W notach do wydań 10.5 i 10.6 zespół napisał, że otrzymał dużą liczbę raportów bezpieczeństwa pochodzących od modeli AI lub przygotowanych z ich pomocą. Wiele z nich po analizie w realistycznym modelu zagrożeń nie ma wpływu na bezpieczeństwo, ale „bardzo chętnie przyjmujemy te zgłoszenia” / „we very much welcome these reports”, zwłaszcza połączone z ludzką analizą, testami i propozycją poprawki.
Zespół zauważył też, że błędy znalezione przez narzędzia AI bywają potem niezależnie odkrywane przez innych badaczy. Z tego OpenSSH wyciąga wniosek, że przeciwnicy, którzy nie zgłaszają błędów projektom open source, też potrafią je znaleźć. Dlatego projekt będzie na razie wydawał poprawki częściej, zamiast zbierać je do kolejnego planowanego wydania.
Za każdą polską firmą AI stoi konkretny człowiek z imieniem i nazwiskiem, często ten sam w kilku miejscach naraz, i to właśnie ludzie, nie tabelki finansowania, są prawdziwym bohaterem tego artykułu.
Metoda trafia do OSS Scanner, darmowego skanera Anthropic dla open source
Anthropic połączył trzy opisane techniki w jedną wielokrotnego użytku umiejętność (skill) dla Claude i pracuje nad jej integracją z OSS Scanner. Skill wykonuje trzy przebiegi po kodzie, za każdym razem z pustym oknem kontekstu i tylko krótką notatką z poprzedniego przebiegu. W każdym przebiegu Claude buduje inwentarz punktów wejścia i potwierdza każde znalezisko dynamicznym śledzeniem programu. Dla znalezisk z domyślnej konfiguracji projektuje bramkę i sprawdza, uruchamiając testy projektu oraz zestaw regresyjny typu black box, że zmodyfikowana kompilacja zachowuje się identycznie jak bazowa. Bramki, które zmieniłyby zachowanie w konfiguracji niedomyślnej, odkłada do decyzji człowieka.
OSS Scanner to uruchomiony 8 października 2026 roku bezpłatny, dobrowolny program cyklicznych skanów bezpieczeństwa dla projektów open source o znaczeniu dla infrastruktury, wzorowany na Google OSS-Fuzz. Opiekunowie zgłaszają projekt przez pull request do repozytorium anthropics/oss-scanner. Według danych Anthropic przytaczanych przez BetaNews firma ujawniła do tej pory 6157 luk w 591 projektach, z czego opiekunowie potwierdzili 5103, a 516 załatali w kodzie źródłowym.
Dla kontrastu: 1 października 2026 roku Google wstrzymał przyjmowanie nowych zgłoszeń w swoim programie nagród za luki w oprogramowaniu open source, tłumacząc to zalewem automatycznych raportów, z których większość była nieprawidłowa. Opiekunowie open source dostają więc z jednej strony narzędzia obronne oparte na AI, a z drugiej spam zgłoszeń generowany przez te same technologie.
Anthropic zachęca organizacje do stosowania opisanej metodologii także bez tego konkretnego skilla i wskazuje kolejne możliwości, np. porównywanie logów runtime z konfiguracją, by wyłączyć nieużywane parsery, stare protokoły i panele administracyjne.
Źródła i metodologia
Artykuł powstał na podstawie analizy redakcji AIPORT.pl oraz dodatkowych źródeł, w tym publikacji badawczej Frontier Red Team Anthropic z dnia 20.10.2026, not wydawniczych OpenSSH dla wersji 10.4, 10.5 i 10.6 oraz omówień LWN.net i BetaNews.
Cytaty z publikacji Anthropic i z not wydawniczych projektu OpenSSH zostały zweryfikowane z oryginalnym anglojęzycznym materiałem źródłowym.
Komentarz redakcyjny i ocena kontekstu branżowego: Piotr Wolniewicz, Redaktor Naczelny AIPORT.pl.
Artykuł będzie aktualizowany w miarę pojawiania się nowych informacji na temat wykorzystania Claude do redukcji powierzchni ataku i programu OSS Scanner.
