Krytyczna podatność WordPress — luki CVE-2026-63030 i CVE-2026-60137. Jak sprawdzić i zabezpieczyć swoją stronę?

17 lipca 2026 r. zespół WordPress opublikował awaryjną aktualizację bezpieczeństwa, która usuwa dwie poważne podatności w rdzeniu systemu — w tym lukę krytyczną, umożliwiającą zdalne wykonanie kodu (Remote Code Execution) i przejęcie strony bez logowania.

Od 18 lipca trwają masowe ataki na niezałatane instalacje, przed którymi ostrzega m.in. CERT Polska. W tym artykule wyjaśniamy, na czym polega zagrożenie, które wersje WordPressa są podatne, jak bezpiecznie wykonać aktualizację — i co zrobić, jeśli podejrzewasz, że Twoja strona mogła już zostać zaatakowana.

Jeżeli prowadzisz stronę firmową, sklep internetowy lub blog oparty na WordPressie, potraktuj ten materiał jako pilną listę kontrolną.

Co się stało? Dwie luki w rdzeniu WordPressa

Podatności zostały zgłoszone zespołowi bezpieczeństwa WordPressa przez niezależnych badaczy i załatane w wydaniach awaryjnych z 17 lipca 2026 r.:

• CVE-2026-63030 (krytyczna) — błąd w obsłudze zapytań zbiorczych REST API (tzw. batch-route confusion). W połączeniu z drugą luką prowadzi do zdalnego wykonania kodu (RCE), czyli sytuacji, w której atakujący może uruchomić własny kod na serwerze i w praktyce przejąć pełną kontrolę nad stroną.
• CVE-2026-60137 (wysoka) — podatność typu SQL Injection, która umożliwia nieautoryzowany dostęp do danych w bazie — w tym do haszy haseł użytkowników.

Co odróżnia ten incydent od większości problemów bezpieczeństwa WordPressa? Luki znajdują się w samym rdzeniu systemu, a nie we wtyczkach. Atak nie wymaga konta użytkownika, żadnej zainstalowanej wtyczki ani niestandardowej konfiguracji — zagrożona jest domyślna instalacja WordPressa w podatnej wersji.

Zagrożenie nie jest teoretyczne. CERT Polska w komunikacie 124/2026 z 18 lipca ostrzegł przed masowym wykorzystaniem podatności. W kolejnych dniach w sieci pojawiły się publiczne exploity, a firmy bezpieczeństwa potwierdziły aktywne ataki: skanowanie internetu w poszukiwaniu podatnych stron, wykradanie danych z baz, instalowanie webshelli (ukrytych „tylnych drzwi” w plikach strony) oraz zakładanie nieautoryzowanych kont administratorów. 21 lipca obie luki trafiły do katalogu aktywnie wykorzystywanych podatności (KEV) prowadzonego przez amerykańską agencję CISA.

Które wersje WordPressa są podatne?

Wersje starsze niż WordPress 6.8 nie są dotknięte opisanymi podatnościami.

Ważna wskazówka: aktualizuj w ramach swojej gałęzi. Jeśli Twoja strona działa na WordPressie 6.8.x, bezpieczną wersją jest 6.8.6 — nie musisz w trybie awaryjnym przechodzić na 7.0.2, co oznaczałoby przeskok o dwie wersje główne (wraz z nowym panelem administracyjnym wprowadzonym w 7.0) i większe ryzyko problemów ze zgodnością wtyczek czy motywu. Migrację na wyższą gałąź zaplanuj osobno, w spokojniejszych warunkach.

„Mam włączone automatyczne aktualizacje — czy to znaczy, że jestem bezpieczny?”

Niekoniecznie — i to jest najważniejszy punkt tego artykułu.

Ze względu na wagę zagrożenia WordPress.org uruchomił wymuszone aktualizacje przez mechanizm auto-update, obejmujące również część stron, które miały automatyczne aktualizacje wyłączone. To działanie stosowane tylko przy najpoważniejszych incydentach. Jednak — jak zaznacza CERT Polska — znane są liczne przypadki, w których wymuszona aktualizacja nie zadziałała.

Dlatego niezależnie od ustawień automatycznych aktualizacji: zaloguj się i sprawdź wersję. Sprawdzenie zajmuje minutę i jest jedynym sposobem, by mieć pewność.

Jak sprawdzić wersję WordPressa?

