Co się właściwie stało?
Poniedziałek, 10 marca, godzina 16:00 UTC. Zespół bezpieczeństwa WordPressa publikuje wersję 6.9.2 – aktualizację łatającą dziesięć podatności w rdzeniu systemu. Wśród nich podatność typu blind SSRF (CVE-2026-3901), stored XSS w menu nawigacyjnym czy obejście autoryzacji w AJAX. Brzmi poważnie i takie właśnie było – zalecenie natychmiastowej aktualizacji pojawiło się od razu.
Problem w tym, że kilka godzin po wydaniu łatki na forach wsparcia WordPressa i Reddicie zaczęły pojawiać się zgłoszenia od administratorów, którym strony przestały działać. Zamiast treści – biały ekran, czyli słynny White Screen of Death. Okazało się, że nowe zabezpieczenia wchodziły w konflikt z częścią motywów, które do ładowania plików szablonów używały obiektów zamiast zwykłych ciągów tekstowych (stringów). Technicznie to motywy robiły coś w sposób nigdy oficjalnie niewspierany przez WordPressa, ale w praktyce działało to od lat i nikt się tym nie przejmował – do teraz.
Pięć godzin później, około 21:00 UTC tego samego dnia, pojawił się WordPress 6.9.3. Ta wersja naprawiała problem z białym ekranem, przywracając kompatybilność z motywami korzystającymi z niestandardowego sposobu ładowania szablonów. Wydawało się, że sprawa jest zamknięta.
Nie była. We wtorek wieczorem, 11 marca, zespół bezpieczeństwa stwierdził, że trzy z dziesięciu łatek bezpieczeństwa z wersji 6.9.2 nie zostały poprawnie zastosowane. Innymi słowy – trzy podatności, które miały być załatane, wciąż częściowo istniały. WordPress 6.9.4 pojawił się o godzinie 22:00 UTC, żeby domknąć to, co 6.9.2 zostawiło otwarte.
Trzy podatności, które pozostały otwarte
Spośród dziesięciu łatanych problemów trzy zasługują na szczególną uwagę, bo to właśnie one nie zostały poprawnie naprawione aż do wersji 6.9.4.
PclZip path traversal (CVE-2026-3907)
PclZip to biblioteka PHP, której WordPress używa do obsługi plików ZIP – na przykład przy instalacji motywów i wtyczek. Podatność path traversal oznacza, że odpowiednio spreparowane archiwum ZIP mogło pozwolić na zapis plików poza katalogiem docelowym. W skrajnym przypadku atakujący mógł nadpisać kluczowe pliki WordPressa albo umieścić na serwerze złośliwy kod. Do wykorzystania tej luki potrzebne było uwierzytelnienie na poziomie co najmniej Autora.
Obejście autoryzacji w funkcji Notes (CVE-2026-3906)
Funkcja Notes, dodana w WordPressie 6.9, miała lukę w kontroli dostępu. Użytkownicy z niższymi uprawnieniami (na przykład Subskrybenci) mogli przez REST API tworzyć notatki i uzyskiwać dostęp do treści, do których nie powinni mieć wglądu. Jeśli ktoś korzystał z Notes do wewnętrznych dyskusji o zamówieniach, klientach czy danych wrażliwych – te informacje mogły wyciec.
XXE injection w bibliotece getID3 (CVE-2026-3908)
getID3 to zewnętrzna biblioteka, którą WordPress wykorzystuje do odczytu metadanych plików multimedialnych. Podatność typu XML External Entity (XXE) pozwalała uwierzytelnionemu użytkownikowi z uprawnieniami Autora na odczyt dowolnych plików z serwera. W praktyce oznacza to potencjalny dostęp do pliku wp-config.php, który zawiera dane logowania do bazy danych i inne krytyczne informacje o środowisku hostingowym.
Firma Wordfence oceniła te podatności w skali CVSS na od 4.3 do 6.5, co plasuje je w kategorii średniego zagrożenia. Istotne jest to, że wszystkie wymagały uwierzytelnienia – atakujący musiał najpierw zalogować się na konto o odpowiednim poziomie uprawnień.
Dlaczego niepełne łatki to poważna sprawa
Między wydaniem wersji 6.9.2 (z niekompletnymi łatkami) a 6.9.4 (z pełnymi poprawkami) minęło około 30 godzin. Mogłoby się wydawać, że to niewiele. Dane z raportu Patchstack „State of WordPress Security in 2026” pokazują jednak, że mediana czasu od publicznego ujawnienia podatności do masowej eksploatacji wynosi zaledwie pięć godzin. Połowa wszystkich krytycznych luk w ekosystemie WordPressa jest aktywnie wykorzystywana w ciągu doby od ich upublicznienia.
Dla stron, które po aktualizacji do 6.9.2 (lub 6.9.3) nie zaktualizowały się dalej do 6.9.4, te 30 godzin to było okno, w którym trzy częściowo załatane podatności mogły być celem ataku. A szczegóły techniczne tych luk krążyły już w komunikatach bezpieczeństwa i raportach badaczy.
Problem z białym ekranem i jego konsekwencje
Biały ekran wywołany przez wersję 6.9.2 to nie była pierwsza taka sytuacja. Grudniowa premiera WordPressa 6.9 popsuła działanie trzech popularnych wtyczek, a tydzień później bug w cache’owaniu spowodował awarie serwerów. Wielu administratorów – szczególnie tych zarządzających stronami firmowymi bez wsparcia dedykowanego zespołu IT – po tych doświadczeniach wyłączyło automatyczne aktualizacje. Inni przyjęli zasadę czekania kilku dni przed zastosowaniem łatek, śledząc fora w poszukiwaniu raportów o problemach.
Kiedy więc przyszła kolejna aktualizacja bezpieczeństwa i znów zaczęły się problemy z białym ekranem, część administratorów wycofała aktualizację. Niektórzy nie zdawali sobie sprawy, że właśnie usunęli krytyczne łatki bezpieczeństwa. Inni czekali z aktualizacją, nie wiedząc, że okno eksploatacji jest liczone w godzinach, nie dniach.
To zjawisko można nazwać zmęczeniem aktualizacjami – sytuację, w której sprzeczne sygnały („aktualizacje psują strony” kontra „musisz natychmiast zaktualizować”) prowadzą do paraliżu decyzyjnego. A paraliż w oknie pięciogodzinnej eksploatacji to dokładnie to, na co liczą atakujący.
Kampania ClickFix w tle
Całe zamieszanie z trzema aktualizacjami w 30 godzin zbiegło się w czasie z ujawnieniem przez Trend Micro kampanii malware o nazwie ClickFix (nazywanej też KongTuke). Według ich raportu z 10 marca 2026 roku ponad 250 skompromitowanych stron na WordPressie serwowało fałszywe strony CAPTCHA Cloudflare’a, które nakłaniały odwiedzających do uruchomienia złośliwych poleceń PowerShell. Efektem było instalowanie malware kradnącego dane logowania z przeglądarek i portfeli kryptowalut.
Administratorzy zajęci gaszeniem pożarów związanych z trzema aktualizacjami core’a mogli łatwiej przeoczyć, że ich strona została skompromitowana w zupełnie inny sposób.
Co poszło nie tak – i co z tego wynika
Warto uczciwie powiedzieć, że zespół bezpieczeństwa WordPressa zareagował szybko. Poprawka białego ekranu pojawiła się po pięciu godzinach, a kompletne łatki – następnego dnia. Problem nie leżał w czasie reakcji, ale w procesie, który dopuścił do wydania niekompletnych poprawek bezpieczeństwa i jednoczesnego wprowadzenia regresji psującej strony.
Część winy leży też po stronie twórców motywów, którzy od lat korzystali z niestandardowego sposobu ładowania szablonów. Filtr template_include w WordPressie oczekuje ciągu tekstowego, a niektóre motywy przekazywały mu obiekt. Działało – dopóki ktoś nie zaostrzył walidacji w ramach łatki bezpieczeństwa.
Dla właścicieli stron najważniejszy wniosek jest taki: jeśli nie prowadzicie wersji 6.9.4, zaktualizujcie się teraz. Jeśli wyłączyliście automatyczne aktualizacje po grudniowych problemach z WordPressem 6.9 – warto rozważyć ich ponowne włączenie. Biały ekran to problem odwracalny. Nienaprawiona podatność XXE, przez którą ktoś odczyta dane do bazy danych z waszego serwera – nie.
Warto też przejrzeć role użytkowników na stronie. Podatności związane z Notes i obejściem autoryzacji w AJAX dotyczyły użytkowników o niższych uprawnieniach, którzy uzyskiwali dostęp ponad swój poziom. Jeśli macie na stronie Współpracowników lub Autorów, sprawdźcie, do czego mieli dostęp w oknie między 10 a 11 marca.
Trzy łatki w 30 godzin to nie jest norma – WordPress sam przyznaje, że to najszybszy cykl aktualizacji core’a od początku istnienia platformy. Ale ekosystem WordPressa jest pod stałą presją. Raport Patchstack za 2025 rok odnotował 11 334 nowe podatności w ekosystemie – o 42% więcej niż rok wcześniej. Dane za 2026 rok zapowiadają kontynuację tego trendu. Warto mieć to na uwadze, planując strategię utrzymania swojej strony.
