53 procent stron WordPress z niezałatanymi CVE: co naprawdę pokazuje audyt GuardingWP 2026

#53 procent stron WordPress z niezałatanymi CVE: co naprawdę pokazuje audyt GuardingWP 2026

Ponad połowa. Pierwszy raport State of WordPress Security 2026 od GuardingWP, wyciągnięty ze skanowania 424 potwierdzonych instalacji WordPressa w ponad czterdziestu branżach, mówi że 53 procent stron uruchamia przynajmniej jeden plugin niosący znany niezałatany CVE. Ten sam raport stawia 93.2 procent bez nowoczesnych nagłówków bezpieczeństwa, 55.9 procent z wyciekającą wersją WordPressa przez meta tag generator i 35.8 procent wciąż serwujących XML-RPC.

Liczba nie zaskakuje. Zaskoczeniem byłby wynik poniżej trzydziestu procent, bo struktura ekonomiki pluginów WordPressa zwraca tę stawkę domyślnie. Ten artykuł czyta dane GuardingWP jako dowód, że lekarstwo to nie lepszy firewall, lecz kontrole łańcucha dostaw już wpisane w NIS2 artykuł 21 paragraf 2 litera d i DORA artykuł 28, a w polskiej jurysdykcji dodatkowo egzekwowane przez ustawę o krajowym systemie cyberbezpieczeństwa i obowiązki zgłaszania incydentów do CERT Polska.

Tekst sąsiaduje z naszymi pillarami o NIS2 i DORA na WordPressie: stack zgodności 2026 i o łańcuchu dostaw pluginów WordPressa, oraz uzupełnia pracę o WCAG, BFSG i EAA, bo zespoły zakupowe pakują dziś dostępność, bezpieczeństwo i odporność w jeden arkusz dostawcy.

#Najważniejsze w jednym akapicie

• GuardingWP 2026 zeskanował 424 instalacje WordPressa w ponad 40 branżach. Cztery główne wyniki są wykrywalne z pojedynczej odpowiedzi HTTP.
• 53 procent stron z przynajmniej jednym niezałatanym CVE w pluginie. 93.2 procent bez nowoczesnych nagłówków. 55.9 procent z wyciekiem wersji. 35.8 procent z otwartym XML-RPC.
• Stawka 53 procent to nie zaniedbanie userów, to domyślny output ekonomiki pluginów: 20 do 40 third-party publisherów na instalację, niezsynchronizowane cykle patchowania, właściciel jako integrator ostatniej szansy.
• WordPress 7.0 dodał infrastrukturę AI z API keys do warstwy sekretów admina. Oliver Sild z Patchstack publicznie zapowiedział “absolutny pęd hakerów po API keys”.
• NIS2 artykuł 21 paragraf 2 litera d i DORA artykuł 28 już kodują lekarstwo: udokumentowana polityka obsługi luk, cadence patchowania, ocena dostawców, rejestr umów ICT trzeciej strony.
• Dźwignia, która przesuwa organizację WordPress z porażki compliance do passu, to nie plugin. To framework kontroli.

#Liczby z primary source

Cztery główne metryki w raporcie GuardingWP 2026 są obserwowalne z zewnątrz strony. Skaner potrzebuje tylko odpowiedzi strony głównej i statusu HTTP na /xmlrpc.php, żeby wyliczyć każdą z nich. To ważne, bo audytorzy compliance coraz częściej zaczynają od evidence zewnętrznych - telemetria Patchstack, GreyNoise i Internet Archive są stałą infrastrukturą pomiarową.

Dla unijnego czytelnika regulowanego baseline dla tych liczb wygląda inaczej dla każdej z nich. CSP i HSTS są wymienione w dobrych praktykach ENISA dla bezpieczeństwa systemów dostępnych z internetu. XML-RPC jako narażony jest explicite w OWASP Top 10. Niezałatane CVE w pluginach mapują się wprost na artykuł 21 NIS2 - kontrolę łańcucha dostaw. Raport GuardingWP to nie lista ciekawostek. To cztery już skodyfikowane luki compliance - zmierzone.

#Dlaczego 53 procent to liczba strukturalna

Typowa instalacja WordPressa uruchamia od dwudziestu do czterdziestu pluginów. WordPress.org publikuje ponad 60 000 pluginów, z długim ogonem autorów bez finansowanych zespołów bezpieczeństwa. Cykl patchowania pluginu A i pluginu B nie jest skoordynowany. Właściciel strony jest integratorem ostatniej szansy. Kiedy CVE-2025-XYZW ląduje w pluginie A we wtorek, właściciel strony jest jedyną stroną, która może zdecydować, czy patchować, czy przetestować przeciw reszcie stacka i czy patch zepsuje plugin B.