1. Zaloguj się do panelu administracyjnego (zwykle twojadomena.pl/wp-admin).
2. Przejdź do Kokpit → Aktualizacje.
3. Zobaczysz zainstalowaną wersję WordPressa oraz informację o dostępnych aktualizacjach. Wersję znajdziesz również w prawym dolnym rogu Kokpitu.

Jeżeli nie masz dostępu do panelu lub stroną opiekuje się zewnętrzna firma — skontaktuj się z administratorem serwisu i poproś o potwierdzenie wersji. Dziś, nie w przyszłym tygodniu.

Jak bezpiecznie zaktualizować WordPress? Krok po kroku

Każdą aktualizację systemu CMS — nawet pilną — warto poprzedzić przygotowaniem:

1. Wykonaj pełną kopię zapasową plików i bazy danych. Dzięki temu w razie nieprzewidzianych problemów szybko przywrócisz działanie strony.
2. Zaktualizuj WordPress do bezpiecznej wersji dla swojej gałęzi (6.8.6 / 6.9.5 / 7.0.2): Kokpit → Aktualizacje → „Aktualizuj teraz”.
3. Zweryfikuj, że aktualizacja faktycznie się wykonała — po zakończeniu procesu sprawdź numer wersji jeszcze raz.
4. Zaktualizuj wtyczki i aktywny motyw. Historycznie to właśnie rozszerzenia odpowiadają za większość włamań na strony WordPress — aktualny rdzeń to konieczny fundament, ale nie całość ochrony.
5. Usuń nieużywane wtyczki i motywy. Każde nieaktywne rozszerzenie to zbędna powierzchnia ataku.
6. Sprawdź poprawność działania strony — stronę główną, formularze, koszyk w sklepie, logowanie.

Sama aktualizacja bezpieczeństwa nie wprowadza zmian funkcjonalnych, więc ryzyko problemów ze zgodnością jest niewielkie — ale kopia zapasowa to żelazna zasada niezależnie od okoliczności.

Nie możesz zaktualizować od razu? Zabezpieczenie tymczasowe

Jeżeli natychmiastowa aktualizacja nie jest możliwa (np. czekasz na okno serwisowe lub zgodę klienta), CERT Polska wskazuje rozwiązania doraźne:

• zablokowanie dostępu do ścieżki /wp-json/batch/v1 oraz parametru ?rest_route=/batch/v1 na poziomie zapory aplikacyjnej (WAF), lub
• zablokowanie dostępu do całego REST API, np. za pomocą wtyczki.

Pamiętaj o dwóch zastrzeżeniach: blokada REST API może zakłócić działanie części funkcji serwisu (np. edytora blokowego czy integracji), a przede wszystkim — środki tymczasowe nie zastępują aktualizacji. Chronią przed znanym wektorem ataku, nie usuwają luki.

Co jeśli strona stała niezałatana przez ostatnie dni?

Ataki trwają od wieczora 17 lipca. Jeżeli Twoja strona działała w tym czasie na podatnej wersji, istnieje realne ryzyko, że została już naruszona — a sama aktualizacja nie usuwa backdoora założonego przed jej wykonaniem.

Na co zwrócić uwagę:

• Konta administratorów — sprawdź listę użytkowników (Użytkownicy → Wszyscy użytkownicy) pod kątem kont, których nie zakładałeś, zwłaszcza z uprawnieniami administratora.
• Nieznane pliki PHP — szczególnie w katalogu głównym strony oraz w wp-content/uploads (katalog przeznaczony na media nie powinien zawierać plików PHP).
• Daty modyfikacji plików — pliki rdzenia zmienione poza terminami aktualizacji to sygnał ostrzegawczy.
• Nietypowe wpisy w logach serwera — zwłaszcza żądania do /wp-json/batch/v1 sprzed aktualizacji.

Jeżeli cokolwiek budzi wątpliwości, nie ograniczaj się do usunięcia podejrzanego pliku — przejęte strony często zawierają więcej niż jeden mechanizm dostępu. W takiej sytuacji warto skorzystać z pomocy specjalisty, przywrócić stronę z czystej kopii zapasowej sprzed 17 lipca i wymusić zmianę haseł wszystkich użytkowników.

Bezpieczeństwo WordPressa to proces, nie jednorazowa akcja

Ten incydent jest wyjątkowy, bo dotyczy rdzenia — ale na co dzień o bezpieczeństwie strony internetowej decyduje suma prostych nawyków:

