Fałszywa weryfikacja Cloudflare na WordPressie. Jak wyglądał atak ClickFix i jak go usunąłem

28 października strona klienta — biura doradztwa podatkowego na WordPressie — zamiast treści pokazywała ekran „Verify you are human” stylizowany na Cloudflare. Prawdziwa strona dalej tam była, tylko ukryta pod spodem. Poniżej opisuję, co to było, gdzie siedziało i jak to posprzątałem.

Sytuacja jest świeża. Gdy szukałem w Google domen i nazwy wtyczki z tego ataku, znalazłem chyba tylko dwa artykuły na ten temat. Dlatego opisuję go dokładnie — jeśli trafisz na to samo, będziesz mieć od czego zacząć.

Panel może pokazywać, że wszystko jest w porządku, a odwiedzający widzą coś zupełnie innego. Zdjęcie: Zulfugar Karimov / Unsplash.

Co widzieli odwiedzający

Na każdej publicznej stronie, na samym początku sekcji head, pojawiał się wstrzyknięty blok kodu. Robił dwie rzeczy:

• ukrywał prawdziwą treść strony (visibility: hidden), dopóki do dokumentu nie została dodana klasa cf-on,
• odszyfrowywał krótką listę adresów i ładował skrypt embed.js z pierwszego serwera, który odpowiedział.

Domeny, z których ładował się skrypt:

• js-static.cfd
• js-static.pro
• js-static.site
• js-static.online

Ten skrypt to strona ClickFix. Udaje kontrolę przeglądarki Cloudflare i na Windowsie namawia odwiedzającego, żeby nacisnął Win + R, wkleił polecenie ze schowka i zatwierdził Enterem. W ten sposób użytkownik sam instaluje sobie złośliwe oprogramowanie. To nie jest odosobniony przypadek — szwajcarskie NCSC pisze o ponad 100 tys. zainfekowanych stron z fałszywymi CAPTCHA, w większości na WordPressie. Skrypt rozpoznaje system odwiedzającego i dopasowuje polecenie do Windowsa lub macOS.

Dlaczego właściciel mógł tego nie zauważyć

Ten atak jest zrobiony tak, żeby administrator go nie widział:

• panel wp-admin wyglądał normalnie — kod sprawdzał is_admin() i w panelu się nie uruchamiał,
• ekran logowania wp-login.php też był czysty, bo ta strona nie wywołuje wp_head,
• na Linuksie przeglądarka często w ogóle nie pokazuje nakładki, bo zdalny skrypt buduje pełny komunikat tylko dla Windowsa.

Czyli: właściciel loguje się do panelu, wszystko działa, a klienci wchodzący na stronę widzą fałszywą weryfikację. CookieYes i Google Tag Manager w nagłówku motywu były prawdziwe i nie miały z tym nic wspólnego.

Gdzie to siedziało: fałszywa wtyczka

Cały mechanizm siedział w jednym pliku: wp-content/plugins/plugin-autoupdate/plugin-autoupdate.php. WordPress pokazywał go na liście jako „Plugin Autoupdate”, wersja 1.0.4, autor „WP Helpers”. To nie jest prawdziwa wtyczka. Podpinała się pod wp_head z priorytetem 1, odszyfrowywała zakodowany blok i wypisywała go na stronie przy każdym żądaniu. Nic nie było zapisane w bazie — dlatego szukanie w treściach wpisów niczego by nie dało.

W tym samym folderze leżał plik tekstowy z około 50 tys. loginów i haseł wykradzionych z przeglądarek Chrome — do zupełnie innych serwisów. Domeny tej strony w nim nie było. To łup atakującego, odłożony na cudzym serwerze. Nie publikuję go i nie przekazuję dalej.

Jak wtyczka trafiła na serwer, nie wiadomo na pewno. Na stronie był zainstalowany WP File Manager 8.0.5, który pozwala wgrać plik PHP do katalogu wtyczek każdemu, kto ma sesję administratora. To prawdopodobny drugi krok, ale nie dowód na to, jak atakujący dostał się do środka.

Co nie było zainfekowane

Po skopiowaniu wszystkich plików sprawdziłem resztę instalacji (WordPress 7.1.4, Apache, PHP 8.5.12 w trybie uwsgi, hosting home.pl):

• rdzeń WordPressa (wp-admin, wp-includes i pliki PHP w katalogu głównym) zgadza się z oficjalnymi sumami kontrolnymi, bez dodatkowych plików PHP,
• aktywny motyw dodaje tylko CookieYes i Google Tag Manager,
• .htaccess wymusza tylko HTTPS i usuwa www, bez auto_prepend,
• przeszukanie bazy pod kątem cf-hs, cf8x i js-static nic nie znalazło,
• starsza kopia strony w katalogu _old nie miała śladów ClickFix.

