TL;DR: Najgroźniejsze podatności WordPressa w 2026 roku to dwie krytyczne luki w samym rdzeniu: wp2shell z lipca (naprawiona w wersji 7.0.2) i CVE-2026-87902 z września (naprawiona w 7.1.2), którą atakujący zaczęli wykorzystywać kilka godzin po publikacji łatki. Do tego dochodzą masowo atakowane wtyczki, m.in. Elementor Pro, All-in-One WP Migration i Modular DS, oraz przejęte wtyczki z wbudowanym backdoorem. Według Patchstack 91% luk w ekosystemie WordPressa siedzi we wtyczkach, a 46% nie miało łatki w dniu ujawnienia. Jeśli Twoja strona nie działa na WordPressie 7.1.3 z aktualnymi wtyczkami, zaktualizuj ją dziś i sprawdź, czy nie ma śladów włamania.
Na co dzień czyszczę zhakowane strony WordPress, więc o lukach w zabezpieczeniach nie czytam tylko w biuletynach. Widzę ich skutki: podmienione strony główne, obce konta administratorów, spam w wynikach Google. Rok 2026 był pod tym względem wyjątkowo intensywny. W tym wpisie zebrałem najważniejsze podatności WordPressa z tego roku, wyjaśniam, kogo dotyczyły i co z tego wynika dla właściciela firmowej strony. Wszystkie numery CVE, wersje i daty mają przypisy do źródeł.
Krótki słowniczek na start. Podatność (luka) to błąd w kodzie, który pozwala zrobić coś, czego autor nie przewidział, np. wgrać plik albo przejąć konto. CVE to numer katalogowy luki, nadawany po to, żeby wszyscy mówili o tym samym. CVSS to ocena powagi w skali 0-10, gdzie wszystko powyżej 9 oznacza poziom krytyczny.
Ostatnia głośna luka w rdzeniu: CVE-2026-87902 i wersja 7.1.2
22 września 2026 roku WordPress wydał wersję 7.1.2, która łatała jedną krytyczną lukę. Zespół WordPressa napisał wprost, że to wydanie bezpieczeństwa i strony trzeba zaktualizować natychmiast[2]. Luka CVE-2026-87902 pozwalała niezalogowanemu atakującemu sprawić, że WordPress przy wyborze szablonu strony dołączy wskazany lokalny plik PHP spoza katalogu motywu. W sprzyjających warunkach kończy się to zdalnym wykonaniem kodu (RCE), czyli przejęciem serwera[3].
Skala była ogromna: podatne były wszystkie wersje od 4.7.0 do 7.1.1. Poprawki trafiły do 7.1.2, 7.0.6, 6.9.9, 6.8.10 i starszych gałęzi aż do 4.7.37. Patchstack ocenił lukę na 9.2 w skali CVSS[4]. Najbardziej uderza tempo: pierwsze próby ataku Patchstack zarejestrował 22 września o 11:49 UTC, czyli tego samego dnia, w którym wyszła łatka. Atakujący analizowali różnice w kodzie poprawki, w ciągu doby ruch atakujący wzrósł dziesięciokrotnie, a ataki szły z kilkuset adresów[4].
Jest też dobra wiadomość. Do skutecznego ataku potrzebne były konkretne warunki: motyw z katalogiem o nazwie zaczynającej się od „page-” i odpowiedni plik dostępny na serwerze. Badacze sami przyznali, że te warunki zmniejszają szansę udanego włamania[5]. Mimo to amerykańska agencja CISA dopisała tę lukę do katalogu podatności aktywnie wykorzystywanych 25 września 2026[6]. Wordfence wdrożył regułę firewalla blokującą atak, ale użytkownicy darmowej wersji dostają takie reguły z 30-dniowym opóźnieniem[7].
wp2shell: lipcowa luka, która działała na czystym WordPressie
17 lipca 2026 roku wyszły wersje 7.0.2, 6.9.5 i 6.8.6, łatające dwie luki tworzące razem łańcuch nazwany wp2shell[8]. Pierwsza, CVE-2026-63030, to pomylenie tras w endpoincie wsadowym REST API (adres /wp-json/batch/v1). W połączeniu z drugą luką pozwalała na wstrzyknięcie zapytań do bazy danych (SQL injection) i zdalne wykonanie kodu. Dotyczyła wersji 6.9.0-6.9.4 oraz 7.0.0-7.0.1, a rekord CVE ocenia ją na 9.8[9]. Druga, CVE-2026-60137, to SQL injection przez parametr author__not_in, z oceną 5.9, obejmująca także gałąź 6.8[10].
Dlaczego to było tak groźne? Atak działał na domyślnej instalacji, bez żadnych wtyczek i bez logowania[11]. Publiczny kod demonstracyjny potrafił odczytać bazę danych razem z zaszyfrowanymi hasłami administratorów[12]. Obie luki trafiły do katalogu CISA jako aktywnie wykorzystywane już 21 lipca 2026[6]. WordPress wymuszał aktualizację na stronach z włączonymi auto-aktualizacjami[11], ale strony z wyłączonymi aktualizacjami zostały odsłonięte.
Z mojej praktyki: włamanie przez endpoint batch
Widziałem w tym roku włamania, w których atakujący wszedł właśnie przez endpoint batch w REST API. Nie twierdzę, że w każdym przypadku chodziło o ten sam numer CVE, ale wzorzec był podręcznikowy. Na stronie firmy usługowej spod Warszawy atakujący podmienił stronę główną, dodał ukryte konto administratora, a backdoory (tylne furtki, czyli kod dający mu stały dostęp) schował w bazie danych, w tabeli wtyczki do snippetów kodu. W plikach nie było więc nic podejrzanego. Sprawca wracał kilka razy, dopóki nie zamknęliśmy wszystkich furtek. Wniosek: sama aktualizacja po włamaniu nie usuwa tego, co atakujący zdążył zostawić.
Co zrobić, jeśli Twoja strona była podatna
- Sprawdź wersję. W kokpicie: Kokpit, Aktualizacje. Aktualna wersja to 7.1.3 z 6 października 2026[13].
- Zaktualizuj rdzeń, wtyczki i motyw. Najpierw kopia zapasowa, potem aktualizacja.
- Sprawdź ślady włamania. Lista użytkowników z rolą administratora, ustawienie domyślnej roli nowych użytkowników (powinna być „Subskrybent”), nazwa witryny, nieznane wtyczki, także te w katalogu mu-plugins. Jeśli coś się nie zgadza, przeczytaj mój poradnik zhakowana strona WordPress - objawy i co zrobić.
Wydania bezpieczeństwa rdzenia WordPress w 2026
Poniżej oś ostatnich aktualizacji bezpieczeństwa WordPressa. Widać na niej, że łatki wychodzą co kilka tygodni, a każda z nich zamyka od jednej do kilkunastu luk.
| Wersja | Data | Co łatała |
|---|---|---|
| 7.0.2 (oraz 6.9.5, 6.8.6) | 17.07.2026 | Łańcuch wp2shell: CVE-2026-63030 i CVE-2026-60137, SQL injection prowadzące do RCE[8] |
| 7.0.3 | 06.08.2026 | 12 poprawek, m.in. XSS na ekranie logowania bez logowania, eskalacja uprawnień w multisite, SSRF, obejście potwierdzenia e-mail[14] |
| 7.1 „Mary Lou” | 19.08.2026 | Wydanie główne[15] |
| 7.1.1 | 17.09.2026 | 11 poprawek, m.in. stored XSS przez niezalogowanego odwiedzającego, path traversal w REST API, nadpisywanie cudzych wpisów przez rolę Współpracownik[16] |
| 7.1.2 | 22.09.2026 | 1 krytyczna luka CVE-2026-87902 (dołączanie plików prowadzące do RCE), backport do 4.7[2] |
| 7.1.3 | 06.10.2026 | 7 poprawek, m.in. stored XSS w panelu Komentarze, DoS, SQL injection w eksporcie WXR, ujawnianie prywatnych komentarzy[13] |
Ważna uwaga z ogłoszenia wersji 7.1.3: aktywnie wspierana jest tylko najnowsza wersja WordPressa. Starsze gałęzie, aż do 4.7, dostają wyłącznie przeniesione poprawki bezpieczeństwa[13]. Jeśli strona od lat siedzi na starej gałęzi „bo działa”, to łatki do niej docierają, ale cała reszta już nie.
Najgroźniejsze luki we wtyczkach w 2026
Rdzeń to tylko część problemu. W praktyce strony najczęściej padają przez wtyczki. Wybrałem siedem głośnych przypadków z tego roku, dotyczących popularnych wtyczek, które spotykam na stronach firmowych i w sklepach.
| Wtyczka | CVE i typ luki | Podatne / naprawione | Ataki |
|---|---|---|---|
| Modular DS (ok. 40 tys. instalacji) | CVE-2026-23550, przejęcie konta admina bez logowania, CVSS 10.0[17] | do 2.5.1 / 2.5.2 | Tak, od 13.01.2026[18] |
| WooCommerce Wholesale Lead Capture | CVE-2026-27540, wgrywanie dowolnych plików bez logowania, CVSS 9.0[19] | do 2.0.3.1 / 2.0.3.2 | Tak, webshelle, ponad 100 000 zablokowanych prób[20] |
| Elementor Pro (6 mln+) | CVE-2026-32475, wgranie pliku PHP przez pole formularza, CVSS 9.0[21] | do 4.2.1 / 4.2.2 | Tak, ataki na strony potwierdzone[22] |
| All-in-One WP Migration and Backup (5 mln+) | CVE-2026-19949, SQL injection prowadzące do RCE przy odtwarzaniu kopii, CVSS 8.8[23] | do 7.109 / 7.110 | Publiczny kod ataku, ok. 3,25 mln niezałatanych stron na początku września[24] |
| The Events Calendar (600 tys.+) | CVE-2026-78159 i CVE-2026-78006, wstrzyknięcie kodu bez logowania, CVSS 9.8[25][26] | do 6.17.3 / 6.17.3.1 oraz do 6.17.4 / 6.17.4.1 | Brak potwierdzonych ataków[27] |
| Unlimited Elements For Elementor (300 tys.+) | CVE-2026-18561, SQL injection bez logowania, CVSS 7.5[28] | do 2.0.16 / 2.0.17 | Brak danych |
| WPForms Lite (5 mln+) | CVE-2026-84744, uruchamianie dowolnych shortcode'ów bez logowania, CVSS 6.5[29] | 1.5.0.1-2.0.2 / 2.0.2.1 | Brak danych |
Wspólny mianownik? Prawie wszystkie te luki da się wykorzystać bez logowania. Atakujący nie musi znać Twojego hasła. Wystarczy, że strona ma podatną wersję wtyczki, a boty skanują internet w poszukiwaniu takich stron przez całą dobę. Szczególnie pouczający jest przypadek Wholesale Lead Capture: atakujący wgrywali webshelle (pliki dające zdalną kontrolę nad serwerem) długo po wydaniu łatki, bo wiele sklepów jej po prostu nie zainstalowało[20].
Przypadek All-in-One WP Migration pokazuje z kolei coś mniej oczywistego. Wtyczka do kopii zapasowych, czyli narzędzie, które ma Cię chronić, sama stała się furtką: luka uruchamiała się przy imporcie lub odtwarzaniu kopii[23].
Backdoor w przejętych wtyczkach, czyli atak na łańcuch dostaw
Najbardziej niepokojąca historia roku nie dotyczyła błędu w kodzie, tylko zaufania. Atakujący kupił na platformie Flippa ponad 30 wtyczek EssentialPlugin, łącznie z około 400 tysiącami instalacji. Backdoor wstawił w sierpniu 2025 roku, a uruchomił go dopiero 5-6 kwietnia 2026[30]. Złośliwy kod dopisywał się do pliku wp-config.php i serwował spam SEO wyłącznie robotowi Google, więc właściciele stron niczego nie widzieli.
WordPress.org zamknął 31 wtyczek jednego dnia i wymusił aktualizację do wersji 2.6.9.1. Ta aktualizacja wyłączyła komunikację z serwerem atakującego, ale nie usunęła kodu, który już siedział w wp-config.php[30]. Strona „zaktualizowana” nadal mogła być zainfekowana.
Spotkałem też odmianę tego problemu w praktyce. Na stronie innej firmy usługowej znalazłem wtyczkę udającą narzędzie do czyszczenia pamięci podręcznej (cache). W rzeczywistości był to backdoor z własnym endpointem REST, przez który atakujący zdalnie wstrzykiwał linki do treści. Miał też własne hasło aplikacji, więc zmiana hasła administratora niczego nie dawała. Dlatego przy każdym przeglądzie sprawdzam nie tylko wersje wtyczek, ale też to, czy każdą z nich ktoś świadomie zainstalował.
Statystyki Patchstack: skąd biorą się luki
Patchstack co roku podsumowuje bezpieczeństwo ekosystemu WordPressa. Raport opublikowany w lutym 2026 (dane za 2025 rok) pokazuje kilka liczb, które warto znać[1]:
- 11 334 nowe podatności w ekosystemie WordPressa w 2025 roku, o 42% więcej niż rok wcześniej (7 966)[1].
- 91% luk dotyczyło wtyczek, 9% motywów, a w samym rdzeniu było ich zaledwie kilka[1].
- 46% podatności nie miało łatki w dniu publicznego ujawnienia. Rok wcześniej było to 33%[1][31].
- Mediana czasu od ujawnienia luki do masowych ataków to 5 godzin[1].
- Typowe zabezpieczenia hostingowe zatrzymały tylko 12% ataków na znane, wykorzystywane podatności[1].
- Znane wykorzystywane luki trafiały się trzy razy częściej we wtyczkach i motywach premium niż w darmowych[1].
Tempo nie zwalnia. Tylko w tygodniu 21-27 września 2026 Wordfence opisał 319 podatności w 222 wtyczkach, w tym 14 krytycznych, a 13 z nich nie miało jeszcze łatki[7]. Te liczby obalają dwa popularne mity. Po pierwsze, „mam płatną wtyczkę, więc jest bezpieczna”. Po drugie, „hosting mnie chroni”. Ani jedno, ani drugie nie wystarcza.
Wnioski dla właściciela firmy
Nie musisz śledzić bazy CVE. Musisz mieć proces, który zadziała szybciej niż boty. Z mojej praktyki wynika kilka prostych zasad:
- Aktualizacje w ciągu godzin, nie tygodni. Przy medianie 5 godzin do masowych ataków comiesięczny przegląd to za mało. Włącz auto-aktualizacje rdzenia, a krytyczne wtyczki aktualizuj tego samego dnia.
- Mniej wtyczek to mniejsze ryzyko. Każda wtyczka to kolejny kod, który może mieć lukę. Usuń te, których nie używasz, zamiast je tylko wyłączać.
- Firewall aplikacyjny (WAF). Skoro prawie połowa luk nie ma łatki w dniu ujawnienia, potrzebujesz warstwy, która zablokuje atak, zanim pojawi się poprawka.
- Kopia zapasowa poza serwerem. Trzymaj ją z dala od strony i testuj odtwarzanie.
- Aktualizacja to nie sprzątanie. Jeśli strona była podatna przez dłuższy czas, po aktualizacji sprawdź, czy ktoś nie zostawił furtek.
Szczegółową listę zabezpieczeń opisałem w osobnym wpisie: jak zabezpieczyć stronę WordPress przed włamaniem. Jeśli nie masz czasu pilnować tego samodzielnie, możesz zlecić stałą opiekę nad stroną WordPress, czyli aktualizacje, kopie zapasowe i monitoring. A jeśli podejrzewasz, że coś już się wydarzyło, sprawdź, na czym polega naprawa zhakowanej strony WordPress.
FAQ - podatności WordPress w 2026
Jaka wersja WordPressa jest teraz bezpieczna?
Na dziś najnowsza jest wersja 7.1.3 z 6 października 2026 roku. Tylko najnowsza wersja jest aktywnie wspierana, a starsze gałęzie dostają wyłącznie poprawki bezpieczeństwa. Najprościej: zaktualizuj do najnowszej wersji i włącz auto-aktualizacje.
Czy aktualizacja WordPressa usuwa skutki włamania?
Nie. Aktualizacja zamyka lukę, ale nie usuwa backdoorów, obcych kont administratorów ani kodu w bazie danych. Przypadek EssentialPlugin pokazał, że nawet wymuszona aktualizacja zostawiła złośliwy kod w wp-config.php. Po aktualizacji podatnej strony zawsze warto sprawdzić ślady włamania.
Skąd mam wiedzieć, że wtyczka na mojej stronie ma lukę?
WordPress pokazuje dostępne aktualizacje w kokpicie, ale nie mówi, które z nich są poprawkami bezpieczeństwa. Informacje o lukach publikują m.in. Wordfence, Patchstack i WPScan. W praktyce lepiej założyć, że każda aktualizacja może łatać lukę, i instalować je szybko.
Czy wtyczki premium są bezpieczniejsze od darmowych?
Nie ma takiej reguły. Według Patchstack znane i wykorzystywane podatności występowały trzy razy częściej w komponentach premium niż w darmowych. Elementor Pro, jedna z najpopularniejszych płatnych wtyczek, miał w tym roku krytyczną lukę atakowaną od dnia ujawnienia.
Czy hosting chroni moją stronę przed atakami na WordPressa?
Tylko częściowo. W teście Patchstack typowe zabezpieczenia hostingowe zablokowały zaledwie 12% ataków na znane wykorzystywane luki. Hosting chroni serwer, ale nie zna specyfiki Twoich wtyczek, dlatego potrzebne są aktualizacje i firewall aplikacyjny.
Podejrzewasz, że Twoja strona została zaatakowana?
Jeśli Twoja strona działała na podatnej wersji WordPressa lub wtyczki, a teraz widzisz dziwne przekierowania, nowe konta albo ostrzeżenia w Google, nie czekaj. Zajmuję się naprawą i czyszczeniem zhakowanych stron WordPress: usuwam złośliwy kod z plików i bazy, zamykam furtki i zabezpieczam stronę przed powrotem atakującego. Jeśli wolisz zapobiegać, w ramach administracji stronami zajmuję się aktualizacjami, kopiami i monitoringiem. Zadzwoń: +48 606 719 343 lub napisz: lukasz@freelancerka.com.
Przypisy i źródła
Wszystkie źródła zweryfikowane; dostęp: 8 października 2026.
- Patchstack, „State of WordPress Security in 2026” (25.02.2026) - patchstack.com
- WordPress.org News, „WordPress 7.1.2 Release” (22.09.2026) - wordpress.org
- CVE.org, „CVE-2026-87902” (22.09.2026) - cve.org
- Patchstack, „CVE-2026-87902: Attackers Started Probing WordPress Sites Hours After the Patch” (22.09.2026) - patchstack.com
- The Hacker News, „Attackers Exploit WordPress CVE-2026-87902 Within Hours of Disclosure” (24.09.2026) - thehackernews.com
- CISA, „Known Exploited Vulnerabilities Catalog” (wersja 2026.10.04) - cisa.gov
- Wordfence, „Wordfence Intelligence Weekly WordPress Vulnerability Report (September 21, 2026 to September 27, 2026)” (01.10.2026) - wordfence.com
- WordPress.org News, „WordPress 7.0.2 Release” (17.07.2026) - wordpress.org
- CVE.org, „CVE-2026-63030” (17.07.2026) - cve.org
- CVE.org, „CVE-2026-60137” (2026) - cve.org
- Rapid7, „CVE-2026-63030: wp2shell, a Critical Remote Code Execution Vulnerability in WordPress Core” (17.07.2026) - rapid7.com
- The Hacker News, „New wp2shell WordPress Core Flaw Lets Unauthenticated Attackers Run Code” (07.2026) - thehackernews.com
- WordPress.org News, „WordPress 7.1.3 Maintenance and Security Release” (06.10.2026) - wordpress.org
- WordPress.org News, „WordPress 7.0.3 release” (06.08.2026) - wordpress.org
- WordPress.org News, „WordPress 7.1 Mary Lou” (19.08.2026) - wordpress.org
- WordPress.org News, „WordPress 7.1.1 Maintenance and Security Release” (17.09.2026) - wordpress.org
- CVE.org, „CVE-2026-23550” (14.01.2026) - cve.org
- The Hacker News, „Critical WordPress Modular DS Plugin Flaw Actively Exploited to Gain Admin Access” (01.2026) - thehackernews.com
- CVE.org, „CVE-2026-27540” (19.03.2026) - cve.org
- The Hacker News, „Attackers Exploit WooCommerce Wholesale Lead Capture Flaw to Plant PHP Web Shells” (16.09.2026) - thehackernews.com
- CVE.org, „CVE-2026-32475” (19.08.2026) - cve.org
- SecurityWeek, „Elementor Pro WordPress Plugin Vulnerability Exploited to Hack Sites” (05.09.2026) - securityweek.com
- CVE.org, „CVE-2026-19949” (25.08.2026) - cve.org
- Tech Times, „WordPress Backup Plugin Flaw: 3.25 Million Sites Exposed, Exploit Code Active” (03.09.2026) - techtimes.com
- CVE.org, „CVE-2026-78159” (12.09.2026) - cve.org
- CVE.org, „CVE-2026-78006” (12.09.2026) - cve.org
- Sucuri Blog, „Vulnerability & Patch Roundup - September 2026” (30.09.2026) - blog.sucuri.net
- CVE.org, „CVE-2026-18561” (11.09.2026) - cve.org
- CVE.org, „CVE-2026-84744” (28.09.2026) - cve.org
- InfoQ, „Attacker Bought 30 WordPress Plugins on Flippa and Backdoored All of Them” (06.05.2026) - infoq.com
- Patchstack, „State of WordPress Security in 2025” (14.03.2025) - patchstack.com