• regularne aktualizacje rdzenia, wtyczek i motywów (z weryfikacją, że się wykonały),
• usuwanie nieużywanych rozszerzeń,
• silne, unikalne hasła i ograniczenie liczby kont administratorów do niezbędnego minimum,
• regularne, automatyczne kopie zapasowe przechowywane poza serwerem strony,
• hosting, który aktywnie monitoruje zagrożenia.

Informacja dla klientów TiCloud i Telvinet

Jeżeli korzystasz z usług hostingowych TiCloud lub Telvinet, na bieżąco monitorujemy sytuację związaną z opisanymi podatnościami i analizujemy pojawiające się zagrożenia.

Pamiętaj jednak, że nawet najlepsze zabezpieczenia infrastruktury serwerowej nie zastąpią aktualnego oprogramowania. Regularna aktualizacja WordPressa i jego komponentów pozostaje podstawowym elementem ochrony każdej strony.

Potrzebujesz pomocy?

Jeżeli nie masz pewności, czy Twoja strona została zaktualizowana, podejrzewasz, że mogła zostać naruszona, albo potrzebujesz wsparcia przy aktualizacji — skontaktuj się z naszym zespołem: kontakt@tiforyou.pl. Pomożemy zweryfikować bezpieczeństwo Twojej witryny i doradzimy, jak ograniczyć ryzyko podobnych zagrożeń w przyszłości.

Najczęściej zadawane pytania (FAQ)

Czy aktualizacja WordPress do wersji 7.0.2 jest bezpieczna?

Tak. Wydanie 7.0.2 (podobnie jak 6.8.6 i 6.9.5) to aktualizacja bezpieczeństwa — zawiera wyłącznie poprawki luk, bez zmian funkcjonalnych, więc ryzyko problemów ze zgodnością jest minimalne. Mimo to przed każdą aktualizacją wykonaj kopię zapasową plików i bazy danych.

Jak sprawdzić, jaką wersję WordPressa mam na stronie?

Zaloguj się do panelu administracyjnego i przejdź do Kokpit → Aktualizacje — zobaczysz tam zainstalowaną wersję i dostępne aktualizacje. Numer wersji znajdziesz też w prawym dolnym rogu Kokpitu.

Mam WordPress 6.8. Czy muszę przechodzić na 7.0.2?

Nie. Dla gałęzi 6.8 wydano poprawkę 6.8.6, która usuwa dotyczącą jej podatność. Zaktualizuj w ramach swojej gałęzi, a migrację na nowszą wersję główną zaplanuj osobno, po przetestowaniu zgodności wtyczek i motywu.

Co zrobić, gdy aktualizacja WordPressa się nie powiedzie?

Przywróć stronę z kopii zapasowej wykonanej przed aktualizacją, a następnie spróbuj ponownie — najczęstsze przyczyny niepowodzenia to brak miejsca na serwerze, ograniczenia uprawnień plików lub konflikt wtyczki. Do czasu skutecznej aktualizacji zablokuj ścieżkę /wp-json/batch/v1 na poziomie WAF. Jeśli problem się powtarza, skontaktuj się ze swoim hostingiem.

Skąd mam wiedzieć, czy moja strona została już zaatakowana?

Sprawdź listę kont administratorów pod kątem użytkowników, których nie zakładałeś, oraz obecność nieznanych plików PHP w katalogu głównym i w wp-content/uploads. Niepokojące są też pliki rdzenia zmodyfikowane poza terminami aktualizacji. W razie wątpliwości skorzystaj z pomocy specjalisty — samo usunięcie jednego podejrzanego pliku często nie wystarcza.

Jak często aktualizować WordPress?

Aktualizacje bezpieczeństwa instaluj natychmiast po ich publikacji — najlepiej z włączonymi automatycznymi aktualizacjami dla wydań poprawkowych i okresową weryfikacją, że faktycznie się wykonują. Wtyczki i motywy przeglądaj co najmniej raz w tygodniu.

Źródła: komunikat bezpieczeństwa WordPress.org z 17 lipca 2026 r. · komunikat CERT Polska 124/2026 z 18 lipca 2026 r.

Artykuł opublikowano 25 lipca 2026 r. Sytuacja rozwija się dynamicznie — w przypadku nowych informacji będziemy aktualizować ten materiał.