CVE-2026-24061: błąd w telnetd, który daje roota w „bezpiecznej” sieci
·Gdy „wszystko jest załatane”, a i tak kończy się rootem
Niejeden program bezpieczeństwa wygląda na papierze bez zarzutu.
- Utwardzony perymetr.
- Rotowane hasła.
- Zaktualizowane narzędzia.
- Skanery podatności na zielono.
- Spisane polityki bezpieczeństwa.
A wystarczy jedna przeoczona usługa albo jeden nieoczekiwany błąd w zaufanym komponencie, żeby to wszystko straciło znaczenie w kilka sekund.
I dokładnie dlatego CVE-2026-24061 ma znaczenie.
Podatność w Telnecie przypomina o czymś prostym: „bezpieczny” nie znaczy „niemożliwy do przejęcia”. Znaczy „trudniejszy do przejęcia”. A atakujący idą najkrótszą drogą.
Czym jest CVE-2026-24061
CVE-2026-24061 to krytyczne obejście uwierzytelniania w GNU InetUtils telnetd. Dotyczy wersji od 1.9.3 do 2.7 i ma ocenę CVSS 9,8.
W skrócie: demon Telnetu przekazuje kontrolowaną przez atakującego wartość USER do systemowego procesu logowania bez poprawnego oczyszczenia danych. Otwiera to drogę do wstrzyknięcia argumentów (ang. argument injection), obejścia uwierzytelniania i uzyskania uprawnień roota.
Podatność ujawnił publicznie w komunikacie bezpieczeństwa Simon Josefsson, kontrybutor GNU. Znalazł ją i odpowiedzialnie zgłosił Kyu Neushwaistein (Carlos Cortes Alvarez).
Jest gorzej: badacze zaobserwowali realną aktywność atakujących krótko po publikacji, a raporty mówią o dużej liczbie usług Telnet wystawionych do internetu na całym świecie.
Dlaczego wygląda to jak „backdoor” (choć nim nie jest)
Nikt nie podłożył tu celowo backdoora. To zwykły błąd.
Tyle że z perspektywy atakującego efekt jest ten sam: droga do roota, która omija zabezpieczenia uznane za wystarczające.
Stąd niewygodny wniosek. Nawet w pełni legalne, powszechnie używane i świeżo zaktualizowane oprogramowanie może zawierać pomyłkę, która otwiera drzwi, o jakich nikt nie wiedział.
Nie wiemy też, ile podobnych luk wykorzystują codziennie grupy przestępcze i sponsorowane przez państwa grupy APT – bez żadnego publicznego ujawnienia.
Scenariusz „bezpiecznego klienta”, który i tak się sypie
Wyobraź sobie klienta, u którego działa:
- Dobrze zaprojektowana, posegmentowana sieć.
- Silne zabezpieczenia perymetru i utwardzone usługi wystawione do internetu.
- Regularne aktualizacje i nowoczesna ochrona stacji końcowych.
- Bezpieczny cykl życia haseł i MFA.
- Aktualne oprogramowanie na serwerach i urządzeniach sieciowych.
Do tego jeden szczegół, który w praktyce spotykamy notorycznie.
Gdzieś nadal działa stara usługa zarządzania. Na wysłużonym urządzeniu, na wbudowanym Linuksie, w segmencie laboratoryjnym, w sieci OT albo jako „tymczasowa” administracyjna furtka, której nikt nie usunął. Telnet jest tu klasykiem, bo wciąż znajdujemy go tam, gdzie wszyscy o nim dawno zapomnieli.
Wystarczy, że atakujący zdobędzie jakikolwiek przyczółek – wykradzione dane logowania, przejęty endpoint VPN, stację po phishingu, naruszenie u dostawcy – i perymetr przestaje być głównym problemem.
Wewnątrz sieci zapomniana usługa Telnet plus podatność taka jak CVE-2026-24061 to najkrótsza droga do eskalacji uprawnień i ruchu bocznego (ang. lateral movement).
Po co testy w modelu assumed breach
Klasyczny test penetracyjny często odpowiada na pytanie „czy da się wejść”.
Assumed breach odwraca je: zakładamy, że atakujący już jest w sieci, i sprawdzamy, co potrafi zrobić dalej.
Ta różnica ma znaczenie, bo perymetr rzadko zatrzymuje atak na zawsze. Atakujący próbują wielu dróg – między innymi przez dostawców i przez ataki na tożsamość – aż któraś zadziała.
Test w modelu assumed breach weryfikuje to, czego nie pokaże żaden dashboard z aktualizacjami:
- Czy atakujący przejdzie między sieciami VLAN a segmentami.
- Czy dotrze do płaszczyzny zarządzania i usług administracyjnych.
- Czy podniesie uprawnienia do poziomu domeny albo roota.
- Czy wyprowadzi dane niezauważony.
- Czy SOC zobaczy jego ścieżkę na tyle wcześnie, żeby zareagować.
CVE-2026-24061 to modelowy materiał na taki test, bo pokazuje, jak jedna usługa zamienia dostęp wewnątrz sieci w pełną kontrolę.
Co firmy powinny zrobić teraz
Kilka kroków, które realnie zmniejszają ryzyko związane z Telnetem i podobnymi „nieoczekiwanymi drzwiami do roota”:
- Wyłącz Telnet wszędzie, gdzie się da: zastąp go SSH albo nowoczesnym kanałem zarządzania. Jeśli Telnet musi zostać, odizoluj go bezwzględnie.
- Znajdź to, o czym wszyscy zapomnieli: prowadź inwentaryzację zasobów obejmującą usługi i nasłuchujące porty. Sprawdzaj na bieżąco, czy port 23 i inne stare porty administracyjne nie wracają przy odbudowie systemów, w obrazach od dostawcy albo przy zmianach awaryjnych.
- Łataj szybko, ale przygotuj wariant „poprawki jeszcze nie ma”: dla CVE-2026-24061 poprawki są dostępne w upstreamie, a załatane wydania wskazuje kilka komunikatów bezpieczeństwa. Wiele środowisk i tak nie zaktualizuje się z dnia na dzień. Muszą więc istnieć środki zaradcze: wyłączenie usługi, ograniczenie dostępu do wybranych adresów IP, reguła na firewallu, blokada na styku sieci.
- Traktuj dostęp administracyjny jak dane produkcyjne: interfejsy zarządzania schowaj za jump hostami, wymuś MFA i ogranicz krąg osób, które mają do nich jakąkolwiek trasę sieciową. Sieć wewnętrzną z założenia traktuj jako wrogą.
- Zbuduj detekcję dla starych protokołów: ustaw alerty na użycie Telnetu, na nieoczekiwane logowania na roota i na nietypowy przebieg uwierzytelniania. Załóż, że ktoś kiedyś znajdzie zapomnianą usługę.
Jak pomaga Haxoris
Jeśli ten wniosek ma się przełożyć na mierzalną poprawę bezpieczeństwa, oto co robimy:
- Testy penetracyjne infrastruktury w modelu assumed breach.
- Testy bezpieczeństwa sieci wewnętrznej i Active Directory.
- Testy zewnętrznej powierzchni ataku i perymetru.
- Ćwiczenia Purple Team.
- Przeglądy utwardzenia konfiguracji (ang. hardening).
Na koniec
CVE-2026-24061 nie jest wyłącznie historią o Telnecie.
To historia o widoczności. O testowaniu. O pokorze.
Bo w bezpieczeństwie infrastruktury obowiązuje niewygodna prawda: można zrobić wiele rzeczy dobrze i przegrać przez jeden przeoczony szczegół.
Kto zakłada, że włamanie już nastąpiło, i testuje jak atakujący, znajduje takie szczegóły pierwszy.
