Japoński hack słów kluczowych: dlaczego wtyczka go nie widzi

#Skaner nie kłamie, skaner jest okłamywany

29 lipca 2026 Joe Youngblood opublikował ostrzeżenie, że japoński hack słów kluczowych rozchodzi się po instalacjach WordPressa w dużym tempie i, cytując, “easily defeating WordFence, Securi, and Malcare along with other security methods / plugins”.

Ta ostatnia część jest najciekawsza i nie jest to wpadka tych produktów w takim sensie, w jakim wygląda. Skan wraca czysty, bo w momencie, w którym skaner pyta, ładunku po prostu nie ma.

Treść jest serwowana warunkowo. Na stronie siedzi web shell, który przy każdym żądaniu decyduje, czy wstrzyknąć. Wygląda jak przeglądarka, dostajesz swoją zwykłą stronę. Wygląda jak Googlebot, dostaje stronę pełną japońskich fraz sklepowych linkujących do podróbek. Wtyczka bezpieczeństwa pobiera stronę jako ona sama, dostaje wersję zwykłą i nie ma czego zgłosić.

Dlatego pierwszy objaw prawie nigdy nie jest na stronie. Jest w Search Console, w wynikach na własną markę albo w spadku ruchu, którego nikt nie umie wytłumaczyć.

#Udowodnij to jednym poleceniem, zanim cokolwiek ruszysz

Zanim zaczniesz kasować pliki, ustal, z czym masz do czynienia. Pobierz ten sam adres dwa razy:

curl -s https://przyklad.pl/jakas-strona/ > przegladarka.html
curl -s -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
  https://przyklad.pl/jakas-strona/ > robot.html
diff przegladarka.html robot.html

Jeśli pliki się różnią, a wersja dla robota niesie linki albo frazy, których nie ma w wersji dla przeglądarki, masz cloaking i diagnoza jest skończona. Bez skanu, bez zgadywania.

To samo zrób z sitemapą. Częstym objawem towarzyszącym jest komunikat w Search Console, że sitemapa “wygląda na stronę HTML”, podczas gdy w przeglądarce otwiera się poprawnie. To ten sam mechanizm: coś przechwytuje trasę sitemapy i podaje robotowi co innego.

Dwa miejsca poza stroną, do których warto zajrzeć od razu:

• Search Console, Problemy dotyczące bezpieczeństwa. Jeśli Google już zaklasyfikował witrynę, znajdziesz tam nazwę wzorca i wniosek o ponowne sprawdzenie, który będzie potrzebny na końcu.
• Search Console, Skuteczność, filtr na zapytania, których nie rozpoznajesz. Japońskie frazy sklepowe na polskiej stronie nie są dwuznaczne.

#Co widzi które narzędzie

Warto być precyzyjnym co do tego, dlaczego skanery wracają czyste, bo wniosek “wtyczka zawiodła” prowadzi ludzi do kupienia innej wtyczki zamiast do zmiany metody.

Wzór w tej tabeli jest całą pointą. Każda metoda oglądająca pliki odpowiada na pytanie “czy coś leży w systemie plików”, a każda metoda oglądająca zachowanie odpowiada na pytanie “czy ta strona właśnie okłamuje roboty”. Potrzebujesz obu, a tylko jedna jest sprzedawana jako produkt.

#Wyłapać wcześnie i wyłapać nawrót

Odstęp między infekcją a wykryciem to moment, w którym dzieje się szkoda SEO. Trzy sygnały pojawiają się przed spadkiem ruchu.

Wyświetlenia na zapytania bez sensu dla twojego biznesu. Search Console, Skuteczność, sortowanie po wyświetleniach, szukasz czegokolwiek w alfabecie, w którym nie publikujesz. To zwykle najwcześniejszy dostępny sygnał i kosztuje minutę tygodniowo.

Podstrona, która nagle strzela w górę. W obecnej fali pierwsza wstrzyknięta strona często dostaje skok wyświetleń, zanim dołączy reszta. Strona, której nie dotykałeś od roku i która nagle zaczyna pracować, jest warta trzydziestu sekund ciekawości.

Zmiana favicony w wynikach. Youngblood zwraca uwagę, że ta fala niesie charakterystyczną faviconę, widoczną w Search Console. Favicona, której nie ustawiałeś, to plik, którego nie napisałeś.

Po posprzątaniu ten sam test dwóch pobrań nadaje się na monitor nawrotu. Uruchamiaj go z dowolnej maszyny z curl, nie z serwera strony, bo zainfekowana strona jest kiepskim sędzią własnego stanu:

