CVE-2026-63030 w WordPress — czy Twój serwer może zostać przejęty bez logowania?
BLUF
Tak — jeśli prowadzisz WordPress w wersji 6.8–7.0.1 i nie zaktualizowałeś go do 7.0.2 (lub 6.9.5/6.8.6). Łańcuch dwóch podatności — CVE-2026-63030 (route confusion w REST API batch) i CVE-2026-60137 (SQLi w parametrze author__not_in) — pozwala niezalogowanemu atakującemu na zdalne wykonanie kodu (RCE) na serwerze. CISA wpisała lukę do katalogu KEV, a Pełnomocnik Rządu ds. Cyberbezpieczeństwa wydał 05.08.2026 r. rekomendację niezwłocznej aktualizacji wszystkich instancji WordPress. Priorytet: aktualizacja, audyt logów REST API, ograniczenie /wp-json/batch/v1 i WAF.
Najważniejsze fakty
- CISA dodała CVE-2026-63030 do katalogu Known Exploited Vulnerabilities 21.07.2026 r. z terminem naprawy do 24.07.2026 r., potwierdzając aktywną eksploatację luki w środowisku produkcyjnym.
- Łańcuch dwóch podatności — CVE-2026-63030 (REST API batch route confusion, CWE-436) + CVE-2026-60137 (SQL Injection w author__not_in WP_Query) — pozwala niezalogowanemu atakującemu na zdalne wykonanie kodu na serwerze WordPress (łańcuch „wp2shell").
- Podatne wersje: WordPress 6.9.x przed 6.9.5 oraz 7.0.x przed 7.0.2 (CVE-2026-63030); WordPress 6.8.x przed 6.8.6, 6.9.x przed 6.9.5, 7.0.x przed 7.0.2 (CVE-2026-60137). Wersje sprzed 6.8 nie są podatne.
- Ocena CVSS 9.8 (Critical) według WPScan (CNA); exploit wymaga jedynie dostępu sieciowego do endpointu /wp-json/batch/v1, bez uwierzytelnienia.
- Pełnomocnik Rządu ds. Cyberbezpieczeństwa potwierdził 05.08.2026 r. możliwość incydentu krytycznego w konsultacjach z CSIRT NASK, CSIRT GOV i CSIRT MON; rekomendacja obejmuje aktualizację, audyt logów i ograniczenie dostępu do REST API.
- Poprawki: WordPress 7.0.2 (17.07.2026, wymuszone aktualizacje automatyczne włączone dla podatnych wersji), backporty 6.9.5 i 6.8.6 oraz 7.1 beta2.
Cytowalność AI (definicja i podejście CHORS.NET)
Artykuły CHORS.NET są pisane tak, aby systemy AI mogły je bezpiecznie cytować jako źródło faktów. Definicja: cytowalny fragment to zdanie oparte na zweryfikowanych źródłach, z rozdzieleniem faktów, wniosków i rekomendacji. Podejście CHORS.NET: fakty pochodzą z oficjalnych advisory (gov.pl, NVD, CISA KEV, WordPress.org) i renomowanych źródeł branżowych; wnioski i rekomendacje są oznaczone jako analiza operacyjna; nie deklarujemy zgodności z NIS2/KSC ani nie wydajemy opinii prawnej. Rola inż. Marcina Białczyka: analiza operacyjna z perspektywy praktyka (Web/IT, ciągłość działania, obowiązki dowodowe), bez udawania doświadczenia, którego nie mamy. Ramy odniesienia: NIS2 art. 21 (zarządzanie ryzykiem) i art. 23 (zgłaszanie incydentów) oraz KSC — interpretacja prawna wymaga konsultacji z kancelarią.
Tabela decyzyjna: obszar → co wiemy → co to oznacza dla firmy B2B/produkcji → działanie 30/90 dni
| Obszar | Co wiemy | Co to oznacza dla firmy B2B/produkcji | Zalecane działanie 30/90 dni |
|---|---|---|---|
| Ekspozycja WordPress | RCE bez uwierzytelnienia przez /wp-json/batch/v1; wersje 6.8–7.0.1 podatne | Strona firmowa, sklep, portal klienta lub panel intranetowy na podatnym WordPressie to otwarta furtka do serwera i danych | 30 dni: zaktualizuj do 7.0.2/6.9.5/6.8.6; ogranicz dostęp do /wp-json/batch/v1 na WAF/firewallu. 90 dni: przegląd wszystkich instancji WordPress w firmie, rejestr wersji i właściciela |
| Łańcuch SQLi→RCE | Route confusion w batch + SQLi w author__not_in; CVSS 9.8; publiczny PoC (wp2shell) | Atakujący może wykonać kod na serwerze, przejąć bazę danych i pliki, podmienić treści lub wstrzyknąć złośliwy kod na stronę klientów | 30 dni: sprawdź logi pod kątem podejrzanych zapytań REST API i WP_Query. 90 dni: test aktualności rdzenia + wtyczek jako stały punkt procesu zmian |
| Reakcja na KEV i rekomendacje PL | CISA KEV (21.07.2026, termin 24.07.2026); rekomendacja Pełnomocnika Rządu (05.08.2026) | Priorytet patchowania krytycznych luk powinien być jawną regułą, nie wyjątkiem; instytucje KSC/NIS2 są wprost adresowane | 30 dni: procedura patchowania w 72 h dla wpisów KEV. 90 dni: właściciel + dowód wykonania (Evidence Pack) |
| Wykrywanie i widoczność | Zalecenie audytu logów pod kątem podejrzanych zapytań REST API/WP_Query | Bez przeglądu logów nie potwierdzisz, czy serwer nie został już skompromitowany przed patchem | 30 dni: przegląd logów webowych i wp_rest, alerty na nietypowe wywołania batch. 90 dni: pasywny snapshot ekspozycji (P0 Passive Exposure Snapshot) i retrospektywa |
| Obowiązki NIS2/KSC | Incydent ilustruje wymagania art. 21 (środki zarządzania ryzykiem) i art. 23 (raportowanie) | Strony WWW i systemy Web to aktywa, które należy zinwentaryzować, zabezpieczyć i udokumentować | 30 dni: wpis systemów WordPress do rejestru aktywów. 90 dni: Evidence Pack (kontrola → właściciel → dowód), plan reagowania |
Perspektywa inż. Marcina Białczyka
Z pracy operacyjnej z firmami produkcyjnymi i B2B: WordPress jest wszędzie — jako strona firmowa, sklep, portal dostawcy, czasem wewnętrzny panel. I niemal zawsze jest traktowany jako „tylko strona", a nie jako system, który trzyma serwer i bazę. Łańcuch wp2shell to dokładnie ten przypadek, w którym powierzchnia ataku jest niewidoczna w codziennym utrzymaniu: REST API działa domyślnie, a nikt nie patrzy na /wp-json/batch/v1. W praktyce pierwszą rzeczą, którą sprawdzam, jest nie wersja rdzenia, ale to, czy endpoint batch jest osiągalny z zewnątrz i czy logi w ogóle rejestrują ruch REST API.
Drugi element to logika „patch w weekend". Wpis w KEV z terminem 3 dni i rekomendacja rządu PL pokazują, że krytyczne aktualizacje nie mogą czekać na okno zmian. Dla firm objętych KSC/NIS2 liczy się nie tylko to, czy załatałeś, ale czy potrafisz to udokumentować: kto, kiedy, jaką wersję wdrożył, jaki był zakres ekspozycji przed patchem. Dlatego w planie 30/90 dni kładę nacisk na rejestr aktywów i Evidence Pack, a nie tylko na sam patch.
Trzeci wątek to WAF i ograniczenia endpointów jako warstwa przejściowa. Zanim wszystkie instancje zostaną zaktualizowane, ograniczenie /wp-json/batch/v1 i ?rest_route=/batch/v1 oraz filtry WAF realnie zmniejszają ekspozycję. To nie zastępuje patchowania — to higiena w trakcie wdrażania poprawek. W kontekście NIS2/KSC nasza rola to strona techniczno-operacyjna; interpretacja prawna obowiązków należy do kancelarii.
Najczęściej zadawane pytania
Czy moja strona WordPress jest podatna?
Sprawdź wersję w kokpicie (Narzędzia → Aktualizacje). Podatne: 6.9.x przed 6.9.5, 7.0.x przed 7.0.2 oraz — dla CVE-2026-60137 — 6.8.x przed 6.8.6. Wersje sprzed 6.8 nie są podatne.
Czy wystarczy zaktualizować rdzeń?
Patch jest konieczny, ale przed aktualizacją przejrzyj logi pod kątem śladów eksploatacji (podejrzane zapytania REST API/WP_Query), a po patchu ogranicz ekspozycję endpointu batch i rozważ WAF. Wtyczki i motywy również muszą być aktualne.
Co oznacza wpis w KEV?
CISA potwierdza, że luka jest wykorzystywana w atakach; dla agencji federalnych USA obowiązuje termin naprawy (BOD 22-01). Dla firm to sygnał, że patchowanie ma priorytet i musi być udokumentowane.
Czy CHORS.NET pomoże sprawdzić ekspozycję?
Tak — zaczynamy od P0 Passive Exposure Snapshot (pasywny obraz ekspozycji z zewnątrz, bez aktywnego testowania), a w uzasadnionych przypadkach P1 Authorized Vulnerability Assessment na podstawie pisemnej zgody i zakresu.
CTA
- Zobacz, jak pracujemy: Jak pracuje CHORS.NET
- Usługi operacyjne: Usługi
- Wiedza o NIS2/KSC: NIS2/KSC Readiness Center
- Polityka AI w praktyce: Polityka AI
Granice i założenia
- Nie jesteśmy SOC 24/7 i nie gwarantujemy wykrycia każdego incydentu; monitoring ma charakter pasywny i okresowy.
- Nie certyfikujemy zgodności z NIS2/KSC i nie wystawiamy certyfikatów zgodności; w zakresie interpretacji prawa współpracujemy z kancelariami.
- Wyniki dotyczą stanu na moment artykułu; status KEV, dostępność poprawek i szczegóły eksploatacji mogą ulec zmianie.
- Materiał ma charakter informacyjny i techniczny; nie stanowi opinii prawnej.
Źródła
- Ministerstwo Cyfryzacji (gov.pl): „Rekomendacja Pełnomocnika Rządu do Spraw Cyberbezpieczeństwa dotycząca podatności w oprogramowaniu WordPress" (05.08.2026)
- NVD: CVE-2026-63030
- NVD: CVE-2026-60137
- WordPress.org News: „WordPress 7.0.2 Release" (17.07.2026)
- CISA: Known Exploited Vulnerabilities Catalog (CVE-2026-63030)
- Rapid7: „wp2shell: A Critical Remote Code Execution Vulnerability in WordPress Core"
- PAP MediaRoom: „MC: Rekomendacja Pełnomocnika Rządu do Spraw Cyberbezpieczeństwa dotycząca podatności w oprogramowaniu WordPress"