Krytyczna luka w WordPress (CVE-2026-63030 i CVE-2026-60137) - co robić w 2026

17 lipca 2026 zespół WordPress wydał awaryjne poprawki bezpieczeństwa, a firmy hostingowe zaczęły masowo ostrzegać swoich klientów. Powód jest poważny: w rdzeniu WordPressa wykryto dwie krytyczne podatności, które połączone ze sobą pozwalają przejąć stronę bez żadnego loginu i hasła. Publiczny kod exploita pojawił się w sieci w ciągu kilku godzin, a firmy monitorujące zagrożenia już odnotowały pierwsze ataki.

W tym artykule tłumaczymy bez straszenia i bez technicznego żargonu: czego dotyczą luki CVE-2026-63030 i CVE-2026-60137, które wersje WordPressa są zagrożone, jak w 5 minut sprawdzić swoją stronę i co zrobić, żeby spać spokojnie. Jeśli nie masz czasu ani pewności, jak wykonać aktualizację, na końcu znajdziesz informację, jak możemy Ci pomóc.

Co się właściwie stało?

W połowie lipca 2026 badacze bezpieczeństwa zgłosili do zespołu WordPress dwie osobne luki w samym rdzeniu systemu (nie we wtyczkach czy motywach, tylko w kodzie, który ma każda instalacja WordPressa). Zespół WordPress zareagował szybko i 17-18 lipca wydał poprawki, jednocześnie uruchamiając wymuszone automatyczne aktualizacje dla stron, które mają tę funkcję włączoną.

Problem w tym, że bardzo wiele stron ma automatyczne aktualizacje wyłączone, celowo lub przez przypadek. Właściciele takich witryn muszą zadziałać ręcznie i to szybko, bo luka jest już aktywnie wykorzystywana przez atakujących. Cała kampania ataku dostała w środowisku bezpieczeństwa nazwę wp2shell, czyli w wolnym tłumaczeniu "od WordPressa do przejęcia serwera".

CVE-2026-63030 - obejście logowania w REST API

Pierwsza luka dotyczy tzw. REST API, czyli interfejsu, przez który WordPress komunikuje się z aplikacjami, wtyczkami i panelem administracyjnym. Konkretnie chodzi o funkcję "batch", która pozwala wysłać kilka poleceń naraz w jednym zapytaniu.

Z powodu błędu w kodzie polecenia wysłane w takiej paczce mogą się "rozjechać" - polecenie z jednej pozycji wykonuje się z uprawnieniami przypisanymi do innej pozycji. W praktyce oznacza to, że atakujący potrafi obejść mechanizm sprawdzania uprawnień. To tak, jakby zamek w drzwiach otwierał się kluczem od zupełnie innych drzwi. Sama w sobie ta luka jest groźna, ale prawdziwy problem zaczyna się, gdy połączy się ją z drugą podatnością.

CVE-2026-60137 - wstrzyknięcie zapytań do bazy danych (SQL injection)

Druga luka to klasyczny błąd typu SQL injection w jednym z parametrów wyszukiwania (technicznie: author__not_in w mechanizmie zapytań WordPressa). Upraszczając: atakujący potrafi tak spreparować zapytanie, że WordPress wykona jego własne polecenia na bazie danych, zamiast tylko odczytać to, co powinien.

Baza danych to serce strony. Znajdują się tam między innymi loginy i zaszyfrowane hasła administratorów. Normalnie ta luka wymaga zalogowania, więc sama w sobie byłaby mniej groźna. Ale w połączeniu z pierwszą podatnością (która wyłącza sprawdzanie logowania) staje się bronią pełnej mocy.

Jak wygląda atak krok po kroku

Siła tych podatności bierze się z ich połączenia. Badacze opisali gotowy scenariusz ataku, który przebiega mniej więcej tak:

