Podatne wtyczki WordPress: audyt, aktualizacja, wymiana

Najsłabszym punktem strony na WordPressie rzadko jest sam WordPress. Radzenie sobie z podatnościami we wtyczkach WordPress sprowadza się do czterech nawyków: dokładnie wiedzieć, co jest zainstalowane, szybko aktualizować, usuwać to, co niepotrzebne, i wymieniać to, czego nikt już nie utrzymuje.

Ten poradnik pokazuje, jak wyrobić sobie każdy z tych nawyków, jak rozpoznać porzucone wtyczki i co zrobić w niewygodnej sytuacji, gdy podatność jest już publicznie znana, a poprawki wciąż brak. To jeden z punktów naszej listy kontrolnej bezpieczeństwa WordPressa, a dla większości stron punkt najważniejszy.

Podatności we wtyczkach WordPress w liczbach

Szczegółowe dane roczne pochodzą z raportu Patchstack State of WordPress Security in 2026, który obejmuje rok 2025. Patchstack to firma z branży bezpieczeństwa, która sprzedaje ochronę przed tymi zagrożeniami, dlatego raport warto traktować jako jedno dobrze poinformowane źródło, a nie oficjalną statystykę. Najważniejsze ustalenia:

• 11 334 nowe podatności w ekosystemie WordPressa w 2025 roku, o 42% więcej niż w 2024 roku.
• 91% dotyczyło wtyczek, a 9% motywów. W rdzeniu WordPressa znaleziono sześć, wszystkie o niskim priorytecie.
• 17% (1966) miało wysoki poziom zagrożenia i prawdopodobnie posłuży do zautomatyzowanych masowych ataków.
• 46% nie miało poprawki od twórcy w chwili publicznego ujawnienia.
• Najczęściej wykorzystywaną kategorią była niewłaściwa kontrola dostępu (broken access control).

Innymi słowy: lista wtyczek to Państwa powierzchnia ataku. Każda wtyczka to kod innego zespołu, któremu powierzają Państwo swoją stronę i przechowywane na niej dane.

Dlaczego liczy się tempo aktualizacji

Atakujący nie wybierają stron ręcznie. Skanują internet w poszukiwaniu podatnej wersji wtyczki i automatycznie atakują każde trafienie. Według tego samego raportu ważona mediana czasu do masowego wykorzystania intensywnie atakowanych podatności wyniosła pięć godzin, a mniej więcej połowa podatności o dużym wpływie została wykorzystana w ciągu 24 godzin.

Comiesięczne okno serwisowe jest w takich przypadkach zbyt wolne. Poprawki bezpieczeństwa potrzebują szybszej ścieżki niż aktualizacje funkcjonalne. Terminowe łatanie to także podstawowy element „odpowiednich” środków bezpieczeństwa, których wymaga art. 32 RODO, a dyrektywa NIS2 wymienia postępowanie w przypadku podatności wśród minimalnych środków (art. 21 ust. 2 lit. e) dla organizacji objętych jej zakresem.

Krok 1: Prowadzić spis wtyczek

Nie da się aktualizować ani oceniać czegoś, o czego istnieniu się nie wie. Prosty spis dla każdej strony, choćby w arkuszu kalkulacyjnym, powinien zawierać:

• nazwę wtyczki, jej slug i zainstalowaną wersję
• źródło: WordPress.org, komercyjny producent lub własny kod
• powód instalacji i osobę, która o nią poprosiła
• status licencji i datę odnowienia w przypadku wtyczek premium
• informację, czy automatyczne aktualizacje są włączone

Większość tych danych WP-CLI wyeksportuje jednym poleceniem:

wp plugin list --fields=name,status,version,update_version,auto_update

Nowsze wersje WP-CLI pokazują też, co WordPress.org wie o każdej wtyczce, w tym czy została zamknięta:

wp plugin list --fields=name,version,wporg_status,wporg_last_updated

Wtyczki spoza WordPress.org mają tu zwykle puste pola, więc ich status trzeba sprawdzić u producenta. Motywy sprawdza się analogicznie poleceniem wp theme list.

Krok 2: Usuwać nieużywane wtyczki

