Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
W projekcie Squid Proxy ujawniono podatność oznaczoną jako CVE-2026-47729, określaną nazwą „Squidbleed”. Jest to błąd typu heap over-read, który może prowadzić do wycieku fragmentów pamięci procesu proxy do innego użytkownika korzystającego z tego samego serwera pośredniczącego.
W praktyce oznacza to możliwość ujawnienia cudzych żądań HTTP przesyłanych jawnym tekstem, w tym nagłówków zawierających dane uwierzytelniające, tokeny sesyjne lub klucze API. Problem nie dotyczy klasycznego tunelowania HTTPS przez CONNECT w takim samym stopniu, ale staje się istotny tam, gdzie proxy analizuje odszyfrowany ruch lub wciąż obsługuje nieszyfrowane HTTP.
W skrócie
- Podatność Squidbleed została oznaczona jako CVE-2026-47729.
- Luka istnieje w kodzie Squid od 1997 roku.
- Źródłem problemu jest parser list katalogowych FTP.
- Atak może prowadzić do wycieku żądań HTTP, ciasteczek, tokenów i danych logowania.
- Warunkiem ataku jest współdzielenie tego samego proxy oraz możliwość skierowania go na kontrolowany serwer FTP.
- Najważniejsze działania obronne to aktualizacja Squid oraz wyłączenie obsługi FTP tam, gdzie nie jest potrzebna.
Kontekst / historia
Squid od wielu lat pozostaje jednym z najbardziej rozpoznawalnych serwerów proxy wykorzystywanych do buforowania, filtrowania i kontroli ruchu sieciowego. Jest często spotykany w środowiskach współdzielonych, takich jak szkoły, uczelnie, biura, sieci gościnne czy infrastruktura operatorów, co zwiększa praktyczne znaczenie tego typu podatności.
Źródłem problemu okazała się historyczna logika zgodności z serwerami NetWare FTP. Mechanizm odpowiedzialny za analizę listingów FTP miał pomijać nadmiarowe spacje przed nazwą pliku. Ta pozornie niegroźna logika przetrwała w kodzie niemal trzy dekady, aż do ujawnienia luki w czerwcu 2026 roku.
Analiza techniczna
Technicznie problem znajduje się w parserze list katalogowych FTP. Podczas przetwarzania odpowiedzi serwera wskaźnik przesuwany jest za pole znacznika czasu, a następnie kod próbuje pominąć białe znaki. Krytyczny błąd pojawia się wtedy, gdy po znaczniku czasu nie występuje nazwa pliku, a wskaźnik trafia na znak końca łańcucha.
W takiej sytuacji logika parsera może wyjść poza granice prawidłowego bufora i odczytać dane z pamięci, które nie należą do bieżąco przetwarzanej odpowiedzi. Następnie ten fragment może zostać zwrócony napastnikowi jako element wygenerowanej odpowiedzi HTML dla katalogu FTP.
Dodatkowym czynnikiem ryzyka jest sposób zarządzania pamięcią w Squid. Bufory są ponownie wykorzystywane bez pełnego zerowania, więc jeśli wcześniej przechowywały żądanie HTTP innego użytkownika, część tych danych może pozostać w pamięci. W efekcie atakujący może uzyskać dostęp do resztek wcześniejszych żądań, w tym do nagłówków uwierzytelniających.
Konsekwencje / ryzyko
Najpoważniejszym skutkiem podatności jest utrata poufności danych. Wyciek może objąć pełne lub częściowe żądania HTTP, a więc również nagłówki logowania, ciasteczka sesyjne, tokeny dostępu, identyfikatory API i inne informacje aplikacyjne przesyłane przez proxy.
Dla organizacji oznacza to ryzyko przejęcia sesji użytkowników, nadużycia poświadczeń, nieautoryzowanego dostępu do usług webowych oraz ekspozycji wrażliwych informacji biznesowych. Szczególnie zagrożone są środowiska wieloużytkownikowe, gdzie z jednego serwera pośredniczącego korzysta większa liczba osób.
Ryzyko jest jednak częściowo ograniczone przez model ataku. Nie jest to podatność dostępna w prosty sposób z internetu dla dowolnego napastnika. Wymaga ona dostępu do tego samego proxy co ofiara oraz możliwości wykorzystania kontrolowanego serwera FTP, ale w wielu wdrożeniach taka powierzchnia ataku nadal może istnieć.
Rekomendacje
Najważniejszym działaniem jest jak najszybsze wdrożenie poprawki bezpieczeństwa dostarczonej przez projekt Squid lub dystrybutora systemu. Warto przy tym sprawdzić nie tylko numer wersji, ale również obecność backportów bezpieczeństwa, ponieważ wiele dystrybucji Linuksa utrzymuje własne pakiety.
Drugim kluczowym krokiem jest wyłączenie obsługi FTP w Squid wszędzie tam, gdzie funkcja ta nie jest bezwzględnie wymagana. W nowoczesnych środowiskach korzystanie z FTP jest zazwyczaj marginalne, a jego dezaktywacja skutecznie usuwa opisywaną powierzchnię ataku.
- ograniczyć dostęp do proxy wyłącznie do autoryzowanych segmentów sieci i użytkowników,
- zweryfikować reguły ACL oraz listy dozwolonych portów i protokołów,
- zminimalizować ruch HTTP przesyłany jawnym tekstem,
- przeanalizować polityki terminowania TLS i zakres inspekcji ruchu,
- monitorować logi pod kątem nietypowych żądań FTP i anomalii w listowaniach katalogów,
- przeprowadzić rotację poświadczeń i tokenów, jeśli istnieje podejrzenie ich ujawnienia.
Podsumowanie
Squidbleed pokazuje, że nawet dojrzałe i szeroko wdrażane komponenty infrastrukturalne mogą przez lata zawierać trudne do wykrycia błędy pamięciowe. W tym przypadku połączenie subtelnej logiki parsera FTP i ponownego użycia niezerowanych buforów stworzyło realne ryzyko ujawnienia cudzych żądań HTTP.
Choć exploit wymaga określonych warunków i nie każde wdrożenie będzie jednakowo narażone, organizacje korzystające ze Squid powinny potraktować tę lukę priorytetowo. Aktualizacja oprogramowania, wyłączenie FTP i ograniczenie powierzchni ataku to podstawowe działania, które mogą znacząco obniżyć ryzyko incydentu.
Źródła
- https://thehackernews.com/2026/06/29-year-old-squid-proxy-bug-squidbleed.html
- https://blog.calif.io/p/squidbleed-cve-2026-47729
- https://www.suse.com/security/cve/CVE-2026-47729.html