#!/usr/bin/env bash
# cloaking-watch.sh - alarmuje, gdy widok robota rozjedzie się z widokiem przeglądarki
URL="https://przyklad.pl/"
UA_BOT="Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

a=$(curl -s --max-time 20 "$URL" | md5sum | cut -d' ' -f1)
b=$(curl -s --max-time 20 -A "$UA_BOT" "$URL" | md5sum | cut -d' ' -f1)

if [ "$a" != "$b" ]; then
  echo "ROZJAZD na $URL o $(date -u +%FT%TZ)"
  exit 1
fi

Dwa zastrzeżenia, zanim wrzucisz to w crona. Strony z rotującą treścią, testami A/B albo personalizacją będą różnić się legalnie, więc celuj w coś stabilnego, na przykład wpis evergreen albo sitemapę. I zdeterminowany shell potrafi rozpoznawać więcej niż user agent, łącznie z zakresem IP, więc czysty wynik jest poszlaką, nie dowodem. Przypadek typowy i tak wyłapuje, i wyłapuje go w ciągu doby, a nie kwartału.

#Jak odróżnić to od innych odmian spamu

Trzy różne infekcje nazywa się “spamem SEO”, a każda wymaga innego pierwszego ruchu, więc warto poświęcić minutę na ustalenie, którą masz.

Spam farmaceutyczny wstawia frazy lekowe w tytuły, zajawki i treść wpisów. Siedzi w bazie danych, widzą go zwykli odwiedzający, i znajdujesz go, przeszukując wp_posts oraz wp_options pod kątem fraz, które pokazuje Google. Jeśli SELECT znajduje te słowa, to jest ten przypadek, a nie japoński.

Spam kasynowy i bukmacherski leży pośrodku. Często robi cloaking tak samo jak odmiana japońska, ale zwykle przychodzi ze wstrzykniętymi blokami hreflang i zmyślonymi wersjami językowymi twoich stron, bo operatorom zależy na kilku rynkach naraz. Jeśli widok dla robota pokazuje odnośniki do wersji językowych, których nigdy nie zakładałeś, szukaj tam.

Japoński hack słów kluczowych nie rusza bazy. Ładunek jest w plikach, renderowany w momencie żądania i tylko dla robotów, czyli w kombinacji, która pokonuje jednocześnie przeszukanie bazy i skan wtyczką.

Jest jeszcze odmiana z przekierowaniem wyłącznie na telefonach, która przełącza się na podstawie user agenta tak samo jak ta, tyle że sprawdza urządzenie mobilne, a nie Googlebota. Jeśli odwiedzający zgłaszają, że wyrzuca ich na obcą stronę, a twoje testy na komputerze wracają czyste, powtórz test dwóch pobrań z mobilnym user agentem zamiast Googlebota. Mechanizm jest identyczny, zmienia się tylko warunek.

Warto też wiedzieć, czego ta odmiana nie robi. Nie podmienia treści, którą widzi klient, więc reklamacje od użytkowników nie przyjdą. Nie psuje panelu, więc administrator niczego nie zauważy przy codziennej pracy. Nie wysyła spamu z serwera, więc nie dostaniesz ostrzeżenia od hostingu o wpisaniu domeny na blokadę. Cały jej sens polega na tym, żeby wyglądać normalnie dla wszystkich poza jednym odbiorcą, i dlatego przeciętnie żyje na stronie znacznie dłużej niż infekcja, która cokolwiek psuje.

#Weryfikuj pliki deterministycznie, potem patrz na daty

Youngblood proponuje przeszukać system plików pod kątem base64 i poprosić model AI o przejrzenie listy. To działa, ale jako krok drugi, nie pierwszy, bo każe modelowi zgadywać, które pliki należą do WordPressa. WordPress już to wie:

wp core verify-checksums
wp plugin verify-checksums --all

To porównuje każdy plik core i wtyczek z oficjalnymi sumami z WordPress.org i nazywa wszystko zmienione albo dodane. Jest deterministyczne, trwa sekundy i daje krótszą listę do przemyślenia niż grep na base64 po całym drzewie.

Czego sumy kontrolne nie sprawdzą: twojego motywu, wtyczek premium, wp-content/uploads i mu-plugins. Tam idzie przejście ręczne:

grep -rl --include="*.php" -E "base64_decode|eval\(|gzinflate|str_rot13" wp-content/ | head -50
find wp-content/uploads -name "*.php"
ls -la wp-content/mu-plugins/

