W lipcu 2026 ujawniono jedną z najpoważniejszych w ostatnich latach luk w samym rdzeniu WordPressa — nazwaną wp2shell (oznaczenia CVE-2026-63030 oraz CVE-2026-60137). Jest ona już aktywnie wykorzystywana przez atakujących w internecie, dlatego jeśli prowadzisz stronę na WordPressie, warto zareagować teraz, a nie „przy okazji”.
Ten wpis tłumaczy w prostych słowach, na czym polega zagrożenie i co konkretnie zrobić. Świadomie nie publikujemy tu żadnych szczegółów technicznych ataku — chcemy pomóc administratorom się zabezpieczyć, a nie ułatwiać życie atakującym.
W skrócie
- To luka w rdzeniu WordPressa, a nie w jednej z wtyczek — dotyczy więc „czystych” instalacji.
- Pozwala na zdalne wykonanie kodu bez logowania (atakujący nie potrzebuje żadnego konta na stronie).
- Jest aktywnie wykorzystywana — pojawiły się gotowe narzędzia atakujące.
- Rozwiązanie jest proste: zaktualizuj WordPressa do wersji z poprawką. Wszystko inne to środki tymczasowe.
Kogo dotyczy
Zagrożone są strony na następujących wersjach WordPressa:
- 6.9.0 – 6.9.4 oraz 7.0.0 – 7.0.1 — pełny, najgroźniejszy wariant.
- 6.8.0 – 6.8.5 — węższy zakres problemu.
Poprawki wydano w wersjach 6.9.5, 7.0.2 oraz 6.8.6 (i nowszych). Jeśli masz włączone automatyczne aktualizacje rdzenia, WordPress mógł już zaktualizować się sam — ale warto to zweryfikować, bo na wielu serwerach automatyczne aktualizacje bywają wyłączone.
Jak sprawdzić, czy jesteś bezpieczny
- Zaloguj się do panelu WordPress i wejdź w Kokpit → Aktualizacje.
- Sprawdź numer wersji WordPressa. Jeśli jest starszy niż 6.8.6 / 6.9.5 / 7.0.2 — zaktualizuj natychmiast.
- Jeśli masz kilka lub kilkaset stron, sprawdź je wszystkie — jedna niezaktualizowana instalacja wystarczy, by mieć problem.
Co zrobić — krok po kroku
- Zaktualizuj rdzeń WordPressa (najważniejsze). To jedyne pełne rozwiązanie. Aktualizacja do 6.8.6 / 6.9.5 / 7.0.2 (lub nowszej) zamyka lukę. Przed aktualizacją wykonaj kopię zapasową — to standardowa dobra praktyka.
- Sprawdź, czy strona nie została już przejęta. Skoro luka jest aktywnie wykorzystywana, warto upewnić się, że nikt nie zdążył wcześniej. Typowe ślady po ataku to nieoczekiwane pliki PHP w katalogach, w których normalnie ich nie ma (np. w folderze pamięci podręcznej albo w bibliotece mediów), oraz nieznane, świeżo dodane konta administratorów. Jeśli masz wątpliwości — poproś o audyt swojego dostawcę usług WordPress.
- Jeśli nie możesz zaktualizować od ręki — zastosuj blokadę tymczasową. Do czasu aktualizacji można tymczasowo zablokować wrażliwy fragment interfejsu API WordPressa. To rozwiązanie „na chwilę”, które kupuje czas — nie zastępuje aktualizacji.
- Po każdym podejrzeniu włamania — posprzątaj porządnie. Zmień hasła wszystkich administratorów, przegeneruj klucze zabezpieczające (sole) w konfiguracji, przejrzyj listę kont użytkowników i usuń te, których nie rozpoznajesz.
Dla administratorów (skrót techniczny)
Luka znajduje się po stronie interfejsu REST API WordPressa i jest osiągalna dla nieuwierzytelnionych żądań. Zalecana kolejność działań:
- Aktualizacja rdzenia do 6.8.6 / 6.9.5 / 7.0.2+ — priorytet bezwzględny.
- Tymczasowa mitygacja na czas przed aktualizacją: zablokowanie wrażliwego punktu końcowego na poziomie serwera (reguła w konfiguracji serwera / WAF) lub na poziomie aplikacji dla żądań nieuwierzytelnionych. Pamiętaj, że reguły serwera Apache/LiteSpeed nie działają na Nginx — zadbaj o warstwę niezależną od serwera.
- Wykrywanie: monitoruj nietypowe odpowiedzi z punktów końcowych API oraz obecność plików PHP w katalogach pamięci podręcznej i mediów.
- Higiena powdrożeniowa: rotacja haseł administratorów, regeneracja soli, przegląd kont.
Dla własnego bezpieczeństwa nie podajemy tu ścieżek, parametrów ani przykładowych żądań — te informacje nie są potrzebne, by się zabezpieczyć.
Jak chronimy klientów TREJKA
Strony pod naszą opieką są w tej sprawie zaopiekowane wielowarstwowo:
- Aktualizacje rdzenia wdrażamy priorytetowo, gdy tylko pojawi się poprawka bezpieczeństwa.
- Nasza wtyczka TREJKA Admin Helper ma wbudowaną, domyślnie włączoną blokadę wrażliwego punktu końcowego dla żądań nieuwierzytelnionych — działa niezależnie od serwera (Apache, Nginx, LiteSpeed) i chroni w oknie czasu między ujawnieniem luki a aktualizacją. Zalogowani redaktorzy nie odczuwają żadnej różnicy.
- Monitoring wykrywa typowe ślady po tego typu atakach (np. podejrzane pliki PHP tam, gdzie nie powinno ich być), więc ewentualny problem wychwytujemy wcześnie.
Jeśli Twoja strona nie jest jeszcze pod naszą opieką, a chcesz mieć pewność, że jest zaktualizowana i bezpieczna — napisz do nas, chętnie pomożemy.
Źródła i dalsza lektura:
- ithardware.pl — Krytyczny atak na WordPress: jedno żądanie HTTP (link do artykułu)
- Rapid7 — analiza CVE-2026-63030 (wp2shell)
- Wiz — informacje o wykorzystywaniu luki w internecie (CVE-2026-63030 / CVE-2026-60137)
Data publikacji: lipiec 2026. Informacje o wersjach i poprawkach są aktualne na dzień publikacji — zawsze instaluj najnowszą dostępną wersję WordPressa.