Trzy tygodnie temu pisaliśmy o WordPressie 7.0.2.
Aktualizacja bezpieczeństwa, dwie podatności, zalecenie: nie odkładać.
Szóstego sierpnia wyszła kolejna.
WordPress 7.0.3 — i znowu nie chodzi o nowy przycisk w edytorze.
Tym razem historia jest o tyle ciekawa, że cała podatność sprowadza się do jednego znaku. Do spacji.
Co się właściwie stało
Szóstego sierpnia 2026 roku WordPress wydał wersję 7.0.3 z poprawką dla podatności oznaczonej jako CVE-2026-64638. Badacze nazwali ją XSS2Shell.
Dotyczy każdej wersji WordPressa — kod, w którym siedział błąd, jest w systemie od wersji 4.7, czyli od 2016 roku. Dziesięć lat.
Miejsce, w którym się ujawnia, jest zaskakująco zwyczajne: ekran logowania.
Wystarczy jedna nieudana próba zalogowania się z odpowiednio przygotowaną nazwą użytkownika, żeby w przeglądarce osoby odwiedzającej stronę uruchomił się kod przygotowany przez atakującego. Bez konta. Bez hasła. Bez niczego.
Na czym polega ten błąd
WordPress ma mechanizmy, które czyszczą dane wpisane przez użytkownika, zanim gdziekolwiek je pokaże. To standardowa praktyka — nie ufamy temu, co ktoś wpisał w formularz, więc najpierw to sprawdzamy.
Problem w tym, że w tym konkretnym miejscu dane przechodzą przez dwa różne mechanizmy czyszczące, jeden po drugim.
I te dwa mechanizmy inaczej rozumieją jedną spację.
Jeśli w nazwie użytkownika wstawić spację w konkretnym miejscu, pierwszy mechanizm uznaje, że to zwykły tekst — więc nie ma czego usuwać i przepuszcza go dalej. Drugi, kilka kroków później, uznaje dokładnie ten sam ciąg za kod — i traktuje go jak kod.
To jest jak dwóch ochroniarzy przy jednych drzwiach, z których każdy ma trochę inną listę gości.
Każdy pracuje dokładnie tak, jak mu polecono. Żaden nie popełnia błędu. Problem powstaje wyłącznie w miejscu, gdzie ich listy się różnią — i przez tę szczelinę można przejść.
Nie musisz tego pamiętać.
Warto zapamiętać co innego: błąd nie siedział w żadnym z tych dwóch mechanizmów. Siedział w przestrzeni między nimi. Dlatego przez dziesięć lat nikt go nie znalazł, choć oba kawałki kodu są publiczne i każdy mógł je przeczytać.
Jak z nieudanego logowania robi się problem na serwerze
Sam błąd na ekranie logowania to jedno. Badacze pokazali jednak, co da się na nim zbudować.
W skrócie, bez technicznych szczegółów: przygotowany kod potrafi — jeżeli w tym samym czasie na stronie jest zalogowany administrator i da się go nakłonić do otwarcia odpowiedniego adresu — wygenerować dla atakującego legalne poświadczenie dostępu do strony. Nie kradnąc hasła. Korzystając z funkcji, która w WordPressie istnieje i działa zgodnie z przeznaczeniem.
Mając takie poświadczenie, można wgrać na stronę wtyczkę. A wtyczka to kod, który wykonuje się na serwerze.
I tu jest rzecz warta uwagi dla właściciela strony:
każdy krok tego łańcucha to normalna, prawidłowo działająca funkcja WordPressa.
Nic nie zostaje „złamane". Nic nie wygląda jak włamanie. W dzienniku nieudanych logowań nie pojawia się nic podejrzanego, bo hasło administratora nikomu nie zostało wykradzione.
Ile to naprawdę groźne
Tu trzeba postawić sprawę uczciwie, bo w mediach ta luka bywa opisywana skrajnie.
Ocena to 8,9 punktu w dziesięciostopniowej skali — wysoka, ale nie krytyczna.
Sama część na ekranie logowania faktycznie nie wymaga żadnego konta. Ale przejście od tego do wykonania kodu na serwerze wymaga dodatkowo: zalogowanego administratora, jego świadomego kliknięcia w przygotowaną stronę oraz określonych warunków po stronie konfiguracji. Innymi słowy — skutecznej socjotechniki, a nie samego automatu.
Na dzień ósmego sierpnia nie potwierdzono przypadków wykorzystania tej luki w realnych atakach. Badacze wstrzymali też publikację pełnego opisu, żeby dać stronom czas na aktualizację.
Reakcja WordPressa zasługuje przy tym na dobre słowo: zgłoszenie wpłynęło 27 lipca, poprawka wyszła 6 sierpnia. Osiem dni. Razem z jedenastoma innymi łatkami bezpieczeństwa i z przeniesieniem poprawki wstecz aż do gałęzi 4.7.
Dlaczego tych aktualizacji będzie więcej, nie mniej
Jest jeszcze jeden szczegół tej historii, który wart jest jednego akapitu.
Tę lukę znalazł autonomiczny system oparty na AI, który porównał zasady działania dwóch mechanizmów czyszczących linijka po linijce i zauważył, że w jednym punkcie się różnią.
Człowiek tego przez dekadę nie zrobił. Nie dlatego, że to było za trudne — tylko dlatego, że to praca żmudna, nudna i nikt nie miał powodu jej wykonać. Oba kawałki kodu żyją w zupełnie różnych miejscach systemu i w żadnym normalnym przeglądzie nie występują obok siebie.
Maszyna się nie nudzi.
Dla właściciela strony wniosek jest praktyczny i całkiem prozaiczny: tempo wykrywania błędów w oprogramowaniu właśnie przyspieszyło. Aktualizacje bezpieczeństwa nie będą rzadszym wydarzeniem. Będą częstszym.
Dwie aktualizacje bezpieczeństwa WordPressa w dwadzieścia dni to nie jest wypadek przy pracy. To nowy rytm.
Automatyczna aktualizacja to nie to samo co sprawdzona aktualizacja
Przy 7.0.2 pisaliśmy, że automat może wykonać aktualizację, ale nie oceni tak dobrze jak człowiek, czy strona nadal działa poprawnie.
Tym razem dochodzi rzecz jeszcze ważniejsza.
Przy poprzedniej aktualizacji CERT Polska ostrzegał, że wymuszona automatyczna aktualizacja w wielu przypadkach po prostu nie zadziałała.
Ta sama uwaga obowiązuje teraz.
Automatyczne aktualizacje bezpieczeństwa są głównym mechanizmem ochrony i dla większości stron zadziałają bez żadnego działania administratora. Ale założenie, że zadziałały, jest dokładnie tym błędem, który popełniono trzy tygodnie temu.
Włączona opcja aktualizacji to nie jest to samo co zaktualizowana strona.
Co warto sprawdzić na swojej stronie
Cztery rzeczy. Żadna z nich nie jest skomplikowana — ale każdą trzeba faktycznie zrobić, a nie założyć.
Po pierwsze: sprawdź numer wersji. Nie to, czy automatyczne aktualizacje są włączone. Numer wersji, który realnie widnieje w panelu. Docelowo 7.0.3 albo odpowiednia załatana wersja ze starszej gałęzi. Instalacje starsze niż 4.7 poprawki nie dostały i wymagają przeniesienia na wspieraną wersję.
Po drugie: przejrzyj hasła aplikacji w kontach administracyjnych i usuń te, których nie rozpoznajesz. To ta funkcja, przez którą przechodzi cały opisany wyżej łańcuch. Większość właścicieli stron nawet nie wie, że taka lista w WordPressie istnieje — a to dwie minuty roboty.
Po trzecie: sprawdź, ile kont ma uprawnienia do wgrywania wtyczek. Cały łańcuch kończy się właśnie na tej jednej funkcji. Jeżeli konto redaktora nie musi instalować wtyczek, nie powinno móc.
Po czwarte: po aktualizacji sprawdź, czy strona działa. Formularz kontaktowy, koszyk, płatności, menu, widok na telefonie, najważniejsze podstrony. To samo, co przy każdej aktualizacji.
Podsumowanie
WordPress 7.0.3 to aktualizacja, którą warto potraktować poważnie — ale bez paniki.
Luka jest realna, ale jej najgroźniejsza część wymaga kilku warunków naraz. Poprawka wyszła szybko. Automat prawdopodobnie zrobił swoje.
Prawdziwa lekcja z tej historii jest inna i dotyczy nie jednej łatki, tylko sposobu myślenia o stronie.
Przez dziesięć lat w kodzie, na którym stoi znaczna część internetu, siedziała różnica jednej spacji między dwoma mechanizmami. Nikt tego nie zauważył, bo nikt nie patrzył na oba naraz.
Strona internetowa to nie jest projekt, który kończy się w dniu publikacji. To system, który żyje — i który w tym roku będzie wymagał więcej uwagi niż w poprzednim, bo tempo znajdowania błędów właśnie się zmieniło.
To nie znaczy, że trzeba samemu śledzić numery CVE i czytać komunikaty bezpieczeństwa.
To znaczy, że ktoś powinien.
W Studio iFOX prowadzimy opiekę nad stronami internetowymi — pilnujemy aktualizacji, sprawdzamy, czy faktycznie się wykonały, kontrolujemy działanie strony po zmianach, dbamy o kopie zapasowe i uprawnienia kont.
Tą aktualizacją i następnymi zajmiemy się za Ciebie.
Chcesz mieć pewność, że Twoja strona jest aktualna i działa poprawnie? Skontaktuj się z nami.