Ekonomika sytuacji nie sprzyja integratorowi. Patchowanie dwudziestu pluginów na miesiąc z testowaniem regresyjnym to praca inżynierska. Większość stron WordPress nie ma budżetu na tę pracę. Dlatego większość stron WordPress nie jest patchowana. Stawka 53 procent to równowaga rynkowa.

Są dwie drogi wyjścia z tej równowagi, i tylko jedna jest trwała.

Pierwsza droga to skurczenie stacka pluginów. Strona WordPress z ośmioma pluginami, wszystkimi pod aktywnym utrzymaniem, indywidualnie zakresowanymi do funkcji, którą właściciel może opisać jednym zdaniem, to traktowalna powierzchnia patchowania. Dyscyplina kosztuje więcej z góry, bo zespół musi albo zbudować funkcję w customowym kodzie, albo żyć bez niej, ale miesięczny koszt utrzymania pozostania-patchowanym spada proporcjonalnie.

Druga droga to outsourcing cadence’u patchowania do managed providera, który to faktycznie robi. To dostarczają poważni managed WordPress hosci i poważne agencje, i tam gdzie kontrakt mówi explicite “stosujemy security patche w ciągu X godzin od release vendora, najpierw staging, potem produkcja”. Jeśli kontrakt tego nie mówi, cadence nie istnieje, a strona jest statystycznie w 53 procentach.

#Co zmienił WordPress 7.0

WordPress 7.0 “Armstrong” zszedł w tym samym tygodniu publikacji co raport GuardingWP. Wydanie 7.0 dodało AI Services Registry i Abilities API, co znaczy że powierzchnia admina przechowuje teraz API keys do hostowanych dostawców modeli (Anthropic, OpenAI), bram AI (Vercel) i self-hostowanych endpointów. Te klucze mają stronę rozliczalną. Skompromitowane konto admina nie jest już tylko problemem integralności treści. Jest też problemem wycieku kosztów.

Oliver Sild, założyciel Patchstack, napisał publicznie na X w dniu release’u 7.0: “there will be an absolute rush by hackers to steal API keys.”

Justin Nealey, pisząc na swoim blogu, sflagował powiązany praktyczny ból głowy: WP AI Client nie ma wbudowanego throttle, a kilka pluginów dzielących jeden klucz API potrafi wydmuchać limit tokenów w niecałą minutę. To nie hipotetyczny adwersarz, to życzliwa misconfiguracja. Obie postacie wycieku kosztów implikują tę samą kontrolę: scoping kluczy per connector, rate limity na bramie a nie w pluginie, audit log który wyciąga niespodziewane zużycie tokenów wewnątrz jednego cyklu rozliczeniowego.

Powierzchnia kontroli jest dobrze zrozumiała. To ta sama powierzchnia, którą zespół finansowy zastosowałby do każdego nowo wybitego rozliczalnego credentiala. WordPress jest niezwykły tylko w tym, że historycznie nie miał tej kategorii credentiala w adminie.

#Jak NIS2 czyta dane GuardingWP

Dyrektywa NIS2 (2022/2555), artykuł 21, paragraf 2, wymienia dziesięć środków technicznych i organizacyjnych, które podmioty kluczowe i ważne muszą stosować. Litera d, słowami samej dyrektywy, wymaga “bezpieczeństwo łańcucha dostaw, w tym aspekty związane z bezpieczeństwem dotyczące relacji między każdym podmiotem a jego bezpośrednimi dostawcami lub usługodawcami”. Instalacja WordPressa z niezałatanymi CVE w pluginach zawodzi literę d niezależnie od tego, czy plugin jest indywidualnie krytyczny - bo podmiot nie ocenił i nie zarządził ryzykiem dostawcy.

Lekarstwo pod NIS2 jest proceduralne. Obejmuje:

• Udokumentowaną politykę obsługi i ujawniania luk, której podmiot faktycznie przestrzega. Paragraf 2 litera b.
• Cadence patchowania i aktualizacji z docelowym czasem zastosowania CVE-ratedych poprawek. Paragraf 2 litera f w połączeniu z literą b.
• Ocenę dostawców obejmującą autorów pluginów, którzy sami są dostawcami ICT trzeciej strony - ich dojrzałość bezpieczeństwa, kanał ujawniania, latencja patchowania. Paragraf 2 litera d.
• Rejestr umów ICT trzeciej strony, który pod DORA ma też explicite obowiązek z artykułu 28 dla podmiotów finansowych.