Po dezaktywacji WordPress przestaje ładować wtyczkę, ale jej pliki zostają na serwerze. Niektóre podatności można wywołać bezpośrednim żądaniem do plików wtyczki, a nieaktywne wtyczki łatwo wypadają z rutyny aktualizacji. Sam WordPress na ekranie Kondycja witryny (Narzędzia → Kondycja witryny) ostrzega, że nieaktywne wtyczki są kuszącym celem dla atakujących.

Gdy wtyczka nie jest już potrzebna, należy wykonać kopię zapasową, a następnie dezaktywować ją i usunąć na ekranie Wtyczki. W wierszu poleceń:

wp plugin uninstall old-slider --deactivate

wp plugin uninstall uruchamia własną procedurę deinstalacji wtyczki, która może usunąć również jej ustawienia i dane z bazy, a następnie kasuje pliki. wp plugin delete usuwa wyłącznie pliki. Wszystko, co będzie jeszcze potrzebne, trzeba wcześniej wyeksportować.

Typowi kandydaci do usunięcia: wtyczki testowe pozostałe po projekcie, dublujące się funkcje (dwie wtyczki do cache albo do SEO), jednorazowe narzędzia do migracji oraz wtyczki, których zadanie przejął już rdzeń WordPressa.

Krok 3: Wymieniać porzucone i pirackie wtyczki

Wtyczka bez aktywnego opiekuna nie dostanie poprawki, gdy wyjdzie na jaw kolejna podatność.

Oznaki, że wtyczka została porzucona

• Brak aktualizacji od dawna. Warto sprawdzić datę ostatniej aktualizacji (Last updated) na stronie wtyczki w WordPress.org. Serwis wyświetla też komunikat, gdy wtyczka nie była testowana z 3 ostatnimi głównymi wydaniami WordPressa.
• Zamknięcie w WordPress.org. Czerwony komunikat informuje, że wtyczka została zamknięta i nie można jej już pobrać. Po 60 dniach dopisywany jest powód, a jednym z możliwych jest „Security Issue” (problem z bezpieczeństwem). Niezależnie od powodu, dopóki wtyczka jest zamknięta, przez WordPress.org nie dotrą do Państwa żadne aktualizacje.
• Wątki na forum wsparcia bez odpowiedzi, zwłaszcza te, w których mowa o problemach z bezpieczeństwem.
• Wtyczki premium, których producent zamilkł: brak nowych wpisów w dzienniku zmian, niedziałające odnawianie licencji, cisza w dziale wsparcia.

Dokumentacja WordPress.org o alertach i ostrzeżeniach wyjaśnia znaczenie tych komunikatów. Gdy się pojawią, warto zaplanować wymianę, zanim wymusi ją sytuacja awaryjna.

Nigdy nie używać wtyczek „nulled”

Wtyczki „nulled” to pirackie kopie wtyczek premium z usuniętym sprawdzaniem licencji. Kod zmodyfikowała nieznana osoba trzecia i nikt nie wie, co jeszcze w nim zmieniono. Ukryte tylne furtki to dobrze znany problem takich kopii. Nie dostają one też aktualizacji ani wsparcia, więc nie da się ich załatać, gdy pojawi się kolejna podatność.

Jeśli taka wtyczka znajdzie się na stronie, należy zastąpić ją licencjonowaną kopią i traktować stronę jako potencjalnie przejętą.

Krok 4: Szybko aktualizować – automatycznie lub przez staging

Od wersji WordPress 5.5 automatyczne aktualizacje można włączyć dla każdej wtyczki osobno w kolumnie „Automatyczne aktualizacje” na ekranie Wtyczki. Domyślnie WordPress uruchamia je dwa razy dziennie i wysyła wyniki e-mailem (dokumentacja WordPress.org). W WP-CLI: wp plugin auto-updates enable --all.

Biorąc pod uwagę, jak szybko następują ataki, automatyczne aktualizacje są właściwym ustawieniem domyślnym dla większości wtyczek. Środowisko testowe (staging) nadal ma sens tam, gdzie nieudana aktualizacja kosztuje realne pieniądze:

Niezależnie od wybranej drogi warto mieć kopie zapasowe, które przynajmniej raz faktycznie przywrócono, i upewnić się, że ktoś czyta e-maile o aktualizacjach.

Krok 5: Śledzić podatności i reagować

Gdzie sprawdzać podatności wtyczek

