Przejęty DNS DebugBear: skrypt do Core Web Vitals okradł użytkowników Polymarket

Popularne wśród specjalistów SEO narzędzie do monitorowania Core Web Vitals stało się furtką do kradzieży kryptowalut. Napastnicy przejęli rekordy DNS firmy DebugBear i podmienili jej skrypt Real User Monitoring (RUM), który na stronie Polymarket opróżnił portfele kilkuset użytkowników. DebugBear apeluje do wszystkich klientów o natychmiastowe usunięcie kodu ze stron, a sprawa pokazuje, ile ryzyka niesie każdy zewnętrzny skrypt dodany „tylko do pomiarów”.

Kontekst: czym jest DebugBear i dlaczego to dotyczy branży SEO

DebugBear to brytyjskie narzędzie do monitorowania wydajności stron. W środowisku SEO kojarzone jest przede wszystkim z pomiarami Core Web Vitals, czyli wskaźników LCP, INP i CLS, które Google wykorzystuje jako jeden z sygnałów jakości strony. Oprócz testów laboratoryjnych (symulowanych wizyt) DebugBear oferuje moduł Real User Monitoring: niewielki skrypt JavaScript wklejany na stronę, który zbiera dane z przeglądarek prawdziwych odwiedzających i wysyła je do panelu narzędzia.

To właśnie ten skrypt stał się wektorem ataku. Kod RUM ładuje się z domeny cdn.debugbear.com, zwykle na każdej podstronie serwisu, i działa z pełnymi uprawnieniami strony, na której jest osadzony. Ma dostęp do drzewa DOM, do pamięci localStorage i do wszystkiego, co widzi zalogowany użytkownik. Dopóki dostawca jest zaufany, nikt się nad tym nie zastanawia. Wystarczy jednak, że ktoś przejmie kontrolę nad adresem, z którego skrypt jest serwowany, a ten sam kod może zrobić w przeglądarce odwiedzającego praktycznie wszystko.

Dla zespołów SEO to sygnał alarmowy z prostego powodu: to często oni rekomendują wdrożenie narzędzi RUM, dodają je przez Google Tag Managera albo wtyczki i rzadko konsultują to z działem bezpieczeństwa. Skrypt pomiarowy traktowany jest jak neutralny element analityki, a nie jak kod wykonywany w imieniu każdego zalogowanego klienta.

Kluczowe fakty: co wiemy o ataku

Złośliwy kod wykryto 29 października 2026 roku. Jak podaje serwis Search Engine Journal, DebugBear tego samego dnia poinformował klientów o incydencie bezpieczeństwa i polecił im usunięcie skryptu Real User Monitoring ze swoich stron. W kolejnej aktualizacji firma wyjaśniła, że napastnicy przejęli jej rekordy DNS za pośrednictwem rejestratora domeny. Według wstępnych ustaleń DebugBear atak był wymierzony w stronę jednego klienta, a firma nie znalazła oznak włamania do swoich systemów wewnętrznych. DebugBear zaznaczył też, że nie może odbierać poczty wysyłanej na swoją domenę, dlatego aktualizacje publikuje na profilu w serwisie X.

Tym jednym klientem okazał się Polymarket, platforma rynków predykcyjnych. Szczegółową analizę techniczną opublikowała firma Hudson Rock na swoim blogu InfoStealers. Badacze pobrali złośliwy plik spod adresu skryptu DebugBear używanego przez Polymarket. Plik miał 15 187 bajtów i według analizy statycznej:

• odczytywał z localStorage klucze związane z sesją logowania i portfelem użytkownika Polymarket,
• przeszukiwał wewnętrzne struktury komponentów React, aby znaleźć obiekt klienta transakcyjnego z metodami składania zleceń,
• sprawdzał wartość portfela i powyżej określonego progu wystawiał zlecenia sprzedaży pozycji albo przelewał tokeny na adres napastnika,
• prosił o podpisy transakcji w standardzie EIP-712 i przesyłał je do infrastruktury Polymarket,
• raportował wyniki na adresy podszywające się pod endpointy pomiarowe DebugBear.