Plik PHP w uploads nie ma powodu, żeby istnieć. Tak samo plik w mu-plugins, którego nie napisałeś, a ten katalog zasługuje na szczególną uwagę, bo ładuje się automatycznie i nigdy nie pokazuje się na liście wtyczek.

Potem posortuj znaleziska po dacie modyfikacji. Większość wstrzykniętych plików ma jeden wspólny znacznik czasu, czyli moment widocznego ataku. Wyjątkiem jest to, co Youngblood nazywa zasiewem: pojedynczy plik podłożony tygodnie, miesiące, czasem lata wcześniej, z datą, która nie pasuje do niczego innego. Jeśli wyczyścisz wszystko poza zasiewem, infekcja wróci i wróci po cichu.

Praktyczny test, czy się udało: przywróć czysty index.php, odczekaj dwie minuty i przeczytaj plik ponownie. Jeśli wrócił do wersji zhakowanej, coś nadal działa i nie skończyłeś.

#Kolejność, która ma znaczenie

Kolejność sprzątania to miejsce, w którym te odzyskiwania się psują, i nie jest intuicyjna.

Skopiuj, zanim wyczyścisz. Najpierw pełna kopia plików i zrzut bazy w stanie zainfekowanym. Przywrócenie backupu z wierzchu niszczy jedyny ślad, jak doszło do wejścia, a jeśli sam backup jest już zainfekowany, nie masz do czego porównywać. Skoro zasiew potrafi wyprzedzać widoczny atak o miesiące, “przywróćmy kopię sprzed miesiąca” jest założeniem, nie rozwiązaniem. Na typowym polskim hostingu współdzielonym warto od razu sprawdzić, jak głęboko sięga retencja kopii, bo jeśli hostingodawca trzyma czternaście dni, a zasiew ma trzy miesiące, każdy dostępny backup jest już po infekcji.

Czyść, potem rotuj, potem zajmij się wyszukiwarką. W tej kolejności. Rotacja poświadczeń, zanim zniknie shell, to podanie atakującemu nowych.

Rotuj więcej niż hasła. To krok, na którym prawie każdy poradnik się kończy:

• Hasła aplikacji, w profilu każdego użytkownika, przeżywają zmianę hasła i zachowują pełny dostęp do REST API. Są per użytkownik, łatwo je utworzyć programowo, gdy ktoś ma już admina, i większość ludzi nie wie, że ta funkcja istnieje. Wylicz je i skasuj.
• Delegowani właściciele w Search Console, w Ustawieniach, Użytkownicy i uprawnienia, istnieją poza twoją stroną. Nic, co zrobisz w WordPressie, ich nie usunie. Sprawdź też weryfikację własności, pod kątem plików HTML i wpisów DNS TXT, których nie zakładałeś.
• Poświadczenia bazy i FTP lub SSH, bo jeśli wejście poszło przez credential stuffing na wp-admin, wszystko, co dzieliło to hasło, też jest wystawione.

Dopiero potem wyszukiwarka. Wygeneruj sitemapę od nowa, potwierdź testem strony na żywo w Search Console, że Googlebot dostaje prawdziwą stronę, i złóż wniosek o ponowne sprawdzenie w raporcie Problemy dotyczące bezpieczeństwa. Ponowne zgłoszenie sitemapy nie zdejmuje flagi, wniosek tak.

#Dwie rady z obiegu, z którymi warto się spierać

Ostrzeżenie, od którego zaczyna się ten tekst, to dobra robota terenowa, a dwie z jego rekomendacji zasługują na sprzeciw.

“Natychmiast zgłoś usunięcie całej witryny w Search Console.” To cięższe narzędzie, niż sytuacja zwykle wymaga. Usuwanie ukrywa adresy z wyników na około pół roku, nie zmienia nic w infekcji i nic w tym, jak Google ostatecznie przeliczy witrynę. Usunięcie prefiksów, pod którymi siedzą wstrzyknięte adresy, jest proporcjonalne. Usunięcie całości chowa też strony, które nadal przynoszą zapytania, a każdą trzeba potem odzyskać przez wycofanie wniosku i przecrawlowanie, na które nie masz wpływu. Po wersję całościową sięgaj, gdy wstrzykniętych stron jest realnie więcej niż prawdziwych, a nie w kroku pierwszym.

“Znajdź dowolny pretekst na informację prasową, żeby ściągnąć Googlebota.” Przecrawlowanie napędzają rzeczy, na które faktycznie masz wpływ: prawdziwe lastmod w sitemapie, linkowanie wewnętrzne ze stron często odwiedzanych przez robota i zgłoszenia w teście adresu URL dla stron, które są ważne. Informacja prasowa to drogi sposób na kupienie kilku wizyt robota.

