Co Squidbleed naprawde ujawnia

Squidbleed, oznaczony jako CVE-2026-47729, to nadmiarowy odczyt bufora sterty w parserze listingów katalogów FTP w Squidzie, jednym z najszerzej wdrożonych proxy webowych w internecie. Gdy Squid renderuje listing FTP, w którym brakuje nazwy pliku, pętla pomijająca białe znaki idzie o krok za daleko i czyta pamięć poza przewidzianym buforem. Ponieważ Squid ponownie wykorzystuje zwolnioną pamięć między żądaniami, te zabłąkane bajty to często fragmenty ruchu innych użytkowników: żądania HTTP w postaci jawnej z hasłami, ciasteczkami, tokenami sesji i kluczami API.

Narażenie jest węższe niż przy Heartbleed, ale realne. Napastnik musi być uprawnionym użytkownikiem współdzielonego proxy i musi kontrolować serwer FTP, który proxy może osiągnąć na porcie 21, co kieruje ryzyko na osoby wewnętrzne i na każdą konfigurację, w której proxy terminuje TLS. Ruch HTTPS przekazywany jako nieprzejrzysty tunel pozostaje zapieczętowany, więc na szali są strumienie HTTP w postaci jawnej i te terminowane w TLS, które wciąż codziennie przechodzą przez firmowe proxy.

Jedna linia, dwadziescia dziewiec lat i AI, ktora to znalazla

Przyczyna źródłowa jest niemal banalna. Kod wywoływał strchr na łańcuchu, który mógł być pusty, a standard C mówi, że strchr traktuje kończący bajt null jako część łańcucha, więc sprawdzenie, które miało się zatrzymać na końcu wejścia, po cichu poszło dalej. Winny wzorzec sięga commita Squida ze stycznia 1997 roku, co oznacza, że błąd trafiał do domyślnych konfiguracji, port 21 znajduje się na domyślnej liście Safe_ports, przez dwadzieścia dziewięć lat, przez niezliczone wydania, przepisania i przeglądy bezpieczeństwa. Poprawka to jeden dodany warunek, sprawdzenie wartości null przed strchr, albo całkowite wyłączenie FTP, które Chromium porzuciło lata temu i na którym prawie żadna sieć już się nie opiera.

Szczegół, który powinien przykuć uwagę operatora, to kto go znalazł. Dwaj badacze zgłosili go niezależnie, Pavel Kohout z Aisle Research w marcu 2026 roku i Lam Jun Rong z Calif.io w kwietniu, a opiekunowie scalili poprawkę w ciągu kilku dni, publiczny komunikat ukazał się 23 czerwca. Ale pierwotne odkrycie pochodziło od agenta AI, którego zadaniem było przejść maszynę stanów FTP, a nie od kolejnego audytu człowieka. Wygodne założenie, że stary, mocno przejrzany kod jest bezpieczny z racji swojego wieku, właśnie oblało bardzo publiczny test, a narzędzie, które je złamało, jest teraz tanie i szeroko dostępne.

Co operator powinien zrobic w tym tygodniu

Konkretny krok jest niewielki: zinwentaryzuj każdą instancję Squida, którą prowadzisz, załataj do naprawionego wydania, a jeśli nie potrzebujesz świadomie proxy FTP, wyłącz je i usuń port 21 z Safe_ports. Priorytetowo potraktuj każde proxy, które terminuje TLS lub przenosi HTTP w postaci jawnej dla wielu użytkowników, bo to tam poświadczenia kolegów mogą przeciekać między sobą. W Polsce NASK i zespoły CSIRT traktują ujawnienie poświadczeń na współdzielonej infrastrukturze jako incydent podlegający zgłoszeniu, a w całej UE ustawa o krajowym systemie cyberbezpieczeństwa, wdrażająca NIS2, kładzie odpowiedzialność za znaną, niezałataną lukę na wyznaczonym kierownictwie, nie tylko na zespole bezpieczeństwa.

Większy ruch to przestać traktować wiek zależności jako dowód jej bezpieczeństwa. Błąd w jednej linii krył się dwadzieścia dziewięć lat w oprogramowaniu, któremu tysiące organizacji ufały właśnie dlatego, że było dojrzałe, a recenzent AI znalazł go w jednym przejściu. Spodziewaj się, że więcej takich uśpionych błędów wypłynie w twoich najstarszych i najbardziej zaufanych komponentach, i zaplanuj w budżecie stały strumień małych, nieefektownych łatek zamiast jednej dramatycznej.

Czytaj dalej: Dwie luki w Cursorze z oceną 9.8 oddają maszynę programisty w ręce atakujących  |  Jeden wyciek u dostawcy odpowiadał za połowę europejskich ofiar ransomware