Istotny szczegół: według Hudson Rock skrypt nie wykradał haseł, fraz seed ani kluczy prywatnych. Nie musiał. Korzystał z uprawnień, które zalogowany użytkownik już miał w otwartej karcie przeglądarki. Polymarket w swoim raporcie z 30 października potwierdził, jak relacjonuje Search Engine Journal, że kod sprzedawał pozycje i przenosił środki z portfeli części użytkowników.

Skala strat różni się w zależności od źródła. Wiele serwisów, m.in. Yahoo Finance i Casino.org, podaje szacunek około 2,7 mln dolarów skradzionych z ponad 700 kont. Serwis CryptoRank pisze o 737 portfelach opróżnionych w ciągu godziny i łącznej kwocie 2,73 mln dolarów. Hudson Rock na podstawie zrzutu ekranu z eksploratora blockchain wskazuje około 2,19 mln dolarów na jednym z adresów odbiorczych, wyraźnie zaznaczając, że nie jest to zweryfikowana suma strat.

Polymarket wstrzymał handel na platformie międzynarodowej, a następnie go wznowił. Jak podała agencja Reuters, firma zapowiedziała zwrot środków poszkodowanym, a według CNBC zgłosiła sprawę brytyjskim organom ścigania. Z analizy Hudson Rock wynika również, że w kodzie produkcyjnym Polymarket pojawiła się zmiana usuwająca skrypt DebugBear RUM, z sygnaturą czasową 29 października, około 18:00 UTC.

Oś czasu incydentu

Wciąż nie wiadomo, czy złośliwy kod trafił także na strony innych klientów DebugBear. Hudson Rock pisze wprost, że zebrane dowody nie wskazują na szerszą kompromitację, ale nie ustalono też momentu pierwszego wstrzyknięcia ani pełnego okna ekspozycji. Rano 1 listopada domena debugbear.com nie rozwiązywała się z naszego serwera testowego, co pasuje do komunikatu firmy o problemach z domeną, choć sama firma tego nie skomentowała.

Co to znaczy dla SEO i AIO

Na pierwszy rzut oka to historia z pogranicza kryptowalut i cyberbezpieczeństwa. W praktyce dotyka codziennej pracy każdego, kto zajmuje się technicznym SEO, bo skrypty RUM są dziś standardowym elementem audytów wydajności. Warto rozbić to na kilka konkretnych wątków.

1. Jeśli używasz DebugBear RUM, usuń skrypt teraz

To pierwsza i najważniejsza rekomendacja, zgodna z komunikatem samego DebugBear. Kod osadzenia wygląda zwykle jak tag <script async src="https://cdn.debugbear.com/IDENTYFIKATOR.js">, przy czym identyfikator różni się w zależności od strony. Trzeba sprawdzić szablony motywu, wtyczki, kontenery Google Tag Managera i wszystkie miejsca, w których ktoś mógł wkleić kod „na chwilę”. Po usunięciu należy wyczyścić cache strony i CDN, a potem zweryfikować w narzędziach deweloperskich przeglądarki, że żądanie do cdn.debugbear.com faktycznie zniknęło.

2. Usunięcie tagu nie cofa szkód

Search Engine Journal słusznie podkreśla, że usunięcie skryptu blokuje tylko nowe załadowania. Nie odwraca działań, które kod mógł wykonać wcześniej. Autor tekstu, Vahan Petrosyan, zaleca zespołom deweloperskim i bezpieczeństwa:

• unieważnienie aktywnych sesji i reset haseł, zaczynając od administratorów i kont uprzywilejowanych, które odwiedzały strony z załadowanym skryptem,
• odwołanie kluczy API, które mogły zostać ujawnione,
• przegląd nowych kont, zmian uprawnień, historii Tag Managera, szablonów i wtyczek pod kątem nieautoryzowanych modyfikacji i backdoorów,
• analizę logów pod kątem nietypowych logowań, nowych plików i transakcji w okresie, gdy skrypt był aktywny.