• Dziennik zmian na stronie wtyczki w WordPress.org lub w serwisie producenta. Warto szukać wpisów typu „security fix”, choć niektórzy producenci opisują poprawki bardzo ogólnikowo.
• Publiczne bazy podatności, takie jak bazy WPScan i Patchstack, które można przeszukiwać według nazwy wtyczki. Obie prowadzą firmy, które sprzedają też usługi bezpieczeństwa.
• Komunikaty i newslettery producentów wtyczek premium.

Ręczne sprawdzanie dziesiątek wtyczek szybko przestaje być wykonalne. Security Audit & Compliance, wtyczka audytowa od secaudit.eu, od razu po instalacji wskazuje nieaktualne wtyczki, motywy i rdzeń. Po włączeniu sprawdzania podatności porównuje także zainstalowane wersje z bezpłatną bazą podatności secaudit.eu, budowaną co noc z oficjalnej listy CVE; lista wtyczek nigdy nie opuszcza Twojej strony.

Co zrobić, gdy poprawki jeszcze nie ma

Prawie połowa wszystkich podatności (46%) nie miała poprawki w chwili ujawnienia. Jeśli dotyczy to używanej wtyczki:

1. Ocenić stopień narażenia. Czy do podatnej funkcji mają dostęp anonimowi odwiedzający, czy tylko zalogowani administratorzy?
2. Dezaktywować wtyczkę, jeśli przez jakiś czas można się bez niej obejść, i usunąć ją, jeśli poprawka się nie pojawi.
3. Zastąpić ją utrzymywaną alternatywą, jeśli producent milczy.
4. Zastosować wirtualne łatanie (virtual patching), jeśli wtyczka jest niezbędna: niektóre zapory aplikacji webowych (WAF) i usługi bezpieczeństwa oferują reguły blokujące żądania pasujące do znanego exploita. To pozwala zyskać na czasie, ale nie naprawia kodu.
5. Sprawdzić, czy nie doszło do włamania, zwłaszcza jeśli luka była publicznie znana przez jakiś czas, zanim ją Państwo zauważyli. Dobrym punktem wyjścia jest nasza lista oznak, że strona na WordPressie została zhakowana.

Sprzedawcy wtyczek a Cyber Resilience Act

Dla producentów postępowanie z podatnościami staje się obowiązkiem prawnym, a część przepisów już obowiązuje. Płatna wtyczka lub motyw sprzedawane klientom w UE to „produkt z elementami cyfrowymi” w rozumieniu Cyber Resilience Act (CRA, akt w sprawie cyberodporności), a ich sprzedawca jest producentem. Od 11 września 2026 producenci muszą zgłaszać aktywnie wykorzystywane podatności w swoich produktach za pośrednictwem pojedynczej platformy sprawozdawczej ENISA (Single Reporting Platform): wczesne ostrzeżenie w ciągu 24 godzin, zgłoszenie w ciągu 72 godzin i raport końcowy w ciągu 14 dni od udostępnienia środka naprawczego.

Od 11 grudnia 2027 zaczną obowiązywać główne obowiązki, w tym aktualizacje zabezpieczeń w okresie wsparcia, proces postępowania z podatnościami, polityka skoordynowanego ujawniania podatności i zestawienie komponentów oprogramowania (SBOM). Bezpłatne, niemonetyzowane wtyczki open source co do zasady nie podlegają temu reżimowi dla producentów. Szczegóły opisujemy w poradniku o Cyber Resilience Act dla sprzedawców wtyczek.

Najczęściej zadawane pytania

Czy dezaktywowana wtyczka jest bezpieczna?

Nie. Jej pliki pozostają na serwerze i nadal mogą zawierać kod podatny na atak. Nieużywane wtyczki należy usuwać.

Czy włączyć automatyczne aktualizacje dla wszystkich wtyczek?

Dla większości wtyczek tak, w połączeniu z niezawodnymi kopiami zapasowymi. Wtyczki kluczowe dla biznesu warto najpierw przetestować na stagingu, ale to opóźnienie powinno być krótkie.

Co, jeśli wtyczka, z której korzystam, została zamknięta w WordPress.org?

Należy traktować ją jako nieutrzymywaną, dopóki nie zostanie ponownie udostępniona w poprawionej wersji, i już teraz zacząć szukać alternatywy.

Ten artykuł ma charakter ogólnoinformacyjny i nie stanowi porady prawnej.