Strona WordPress może przejść techniczne czytanie NIS2 (czyli nie mieć niezałatanych CVE w dniu audytu) i wciąż polegnąć na czytaniu proceduralnym, jeśli podmiot nie pokaże dokumentów. Stawka 53 procent sugeruje, że dokumenty nie istnieją dla połowy stron w zakresie.

W Polsce dodatkową warstwą egzekucji jest krajowy system cyberbezpieczeństwa, gdzie operator usługi kluczowej i podmiot ważny zgłaszają incydenty do CERT Polska (CSIRT NASK). Audyt KSC może kwestionować brak udokumentowanej polityki obsługi luk w portfelu pluginów. Profil 53 procent jest zatem nie tylko ryzykiem operacyjnym, ale jasnym ryzykiem regulacyjnym dla podmiotów w polskim zakresie KSC.

To ta część rozmowy, której większość vendorów narzędzi security unika. Sprzedaż firewalla jest łatwiejsza niż sprzedaż frameworku kontroli. Framework kontroli to to, czego NIS2 faktycznie wymaga.

#Jak DORA czyta dane GuardingWP dla instytucji finansowych

Rozporządzenie DORA (2022/2554) jest bezpośrednio stosowane od 17 stycznia 2025. Stosuje się do instytucji kredytowych, instytucji płatniczych, ubezpieczycieli, firm inwestycyjnych, dostawców usług krypto-assets i mniej więcej piętnastu dalszych kategorii wymienionych w artykule 2.

DORA artykuł 28 reguluje zarządzanie ryzykiem ICT trzeciej strony. Autorzy pluginów WordPress publicznej strony instytucji finansowej wpadają w tę definicję. Dwa praktyczne konsekwencje wynikają z profilu GuardingWP.

Po pierwsze, podmiot musi prowadzić rejestr umów z dostawcami ICT trzeciej strony (artykuł 28 paragraf 3). Rejestr musi obejmować publisherów pluginów, których kod uruchamia się na publicznej stronie. Dla większości instytucji finansowych ten rejestr aktualnie nie zawiera autorów pluginów WordPress w ogóle. Lekarstwo nie jest techniczne, jest administracyjne: wyciągnij listę aktywnych pluginów, zmapuj każdy plugin do publishera, dołącz kanał obsługi luk publishera i latencję patchowania, dodaj wpis do rejestru.

Po drugie, artykuł 28 paragraf 5 wymaga, żeby umowy z dostawcami ICT obsługującymi krytyczne lub ważne funkcje zawierały “strategie wyjścia, w szczególności ustalające obowiązkowy odpowiedni okres przejściowy”. Dla strony WordPress, która zależy od jednego specjalistycznego pluginu dla krytycznego workflow (dostawa podpisanego dokumentu, adapter KYC, asemblowanie PDF raportu regulacyjnego), strategia wyjścia musi istnieć w piśmie. Rzadko istnieje.

To nie są efektowne kontrole. To papier. To też jak wygląda faktyczny audyt DORA.

#Gdzie raport GuardingWP jest za cichy

Główne liczby raportu są dobrze udokumentowane, ale raport niedoszacowuje jedną rzecz, którą czytelnik praktyk powinien zobaczyć jasno: stawka 53 procent koncentruje się w długim ogonie instalacji małych biznesów i jest dużo niższa w instalacjach z managed providerem na kontrakcie, który explicite obejmuje patchowanie bezpieczeństwa. Nie mamy podziału GuardingWP, ale nasza własna koncentracja stron WordPress pod kontraktem utrzymania czyta jednocyfrowo dla stawki niezałatanego CVE w dowolnym tygodniu audytu.

Implikacja nie jest taka, że managed WordPress hosci i security-focused agencje są doskonali. Jest taka, że równowagowy 53 procent to średnia rynkowa, która miesza dwie bardzo różne populacje. Kupujący czytający raport nie powinien dojść do “WordPress jest niebezpieczny”. Powinien dojść do “strony WordPress bez frameworku kontroli są niebezpieczne, a rozmiar nieobsługiwanego ogona to połowa rynku”.

#Co zmienia poważne potraktowanie WordPress 7.0

Wydanie WordPress 7.0 z infrastrukturą AI jest użyteczną funkcją wymuszającą dla nieobsługiwanego ogona, bo dodanie API keys do powierzchni admina czyni przypadek wycieku kosztów widocznym w sposób, w jaki XSS albo eksfiltracja zapisanego credentiala nie były. Osobę z finansów, której nie ruszyło “możesz mieć niezałatany CVE”, ruszy “twoja faktura od dostawcy AI za zeszły miesiąc była trzycyfrowo wyższa niż zwykle i nie potrafimy wyjaśnić tego ruchu”.

