Deweloper konkurencyjnej wtyczki oskarżył Rank Math o to, że jego oprogramowanie po cichu tworzy na stronie hasło aplikacji z uprawnieniami administratora i wysyła je na serwery firmy macierzystej. Zarzut dotyczy wydania 1.0.277 i wtyczki, która według danych repozytorium działa na ponad czterech milionach witryn WordPress. Rank Math do momentu publikacji pierwszych doniesień nie wydał oświadczenia ani nie zaprzeczył.
Sprawa wybuchła między 28 a 30 sierpnia 2026 roku i dotyczy mechanizmu, który sam w sobie jest standardowym elementem WordPressa, czyli haseł aplikacji. Problem nie leży w technologii, tylko w tym, kto, kiedy i za czyją zgodą taki klucz zakłada.
Kontekst: czym są hasła aplikacji w WordPressie
Hasła aplikacji (Application Passwords) trafiły do rdzenia WordPressa w wersji 5.6 jako bezpieczniejsza alternatywa dla podawania właściwego hasła do konta w integracjach zewnętrznych. Każde takie hasło jest osobnym poświadczeniem przypisanym do konkretnego użytkownika, można je nazwać, można je odwołać pojedynczo, a jego wyciek nie oznacza automatycznie utraty samego konta.
Kluczowa jest jednak jedna właściwość: hasło aplikacji dziedziczy uprawnienia użytkownika, dla którego zostało wygenerowane. Jeżeli zakłada je administrator, powstaje poświadczenie o pełnych uprawnieniach administratora do REST API danej witryny. Kto ma taki ciąg znaków, ten może zdalnie publikować i usuwać treści, zmieniać ustawienia, a w wielu konfiguracjach także instalować kod.
Właśnie dlatego WordPress projektował ten mechanizm jako operację świadomą. Użytkownik wchodzi do swojego profilu, wpisuje nazwę integracji, klika przycisk i dostaje hasło pokazane jeden jedyny raz. Cała krytyka, która spadła na Rank Math, sprowadza się do zarzutu, że ten świadomy krok został pominięty.
Co dokładnie zarzuca się wtyczce
Autorem oskarżenia jest Sybre Waaijer, deweloper wtyczki The SEO Framework, czyli bezpośredniej konkurencji Rank Math na rynku wtyczek SEO dla WordPressa. Waaijer opisał sprawę publicznie w serwisie X, a jego ustalenia podchwyciły branżowe media, w tym Search Engine Journal, który opisał je 30 sierpnia.
Według tych doniesień wtyczka w wersji 1.0.277 zawiera komponent w katalogu dostawcy o ścieżce vendor/groupone/wap-client/includes/class-app-password-manager.php. Kod ten ma uruchamiać się w bardzo konkretnym scenariuszu: gdy administrator witryny połączonej z darmowym kontem rankmath.com otwiera w panelu sekcję pomocy i wsparcia. Samo wejście do tej zakładki ma wystarczyć, żeby powstało nowe hasło aplikacji.
Nazwa wpisu, który pojawia się wtedy w profilu użytkownika, zaczyna się od skrótu „WAP” i zawiera frazę „Rank Math Support Agent”. To właśnie ten ciąg jest dziś najprostszym sygnałem, że mechanizm zadziałał na danej stronie.
| Element zarzutu | Opis według doniesień |
|---|---|
| Wersja wtyczki | 1.0.277, wydanie, które zamknęło też około tuzina zgłoszeń bezpieczeństwa |
| Plik | vendor/groupone/wap-client/includes/class-app-password-manager.php |
| Wyzwalacz | otwarcie sekcji pomocy i wsparcia przy połączonym darmowym koncie rankmath.com |
| Poziom uprawnień | administrator, czyli pełny dostęp do REST API witryny |
| Nazwa poświadczenia | wpis rozpoczynający się od „WAP”, z dopiskiem o agencie wsparcia |
| Czas życia | brak daty wygaśnięcia |
| Odbiorca | serwery group.one, właściciela Rank Math |
| Skala | ponad 4 mln aktywnych instalacji wtyczki |
Trzy szczegóły z tej listy ważą najwięcej. Po pierwsze, poświadczenie ma nie wygasać, więc nie znika samo po zakończeniu rozmowy z supportem. Po drugie, zamknięcie karty przeglądarki go nie unieważnia, co odróżnia je od typowej sesji pomocy technicznej. Po trzecie, klucz opuszcza serwer witryny i trafia do infrastruktury podmiotu zewnętrznego.
Group.one to duński holding hostingowy, który poza Rank Math ma w portfolio także WP Rocket, jedną z najpopularniejszych wtyczek cache dla WordPressa. Deklarowanym celem mechanizmu ma być umożliwienie agentowi AI działania po stronie witryny, czyli diagnozowania i naprawiania problemów bez proszenia użytkownika o ręczne kroki. Waaijer zwraca uwagę, że w interfejsie istnieje wprawdzie pole z regulaminem, ale samo utworzenie hasła nie jest od niego uzależnione.
Backdoor czy zły domyślny wybór
Najciekawsze w tej sprawie jest to, że sam autor zarzutu nie postawił kropki nad i. Waaijer wahał się, czy nazwać to zachowanie backdoorem, i to wahanie jest merytorycznie uzasadnione. Funkcja wsparcia zbudowana na złych ustawieniach domyślnych oraz celowo ukryte wejście dają identyczny efekt w profilu użytkownika i wymagają dokładnie tej samej reakcji, ale to nie jest ten sam zarzut.
Różnica dotyczy intencji, a intencji nie da się odczytać z samego kodu. Można natomiast ocenić zgodność z regułami. Wytyczne repozytorium WordPress.org wymagają wyraźnej i autoryzowanej zgody użytkownika na kontakt z serwerami zewnętrznymi. Jeżeli opis zdarzenia się potwierdzi, to właśnie ten punkt jest najsłabszym ogniwem, niezależnie od tego, jaką etykietę przyklei się całej sprawie.
Warto też zachować proporcje przy ocenie historii bezpieczeństwa wtyczki. Publiczne zestawienia notują siedem podatności w 2024 roku, cztery w 2025 i trzy w 2026. To profil typowy dla dużego, aktywnie rozwijanego projektu, w którym zgłoszenia są zgłaszane i łatane, a nie obraz oprogramowania systemowo zaniedbanego. Obecny zarzut jest innej natury: nie mówi o błędzie, tylko o świadomie napisanej funkcji.
Jak sprawdzić własną stronę
Weryfikacja zajmuje mniej niż minutę i nie wymaga żadnych narzędzi poza panelem WordPressa. Ścieżka wygląda tak:
- Zaloguj się do panelu administracyjnego i przejdź do sekcji Użytkownicy.
- Otwórz profil konta, na którym pracujesz, i zjedź do bloku Hasła aplikacji.
- Poszukaj wpisu, którego nazwa zaczyna się od „WAP”.
- Jeżeli taki wpis istnieje, użyj opcji unieważnienia.
- Powtórz kontrolę na wszystkich kontach z rolą administratora, nie tylko na własnym.
Ten ostatni punkt jest najczęściej pomijany. W agencjach i na stronach klienckich rolę administratora ma zwykle kilka osób, a mechanizm opisany przez Waaijera miał uruchamiać się dla tego konta, które faktycznie otworzyło zakładkę pomocy. Sprawdzenie wyłącznie własnego profilu może więc dać fałszywe poczucie bezpieczeństwa.
Jeżeli zarządzasz większą liczbą witryn, warto potraktować to jako pretekst do audytu wszystkich haseł aplikacji, nie tylko tych związanych z jedną wtyczką. Na stronach żyjących od lat potrafią zalegać poświadczenia po dawnych integracjach, migracjach i wykonawcach, o których nikt już nie pamięta. Przy okazji przydaje się analiza logów serwera, bo to ona pokazuje, czy i dokąd faktycznie wychodzi ruch z witryny.
Co to znaczy dla SEO i AIO
Na pierwszy rzut oka to sprawa czysto bezpieczeństwowa, a nie widocznościowa. W praktyce dotyka jednak SEO w kilku miejscach naraz.
Pierwsza konsekwencja jest operacyjna. Poświadczenie z uprawnieniami administratora do REST API pozwala na zdalną edycję treści i ustawień. Wtyczka SEO steruje tytułami, opisami meta, kanonicznymi adresami, danymi strukturalnymi i plikiem robots. To dokładnie ta warstwa, w której cicha, niezauważona zmiana potrafi kosztować ruch, zanim ktokolwiek zorientuje się, że coś się wydarzyło. Ryzyko nie polega na tym, że ktoś podmieni stronę główną, bo to zauważy każdy. Polega na tym, że modyfikacje w metadanych bywają niewidoczne z poziomu przeglądarki.
Druga konsekwencja dotyczy modelu zaufania w epoce agentów. Rank Math stosunkowo niedawno wprowadził funkcje mierzenia widoczności marki w modelach językowych, o czym pisaliśmy przy okazji premiery modułu AI Visibility. Cała branża idzie w stronę narzędzi, które nie tylko raportują, ale też same wprowadzają zmiany. Agent, który ma naprawiać stronę, musi mieć do niej dostęp zapisu, to nie jest kontrowersyjne. Kontrowersyjny jest sposób, w jaki ten dostęp jest pozyskiwany, oraz brak jasnej informacji, kiedy dokładnie się zaczyna i jak się kończy.
Trzecia konsekwencja jest procesowa. Jeżeli budujesz automatyzacje SEO oparte na REST API, to hasła aplikacji są twoim głównym mechanizmem uwierzytelniania. Warto mieć ich rejestr: kto założył, do czego służy, kiedy ostatnio było używane. Bez takiej ewidencji nie da się odróżnić własnej integracji od poświadczenia, które pojawiło się bez pytania.
Dlaczego to szczególnie boli w modelu agencyjnym
Na jednej własnej stronie sprawa jest niewygodna, ale ograniczona. Problem rośnie liniowo wraz z liczbą obsługiwanych witryn, a agencje SEO i studia WordPress zarządzają zwykle dziesiątkami, czasem setkami instalacji, na których ta sama wtyczka jest elementem standardowego zestawu startowego.
Pojawia się wtedy pytanie, na które trudno odpowiedzieć w pięć minut: na ilu z tych stron ktoś w ogóle zaglądał do zakładki wsparcia. Odpowiedź brzmi zazwyczaj „nie wiadomo”, bo w zespole pracuje kilka osób, konta administratorów bywają współdzielone z klientem, a historia takich kliknięć nigdzie się nie zapisuje. Sprawdzenie wymaga fizycznego wejścia na każdą witrynę albo napisania skryptu, który przejdzie po REST API i wylistuje poświadczenia na wszystkich kontach z rolą administratora.
Druga warstwa problemu jest relacyjna, nie techniczna. Jeżeli obsługujesz klienta na umowie, w której zobowiązujesz się do dbania o bezpieczeństwo jego witryny, to poświadczenie administratora przekazane podmiotowi trzeciemu bez wiedzy właściciela strony jest zdarzeniem, o którym trzeba poinformować. Nie dlatego, że doszło do naruszenia, bo na to nie ma dowodów, ale dlatego, że milczenie i późniejsze wyjście sprawy na jaw kosztuje więcej niż wcześniejszy, spokojny komunikat.
Praktyczna rada dla zespołów obsługujących wiele stron brzmi więc: potraktuj to jako inwentaryzację, a nie jako incydent. Zbierz listę witryn z tą wtyczką, przejdź po profilach administratorów, zapisz wynik w arkuszu i ustal właściciela tego przeglądu. Ten sam rejestr przyda się przy każdej kolejnej sprawie tego typu, a takich spraw w erze wtyczek z funkcjami agentowymi będzie więcej, nie mniej.
Reakcje branży
Ton dyskusji był ostry, ale nie jednomyślny. Część komentujących uznała opis zachowania za wystarczający powód do natychmiastowej deinstalacji wtyczki i migracji na alternatywę. Argument brzmiał prosto: przy czterech milionach instalacji nawet niewielkie ryzyko mnoży się na tyle stron, że nie warto go akceptować.
Druga grupa zwracała uwagę na kontekst, w jakim zarzut się pojawił. Sybre Waaijer rozwija konkurencyjną wtyczkę SEO, więc jego głos, choć technicznie precyzyjny, nie jest głosem neutralnego audytora. To nie unieważnia ustaleń, bo ścieżka pliku i nazwa poświadczenia są weryfikowalne przez każdego, kto ma dostęp do kodu i do własnego profilu. Nakazuje jednak ostrożność przy interpretacji intencji i przy doborze słów.
Trzeci wątek dotyczył samego repozytorium. Powracało pytanie, jak funkcja o takim profilu przeszła przez proces przeglądu WordPress.org, skoro wytyczne wprost wymagają zgody na komunikację z serwerami zewnętrznymi. To pytanie wykracza poza jedną wtyczkę i dotyka skalowalności ręcznej moderacji przy repozytorium tej wielkości.
Charakterystyczne jest natomiast to, czego w tej dyskusji zabrakło. W momencie, gdy sprawa rozchodziła się po branżowych mediach, nie było publicznego stanowiska producenta. Search Engine Journal wprost odnotował brak oświadczenia i brak zaprzeczenia. W kryzysie komunikacyjnym tej skali cisza sama staje się komunikatem, a próżnię wypełniają interpretacje osób trzecich.
Co dalej
Sprawa ma trzy możliwe rozwinięcia i warto wiedzieć, na co patrzeć.
Scenariusz pierwszy to szybka korekta. Producent publikuje wyjaśnienie, zmienia mechanizm tak, żeby hasło powstawało wyłącznie po jednoznacznym kliknięciu użytkownika, dodaje datę wygaśnięcia i automatyczne unieważnienie po zamknięciu zgłoszenia. To rozwiązanie, które godzi realną potrzebę wsparcia technicznego z zasadą świadomej zgody. Sygnałem będzie wydanie z wpisem o tej zmianie w dzienniku zmian.
Scenariusz drugi to interwencja po stronie repozytorium. Zespół WordPress.org ma narzędzia od prośby o poprawkę po czasowe zawieszenie wtyczki. Przy projekcie o takiej skali zawieszenie byłoby krokiem ostatecznym, ale samo zainteresowanie moderacji zwykle wymusza zmianę w ciągu dni, nie tygodni.
Scenariusz trzeci to spór o interpretację, który się przeciąga. Producent broni funkcji jako elementu wsparcia objętego regulaminem, krytycy podtrzymują zarzut braku zgody, a użytkownicy zostają z decyzją do podjęcia we własnym zakresie. To wariant najbardziej męczący, bo nie daje jednoznacznego sygnału.
Niezależnie od scenariusza rekomendacja praktyczna jest ta sama i nie wymaga czekania na rozstrzygnięcie. Sprawdź hasła aplikacji na wszystkich kontach administratorów, unieważnij wpisy, których nie rozpoznajesz, i wprowadź nawyk okresowej kontroli tej sekcji. To zajmuje kilka minut na witrynę, a jest jedyną częścią całej sprawy, na którą masz pełny wpływ.
Warto też zapisać sobie szerszy wniosek. Wtyczki przestają być pasywnymi narzędziami raportującymi i coraz częściej stają się aktywnymi agentami z prawem zapisu. Ta zmiana jest nieunikniona i ma sens, bo ręczne wdrażanie każdej rekomendacji nie skaluje się. Ale zmienia też pytanie, które trzeba zadawać przy wyborze oprogramowania. Nie brzmi ono już „co ta wtyczka mierzy”, tylko „co ta wtyczka może zrobić z moją stroną, kiedy nie patrzę, i jak to wyłączyć”.
FAQ
Czy muszę natychmiast odinstalować Rank Math?
Nie ma podstaw do paniki, ale jest podstawa do sprawdzenia. Zacznij od kontroli haseł aplikacji na wszystkich kontach administratorów i unieważnienia wpisów zaczynających się od „WAP”. Decyzję o zmianie wtyczki podejmij dopiero po stanowisku producenta, bo migracja ustawień SEO na inną wtyczkę sama w sobie niesie ryzyko utraty metadanych i przekierowań.
Skąd mam wiedzieć, czy mechanizm zadziałał na mojej stronie?
Według opisu zdarzenia poświadczenie powstaje tylko wtedy, gdy witryna jest połączona z kontem rankmath.com, a administrator otworzy sekcję pomocy i wsparcia. Jeżeli nigdy nie łączyłeś strony z kontem producenta ani nie zaglądałeś do tej zakładki, wpis najprawdopodobniej nie powstał. Kontrola profilu i tak jest jednak warta minuty.
Czy unieważnienie hasła aplikacji zepsuje działanie wtyczki?
Unieważnienie poświadczenia oznacza utratę zdalnego dostępu dla agenta wsparcia, a nie wyłączenie funkcji SEO. Optymalizacja treści, mapy witryny, dane strukturalne i przekierowania działają lokalnie i nie zależą od tego klucza. Jeżeli w przyszłości skorzystasz ze wsparcia technicznego, może pojawić się prośba o ponowne nadanie dostępu.
Czy inne wtyczki robią to samo?
Mechanizm haseł aplikacji jest częścią rdzenia WordPressa i korzysta z niego wiele legalnych integracji, od narzędzi publikacyjnych po systemy backupu. Różnica leży w tym, czy poświadczenie powstaje po świadomym działaniu użytkownika, czy jako efekt uboczny otwarcia zakładki. Przy audycie warto przejrzeć całą listę, a nie tylko wpisy jednego producenta.
Czy ta sprawa może wpłynąć na widoczność mojej strony w Google?
Sam fakt istnienia hasła aplikacji nie jest sygnałem rankingowym i nie obniża pozycji. Ryzyko jest pośrednie: poświadczenie administratora pozwala na zmianę tytułów, opisów meta i danych strukturalnych, czyli warstwy, w której ciche modyfikacje realnie przekładają się na kliknięcia i cytowania w wynikach generatywnych. Regularna kontrola metadanych jest tu skuteczniejsza niż jednorazowa reakcja.