Reszta tamtego materiału, w szczególności obserwacja o unikalnej dacie pliku zasiewowego i ostrzeżenie, żeby sprawdzić index.php po przywróceniu, zgadza się z tym, jak te sprzątania wyglądają w praktyce.

#Zamknięcie drzwi, których atak faktycznie użył

Zgłoszony łańcuch wejścia w tej fali jest konkretny: credential stuffing na wp-admin z list wyciekniętych adresów i haseł, potem instalacja wtyczki dającej dostęp do plików, potem wgranie jednego pliku z ładunkiem. Każdy z tych kroków ma kontrolę, która go zatrzymuje.

Dwuskładnikowe uwierzytelnianie na każdym administratorze. Credential stuffing działa, bo hasło jest już znane. Drugi składnik sprawia, że poprawne hasło nie wystarcza, czyli wycina cały atak.

DISALLOW_FILE_MODS. W wp-config.php:

define( 'DISALLOW_FILE_MODS', true );

To blokuje instalowanie wtyczek i motywów z panelu. W opisanym łańcuchu jest to krok drugi. Atakujący z ważną sesją administratora nie zainstaluje menedżera plików, który daje mu system plików. Kompromis jest realny i trzeba go znać: znikają też automatyczne aktualizacje, więc aktualizacje idą przez WP-CLI albo pipeline wdrożeniowy. Na stronie wdrażanej z repozytorium tak to i tak powinno wyglądać.

Zakaz wykonywania PHP w uploads. Na poziomie serwera, nie wtyczki. To dewaluuje najczęstszą ścieżkę z “atakujący wgrał plik” do “atakujący wykonuje kod”.

Mniej administratorów. Agencja, deweloper, który raz pomógł, support sprzed dwóch lat. Każde z tych kont to poświadczenie, które można wpuścić w credential stuffing. Zdegraduj to, co nie potrzebuje roli.

Patrz w Search Console, nie w panel. Panel jest miejscem, w którym ten atak jest niewidoczny z założenia. Cotygodniowe spojrzenie na Skuteczność pod kątem nierozpoznanych zapytań łapie go wcześniej niż jakikolwiek skan.

#Co powiedzieć klientowi albo szefowi

Jeśli sprzątasz to dla kogoś, najtrudniejsza część rozmowy nie dotyczy techniki, tylko czasu. Sprzątanie idzie w godzinach, a powrót widoczności w tygodniach, i te dwie rzeczy łatwo się zlewają w jedno oczekiwanie, że po wieczornej naprawie rano ruch wróci. Nie wróci, bo Google musi najpierw ponownie odwiedzić strony, które sam wcześniej oznaczył jako spam, a kolejka zależy od tego, jak często wcześniej crawlował serwis.

Druga rzecz, którą warto powiedzieć wprost: nie da się uczciwie odpowiedzieć na pytanie “czy wyciekły dane klientów”, jeśli logi serwera mają siedmiodniową retencję, a plik zasiewowy jest z lutego. Odpowiedź brzmi wtedy “nie wiemy i nie dowiemy się”, i to jest informacja, a nie unik. Przy sklepie z danymi osobowymi ten brak wiedzy ma konsekwencje w ocenie obowiązku zgłoszenia naruszenia, więc lepiej postawić go na stole na początku niż tydzień później.

Trzecia: koszt tej infekcji rzadko jest kosztem sprzątania. Jest nim ruch, którego nie było przez te tygodnie, i to jest liczba, którą warto policzyć razem z klientem z danych sprzed infekcji, zamiast zostawiać ją jako mgliste “trochę spadło”.

#Jeśli jesteś w środku takiej sprawy

Wersja krótka: udowodnij cloaking testem dwóch pobrań, zweryfikuj core i wtyczki sumami kontrolnymi, poluj na zasiew po dacie modyfikacji, skopiuj wszystko przed przywracaniem czegokolwiek i pamiętaj, że hasła aplikacji oraz delegowani właściciele w Search Console przeżyją zmianę haseł, którą właśnie planujesz.

Tę sekwencję uruchamiamy w ramach audytu bezpieczeństwa WordPress, a szerszy proces czyszczenia, razem z pracą na bazie i przeglądem logów, opisaliśmy w przewodniku po czyszczeniu zainfekowanego WordPressa.

Ostatnia aktualizacja: 30 lipca 2026, po zgłoszeniu obecnej fali.