CVE-2026-41940 to krytyczna podatność w cPanel & WHM, obejmująca także DNSOnly, która pozwalała niezalogowanemu atakującemu zdalnie ominąć uwierzytelnienie i uzyskać nieautoryzowany dostęp do panelu. NVD opisuje ją jako authentication bypass w login flow, a oficjalny advisory cPanel potwierdza, że problem dotyczył oprogramowania cPanel, w tym DNSOnly, dla wersji po 11.40.
To nie była drobna usterka „gdzieś na zapleczu”. To była luka, która uderzała w samą warstwę zarządzania serwerem. Rapid7 ocenił ją na CVSS 9.8, a Censys oraz CSA Singapore wskazały, że exploitacja zaczęła się bardzo szybko po ujawnieniu i była obserwowana aktywnie w sieci.
Co to jest CVE-2026-41940
CVE-2026-41940 to podatność typu pre-authentication bypass, czyli luka pozwalająca obejść logowanie przed prawidłowym uwierzytelnieniem użytkownika. NVD wskazuje, że dotyczyła wersji cPanel i WHM po 11.40, a cPanel opublikował poprawki dla konkretnych gałęzi wydań, m.in. 11.86, 11.94, 11.102, 11.110, 11.118, 11.124, 11.126, 11.130, 11.132, 11.134 i 11.136.
W praktyce oznaczało to, że atakujący nie musiał znać hasła, nie musiał przechodzić normalnego procesu logowania i nie potrzebował wcześniejszego konta w systemie. Jeśli panel zarządzania był wystawiony do internetu i działał na podatnej wersji, system był zagrożony z definicji. Rapid7 ujął to wprost: systemy wystawiające podatne usługi webowe były vulnerable by default.
Czego dotyczyła ta luka
Podatność dotyczyła mechanizmu logowania i ładowania sesji w cPanel/WHM. Z technicznego punktu widzenia była powiązana z CRLF injection w procesie tworzenia i odczytu sesji. Rapid7 opisał, że demon cpsrvd zapisuje plik sesji jeszcze przed pełnym uwierzytelnieniem, a błąd pozwalał zmanipulować cookie whostmgrsession, ominąć oczekiwane przetwarzanie fragmentu danych i wstrzyknąć surowe znaki \r\n, które finalnie trafiały do pliku sesji bez właściwej sanityzacji.
W rezultacie atakujący mógł dopisać do swojej sesji arbitralne właściwości, np. user=root, a następnie doprowadzić do ponownego załadowania tej sesji z pliku. To przekładało się na uzyskanie administracyjnego dostępu do WHM, a więc de facto do całego hosta i zasobów, którymi zarządzał.
Co powodowała podatność
Skutek był bardzo poważny: przejęcie panelu administracyjnego oznaczało możliwość zarządzania serwerem hostingowym, kontami, stronami, bazami danych i konfiguracją. Rapid7 wskazuje, że skuteczne wykorzystanie CVE-2026-41940 dawało kontrolę nad hostem cPanel, jego konfiguracją, bazami danych i stronami, którymi zarządzał.
To tłumaczy, dlaczego luka tak szybko została uznana za krytyczną. Censys zaobserwował po ujawnieniu gwałtowny wzrost złośliwej aktywności na hostach z cPanel/WHM i wskazał co najmniej dwa aktywne scenariusze po przejęciu: wdrażanie wariantów Mirai oraz kampanię ransomware szyfrującą pliki z rozszerzeniem .sorry.
Czy mogło to dotyczyć DNSOnly
Tak. To jest bardzo ważny szczegół. Oficjalne advisory cPanel mówi wprost, że problem dotyczył oprogramowania cPanel including DNSOnly. Czyli jeżeli ktoś miał serwery DNSOnly wystawione publicznie i działające na podatnych buildach, one również wchodziły w zakres ryzyka tej luki.
To nie oznacza automatycznie, że każdy incydent na serwerze DNSOnly był skutkiem właśnie CVE-2026-41940. Oznacza jednak, że technicznie był to bardzo wiarygodny kandydat dla kompromitacji zdalnej, szczególnie jeśli objawy pojawiły się w czasie aktywnej kampanii i na serwerze działała podatna wersja. To jest już wniosek analityczny oparty na zbieżności: oficjalnie wiadomo, że DNSOnly było objęte zakresem luki, a exploitacja była aktywna na dużą skalę.
Jakie wersje były poprawione
Według cPanel poprawione były co najmniej następujące wersje i nowsze: 11.86.0.41, 11.94.0.28, 11.102.0.39, 11.110.0.97, 11.118.0.63, 11.124.0.35, 11.126.0.54, 11.130.0.19, 11.132.0.29, 11.134.0.20, 11.136.0.5, a dla WP Squared: 136.1.7. cPanel zaznaczył też, że wszystkie dalsze wersje tych gałęzi są już załatane.
Dla środowisk legacy pojawiły się też szczególne instrukcje, np. dla CentOS 6 / CloudLinux 6 na 110.0.50 wskazano build 11.110.0.103 jako ścieżkę aktualizacji. To pokazuje, że starsze środowiska były dodatkowym problemem operacyjnym i wymagały ręcznych działań, zamiast liczenia na „samo się zaktualizuje”.
Co należało zrobić od razu
Oficjalna ścieżka była bardzo jasna: natychmiast zaktualizować serwer do poprawionej wersji przez /scripts/upcp --force, potem zweryfikować build komendą /usr/local/cpanel/cpanel -V i zrestartować cpsrvd poleceniem /scripts/restartsrv_cpsrvd --hard. cPanel ostrzegał też, że jeśli aktualizacje były wyłączone albo wersja była przypięta na sztywno, takie hosty trzeba było zidentyfikować i poprawić ręcznie.
Jeżeli ktoś nie mógł wykonać aktualizacji od razu, cPanel zalecał mitigacje tymczasowe: zablokowanie ruchu przychodzącego na portach 2083, 2087, 2095 i 2096, wyłączenie Service Subdomains, albo wręcz zatrzymanie usług cpsrvd i cpdavd. To były działania awaryjne, nie docelowe. Vendor wyraźnie stawiał na patching jako właściwe rozwiązanie.
Jak sprawdzić, czy system mógł być dotknięty
Pierwszy krok to ustalenie wersji cPanel i porównanie jej z buildami poprawionymi przez vendora. Drugi krok to sprawdzenie, czy panel był wystawiony publicznie i czy w ogóle był osiągalny na portach administracyjnych. Trzeci krok to poszukiwanie IOC, czyli wskaźników kompromitacji. cPanel opublikował do tego własny detection script, który skanował pliki sesji w /var/cpanel/sessions i odwoływał się też do logu /usr/local/cpanel/logs/access_log.
To ważne, bo samo załatanie hosta po fakcie nie odpowiada na pytanie, czy ktoś zdążył już wejść wcześniej. W praktyce przy takiej luce trzeba było robić dwie rzeczy równolegle: patch + triage powłamaniowy. Innymi słowy: najpierw zatkaj dziurę, ale zaraz potem sprawdź, czy dom już nie jest pusty.
Czy można było się zabezpieczyć przed tym wcześniej
Tak, ale trzeba uczciwie rozdzielić dwie rzeczy.
1. Czy można było naprawić samą lukę przed ujawnieniem?
Nie, jeśli producent nie opublikował jeszcze poprawki, administrator nie miał jak „napisać sobie” bezpiecznego cPanela od zera. To była podatność w logice aplikacji po stronie vendora.
2. Czy można było ograniczyć ryzyko wykorzystania?
Tak — i to bardzo wyraźnie. Gdyby panel administracyjny nie był publicznie wystawiony na cały internet, tylko ograniczony np. do VPN, ACL po adresach IP, oddzielnej sieci zarządzającej albo byłby czasowo niedostępny z zewnątrz, to możliwość masowego zdalnego wykorzystania znacząco by spadła. Sama treść mitigacji cPanel, czyli blokowanie portów 2083/2087/2095/2096 i wyłączanie usług, pokazuje wprost, że ekspozycja interfejsu zarządzania była kluczowym elementem ryzyka.
Jak się zabezpieczać na przyszłość
Najważniejsza lekcja z CVE-2026-41940 jest brutalnie prosta: panel administracyjny nie powinien być „normalną publiczną stroną WWW”. To warstwa zarządzania, a nie warstwa klienta. Jeśli jest wystawiona szeroko do internetu, to każda pre-auth luka staje się alarmem najwyższego stopnia. Rapid7, Censys i advisory vendorów pokazują, że po ujawnieniu exploitów czas do masowej eksploatacji był bardzo krótki.
Dobre praktyki na przyszłość są więc dość konkretne:
- nie wystawiać WHM/cPanel/DNSOnly publicznie bez potrzeby,
- ograniczać dostęp do paneli zarządzania po IP albo przez VPN,
- utrzymywać automatyczne i sprawne aktualizacje,
- nie trzymać środowisk na zamrożonych, starych branchach bez planu update,
- monitorować logi i IOC po każdej krytycznej luce,
- mieć plan awaryjny: szybko zablokować porty lub wyłączyć usługę.
Te zalecenia nie są teorią — są bezpośrednio zgodne z tym, co cPanel zalecał jako działania awaryjne i co obserwowano w realnych kampaniach po disclosure.
Czy MFA, silne hasła i 2FA by pomogły?
Nie jako główna obrona. To bardzo ważne. Przy authentication bypass problem polega właśnie na tym, że napastnik omija normalny mechanizm logowania. Silne hasło i 2FA są nadal potrzebne, ale w tej konkretnej luce nie stanowiły centralnej bariery, jeśli atak trafiał przed etap właściwego uwierzytelnienia. To wynika z samej natury podatności opisanej przez NVD i Rapid7.
Czyli mówiąc wprost: hasła mogły być wzorowe, a serwer i tak mógł zostać przejęty, jeśli panel był publiczny i działał na podatnej wersji. Dlatego właśnie warstwa ograniczenia ekspozycji jest tak ważna.
Sekcja praktyczna
Co zrobić, jeśli nadal analizujesz stary incydent
- Ustal wersję cPanel/DNSOnly, która działała w czasie incydentu. Porównaj ją z listą wersji poprawionych.
- Sprawdź, czy panel był publicznie dostępny na portach 2083, 2087, 2095, 2096. To kluczowy wektor ekspozycji.
- Przejrzyj
/var/cpanel/sessionsoraz/usr/local/cpanel/logs/access_log, najlepiej zgodnie z logiką IOC opisaną przez cPanel. - Załóż, że samo patchowanie po czasie nie czyści skutków kompromitacji. Jeśli są oznaki wejścia, rób pełny incident response.
- Na przyszłość odseparuj płaszczyznę zarządzania od internetu publicznego. To najtańsza i najskuteczniejsza lekcja z tej historii.
Garść ciekawostek
- CVE-2026-41940 otrzymało CVSS 9.8, czyli prawie maksymalną ocenę krytyczności.
- Oficjalne advisory cPanel potwierdzało, że luka dotyczyła także DNSOnly, co dla branży hostingowej miało duże znaczenie.
- Rapid7 wskazał, że prosty search Shodana dawał około 1,5 mln publicznie widocznych instancji cPanel, co pokazuje skalę potencjalnego celu.
- Censys zaobserwował po ujawnieniu luki wzrost kampanii z Mirai i ransomware z rozszerzeniem
.sorryna przejętych hostach cPanel. - cPanel opublikował nie tylko poprawki, ale też własny skrypt detekcyjny do szukania oznak kompromitacji w sesjach.
Podsumowanie
CVE-2026-41940 była jedną z tych podatności, które bardzo jasno pokazują różnicę między „system działa” a „system jest bezpiecznie wystawiony”. To była krytyczna luka pre-auth w cPanel/WHM/DNSOnly, pozwalająca ominąć logowanie i przejąć panel administracyjny bez hasła. Gdy exploitacja ruszyła na szeroką skalę, skutki mogły obejmować pełne przejęcie hosta, malware i ransomware.
Najważniejszy wniosek na przyszłość jest prosty: nie da się przewidzieć każdej 0-day czy fresh CVE, ale da się zmniejszyć powierzchnię ataku. Zarządzanie powinno być odseparowane, panele ograniczone dostępem, aktualizacje sprawne, a po krytycznym advisory trzeba działać od razu — nie „jak będzie chwila”. W tej klasie luk to właśnie czas reakcji i ekspozycja decydują, czy kończy się na nerwach, czy na realnym przejęciu infrastruktury.
Źródła
- cPanel, Security: CVE-2026-41940 – cPanel & WHM / WP2 Security Update 04/28/2026.
- NVD, CVE-2026-41940 Detail.
- Rapid7, CVE-2026-41940: cPanel & WHM Authentication Bypass.
- Censys, The cPanel Situation Is….
- CSA Singapore, Active Exploitation of Critical Vulnerability in cPanel, WHM and WP2.
Autor: Redakcja youITcare · AI-Assisted
Artykuł opracowany przy wsparciu narzędzi sztucznej inteligencji, pod redakcyjnym nadzorem zespołu youITcare.