Dla właścicieli stron na WordPressie to szczególnie ważne. Jeśli skrypt ładował się także w panelu administracyjnym albo na stronach odwiedzanych przez zalogowanych redaktorów, teoretycznie mógł wykonywać akcje z ich uprawnieniami. To kontrole do przeprowadzenia, a nie potwierdzone przypadki u innych klientów, ale ryzyko jest realne.

3. Zhakowana strona to problem rankingowy, nie tylko wizerunkowy

Jeżeli strona zacznie serwować złośliwy kod, Google może oznaczyć ją przez Safe Browsing jako niebezpieczną. Użytkownicy Chrome zobaczą wtedy czerwone ostrzeżenie zamiast treści, a w Google Search Console pojawi się wpis w raporcie problemów z bezpieczeństwem. Ruch organiczny w takiej sytuacji spada niemal do zera z dnia na dzień, a odzyskanie zaufania wymaga oczyszczenia serwisu i złożenia prośby o ponowne sprawdzenie.

Search Engine Journal radzi, by po potwierdzeniu kompromitacji przełączyć serwis w tryb konserwacji z kodem odpowiedzi HTTP 503. Z perspektywy SEO to właściwy wybór: Google traktuje 503 jako sygnał przejściowej niedostępności i nie wyrzuca od razu stron z indeksu. Trzeba jednak pamiętać, że tryb konserwacji trwający wiele dni zaczyna szkodzić widoczności, więc sprzątanie powinno być szybkie, a powrót poprzedzony weryfikacją, że w kodzie nie zostały żadne backdoory.

4. Każdy zewnętrzny skrypt to dług zaufania

Incydent DebugBear przypomina głośną sprawę Polyfill.io z 2024 roku, kiedy po przejęciu domeny popularnej biblioteki złośliwy kod trafił na ponad sto tysięcy stron. Mechanizm jest ten sam: strona ufa domenie zewnętrznej, a domena zmienia właściciela lub zostaje przejęta. Tym razem nie chodziło o sprzedaż domeny, lecz o przejęcie rekordów DNS u rejestratora, co jest jeszcze trudniejsze do wykrycia z perspektywy klienta.

Dla zespołów technicznego SEO wynika z tego kilka praktycznych wniosków:

• Inwentaryzacja skryptów. Warto mieć aktualną listę wszystkich zewnętrznych domen, z których strona ładuje JavaScript, wraz z informacją, kto i po co je dodał. Osierocone tagi po zakończonych testach to najczęstsze źródło niepotrzebnego ryzyka.
• Content Security Policy. Nagłówek CSP z listą dozwolonych źródeł nie uchroni przed przejęciem zaufanej domeny, ale ogranicza, dokąd złośliwy kod może wysyłać dane i skąd może dociągać kolejne pliki.
• Self-hosting tam, gdzie się da. Biblioteka web-vitals od Google może być serwowana z własnego serwera, a dane wysyłane do własnego endpointu lub do GA4. Nie zastąpi rozbudowanych paneli komercyjnych narzędzi, ale nie wprowadza zewnętrznej domeny do łańcucha zaufania.
• Brak RUM na stronach wrażliwych. Panel klienta, koszyk, płatności i panel administracyjny to miejsca, gdzie skrypty pomiarowe dają najmniej wartości SEO, a niosą największe ryzyko.

5. Dane polowe można mieć bez żadnego skryptu

Warto przypomnieć, że Google sam udostępnia dane o rzeczywistych doświadczeniach użytkowników z raportu Chrome UX Report (CrUX). Widać je w PageSpeed Insights, w raporcie Core Web Vitals w Search Console oraz przez API CrUX. Nie wymagają osadzania czegokolwiek na stronie. Mają swoje ograniczenia: są agregowane w oknie 28 dni, dotyczą tylko stron z odpowiednio dużym ruchem i nie pokazują szczegółów sesji. Dla wielu mniejszych serwisów są jednak w zupełności wystarczające, o czym pisaliśmy przy okazji analizy, ile realnie ważą Core Web Vitals dla pozycji. Jeśli szukasz alternatyw, przydatne może być też nasze zestawienie darmowych narzędzi SEO, które realnie zastępują płatne.

