Cały łańcuch zaczyna się od jednej spacji. Ciąg < area z odstępem po nawiasie ostrym przechodzi przez pierwszy filtr WordPressa jako zwykły tekst, bo PHP nie uznaje tego za znacznik. Kawałek dalej ten sam ciąg trafia na drugi filtr, który uznaje go za poprawny element strony i wpuszcza na ekran logowania. Na tym rozjeździe stoi CVE-2026-64638, łańcuch prowadzący od nieudanej próby logowania aż do uruchomienia własnego kodu na serwerze. Poprawka nosi numer 7.0.3 i jest dostępna od 6 sierpnia 2026. Bezpieczeństwo WordPressa dostało jednak przy tej okazji drugi temat do przemyślenia, ciekawszy od samej luki. Znalazł ją autonomiczny system, a nie badacz.
Na czym polega ta luka w WordPressie
Rzecz sprowadza się do tego, że dwa mechanizmy w tym samym systemie czytają ten sam tekst inaczej. Kiedy wpiszesz nieistniejącą nazwę użytkownika, WordPress wkleja ją do komunikatu o błędzie. Zanim to zrobi, przepuszcza ją przez funkcję czyszczącą znaczniki. Ta funkcja opiera się na strip_tags() z PHP, a strip_tags() uznaje coś za znacznik tylko wtedy, gdy zaraz po nawiasie ostrym stoi litera. Odstęp wystarczy, żeby ciąg przeszedł nietknięty.
Potem komunikat wędruje dalej i trafia do KSES, własnego mechanizmu WordPressa od czyszczenia kodu strony. KSES ma osobny sposób czytania i spacja mu nie przeszkadza. Widzi poprawny znacznik <area>, który w dodatku jest na jego liście dozwolonych razem z <div> i <button>. Jeden filtr mówi “to tekst”, drugi mówi “to dozwolony kod strony”. Przeglądarka dostaje gotowe elementy podstawione przez atakującego.
Same elementy jeszcze niczego nie uruchamiają. Robi to skrypt, który WordPress ładuje na stronie logowania przy okazji resetowania hasła. Ten skrypt został napisany dla panelu edycji profilu i szuka na stronie elementów, których na logowaniu normalnie nie ma. Po wstrzyknięciu już są, więc skrypt sam klika podstawiony przycisk i wysyła zapytanie pod adres wskazany przez atakującego. Odpowiedź wraca oznaczona jako skrypt i zostaje wykonana.
Bez kliknięcia administratora nie ma kodu na serwerze
Ta część decyduje o realnej skali i łatwo ją zgubić w skrócie. Sam wstrzyknięty skrypt działa bez konta, przed zalogowaniem, i to jest paskudne samo w sobie. Ale przejęcie serwera wymaga jeszcze jednego zdarzenia: zalogowany administrator musi wejść na przygotowaną przez atakującego stronę.
Dopiero wtedy rusza reszta. Skrypt klika w oknie administratora przycisk zatwierdzający dostęp dla zewnętrznej aplikacji i przechwytuje wygenerowane hasło aplikacji. Przez to hasło publikuje stronę z własnym kodem, a na końcu wgrywa wtyczkę w postaci archiwum z plikiem PHP. Plik jest osiągalny przez adres URL nawet bez włączania wtyczki. Autorzy sprawdzili to na własnej instalacji i posprzątali po sobie: unieważnili hasło, skasowali stronę i usunęli katalog.
Oficjalna punktacja oddaje to lepiej niż nagłówki. W bazie NVD luka ma 8,9 punktu na 10, czyli poziom wysoki. Ten sam wektor zawiera jednak dwie ważne adnotacje: atak wymaga aktywnego udziału użytkownika i ma wysoką złożoność. Warto też uważać na liczbę 500 milionów, która krąży w opisach. To szacunek autorów narzędzia dotyczący tego, ile stron w ogóle stoi na WordPressie, a nie ile z nich ktoś zaatakował. Żadne z dwóch źródeł nie wspomina o wykorzystaniu tej luki w prawdziwych atakach.
Która wersja WordPressa jest teraz bezpieczna
Docelowy numer się przesunął i to jest najważniejsza informacja praktyczna. Pisaliśmy w sierpniu o rekomendacji Pełnomocnika Rządu i aktualizacji WordPressa. Bezpieczne wydania były tam trzy: 7.0.2, 6.9.5 i 6.8.6, wszystkie z 17 lipca. Tamten tekst dotyczy innych podatności i pozostaje aktualny co do zaleceń, ale sam numer wersji już nie wystarcza. Od 6 sierpnia gałąź 7.0 jest bezpieczna dopiero w wydaniu 7.0.3.
Projekt backportuje poprawki do wszystkich gałęzi objętych wsparciem bezpieczeństwa, sięgając aż do wersji 4.7. W dniu wydania część z nich jeszcze powstawała, więc na starszej gałęzi warto sprawdzić panel aktualizacji ponownie. Strony z włączonymi automatycznymi aktualizacjami w tle dostają poprawkę same. Problem w tym, że w firmowych instalacjach ten mechanizm bywa wyłączony. Zwykle stoi za tym wtyczka, która kiedyś przy podbiciu wersji przestała działać.
Bezpieczeństwo WordPressa nie kończy się przy tym na jednej luce. Wydanie 7.0.3 zamyka dwanaście zgłoszeń, nie jedno, i ten szczegół ginie w relacjach. Są wśród nich kolejne wstrzyknięcia skryptu, podniesienie uprawnień w sieciach wielowitrynowych i ujawnianie komentarzy z wpisów chronionych hasłem. Lista zgłaszających jest znakiem czasu, bo obok firm bezpieczeństwa i zespołu WordPressa figuruje w niej Anthropic.
Pierwsza Misja AI · Kodożercy
Rozumiesz zagrożenia AI, gdy rozumiesz jak naprawdę działa.
Kurs Pierwsza Misja AI ma dedykowaną lekcję o ciemnej stronie AI: halucynacje, deepfakes, manipulacja. Zanim zaczniesz się bać – zacznij rozumieć.
Poznaj pełny program →
Tydzień temu te same narzędzia produkowały fałszywe zgłoszenia
Zestawienie z początkiem sierpnia robi się niewygodne dla obu stron sporu o przydatność modeli w bezpieczeństwie. Opisywaliśmy wtedy pięćdziesiąt pięć zgłoszeń podatności w SQLite, z których pięćdziesiąt cztery firma JFrog uznała za wygenerowane przez model językowy. Dowody nie odtwarzały żadnej awarii, a autor biblioteki napisał, że nowe zgłoszenia przeciwko jego projektowi można uznać za fałszywe.
Tu jest odwrotnie i różnica leży dokładnie w tym, co dało się sprawdzić. Zgłoszenie z WordPressa nie zostało uznane za wiarygodne dlatego, że brzmiało fachowo. Zostało uznane, bo dołączono do niego działający dowód: uruchomienie kodu na serwerze testowym. Projekt potwierdził ryzyko następnego dnia po zgłoszeniu i wydał poprawkę przed ujawnieniem sprawy.
Wniosek z obu historii jest ten sam, choć wygląda inaczej. Nie liczy się, kto albo co znalazło błąd, tylko czy ktoś jest w stanie go odtworzyć. Zalew zgłoszeń, których nie da się powtórzyć, kosztuje projekty open source czas ludzi. Jedno odtwarzalne zgłoszenie z dowodem jest warte pięćdziesięciu wiarygodnie brzmiących opisów.
Co dokładnie znaczy, że znalazł to system
Deklaracja pwn.ai brzmi mocno, więc warto ją przeczytać dokładnie. Firma pisze, że jej system dostał gotowy punkt wyjścia: pracę badawczą Paulosa Yibelo z 2022 roku. Do tego dostał zadanie zbudowania na niej pełnego łańcucha. Reszta zajęła, cytując wpis, blisko cztery dni pracy z modelami otwartoźródłowymi i złożonym układem wielu współpracujących agentów. Nazw tych modeli firma nie podaje.
Ten sam wpis kończy się zdaniem o odkryciu dokonanym w pełni autonomicznie. Te dwa fragmenty niezupełnie się ze sobą zgadzają. Człowiek wskazał kierunek i postawił cel, maszyna przeszła drogę. To nadal jest wynik, jakiego rok temu nie było. Opisywanie go jako samodzielnego odkrycia od zera rozmija się jednak z tym, co napisał sam producent. Warto pamiętać, kto tu o czym mówi: to oświadczenie firmy o możliwościach własnego narzędzia, wystawione na jej blogu obok odnośnika do produktu.
Dla właściciela strony żaden z tych sporów nie zmienia zadania na dziś. Zmienia się natomiast tempo, w jakim luki będą wychodziły na wierzch, i dotyczy to obu stron. Błąd siedział w kodzie od najwcześniejszych wersji WordPressa i przeoczyły go wszystkie dotychczasowe audyty. W blisko cztery dni znalazł go system, któremu człowiek wskazał badanie i cel. Taki system da się przy tym uruchomić równolegle w wielu kopiach.
Podsumowanie
Jedna spacja po nawiasie ostrym wystarczyła, żeby dwa filtry WordPressa przestały się zgadzać co do tego, czym jest wpisany tekst. Na tym rozjeździe stoi łańcuch od ekranu logowania do uruchomienia kodu na serwerze. Nosi numer CVE-2026-64638 i 8,9 punktu na 10 w bazie NVD. Pełne przejęcie wymaga jednak, żeby zalogowany administrator wszedł na przygotowaną stronę. Automatycznego zagrożenia dla wszystkich instalacji tu więc nie ma. Numer bezpiecznej wersji przesunął się z lipcowego 7.0.2 na 7.0.3 z 6 sierpnia, a backporty do starszych gałęzi wychodzą stopniowo. Osobno warto odnotować to, jak lukę znaleziono. System pwn.ai dostał od ludzi punkt wyjścia i cel, a przez cztery dni zbudował działający łańcuch tam, gdzie kolejne audyty niczego nie zauważyły.
Newsletter · DevstockAcademy & Kodożercy
Bądź na bieżąco ze światem IT, AI i automatyzacji
Co wtorek: newsy z branży, praktyczne tipy i narzędzia które warto znać. Zero spamu.
