Błąd parsera FTP z 1997 roku. Znalazł go Claude Mythos Preview w niemal sekundę — ten sam program Glasswing, którego trajektorię śledzimy od kwietnia.

W czerwcu firma Calif.io ujawniła Squidbleed (CVE-2026-47729) — błąd w serwerze proxy Squid, który pozwala odczytać cudze, niezaszyfrowane żądanie HTTP, razem z poświadczeniami i tokenami sesji, jakie ono niesie. Nazwa nawiązuje do Heartbleed, bo mechanizm jest ten sam: wyciek pamięci, której nikt nie wyczyścił. Błąd wywodzi się ze zmiany w parserze FTP z 1997 roku i przez 29 lat żył w domyślnej konfiguracji Squida, niezauważony.

Znalazł go Claude Mythos Preview — model stojący za Project Glasswing — i, jak pisze Calif.io, wychwycił dziwactwo w wywołaniu strchr niemal natychmiast.

Dla cyberflux to jest moment, który domyka dwa wątki naraz. Po pierwsze — to jest pierwszy publiczny, nazwany CVE, który możemy bezpośrednio przypisać modelowi klasy Mythos, czyli materializacja całej trajektorii Glasswing, którą śledzimy od kwietnia. Po drugie — to kolejny prastary błąd znaleziony przez AI, dokładnie ten wzorzec, który opisujemy od miesięcy.

Jak działa wyciek

Squid to serwer proxy — pośredniczy w ruchu sieciowym między użytkownikami a internetem, często w sieciach współdzielonych: szkołach, biurach, publicznym WiFi. To jest istotne dla modelu zagrożenia, do którego wrócimy.

Błąd siedzi w parserze listingu katalogów FTP. Kod miał obsłużyć stare serwery NetWare, które dopełniały listingi dodatkowymi spacjami, więc pomija białe znaki pętlą przeskakującą kolejne znaki odstępu. Problem pojawia się, gdy serwer FTP kontrolowany przez atakującego wyśle linię listingu, która kończy się tuż po znaczniku czasu, bez nazwy pliku. Wskaźnik ląduje wtedy na terminatorze NUL kończącym napis — a funkcja strchr traktuje ten NUL jako część przeszukiwanego napisu i zamiast zatrzymać pętlę, zwraca wskaźnik. Pętla nigdy się nie kończy, wychodzi poza bufor, a kopiowanie zwraca atakującemu jako „nazwę pliku" to, co znajdowało się w pamięci za buforem.

I tu jest sedno wycieku. Squid ponownie używa zwolnionych buforów pamięci, nie zerując ich. Bufor o rozmiarze 4 KB, który przed chwilą zawierał żądanie HTTP ofiary, wciąż trzyma jego większość. Krótka linia FTP nadpisuje tylko pierwsze kilka bajtów; nadczytanie zwraca resztę. Demonstracja Calif.io wyciąga w ten sposób nagłówek Authorizationofiary korzystającej z tego samego proxy — co wystarcza, by działać jako ten użytkownik.

To jest mechanicznie ta sama klasa, co dwuletni use-after-free w Redisie — pamięć, której nie wyczyszczono, zwracana komuś, kto nie powinien jej zobaczyć. Różnica jest w wieku błędu: tu są to 29 lat.

Model zagrożenia — wąski, ale realny

Warto być precyzyjnym co do tego, kto i w jakich warunkach może ten błąd wykorzystać, bo to definiuje ryzyko.

Squid opisuje to jako atak „zaufanego klienta" — kogoś, kto już ma prawo korzystać z proxy, nie dowolnego hosta z internetu. To pasuje do typowego środowiska Squida: sieci współdzielone, gdzie atakujący jest po prostu kolejnym użytkownikiem tego samego proxy. Wyciek dosięga tylko ruchu, który Squid może odczytać — normalny HTTPS jedzie przez nieprzejrzysty tunel CONNECT, więc Squid nie widzi jego wnętrza. Narażony jest niezaszyfrowany ruch HTTP oraz konfiguracje, w których Squid terminuje TLS i inspekcjonuje treść. Atakujący potrzebuje też, by proxy mogło połączyć się z jego serwerem FTP na porcie 21 — a FTP i ten port są domyślnie włączone.

To zawęża zagrożenie, ale go nie eliminuje. W szkole, biurze czy na publicznym WiFi „zaufany klient" to dosłownie każdy, kto korzysta z tej samej sieci. SUSE ocenia błąd jako umiarkowany, CVSS 6.5 — wektor wymaga dostępu do proxy (niskie uprawnienia), a jedynym skutkiem jest naruszenie poufności, nic po stronie integralności czy dostępności. Ryzyko jest realne, ale ograniczone. Kod proof-of-concept jest publiczny; w momencie publikacji nie zgłoszono eksploatacji w praktyce.

Sednem: 29-letni błąd i model, który znalazł go w sekundę

Tu jest powód, dla którego ten błąd zasługuje na miejsce w cyberflux obok znacznie groźniejszych technicznie podatności.

Calif.io przypisuje odkrycie Claude Mythos Preview — modelowi stojącemu za Project Glasswing — który wychwycił dziwactwo strchr niemal natychmiast. To jest ten sam rodzaj zakopanego błędu w parserze, który agenty AI ujawniają w innych miejscach, w tym we FFmpeg. Calif.io sugeruje wprost, że kod FTP Squida może nie być ostatnim miejscem, w którym ten model „zapomniał przestać czytać".

