Ktoś kupił 30 pluginów WordPress i wstawił backdoora we wszystkich

Osiem miesięcy. Tyle backdoor siedział w 31 pluginach WordPress, zanim ktokolwiek go zauważył. Nie chodzi o atak hakerski na serwery. Nie chodzi o złamane hasło. Ktoś po prostu kupił popularne pluginy na Flippie za sześć cyfr, podmienił jedną linijkę kodu i czekał. 7 kwietnia 2026 zespół WordPress.org zamknął wszystkie 31 pluginów jednym ruchem. Setki tysięcy stron internetowych miały w swoim rdzeniu kod, który serwował spam wyłącznie dla Googlebota. Właściciele stron nie widzieli nic podejrzanego. Ich pozycje w Google natomiast mogły już ucierpieć.

Jak wyglądał atak krok po kroku?

Historia zaczyna się w 2024 roku. Zespół deweloperów znany jako WP Online Support (później Essential Plugin) prowadził portfolio 31 pluginów WordPress od 2015 roku. Pluginy miały setki tysięcy aktywnych instalacji. Countdown Timer Ultimate, Popup Anything on Click, WP Testimonial, SP FAQ, Timeline Slider i ponad 20 innych.

Pod koniec 2024 roku przychody z portfolio spadły o 35-45%. Deweloperzy wystawili je na Flippie. Kupił je człowiek przedstawiający się jako “Kris”, z doświadczeniem w SEO, kryptowalutach i marketingu hazardowym.

8 sierpnia 2025 roku nowy właściciel opublikował wersję 2.6.7 jednego z pluginów. Changelog mówił o “poprawkach kompatybilności”. W rzeczywistości doszło 191 linii złośliwego kodu do pliku class-anylc-admin.php. Plik urósł z 473 do 664 linii.

Co robi ten kod? Łączy się z zewnętrznym serwerem analytics.essentialplugin.com, pobiera instrukcje i wykonuje dowolne funkcje PHP przesłane z serwera. Technicznie to klasyczny RCE (Remote Code Execution) przez deserializację. Plugin ma otwarty endpoint API z ustawieniem permission_callback: __return_true. Co to oznacza w praktyce? Każdy może się połączyć, bez uwierzytelniania.

Przez 8 miesięcy backdoor był uśpiony. Żadna złośliwa aktywność. Żaden alarm. Dopiero 5-6 kwietnia 2026 serwer zaczął wysyłać payloady.

Co backdoor robił po aktywacji?

Atak był sprytnie zaprojektowany. Serwer C2 (command and control) wysyłał plik o nazwie wp-comments-posts.php. Nazwa celowo naśladuje prawdziwy plik WordPressa wp-comments-post.php, różnica to jedna litera “s”. Administrator przeglądający pliki na serwerze mógł go po prostu przeoczyć.

Następnie backdoor wstrzykiwał około 6 KB kodu PHP bezpośrednio do wp-config.php, najważniejszego pliku konfiguracyjnego WordPressa. Dopisywał złośliwy kod w tej samej linii co require_once ABSPATH . wp-settings.php;. Każde normalne przeglądanie pliku pokazywało tę linię jako poprawną. Trzeba było przewinąć daleko w prawo, żeby zobaczyć doklejony fragment.

Co robił wstrzyknięty kod? Serwował spam, przekierowania i fałszywe strony. Jednak wyłącznie dla Googlebota. Właściciel strony odwiedzający własny serwis widział wszystko normalnie. Google widział zupełnie inną treść. Ta technika to cloaking i jest jednym z najcięższych wykroczeń w oczach Google. Strony mogły stracić pozycje w wynikach wyszukiwania, nawet jeśli właściciel nie miał pojęcia o infekcji.

Dodatkowy element: adres serwera C2 był rozwiązywany przez smart kontrakt na blockchainie Ethereum. Atakujący mógł zmienić adres serwera w dowolnym momencie, bez dotykania kodu pluginu. Tradycyjne blokowanie domen nic tu nie dało.

Jak sprawdzić czy Twoja strona jest zainfekowana?

WordPress.org wymusił aktualizację do wersji 2.6.9.1 na 8 kwietnia 2026. Ta wersja dezaktywuje backdoora w kodzie pluginu. Jednak nie czyści wp-config.php. Jeśli Twoja strona była zainfekowana, złośliwy kod wciąż tam siedzi i nadal serwuje spam dla Googlebota.

Dlatego ręczna weryfikacja jest konieczna. Otwórz plik wp-config.php na swoim serwerze i sprawdź jego rozmiar. Czysty wp-config.php typowej instalacji WordPress waży około 3-4 KB. Jeśli plik waży 9-10 KB, masz problem. Dodatkowo sprawdź czy w katalogu WordPressa nie ma pliku wp-comments-posts.php (z “s” na końcu). Prawdziwy plik core’a to wp-comments-post.php bez “s”.

Które pluginy zostały zamknięte? Oto pełna lista wszystkich 31 pozycji:

1. Accordion and Accordion Slider
2. Album and Image Gallery Plus Lightbox
3. Audio Player with Playlist Ultimate
4. Blog Designer for Post and Widget
5. Countdown Timer Ultimate
6. Featured Post Creative
7. Footer Mega Grid Columns
8. Hero Banner Ultimate
9. HTML5 VideoGallery Plus Player
10. Meta Slider and Carousel with Lightbox
11. Popup Anything on Click
12. Portfolio and Projects
13. Post Category Image with Grid and Slider
14. Post Grid and Filter Ultimate
15. Preloader for Website
16. Product Categories Designs for WooCommerce
17. Responsive WP FAQ with Category (wcześniej znany jako SP FAQ)
18. SlidersPack – All in One Image Sliders
19. SP News And Widget
20. Styles for WP PageNavi – Addon
21. Ticker Ultimate
22. Timeline and History Slider
23. Woo Product Slider and Carousel with Category
24. WP Blog and Widgets
25. WP Featured Content and Slider
26. WP Logo Showcase Responsive Slider and Carousel
27. WP Responsive Recent Post Slider
28. WP Slick Slider and Image Carousel
29. WP Team Showcase and Slider
30. WP Testimonial with Widget
31. WP Trending Post Slider and Widget

