Tak, jeśli utrzymujesz WordPressa w wersji starszej niż 7.0.3 — niezależnie od tego, czy to blog, strona firmowa, intranet, czy sklep na WooCommerce. CVE-2026-64638 (CVSS 8.9, nazwa „XSS2Shell") to reflected XSS w wp-login.php dostępny bez uwierzytelnienia i bez kliknięcia użytkownika. Jeden wadliwy request logowania wystarczy, by wstrzyknąć JavaScript w originie WordPressa; w pełnym łańcuchu atak prowadzi do przejęcia sesji administratora i wykonania dowolnego kodu PHP. Patch jest już wydany (7.0.3, 06.08.2026, plus backporty na starsze gałęzie). Działanie priorytetowe: zaktualizuj WordPressa i zweryfikuj, czy nikt nie zostawił backdoora przed patchem. (88 słów)

Najważniejsze fakty

• WordPress 7.0.3 wydany 6 sierpnia 2026 r. łata CVE-2026-64638 (CVSS 8.9) — reflected XSS w wp-login.php osiągalny bez uwierzytelnienia i bez interakcji użytkownika; luka dotyczy WSZYSTKICH wersji WordPressa od 4.7 wzwyż (ok. 500M+ instalacji), backporty dostępne dla starszych gałęzi.
• Root cause to różnica w parserach: PHP strip_tags() przepuszcza znacznik ze spacją (< x>...), a WordPress KSES/wp_kses_post() traktuje go jako legalny HTML; to wystarczy do DOM clobberingu i uruchomienia skryptu w originie WordPressa.
• Łańcuch XSS2Shell: reflected XSS → DOM clobbering → Script gadget via SOME (Same-Origin Method Execution) → jeden klik administratora → instalacja złośliwej wtyczki → dowolny kod PHP na serwerze (RCE).
• Lukę odkryły open-source'owe agenty AI (zespół pwn.ai, ~4 dni pracy) — to pierwszy szeroko opisany przypadek luki core'a WordPressa znalezionej przez autonomiczny system AI w normalnym trybie działania.
• Na 07.08.2026 nie ma potwierdzonej eksploatacji in-the-wild; luka nie jest wpisana do CISA KEV; publiczny PoC pojawił się na GitHubie (Boreas37/CVE-2026-64638-PoC).
• Wtyczki, motywy i integracje WooCommerce są zależne od core'a WordPressa — podatność core'a propaguje się na wszystkie warstwy powyżej.
• Odkrycie wpisuje się w trend „AI-discovered vulnerabilities": wcześniej w 2026 r. agenty AI znalazły m.in. luki w OpenAI Operator i Hugging Face; tempo publikacji rośnie.

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 (WordPress Security Release, GHSA, Patchstack) i renomowanych mediów (Niebezpiecznik, Hadrian, Brandefense); wnioski i rekomendacje są oznaczone jako analiza; nie deklarujemy zgodności z NIS2/KSC ani nie wydajemy opinii prawnej. Rola inż. Marcina Białczyka: analiza operacyjna z perspektywy praktyka (zarządzanie stronami i sklepami, higiena aktualizacji, widoczność ekspozycji), 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
Ekran logowania WordPressa	Pre-auth reflected XSS w wp-login.php, każda wersja < 7.0.3	Każdy publiczny endpoint logowania to potencjalna furtka do konta administratora, a przez konto admina — do plików i bazy	30 dni: patch do 7.0.3 lub najnowszego backportu (Security Release). 90 dni: ograniczenie ekspozycji wp-login.php (WAF, geoblokada, MFA), audyt kont adminów
Łańcuch XSS → RCE	DOM clobbering + SOME + instalacja wtyczki = wykonanie kodu PHP	Nawet jednorazowe kliknięcie administratora może zainstalować backdoor; zwykły audit „kto ma konto admin" nie wystarczy	30 dni: przegląd listy wtyczek i motywów (nieznane = wyłączone). 90 dni: zasada „minimalna liczba adminów", automatyczny alarm na nową wtyczkę
Odkrycie przez AI	Pierwszy szeroko opisany core-vuln WP znaleziony przez autonomiczny agent AI (~4 dni)	AI-discovered vulnerabilities rosną w tempie; standardowe okno „tajemnicy" przed publicznym PoC się skraca	30 dni: aktualizacja w 72 h od Security Release (dokumentowana). 90 dni: polityka aktualizacji (owner, SLA, dowód) z uwzględnieniem AI-found bugs
Widoczność i wykrywanie	Brak potwierdzonej in-the-wild eksploatacji; PoC publiczny; logi WordPressa standardowo nie wystarczają	Bez dodatkowej widoczności nie odróżnisz „bezpiecznej" strony od skompromitowanej przed patchem	30 dni: przegląd logów WP i serwera pod kątem nietypowych POST do wp-login.php, nieznanych wtyczek, plików .php w wp-content/. 90 dni: P0 Passive Exposure Snapshot od zewnątrz + monitoring zmian plików
Obowiązki NIS2/KSC	Incydent ilustruje wymagania art. 21 (środki zarządzania ryzykiem) i art. 23 (raportowanie)	Strona WP z obsługą klientów, danymi osobowymi lub integracją z produkcją to aktywo, które trzeba zinwentaryzować	30 dni: wpis strony WP do rejestru aktywów. 90 dni: Evidence Pack (kontrola → właściciel → dowód) obejmujący aktualizacje i audyt wtyczek
Suply chain (wtyczki/motywy)	Podatność core'a propaguje się na wtyczki i motywy; backdoor może powstać w wyniku instalacji złośliwej wtyczki	Sklep na WooCommerce, strona z formularzem kontaktowym, blog z newsletterm — każdy element jest potencjalnie podatny	30 dni: przegląd źródeł wtyczek (oficjalny katalog vs. nulled). 90 dni: SBOM dla aplikacji webowej (lista wtyczek + wersji), automatyczne alerty na nowe pliki PHP

Perspektywa inż. Marcina Białczyka

Z perspektywy operacyjnej: WordPress pozostaje najpopularniejszym CMS-em świata i jednocześnie jednym z najczęstszych wektorów incydentów, z którymi stykamy się u klientów B2B. Większość zespołów traktuje aktualizacje WordPressa jako „działanie IT", a nie jako decyzję bezpieczeństwa. Tymczasem CVE-2026-64638 pokazuje coś ważniejszego: atakujący nie potrzebuje dziś phishingowej socjotechniki ani znanego hasła — wystarczy, że strona logowania jest osiągalna, a WordPress nie jest zaktualizowany. Pre-auth XSS bez kliknięcia użytkownika zmienia rachunek ryzyka: nie można już powiedzieć „nic się nie stało, bo nikt nie kliknął". W praktyce pierwszą rzeczą, którą sprawdzam u klienta po tego typu advisory, jest nie wersja core'a, ale to, czy strona logowania jest w ogóle dostępna z internetu i czy logi się gdzieś zbierają.

Drugi wątek to AI-discovered vulnerabilities. Fakt, że autonomiczny agent AI znalazł tę lukę w cztery dni, a nie w cztery tygodnie jak tradycyjny badacz, oznacza skrócenie okna „tajemnicy". Jeśli luka jest prosta (a XSS2Shell jest prosta w koncepcie), publiczny PoC pojawia się szybko — Boreas37 opublikował go na GitHubie w ciągu dni. Dlatego w planie 30/90 dni kładę nacisk na 72-godzinny SLA patchowania Security Release WordPressa (nie „w wolnej chwili"), a nie tylko na sam fakt aktualizacji. To nie jest nadmiar ostrożności — to nowa higiena w świecie, w którym AI skraca czas do PoC.

