Publiczny diff zawęża agentowi poszukiwanie luki, ale nie dowodzi ataku

Publiczne udostępnienie poprawki bezpieczeństwa pomaga obrońcom, ale jednocześnie wskazuje klasę błędu i fragment kodu, który warto zaatakować. Przypadek biblioteki cohttp pokazuje ten konflikt czasowy. Nie pozwala jednak stwierdzić, że sondy zauważone po publikacji poprawki wygenerował agent AI: publiczne są kod, komunikat bezpieczeństwa i relacja opiekuna projektu, ale nie surowe logi ani dane o wykonawcy żądań.

Publiczny diff skraca czas na reakcję, ale nie identyfikuje wykonawcy sond

Co się wydarzyło

11 sierpnia 2026 r. do zespołu bezpieczeństwa OCaml trafiło prywatne zgłoszenie błędu przejścia poza katalog dokumentów w Cohttp.Path.resolve_local_file. 14 sierpnia o 11:16 UTC Anil Madhavapeddy otworzył publiczny pull request #1145, a 20 sierpnia poprawka została scalona i wydana w cohttp 6.3.0. Podatność otrzymała identyfikator OSEC-2026-16. Advisory OSV z osią czasu, pull request z poprawką

Błąd wynikał z kolejności operacji. Biblioteka najpierw usuwała segmenty . i .., a dopiero potem dekodowała zapis procentowy. Separator / zakodowany jako %2f przechodził więc przez normalizację jako część zwykłego segmentu, po czym dekodowanie tworzyło ścieżkę w rodzaju ../../../etc/passwd. Wydanie 6.3.0 dekoduje ścieżkę dokładnie raz przed usunięciem segmentów nadrzędnych; wersje wcześniejsze niż 6.3.0 są oznaczone jako podatne. Opis mechanizmu i zakres wersji, ogłoszenie wydania 6.3.0

Madhavapeddy, współautor poprawki i opiekun projektu OCaml, podał 22 sierpnia, że około dziesięciu minut po otwarciu publicznego PR jego serwer otrzymał żądania z zakodowanymi procentowo sekwencjami przejścia po katalogach. Opisał też własny test: po wskazaniu klasy problemu agent oparty na DeepSeek V4 Pro miał znaleźć powiązane błędy i w czasie krótszym niż minuta utworzyć lokalny PoC. To relacja osoby bezpośrednio zaangażowanej w incydent, a nie niezależna reprodukcja. Nie opublikowano logów serwera, transkryptu agenta, dokładnego identyfikatora wersji modelu ani liczby prób. Relacja opiekuna projektu i opis testu

Co potwierdzają źródła

Kod PR potwierdza, że publiczny diff ujawniał zarówno podatną funkcję, jak i wzorzec ..%2f..%2f. Zmiana obejmowała 13 plików, dodawała testy dla zakodowanego separatora i funkcję Cohttp.Path.normalise. Sam diff wystarcza więc do zrekonstruowania klasy wejścia potrzebnego do PoC. Nie potwierdza natomiast, kto wysłał późniejsze sondy ani jakich narzędzi użył. Zmiany i testy w PR #1145

Dane zbiorcze nie uzasadniają prostego wniosku, że luki wykryte z pomocą AI są częściej wykorzystywane. VulnCheck przeanalizował 495 podatności z potwierdzoną eksploatacją w pierwszej połowie 2026 r. Dla 23,43% z nich dowody eksploatacji pojawiły się najpóźniej w dniu publikacji CVE, a mediana czasu od publikacji CVE do potwierdzenia statusu KEV spadła ze 120 dni w 2025 r. do 80 dni. W osobnym połączeniu dwóch rejestrów luk przypisanych narzędziom AI z bazą VulnCheck 14 z 1061 pozycji, czyli 1,3%, miało potwierdzoną eksploatację — odsetek zbliżony do wszystkich podatności z pierwszej połowy roku. Autor zaznacza, że kohorta jest młoda i późniejsze dowody mogą zmienić wynik. VulnCheck sprzedaje dane o zagrożeniach i część detekcji pochodzi z własnych systemów, więc pełna reprodukcja zestawu nie jest możliwa z samego artykułu. Analiza VulnCheck za pierwszą połowę 2026 r.

Mandiant, należący do Google, oszacował na podstawie dochodzeń z 2025 r. średni czas do wykorzystania podatności na minus siedem dni; według autorów oznacza to eksploatację jeszcze przed wydaniem poprawki. Ten pomiar obejmuje jednak cały badany krajobraz podatności, a nie luki znalezione przez AI. Ten sam raport stwierdza, że w danych Mandiant za 2025 r. nie widać jeszcze, by większość udanych włamań wynikała bezpośrednio z użycia AI. M-Trends 2026 — metodyka i wyniki

Analiza ekonomiki obsługi podatności wskazuje dodatkowy mechanizm: modele obniżają koszt generowania kandydatów, PoC i raportów szybciej niż rośnie zdolność opiekunów projektów do walidacji, przeglądu poprawek i wydawania wersji. Autorzy opierają ten wniosek na publicznych danych o programach zgłoszeń i incydentach; nie mierzą bezpośrednio przypadku cohttp. Analiza kosztów walidacji i wydawania poprawek