Jeśli masz którykolwiek z tych pluginów, sprawdź swoją stronę natychmiast. Autor “Essential Plugin” już nie istnieje w wyszukiwarce WordPress.org.

Podobny atak zdarzył się już w 2017 roku. Ktoś o pseudonimie “Daley Tias” kupił plugin Display Widgets z 200 000 instalacjami za zaledwie 15 000 dolarów i wstrzyknął spam z pożyczkami chwilówkowymi. Ta sama osoba skompromitowała co najmniej 9 kolejnych pluginów tą samą metodą.

Jeśli interesujesz się bezpieczeństwem narzędzi w ekosystemie automatyzacji, przeczytaj nasz artykuł o krytycznej luce RCE w n8n i sposobach aktualizacji.

Dlaczego WordPress.org nie chroni przed tym atakiem?

Największy problem jest systemowy. WordPress.org nie ma mechanizmu powiadamiania użytkowników o zmianie właściciela pluginu. Nie wymaga dodatkowego przeglądu kodu po pojawieniu się nowego committera. Nie monitoruje transakcji na platformach typu Flippa.

W praktyce wygląda to tak: ktoś kupuje plugin z 200 000 instalacjami, dostaje dostęp do repozytorium na WordPress.org, publikuje aktualizację z backdoorem i nikt nie pyta dlaczego. System zaufania WordPress opiera się na założeniu, że deweloper który raz przeszedł review będzie uczciwy na zawsze. Gdy ktoś inny przejmuje konto, zaufanie przenosi się automatycznie.

Porównajmy to z innymi ekosystemami. npm (JavaScript) po serii ataków supply chain wprowadził obowiązkowe 2FA dla popularnych pakietów. PyPI (Python) zaczął wymagać podpisów kryptograficznych. WordPress.org wciąż pozwala na zmianę właściciela pluginu bez żadnego dodatkowego audytu.

Dla właścicieli stron WordPress lekcja jest jasna: nie ufaj pluginowi tylko dlatego, że ma dużo instalacji i dobrą historię. Historia może należeć do kogoś innego niż obecny właściciel. Monitoruj aktualizacje pluginów. Sprawdzaj changelogi. Jeśli plugin nagle zmienia autora, potraktuj to jako żółtą flagę.

Więcej o tym, jak atakujący wykorzystują zaufanie w ekosystemach narzędzi AI i automatyzacji, przeczytasz w naszym artykule o 137 000 problemach bezpieczeństwa w serwerach MCP.

Kurs n8n 2.0 · Kodożercy

Od zera do własnych automatyzacji – bez doświadczenia

Kurs n8n 2.0 od Kodożerców przeprowadzi Cię krok po kroku przez budowanie prawdziwych automatyzacji. Od webhooków, przez integracje z API, po własne przepływy danych – wszystko bez programowania.

Sprawdź kurs n8n 2.0 →

FAQ – Najczęstsze pytania o atak na pluginy WordPress

Czy moja strona WordPress jest bezpieczna jeśli nie mam tych pluginów?

Tak, ten konkretny atak dotyczył wyłącznie 31 pluginów od autora “Essential Plugin”. Jeśli żadnego z nich nie masz zainstalowanego, Twoja strona nie jest zagrożona tym backdoorem. Jednak atak pokazuje szerszy problem: każdy plugin WordPress może zmienić właściciela bez Twojej wiedzy.

Czy automatyczna aktualizacja WordPress rozwiązała problem?

Częściowo. WordPress.org wymusił aktualizację do wersji 2.6.9.1, która dezaktywuje backdoora w kodzie pluginu. Jednak aktualizacja nie czyści pliku wp-config.php. Jeśli Twoja strona była zainfekowana, musisz ręcznie usunąć złośliwy kod z tego pliku.

Jak mogę chronić się przed podobnymi atakami w przyszłości?

Monitoruj changelogi aktualizacji pluginów. Sprawdzaj czy autor pluginu się nie zmienił. Używaj firewalla aplikacyjnego (np. Wordfence). Rób regularne backupy i porównuj rozmiary kluczowych plików. Rozważ automatyzację monitoringu zmian w plikach na serwerze.

Podsumowanie

Ktoś kupił 31 pluginów WordPress za sześć cyfr, wstawił backdoora i czekał 8 miesięcy. Backdoor serwował spam wyłącznie dla Googlebota, więc właściciele stron nie widzieli nic podejrzanego. WordPress.org zamknął wszystkie pluginy 7 kwietnia 2026, ale wymuszona aktualizacja nie oczyściła zainfekowanych plików wp-config.php. Problem jest systemowy: WordPress.org nie powiadamia użytkowników o zmianie właściciela pluginu i nie wymaga dodatkowego audytu po takiej zmianie. Każdy kto ma stronę na WordPressie powinien sprawdzić swoje pluginy i rozmiar pliku wp-config.php.

Mateusz Wojdalski

Specjalista SEO i content marketingu w Devstock. Zajmuję się strategią treści, automatyzacją procesów marketingowych i wdrożeniami AI w codziennej pracy. Badam nowe narzędzia, adaptuję je do realnych zadań i piszę o tym, co faktycznie działa.