Trzeci wątek to widoczność po patchu. Łańcuch XSS2Shell kończy się instalacją złośliwej wtyczki — czyli po zaktualizowaniu core'a strona może nadal być skompromitowana. Dlatego samo „update WordPressa do 7.0.3" nie zamyka sprawy; trzeba przejrzeć listę zainstalowanych wtyczek, sprawdzić daty dodania plików w wp-content/plugins/, zweryfikować konta adminów. W kontekście NIS2/KSC pytanie brzmi nie „czy zareagowałeś", ale „czy potrafisz to udokumentować: kto, kiedy, jaką wersję zainstalował, jaki był zakres ekspozycji, jakie dowody zachowałeś". Interpretacja prawna tych obowiązków należy do kancelarii; nasza rola to strona techniczno-operacyjna: rejestr aktywów, Evidence Pack, plan reagowania.

Najczęściej zadawane pytania

Czy luka dotyczy tylko WordPressa 7.x?

Nie — advisory GHSA-52p2-r8wf-jcrf obejmuje wszystkie wersje od 4.7 wzwyż; Security Release 7.0.3 jest główną poprawką, ale backporty są też dla starszych gałęzi. Sprawdź wersję w wp-includes/version.php niezależnie od tego, jaki branch prowadzisz.

Czy WAF przed wp-login.php wystarczy?

WAF utrudnia masową eksploatację i daje czas na patch, ale nie zastępuje aktualizacji: reguły można obejść wariantami wektora (parser differential jest wrażliwy na drobne różnice). Traktuj WAF jako warstwę uzupełniającą, nie jako remedium.

Jak sprawdzić, czy strona została już skompromitowana?

Porównaj listę zainstalowanych wtyczek z oczekiwaną, sprawdź pliki .php w wp-content/plugins/ z datą nowszą niż ostatnia planowana instalacja, przejrzyj logi serwera pod kątem nietypowych POST do wp-login.php i wykonaj audyt kont adminów. Jeśli nie masz baseline — wykonaj P0 Passive Exposure Snapshot od zewnątrz i przegląd hosta.

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. Wtyczki nulled i backdoory w core to klasyczny efekt uboczny braku podstawowej higieny — nie wymaga on rozbudowanej oceny technicznej ani deklaracji zgodności z NIS2.

Jak CHORS.NET pomaga

CHORS.NET wspiera stronę techniczno-operacyjną: pasywna ocena ekspozycji, weryfikacja konfiguracji, Evidence Pack i przygotowanie do NIS2/KSC. Zobacz: Usługi, Jak pracuje CHORS.NET, NIS2/KSC Readiness Center oraz 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 PoC, KEV i publicznych exploitów może się zmienić — weryfikuj przed podjęciem decyzji operacyjnych.
• Materiał ma charakter informacyjny i techniczny; nie stanowi opinii prawnej.

Źródła

1. WordPress Security Release 7.0.3
2. Niebezpiecznik: „Nowy atak na WordPressa znaleziony przez AI — od XSS do admina i wykonania dowolnego kodu PHP"
3. GHSA-52p2-r8wf-jcrf (GitHub Security Advisory)
4. Hadrian: „WordPress XSS2Shell: Unauthenticated Login-Screen XSS to PHP Code Execution (CVE-2026-64638)"
5. Patchstack: „WordPress 7.0.3 Released: 12 Vulnerabilities Found and Fixed"
6. Brandefense: „XSS2Shell (CVE-2026-64638): WordPress Login Page Pre-Auth XSS to RCE"
7. GBHackers: „Critical WordPress Vulnerability Allows Pre-Auth XSS to Remote Code Execution"