1. Atakujący wykorzystuje CVE-2026-63030, żeby obejść mechanizm logowania w REST API.
2. Następnie, jako niezalogowany gość, wysyła spreparowane zapytanie wykorzystujące CVE-2026-60137.
3. Zapytanie wyciąga z bazy danych tabelę użytkowników wraz z zaszyfrowanymi hasłami administratorów.
4. Atakujący łamie hasło albo podmienia je na własne i loguje się jako administrator.
5. Z panelu administratora wgrywa tzw. webshell, czyli furtkę pozwalającą wykonywać dowolny kod na serwerze.

Efekt końcowy to pełne przejęcie strony i serwera - bez znajomości jakiegokolwiek loginu czy hasła. W skali zagrożeń taki scenariusz jest oceniany na 9.8 na 10 (poziom krytyczny). Ważny szczegół techniczny: atak działa na stronach, które nie mają włączonego trwałego cache obiektów po stronie serwera. Zdecydowana większość zwykłych stron firmowych i blogów takiego cache nie ma, więc są podatne w konfiguracji domyślnej.

Kogo to dotyczy? Sprawdź swoją wersję

Podatne są następujące wersje WordPressa:

Jak sprawdzić swoją wersję? Zaloguj się do panelu WordPress (kokpit) i spójrz na dół strony głównej kokpitu - wersja jest wyświetlona w prawym dolnym rogu. Możesz też wejść w Kokpit → Aktualizacje. Jeśli nie masz dostępu do panelu, wersję często (choć nie zawsze) widać w kodzie źródłowym strony w znaczniku generator.

Jak zabezpieczyć stronę - instrukcja

Najważniejsze i najskuteczniejsze działanie to aktualizacja WordPressa do bezpiecznej wersji. Oto co warto zrobić:

1. Zrób kopię zapasową strony i bazy danych, zanim cokolwiek zmienisz. To zasada numer jeden przy każdej aktualizacji.
2. Zaktualizuj WordPress w Kokpit → Aktualizacje. Jeśli masz włączone automatyczne aktualizacje bezpieczeństwa, poprawka najprawdopodobniej wgrała się już sama - i tak warto to zweryfikować.
3. Zaktualizuj też wtyczki i motyw przy okazji, bo one bywają osobnym wektorem ataku.
4. Sprawdź, czy nikt się nie włamał zanim zaktualizowałeś: podejrzane nowe konta administratora, nieznane pliki, dziwne przekierowania, ostrzeżenia w Google Search Console.
5. Rozważ włączenie automatycznych aktualizacji bezpieczeństwa na przyszłość, żeby kolejna taka sytuacja załatała się bez Twojego udziału.

Nie masz czasu albo pewności? Pomożemy

Aktualizacja WordPressa brzmi prosto, ale w praktyce bywa stresująca - zwłaszcza gdy strona zarabia, a aktualizacja "kiedyś już coś popsuła". W Noril od lat zajmujemy się techniczną stroną witryn naszych klientów i tego typu sytuacje obsługujemy rutynowo.

Jak możemy pomóc w tej konkretnej sprawie:

• Bezpłatny przegląd bezpieczeństwa - sprawdzimy wersję Twojego WordPressa i powiemy wprost, czy jesteś zagrożony.
• Bezpieczna aktualizacja - wykonamy kopię zapasową, przetestujemy aktualizację i wdrożymy ją tak, żeby nic się nie posypało. Bez abonamentu, w rozliczeniu godzinowym (50 zł za pierwszą godzinę dla danej domeny, 70 zł za każdą kolejną).
• Skan i oczyszczenie jeśli okaże się, że strona została już zaatakowana.
• Stała opieka nad stroną - od 299 zł/mc pilnujemy aktualizacji, kopii zapasowych i monitoringu, żeby następna krytyczna luka załatała się automatycznie w ciągu godzin, a nie tygodni.

Jeśli Twoja strona na WordPress jest już mocno przestarzała i aktualizacja to ciągła walka, warto rozważyć nowoczesną, lekką stronę zbudowaną bez ciężkich wtyczek - z mniejszą powierzchnią ataku i lepszymi wynikami w Google.

Najczęstsze pytania