Cofnijmy się do trajektorii, którą prowadzimy od wiosny. W kwietniu Mythos Preview trafił do 50 organizacji w ramach Glasswing. W maju Glasswing znalazł ponad 10 000 podatności. 2 czerwca rozszerzył się do 200 organizacji. 9 czerwca pochodny model Fable 5 trafił do publicznego użytku. Przez cały ten czas mówiliśmy o liczbach i programach — „10 000 podatności", „50 organizacji", „dostęp dla wszystkich". Squidbleed jest pierwszym przypadkiem, gdy zamiast liczby zbiorczej mamy konkretny, nazwany CVE z konkretnym mechanizmem, który możemy bezpośrednio prześledzić do modelu Mythos.

To jest różnica między „program znalazł tysiące błędów" a „oto jeden z nich, oto jak działa, oto skąd się wziął". Squidbleed nadaje całej abstrakcyjnej trajektorii Glasswing konkretny, techniczny kształt — błąd parsera FTP starszy niż większość dzisiejszych inżynierów bezpieczeństwa, przeoczony przez 29 lat ludzkich przeglądów, znaleziony przez model w czasie liczonym w sekundach.

I jest w tym ta sama dwoistość, którą opisujemy od maja. Z jednej strony to triumf strony obrony — Calif.io użyło modelu do znalezienia i odpowiedzialnego ujawnienia błędu, zanim zrobił to ktokolwiek o złych intencjach. Z drugiej — ten sam rodzaj zdolności jest teraz, po publicznym wydaniu Fable 5, dostępny znacznie szerzej. To, co dziś znajduje obrońca z modelem Mythos, jutro może znaleźć ktoś inny z modelem klasy Fable na kodzie, który uważamy za sprawdzony. Wyciek pamięci w 29-letnim parserze FTP jest dowodem, że „sprawdzony przez dekady" nie znaczy „przeskanowany przez AI".

Disclosure i zamieszanie z wersjami

Proces ujawnienia był odpowiedzialny — Calif.io zgłosiło błąd, opublikowało analizę i PoC po skoordynowaniu, bez eksploatacji w praktyce. Ale publiczny wątek wokół łatki jest, delikatnie mówiąc, niespójny, i warto to odnotować, bo ma praktyczne znaczenie.

Maintainer Squida Amos Jeffries najpierw powiedział, że poprawkę niesie Squid 7.6, potem skorygował to na 7.7, a 22 czerwca Salvatore Bonaccorso z Debiana zauważył, że wskazany commit wygląda, jakby był już w 7.6. Sama poprawka jest niewielka — sprawdzenie terminatora NUL przed feralnymi wywołaniami strchr, scalone do gałęzi rozwojowej w kwietniu i do v7 w maju.

Praktyczny wniosek: jeśli łatasz, weryfikuj samą poprawkę, nie tylko numer wersji. Potwierdź, że zabezpieczenie jest w pliku FtpGateway.cc, albo sprawdź backport swojej dystrybucji — bo dystrybucje budują własne wersje (Debian pakuje Squida 5.7). To jest dokładnie ta lekcja, którą opisywaliśmy przy łataniu według numerów CVE — numer wersji bywa zawodnym sygnałem, liczy się obecność konkretnej poprawki w kodzie.

Co zrobić

Najprostszy i najczystszy ruch to wyłączyć FTP. To rekomendacja samych badaczy: Chromium porzucił FTP lata temu, większość sieci przenosi go znikomo, więc wyłączenie usuwa tę powierzchnię ataku za darmo, niezależnie od wersji, którą prowadzisz. Skoro atak wymaga, by proxy łączyło się z serwerem FTP atakującego na porcie 21, odcięcie FTP eliminuje wektor u źródła.

Jeśli łatasz — zweryfikuj obecność poprawki w FtpGateway.cc, nie ufaj samemu numerowi wersji ze względu na zamieszanie w komunikacji maintainerów. Sprawdź backport swojej dystrybucji osobno.

Ogranicz, kto może korzystać z proxy. Skoro to atak „zaufanego klienta", zawężenie kręgu użytkowników proxy i segmentacja sieci zmniejszają liczbę potencjalnych atakujących. W środowiskach współdzielonych jak publiczne WiFi to jest trudniejsze — tym ważniejsze jest wyłączenie FTP.

Pamiętaj, że HTTPS przez CONNECT jest bezpieczny, ale ruch HTTP i konfiguracje z terminacją TLS — nie. Jeśli Squid deszyfruje i inspekcjonuje ruch, ten ruch jest w zasięgu wycieku. To jest argument za minimalizacją inspekcji TLS tam, gdzie nie jest niezbędna.

Źródła

Calif.io — oryginalna analiza Squidbleed z mechanizmem, demonstracją i przypisaniem odkrycia Claude Mythos Preview: https://blog.calif.io/p/squidbleed-cve-2026-47729

The Hacker News — omówienie z kontekstem Project Glasswing i szczegółami zamieszania wokół wersji: https://thehackernews.com/2026/06/29-year-old-squid-proxy-bug-squidbleed.html

Squid / oss-sec — wątek dyskusyjny o modelu zagrożenia „trusted client" i statusie łatek: https://seclists.org/oss-sec/2026/q2/896

SUSE — ocena CVE-2026-47729 jako umiarkowanej, CVSS 6.5: https://www.suse.com/security/cve/CVE-2026-47729.html

GitHub (squid-cache) — commit z poprawką (sprawdzenie terminatora NUL przed wywołaniami strchr): https://github.com/squid-cache/squid/commit/865a131c7d557e68c965043d98c2eccae26deef8