W piątek 17 lipca 2026 roku WordPress opublikował nadzwyczajną aktualizację bezpieczeństwa. Dla milionów właścicieli stron firmowych pojawił się baner w panelu administracyjnym: „Dostępna krytyczna aktualizacja bezpieczeństwa”. To nie była rutynowa poprawka — wersja 7.0.2 naprawia dwie podatności, z których jedna pozwala atakującemu bez uwierzytelnienia przejąć pełną kontrolę nad serwerem, na którym działa strona.
Jeśli Twoja strona firmowa działa na WordPressie w wersji 6.8, 6.9 lub 7.0 i nie wykonałeś aktualizacji przez ostatni tydzień — ten post jest dla Ciebie. Wyjaśniamy, co dokładnie zostało odkryte, które wersje są zagrożone, co atakujący może zrobić z niezałataną stroną, i jak w ciągu kilku minut sprawdzić oraz zabezpieczyć swoją witrynę.
Dlaczego ta aktualizacja jest wyjątkowa
WordPress regularnie wydaje aktualizacje bezpieczeństwa, ale ta jest niestandardowa z kilku powodów, które warto rozumieć jako właściciel firmy.
Po pierwsze, WordPress.org włączył wymuszone automatyczne aktualizacje dla wszystkich stron z włączoną funkcją background updates. Oznacza to, że po raz pierwszy od lat zespół WordPress zdecydował się narzucić aktualizację bez oczekiwania na zgodę administratora strony. To wyjątkowy krok — dla porównania, poprzedni raz WordPress zdecydował się na podobne wymuszone aktualizacje był przy podatności krytycznej z 2021 roku. Gdy WordPress.org robi to ponownie, sygnał jest jednoznaczny: luka jest na tyle poważna, że nie można czekać.
Po drugie, Cloudflare — jeden z największych globalnych dostawców infrastruktury CDN i bezpieczeństwa sieciowego — natychmiast po ogłoszeniu podatności wdrożył reguły WAF (Web Application Firewall) chroniące strony swoich klientów. Informacja o tym pojawiła się na blogu Cloudflare 17 lipca, równolegle z release notes WordPress. To bardzo rzadka sytuacja skoordynowanej odpowiedzi na poziomie infrastruktury — dostawcy CDN nie wdrażają reguł bezpieczeństwa dla konkretnych podatności przy każdej aktualizacji WP. Zrobili to tutaj ze względu na powagę zagrożenia.
Po trzecie, podatności zostały odkryte przez zewnętrznych badaczy bezpieczeństwa i zgłoszone w sposób odpowiedzialny (responsible disclosure). Oznacza to, że między odkryciem a publicznym ogłoszeniem WordPress miał czas na przygotowanie łatki. Jednak od momentu publicznego ogłoszenia 17 lipca, szczegóły techniczne luki są dostępne publicznie — i atakujący mają wszystkie informacje, których potrzebują, by skanować internet w poszukiwaniu niezałatanych stron.
Ostrzeżenie: Jeśli Twoja strona nie ma włączonych automatycznych aktualizacji i minął więcej niż tydzień od 17 lipca 2026 — Twoja strona jest aktualnie podatna na publicznie znane ataki. Czas reakcji po publicznym ogłoszeniu podatności mierzony jest w dniach, nie tygodniach.
Dwie podatności, które musisz znać
Oficjalny release WordPress 7.0.2 wymienia dwie podatności, obie z niezależnymi CVE. Warto wiedzieć, czym są — nie dlatego, żebyś musiał rozumieć techniczne szczegóły, ale żebyś rozumiał ryzyko dla Twojego biznesu.
CVE-2026-60137 — SQL injection (HIGH severity)
Pierwsza podatność to tzw. SQL injection — jeden z najstarszych i nadal najczęściej wykorzystywanych typów ataków na aplikacje webowe.
Jak to wytłumaczyć bez technicznego żargonu? Wyobraź sobie, że Twoja strona to restauracja, a baza danych to karta dań i lista zarezerwowanych stolików. SQL injection to technika, w której ktoś podchodzi do baru i zamiast zamówić „porcję frytek”, wpisuje specjalnie sformatowane polecenie, które myli system i każe mu ujawnić całą zawartość chłodni — albo rezerwacje wszystkich klientów, albo hasła do panelu.
W praktyce, exploitacja SQL injection może pozwolić atakującemu:
- Odczytać całą bazę danych strony — dane kontaktowe klientów, historię zamówień (jeśli masz sklep), komentarze, adresy email subskrybentów, zahashowane hasła,
- Zmodyfikować treść strony — zmienić teksty, ceny, dane kontaktowe,
- Uzyskać dane logowania — jeśli hash hasła administratora zostanie odczytany i złamany.
Podatność CVE-2026-60137, nazwana „facilitated SQL injection issue”, zgłosiło jako zespół trzech badaczy: TF1T, dtro i haongo. WordPress ocenił ją jako HIGH severity — co oznacza poważne zagrożenie, ale wymagające pewnych warunków do exploitacji.
Dotknięte wersje: WordPress 6.8.x, 6.9.x i 7.0.x. Wersje naprawione: WordPress 6.8.6, 6.9.5, 7.0.2.
CVE-2026-63030 — REST API → Remote Code Execution (CRITICAL)
Druga podatność to problem klasy krytycznej (CRITICAL) — najwyższy możliwy poziom zagrożenia w cyberbezpieczeństwie. WordPress opisuje ją oficjalnie jako „REST API batch-route confusion and SQL injection issue leading to Remote Code Execution”.
Wróćmy do analogii z restauracją: to tak jakby klient mógł nie tylko przeczytać menu czy listę rezerwacji, ale wejść za kuchenny blat i uruchomić własne oprogramowanie na komputerze restauracji — wynieść kasy, zainstalować podsłuch, zaszantażować właściciela żądając okupu za przywrócenie systemu do działania.
Remote Code Execution (RCE) to najgroźniejsza klasa podatności webowych — daje atakującemu pełną kontrolę nad maszyną. Praktyczne konsekwencje to m.in.:
- instalacja złośliwego oprogramowania (malware, ransomware) na serwerze,
- defacement strony — podmiana treści na szokujące lub nielegalne materiały,
- wykorzystanie serwera do atakowania innych systemów (botnet),
- kradzież wszystkich danych z bazy i serwera,
- zablokowanie strony i żądanie okupu za przywrócenie dostępu.
Podatność odkrył Adam Kues z Assetnote / Searchlight Cyber, firmy zajmującej się bezpieczeństwem ofensywnym. Problem dotyczy REST API — interfejsu programistycznego WordPressa, który od wersji 4.7 jest domyślnie włączony i korzystają z niego dziesiątki popularnych wtyczek, motywy budowane z Gutenbergiem oraz narzędzia zewnętrzne.
Dotknięte wersje: WordPress 6.9.x i 7.0.x (i 7.1 Beta — dla osób testujących). Wersje naprawione: WordPress 6.9.5 i 7.0.2. Ważna uwaga: WordPress 6.8.x jest dotknięty tylko pierwszą podatnością (CVE-2026-60137), nie tą krytyczną (RCE).
Skala zagrożenia w liczbach
Według danych W3Techs (w3techs.com), WordPress jest używany przez 59,1% wszystkich stron z CMS i 41,2% wszystkich stron w internecie. Oznacza to, że podatność dotyczy setek milionów witryn na całym świecie. Nawet jeśli przyjmiemy, że tylko część z nich działa na wersjach 6.8–7.0, mowa o dziesiątkach milionów potencjalnych celów — i o polskich stronach MŚP wśród nich.
Automatyczne skanowanie internetu w poszukiwaniu niezałatanych wersji WordPress to standardowa technika atakujących — zautomatyzowane boty przeglądają internet w poszukiwaniu stron na podatnych wersjach i próbują exploitu w ciągu minut od potwierdzenia, że wersja jest podatna. Nie jesteś za mały, żeby zostać zaatakowany — boty nie wybierają celów według rozmiaru firmy.
Które wersje WordPressa są zagrożone
Oto czytelna tabela z informacjami bezpośrednio ze strony wordpress.org:
| Wersja WordPress | CVE-2026-60137 (SQL) | CVE-2026-63030 (RCE) | Co zrobić |
|---|---|---|---|
| 7.0.x | TAK | TAK (CRITICAL) | Zaktualizuj do 7.0.2 |
| 6.9.x | TAK | TAK (CRITICAL) | Zaktualizuj do 6.9.5 |
| 6.8.x | TAK | Nie | Zaktualizuj do 6.8.6 |
| < 6.8 (6.7, 6.6, 6.5…) | Nie | Nie | Brak wymagania tej konkretnej aktualizacji |
Ważna obserwacja: strony na wersjach WordPress starszych niż 6.8 nie są dotknięte tymi konkretnymi podatnościami. Nie oznacza to jednak, że są bezpieczne — WordPress 6.5 i starsze mają swoje własne niezałatane luki i dawno minęły datę wsparcia. Jeśli Twoja strona działa na WP starszym niż 6.7, to jest to oddzielny temat do pilnego rozwiązania.
Jeśli jesteś na WordPress 7.1 Beta — nie powinieneś używać wersji Beta na stronie produkcyjnej. Wersja 7.1 Beta 2 zawiera poprawkę dla obu podatności, ale to nie zmienia zalecenia: strona produkcyjna powinna działać na stabilnej gałęzi (7.0.2 lub odpowiednia gałąź 6.x).
Jak sprawdzić wersję i zaktualizować WordPressa w 5 krokach
Aktualizacja WordPress to jedna z najprostszych czynności w panelu administracyjnym. Oto krok po kroku:
Krok 1 — Sprawdź wersję bez logowania
Nie musisz nawet logować się do panelu, żeby sprawdzić wersję. Wejdź na adres twojastrona.pl/wp-admin/update-core.php — jeśli WordPress obsługuje tę stronę publicznie, pokażę wersję. Alternatywnie: wejdź na twojastrona.pl/feed/ — w znaczniku <generator> XML zobaczysz numer wersji.
Krok 2 — Zaloguj się do panelu WP Admin
Wejdź na adres twojastrona.pl/wp-admin i zaloguj się na konto administratora. Jeśli nie pamiętasz hasła, skorzystaj z opcji „Zapomniałem hasła” na stronie logowania.
Krok 3 — Przejdź do sekcji Aktualizacje
W lewym menu wybierz Kokpit → Aktualizacje. Jeśli dostępna jest aktualizacja bezpieczeństwa, zobaczysz na górze wyraźny baner „Ważna aktualizacja bezpieczeństwa dostępna” z żółtym lub czerwonym tłem. Numer aktualnej wersji widzisz też w lewym dolnym rogu panelu przy logo WordPress.
Krok 4 — Zastosuj aktualizację
Kliknij Zaktualizuj teraz. Aktualizacja security release (7.0.1 → 7.0.2) jest mała — trwa zazwyczaj 30–60 sekund. Strona będzie przez chwilę niedostępna (pojawi się tryb konserwacji). Nie zamykaj okna przeglądarki w trakcie.
Krok 5 — Zweryfikuj powodzenie i sprawdź stronę
Po aktualizacji panel powinien pokazać komunikat „WordPress X.X.X jest aktualny”. Przejdź na stronę główną i kilka podstron, żeby sprawdzić, czy działają poprawnie. Sprawdź też, czy formularze kontaktowe i sklep (jeśli jest) działają normalnie.
Co jeśli masz zarządzany hosting WordPress? Dostawcy managed hosting — w tym GoDaddy, Hostinger, Bluehost, a z polskich m.in. LH.pl — zazwyczaj automatycznie stosują krytyczne aktualizacje bezpieczeństwa. Warto to jednak sprawdzić w panelu hostingowym lub skontaktować się z supportem. W komunikacie WordPress.org wprost wymieniono przedstawicieli Cloudflare, GoDaddy, Hostinger i WP Engine jako uczestników prac nad aktualizacją — co sugeruje, że ci dostawcy są dobrze poinformowani.
Co jeśli masz włączone automatyczne aktualizacje? Twoja strona mogła się zaktualizować sama bez Twojej ingerencji — właśnie po to WordPress.org włączył wymuszone updates. Sprawdź wersję w kokpicie: jeśli widzisz 7.0.2, 6.9.5 lub 6.8.6, masz już poprawkę i nie musisz robić nic więcej.
Co jeśli aktualizacja psuje coś na stronie? Security releases w ramach tej samej gałęzi (np. 7.0.x) są projektowane tak, żeby nie wprowadzać breaking changes. Problemy zdarzają się rzadko i zazwyczaj wynikają z konfliktów ze źle napisanymi wtyczkami. Jeśli coś przestaje działać po aktualizacji — zrób backup, dezaktywuj wtyczki pojedynczo i znajdź winowajcę.
Co zrobić po aktualizacji — profilaktyka na przyszłość
Samo zainstalowanie 7.0.2 zamknęło bieżącą lukę, ale bezpieczeństwo strony to ciągły proces, nie jednorazowa czynność. Oto kilka kroków, które warto podjąć teraz:
Włącz automatyczne aktualizacje rdzenia WordPress
W panelu WP Admin, w sekcji Kokpit → Aktualizacje, możesz wymusić, by aktualizacje bezpieczeństwa (minor updates, tj. 7.0.x → 7.0.2) były instalowane automatycznie. To rekomendowana praktyka dla stron, które nie mają silnie dostosowanego kodu wymagającego ręcznego testowania przy każdej aktualizacji — czyli dla większości stron firmowych.
Automatyczne aktualizacje core WordPress nie obejmują aktualizacji wtyczek i motywów (te muszą być zarządzane osobno), ale w przypadku krytycznych podatności to właśnie core jest kluczowy.
Zadbaj o WAF jako drugą warstwę ochrony
Cloudflare WAF — dostępny nawet w bezpłatnym planie — wdrożył reguły ochronne dla obu podatności jeszcze 17 lipca, zanim większość administratorów zdążyła zaaplikować aktualizację. WAF to filtry działające na poziomie sieci, które blokują złośliwe zapytania zanim w ogóle dotrą do Twojego serwera. To ważna zasada bezpieczeństwa warstwowego: aktualizacja zamknęła lukę, ale WAF daje dodatkową ochronę na wypadek pojawienia się nowych podatności w przyszłości. Więcej o tym, jak poprawnie skonfigurować Cloudflare WAF i inne elementy ochrony, opisaliśmy szczegółowo w osobnym wpisie o bezpieczeństwie strony firmowej — minimum konfiguracji dla MŚP.
Audyt wtyczek i motywów
Statystyki pokazują, że zdecydowana większość udanych ataków na WordPress pochodzi nie przez podatności w samym rdzeniu, ale przez nieaktualne lub źle napisane wtyczki i motywy. Rdzeniowe luki jak ta z 7.0.2 są stosunkowo rzadkie — łuki we wtyczkach są codziennością. Warto raz na kwartał przejrzeć listę zainstalowanych wtyczek i:
- usunąć wtyczki, których nie używasz (dezaktywowana wtyczka wciąż może mieć podatne pliki na serwerze),
- zaktualizować wszystkie aktywne wtyczki i motyw,
- sprawdzić datę ostatniej aktualizacji każdej wtyczki w repozytorium wordpress.org — wtyczka bez aktualizacji przez 2+ lata to ryzyko.
Narzędzia jak WPScan (dostępny w wersji darmowej) pozwalają przeskanować stronę pod kątem znanych podatności w zainstalowanych wtyczkach.
Regularne backupy — zanim, nie po
Chociaż aktualizacje WordPress security releases są zazwyczaj bezpieczne, zawsze warto mieć aktualny backup. Backup powinien obejmować zarówno pliki strony, jak i bazę danych. Wiele hostingów oferuje automatyczne codzienne backupy — sprawdź, czy masz to aktywowane i czy możesz przywrócić backup w razie potrzeby (samo istnienie backupu bez możliwości przywrócenia to fałszywe poczucie bezpieczeństwa).
Kiedy rozważyć migrację z WordPress?
Jeśli Twoja strona to prosta strona firmowa (kilka podstron, bez sklepu, bez aktywnego bloga) i regularnie musisz śledzić aktualizacje bezpieczeństwa, jest to naturalne pytanie. Statyczne generatory jak Astro eliminują całą klasę podatności związanych z backendem: nie ma bazy danych, nie ma panelu administracyjnego dostępnego przez internet, nie ma REST API podatnego na tego rodzaju ataki. Pisaliśmy o tym szerzej przy okazji premiery WordPress 7.0 Armstrong i porównania z alternatywami statycznymi dla MŚP.
Nie jest to wniosek, że WordPress jest zły — jest to masowy, dojrzały produkt open source z bardzo aktywnym zespołem bezpieczeństwa (jak widać po tej aktualizacji). Ale świadomy wybór platformy, uwzględniający koszty utrzymania i profil ryzyka, to dobra praktyka biznesowa.
Podsumowanie
Aktualizacja WordPress 7.0.2 to obowiązkowy krok dla każdej firmy z aktywną stroną na WordPress 6.8, 6.9 lub 7.0. Kluczowe wnioski:
- CVE-2026-60137 (HIGH): SQL injection dotyczący wersji 6.8–7.0 — aktualizuj do 6.8.6, 6.9.5 lub 7.0.2. Może pozwolić na kradzież danych z bazy (dane klientów, hasła).
- CVE-2026-63030 (CRITICAL): REST API → Remote Code Execution dotyczący 6.9.x i 7.0.x — to najgroźniejsza klasa podatności, dająca atakującemu pełną kontrolę nad serwerem.
- WordPress.org włączył wymuszone auto-aktualizacje ze względu na powagę sytuacji — to wyjątkowy, rzadki krok.
- Wersje WordPress starsze niż 6.8 nie są dotknięte przez te konkretne podatności (mają jednak swoje własne zaległe problemy bezpieczeństwa).
- Aktualizacja zajmuje dosłownie kilka minut w panelu wp-admin (Kokpit → Aktualizacje → Zaktualizuj teraz).
- Cloudflare WAF (nawet bezpłatny plan) daje dodatkową warstwę ochrony, ale nie zastępuje aktualizacji.
- Włącz automatyczne aktualizacje bezpieczeństwa rdzenia, żeby uniknąć podobnej sytuacji w przyszłości.
Wskazówka: traktuj aktualizacje bezpieczeństwa WordPressa jak przegląd techniczny samochodu — nie musisz znać mechaniki, ale musisz to robić regularnie. Odkładanie aktualizacji na „spokojniejszy moment” to najczęstszy powód, dla którego strony firmowe zostają przejęte przez atakujących.
Jeśli masz pytania dotyczące konfiguracji bezpieczeństwa Twojej strony lub chcesz sprawdzić, czy Twoja aktualna platforma odpowiada dzisiejszym standardom — napisz do nas.