Powierzchnia kontroli, która zamyka ryzyko klucza AI, zamyka też dużo reszty wyników GuardingWP, bo kontrole się pokrywają:

• Nowoczesne nagłówki bezpieczeństwa (CSP, HSTS, X-Content-Type, Referrer-Policy) na edge. Jeden Cloudflare Worker albo jeden blok .htaccess. Zamyka lukę 93.2 procent.
• Tłumienie meta tagu generator. Jeden filtr. Zamyka lukę 55.9 procent.
• XML-RPC wyłączony albo rate-limited na edge. Jedna reguła firewalla albo linia .htaccess. Zamyka lukę 35.8 procent.
• Scoping kluczy API, rate limit per connector, alertowanie anomalii zużycia tokenów. Nowa powierzchnia kontroli. Zamyka ryzyko 7.0 zanim ma skalę.

To nie są heroiczne zadania inżynierskie. To pozycje w scope of work managed-services.

#Praktykowane czytanie

Prowadzę audyty bezpieczeństwa stron WordPress pod unijnymi jurysdykcjami od piętnastu lat. Wzorzec tygodnia w 2026 jest ten sam co w 2018: strona przychodzi z dwudziestoma ośmioma pluginami, właściciel nie potrafi wymienić co robi osiem z nich, a ciężar testowania regresyjnego patchowania wszystkiego w jednym cyklu przekracza budżet. Stawka GuardingWP jest wiernym opisem tego wzorca. Lekarstwo, które faktycznie działa w horyzoncie rocznym, to to, którego nikt nie lubi:

1. Audyt listy pluginów. Usuń każdy plugin, którego funkcji właściciel nie potrafi opisać jednym zdaniem.
2. Wymień dwa albo trzy pluginy, które przeżyły, ale mają stagnujące kanały utrzymania.
3. Ustanów udokumentowany cadence patchowania i politykę obsługi luk. Spisz to. Odnoś się do tego nazwą w kontrakcie utrzymania.
4. Dodaj rejestr umów ICT trzeciej strony odzwierciedlający aktywną listę pluginów i aktualizowany przy każdym dodaniu lub usunięciu pluginu.
5. Dla instalacji WordPress 7.0 zakresuj każdy klucz dostawcy AI per connector, zastosuj rate limity na bramie i alertuj anomalia zużycia tokenów.

Pierwsze cztery pozycje to praca compliance pod NIS2 artykuł 21. Piąta to nowa klasa kontroli wprowadzona przez 7.0. Żadna z pięciu nie jest kupowana od vendora jako produkt. To jak praktyk WordPress przychodzi do pracy.

#Argument zamykający

Raport GuardingWP 2026 jest najbardziej użytecznym pojedynczym dokumentem, jaki społeczność bezpieczeństwa WordPress opublikowała w pięć lat, bo przeformułowuje debatę, która tkwiła w trybie tool-comparison za długo. Właściwe czytanie to nie “przerzuć się na Patchstack” albo “zainstaluj Wordfence”. To: połowa rynku nie prowadzi frameworku kontroli, kontrole zamykające lukę są skodyfikowane w NIS2 i DORA, a kupujący po stronie regulacji UE w 2026 jest tym z dźwignią, żeby wymusić kontrole w kontrakcie dostawcy.

Dla czytelnika z agencji WordPress jest to najsilniejszy moment komercyjny od lat, żeby sprzedawać framework, nie narzędzie. Liczba 53 procent jest leadem następnej prezentacji ofertowej dostawcy.

#Źródła

• GuardingWP, State of WordPress Security 2026 (strona raportu)
• Dyrektywa (UE) 2022/2555 o bezpieczeństwie sieci i systemów informatycznych (NIS2), artykuł 21
• Rozporządzenie (UE) 2022/2554 o operacyjnej odporności cyfrowej sektora finansowego (DORA), artykuł 28
• Patchstack
• ENISA: dobre praktyki bezpieczeństwa systemów dostępnych z internetu
• CERT Polska (CSIRT NASK)
• Krajowy System Cyberbezpieczeństwa
• OWASP Top 10 2021

#Powiązane teksty u nas

• Pillar: NIS2 i DORA na WordPressie: stack zgodności 2026
• Łańcuch dostaw pluginów WordPress 2026: cztery backdoory w jednym miesiącu
• WCAG 2.2, BFSG i EU Accessibility Act: stack zgodności 2026 dla WordPressa
• Audyt bezpieczeństwa WordPress
• DORA artykuł 28 ryzyko ICT trzeciej strony: audyt dostawcy hostingu i WAF WordPress

Ostatnio sprawdzone: 2026-05-23