Co mówi dyskusja

Najmocniejsza relacja operacyjna w wątku Hacker News pochodzi od Nicka Craig-Wooda, opiekuna projektu rclone. Podał on, że przez pierwsze dziesięć lat projekt otrzymał około 20 zgłoszeń bezpieczeństwa przez GitHub, a w ostatnim miesiącu ponad 40; według jego oceny około 75% wymagało sprawdzenia jakiegoś rzeczywistego problemu. Napisał też, że przydział identyfikatora CVE wydłużył się u niego z 2–3 dni do 3–4 tygodni. To doświadczenie osoby utrzymującej konkretny projekt, ale bez opublikowanego zbioru zgłoszeń i bez podstawy do uogólnienia na cały ekosystem. Komentarz opiekuna projektu rclone

Drugi argument rozdziela nową skalę od starej techniki. Jeden z uczestników zauważa, że odtwarzanie exploita z patcha, komunikatu commita lub krótkiej wskazówki istniało przed LLM. Jego zdaniem modele zmniejszają koszt i wymagany poziom wiedzy, ale nie tworzą nowej kategorii ataku. To spójna interpretacja mechanizmu, nie pomiar częstości ani dowód udziału AI w sondach cohttp. Argument o patch diffingu i zmianie kosztu

Trzeci argument dotyczy wdrożenia: nawet jeśli opiekun projektu przygotuje poprawkę w kilka minut, użytkownik musi ją jeszcze otrzymać, zweryfikować i zainstalować. Natychmiastowe automatyczne aktualizacje zmniejszają okno dla znanej luki, ale zwiększają ryzyko przyjęcia przejętej aktualizacji łańcucha dostaw. Dyskusja nie rozstrzyga tego kompromisu; pokazuje, że szybkość generowania poprawki nie jest równa szybkości usunięcia podatności z wdrożeń. Dyskusja o czasie wdrożenia i ryzyku łańcucha dostaw

Wątek jest samowybraną dyskusją publiczną. Część komentarzy opisuje własne narzędzia lub doświadczenia, ale nie podaje metod ani danych. Nie można z niego wyprowadzać częstości automatycznych ataków ani konsensusu branży.

Wnioski

Fakt — pewność wysoka: OSEC-2026-16 umożliwiał przejście poza katalog dokumentów przez zakodowane separatory ścieżki; publiczny PR z 14 sierpnia zawierał wzorzec wejścia, testy i poprawkę, a wersja 6.3.0 z 20 sierpnia usuwa podatność.
Wniosek — pewność wysoka: publiczny diff bezpieczeństwa może pełnić rolę precyzyjnej wskazówki dla człowieka lub agenta, ponieważ ogranicza poszukiwanie do konkretnej funkcji, kolejności operacji i klasy wejścia. Nie wynika z tego, że każdy obserwowany skan używa AI.
Wniosek — pewność średnia: agenci prawdopodobnie zwiększają liczbę podmiotów zdolnych szybko przejść od wskazówki do PoC, lecz przypadek cohttp nie mierzy tego efektu. Pewność nie jest wysoka, bo brakuje surowych logów, powtarzalnego eksperymentu i porównania z klasycznymi skanerami.
Scenariusz — pewność średnia: projekty open source będą częściej łączyć prywatne przygotowanie poprawek z krótkim cyklem wydawniczym i tymczasowymi regułami blokującymi wzorzec ataku. Nie wiadomo, czy mniejsze projekty mają CI, kanały dystrybucji i czas opiekunów potrzebne do takiego procesu.

Czego jeszcze nie wiemy

Czy żądania odnotowane po publikacji PR były skierowane konkretnie przeciwko cohttp, czy stanowiły typowy szum skanerów sprawdzających popularne warianty path traversal.
Jakie adresy źródłowe, nagłówki, sekwencje żądań i odstępy czasowe zawierały logi serwera; bez nich nie można ocenić automatyzacji ani powiązać sond z obserwacją repozytorium.
Jakiej dokładnie wersji DeepSeek V4 Pro, promptu, zestawu narzędzi i limitów użyto w teście opiekuna projektu oraz ile było prób nieudanych.
Ile publicznie dostępnych wdrożeń używało podatnych wywołań cohttp i jak szybko przeszły na wersję 6.3.0.
Czy odsetek eksploatowanych luk przypisanych odkryciu przez AI wzrośnie po dojrzewaniu kohorty z pierwszej połowy 2026 r.
Czy wzrost liczby zgłoszeń opisany przez opiekuna projektu rclone występuje także w innych projektach oraz jaka część raportów została wygenerowana automatycznie.

Źródła

Źródła pierwotne

Niezależne analizy i relacje

Dyskusje publiczne

Wykorzystuję treści generowane przez AI jako część mojego codziennego procesu nauki.