W kontekście AIO incydent ma jeszcze jeden wymiar. Agenci AI i przeglądarki z wbudowanymi asystentami coraz częściej działają w imieniu zalogowanego użytkownika. Każdy skrypt wykonywany na stronie dzieli z nimi to samo środowisko. Im więcej transakcji przechodzi przez interfejsy webowe obsługiwane przez agentów, tym większą wartość dla napastników ma przejęcie dowolnego zaufanego skryptu, który ładuje się w tej samej karcie.

Reakcje branży

Incydent szybko wyszedł poza media kryptowalutowe. Search Engine Journal opublikował osobny alert skierowany do właścicieli stron i zespołów SEO, a autor podkreślił, że kluczowe pytanie brzmi: co złośliwy kod może zrobić z uprawnieniami odwiedzającego, który jest już zalogowany. To pytanie dotyczy każdego sklepu internetowego, serwisu SaaS czy portalu z kontami użytkowników, nie tylko platform kryptowalutowych.

Hudson Rock w swojej analizie zachowuje dużą ostrożność. Badacze wyraźnie oddzielają ustalenia z analizy kodu od niezweryfikowanych informacji, nie przypisują ataku konkretnej grupie i zaznaczają, że nagłówek modyfikacji pliku na CDN nie wyznacza początku ataku. Wskaźniki złośliwego kodu opublikowała także firma The Layman Security i to na nie powołuje się Search Engine Journal, rekomendując przegląd logów.

W mediach ogólnych, m.in. u Reutersa, w Forbesie, WIRED i The Guardian, akcent padł na wstrzymanie handlu i zapowiedź pełnego zwrotu środków przez Polymarket. Komentatorzy rynku krypto zwracają uwagę, że to kolejny w tym roku incydent bezpieczeństwa związany z platformą, choć wcześniejszy, czerwcowy, miał inny przebieg. W branży webdeweloperskiej powraca natomiast dyskusja o tym, jak niewiele kontroli właściciele stron mają nad kodem ładowanym z cudzych domen i jak rzadko audyty uwzględniają rejestratora domeny dostawcy jako element łańcucha dostaw.

Co dalej

Najbliższe dni powinny przynieść odpowiedzi na kilka kluczowych pytań. Po pierwsze, czy złośliwy kod był serwowany wyłącznie na stronie Polymarket, czy także u innych klientów DebugBear. Po drugie, jak dokładnie doszło do przejęcia DNS u rejestratora: przez przejęte konto, socjotechnikę wobec obsługi czy lukę po stronie samego rejestratora. Po trzecie, jak długo trwało okno ekspozycji.

Dla zespołów SEO plan działania jest prosty, niezależnie od tego, jak zakończy się dochodzenie:

• usuń skrypt DebugBear RUM i potwierdź, że już się nie ładuje,
• przekaż sprawę zespołowi deweloperskiemu i bezpieczeństwa, z prośbą o przegląd sesji, kont i zmian w kodzie,
• sprawdź raport problemów z bezpieczeństwem w Google Search Console,
• przejrzyj pozostałe zewnętrzne skrypty na stronie i usuń te, których nikt już nie używa,
• rozważ oparcie monitoringu Core Web Vitals na danych CrUX lub na samodzielnie hostowanej bibliotece pomiarowej.

Jeżeli przy okazji robisz szerszy przegląd serwisu, warto przejść przez naszą listę kontrolną technicznego SEO i dopisać do niej punkt o inwentaryzacji skryptów zewnętrznych. Po incydencie DebugBear trudno go traktować jako opcjonalny.

FAQ