Czy to luka w PHP z października?

Pierwsze skojarzenie było oczywiste, bo tydzień wcześniej wyszła krytyczna poprawka PHP. Odpowiedź brzmi: nie.

Luka PHP2Shell, czyli CVE-2026-109618 opisana w zgłoszeniu GHSA-w8hw-w9fx-j79w, pozwala na zdalne wykonanie kodu bez logowania. Najgroźniejsza ścieżka dotyczy Apache z mod_php. Poprawki wyszły 21 października 2026 w wersjach 8.2.35, 8.3.36, 8.4.27 i 8.5.12.

Ta strona działała już na PHP 8.5.12 i w trybie uwsgi, a nie mod_php. Nakładka pochodziła z podrzuconej wtyczki, a nie z błędu pamięci w PHP. Jeśli jednak masz starszą wersję, PHP Foundation zaleca aktualizację bez zwłoki. „PHP jest stary” i „na stronie jest nakładka” to dwa osobne problemy.

Co zrobiłem

1. Usunąłem fałszywą wtyczkę i WP File Manager. Bezpośrednio na serwerze. Strona główna i blog przestały ładować skrypt.
2. Uporządkowałem konta. Zmieniłem hasło zaufanego administratora, pozostałych administratorów zdegradowałem do subskrybentów, sprawdziłem ich adresy e-mail i daty rejestracji, unieważniłem hasła aplikacji.
3. Wymieniłem klucze (salts) w wp-config.php. Wszystkie osiem. To wylogowuje wszystkie istniejące sesje — również te, które mógł mieć atakujący.
4. Przeszukałem bazę danych. Better Search Replace w trybie testowym (dry run), bez wyników. Wtyczka była tylko tymczasowym narzędziem.
5. Zmieniłem hasło do MySQL. W panelu home.pl i od razu w wp-config.php. Baza nie była dostępna z internetu, ale hasło leżało jawnym tekstem w pliku, do którego atakujący mógł mieć dostęp.

Jeśli to Twoja strona

Jeśli Twój WordPress pokazuje fałszywą weryfikację Cloudflare, w takiej kolejności:

1. Usuń katalog fałszywej wtyczki na serwerze. Po odświeżeniu strony treść nie powinna być już ukryta, a przeglądarka nie powinna pobierać embed.js.
2. Zmień hasła administratorów, którym ufasz. Konta, których nie znasz, zdegraduj lub usuń. Sprawdź adres e-mail na każdym koncie, zanim wyślesz link resetujący — reset na skrzynkę atakującego oddaje mu stronę z powrotem.
3. Wymień klucze w wp-config.php. Gotowy zestaw wygenerujesz na api.wordpress.org/secret-key/1.1/salt/.
4. Przeszukaj bazę pod kątem cf-hs, cf8x i js-static. Wystarczy tryb testowy. Narzędzie do wyszukiwania usuń po wszystkim. Nie instaluj do tego menedżera plików ani wtyczek w stylu phpMyAdmin — to dokładnie ta klasa narzędzi, która ułatwia kolejne włamanie.
5. Zmień hasło do bazy i wp-config.php za jednym podejściem. Zmiana tylko w pliku wyłączy stronę. Zmiana tylko w MySQL nic nie da, dopóki plik się nie zgadza.
6. Sprawdź wersję PHP i tryb działania. W panelu: Narzędzia → Stan witryny → Informacje. Do tego włącz logowanie dwuskładnikowe dla administratorów.

Jeśli jesteś odwiedzającym

Prawdziwa weryfikacja Cloudflare nigdy nie każe naciskać Win + R, otwierać PowerShella ani Terminala i wklejać tam czegokolwiek. Jeśli strona o to prosi — zamknij kartę i nic nie wklejaj.

Wtyczka to też kod na serwerze

Ten przypadek dobrze pokazuje, że „panel wygląda normalnie” nie znaczy „strona jest czysta”. Atak był ukryty przed administratorem, nie zostawił śladów w bazie i podszywał się pod niewinną wtyczkę do aktualizacji. Wystarczył jeden plik PHP w katalogu wtyczek.

Im mniej wtyczek i im mniej osób z uprawnieniami administratora, tym mniejsza powierzchnia ataku. Menedżer plików w panelu WordPressa to wygoda, która w złych rękach daje pełny dostęp do serwera.

Wszystkiego dobrego,
Sławek

Jeśli potrzebujesz strony, która buduje zaufanie i prowadzi do kontaktu, zobacz ofertę strony internetowej .