Narzędzie, które tysiące specjalistów SEO wkleja na swoje strony, żeby mierzyć Core Web Vitals, na kilka godzin stało się bronią. 29 października 2026 roku napastnicy przejęli rekordy DNS firmy DebugBear i podmienili skrypt Real User Monitoring u jednego z klientów, giełdy prognoz Polymarket. Złośliwy kod sprzedawał pozycje zalogowanych użytkowników i wyprowadzał środki z ich portfeli, a według analiz on-chain na adres napastnika trafiło od około 2,2 do 2,6 mln dolarów.
To nie jest kolejna historia o wycieku haseł. To podręcznikowy atak na łańcuch dostaw przez skrypt zewnętrzny, czyli dokładnie ten typ kodu, który zespoły SEO i marketingu dodają do stron najczęściej i sprawdzają najrzadziej.
Kontekst: czym jest DebugBear i dlaczego to dotyczy branży SEO
DebugBear to narzędzie do monitorowania wydajności stron, popularne wśród specjalistów SEO i deweloperów front-endu. Oprócz testów laboratoryjnych oferuje moduł RUM (Real User Monitoring), który zbiera dane o LCP, INP i CLS od prawdziwych odwiedzających. Działa to w najprostszy możliwy sposób: właściciel strony wkleja do szablonu lub do menedżera tagów krótki kod osadzający, który ładuje plik JavaScript z adresu w rodzaju cdn.debugbear.com/IDENTYFIKATOR.js. Każdy klient ma własny identyfikator, a więc własny plik.
Jak podkreśla serwis Search Engine Journal, który opisał incydent w materiale Vahana Petrosyana, narzędzie jest szeroko używane przez ekspertów SEO. Skrypty RUM są dziś standardem w każdym poważniejszym stosie do pracy nad wydajnością, obok analityki, pikseli reklamowych, narzędzi do map cieplnych i testów A/B. Jeśli zajmujesz się optymalizacją szybkości strony, prawdopodobnie sam rekomendowałeś klientom podobne rozwiązanie. Przegląd takich narzędzi znajdziesz w naszym zestawieniu narzędzi do mierzenia wydajności strony.
Problem polega na tym, że skrypt monitorujący działa w przeglądarce użytkownika z pełnymi uprawnieniami strony, na której jest osadzony. Ma dostęp do DOM, do localStorage, do ciasteczek dostępnych z poziomu JavaScriptu i do wszystkiego, co aplikacja trzyma w pamięci. Jeśli ktoś podmieni jego treść, przejmuje kontrolę nad sesją każdego odwiedzającego.
Kluczowe fakty: co się wydarzyło 29 października
Rekonstrukcję zdarzeń przygotowały dwa niezależne źródła: firma Hudson Rock na swoim portalu InfoStealers oraz serwis The Layman Security, który zebrał ustalenia badaczy (w tym analityka podpisującego się jako Ohey), dane z blockchaina i komunikaty obu firm. Poniższa oś czasu podaje godziny w UTC.
| Godzina (UTC) | Zdarzenie | Źródło |
|---|---|---|
| ok. 16:54 | Serwer źródłowy DebugBear przestaje odpowiadać, od tego momentu badacze datują aktywność złośliwego skryptu | The Layman Security za Ohey |
| 17:10 | Pierwsze tokeny POL trafiają na portfel napastnika | The Layman Security |
| 17:26 | Na portfel napastnika wpływa pierwsza partia przejętych pozycji | The Layman Security |
| 17:45 | Jeden z traderów publicznie ostrzega innych, zgłaszając stratę około 800 tys. dolarów | The Layman Security |
| 17:59 | Polymarket buduje wersję serwisu z opisem zmiany „remove debugbear rum script” | Hudson Rock |
| 18:00 | DebugBear ogłasza incydent i prosi klientów RUM o usunięcie kodu osadzającego | DebugBear, LinkedIn |
| 18:05 | Polymarket przełącza giełdę w tryb „tylko anulowanie” i wstrzymuje akcje relayera | The Layman Security za stroną statusu Polymarket |
| 18:12 | Hudson Rock pobiera działający złośliwy plik do analizy | Hudson Rock |
| 18:28–18:38 | Skradzione POL zostają rozdzielone na trzy kolejne portfele | The Layman Security |
| ok. 19:00 | Polymarket informuje o pełnym przywróceniu handlu | The Layman Security |
Jak napastnicy dostali się do skryptu
W drugim komunikacie opublikowanym na LinkedIn DebugBear napisał, że rekordy jego serwerów DNS zostały przejęte za pośrednictwem rejestratora domeny. Firma przyznała też, że w efekcie nie może odbierać poczty wysyłanej na swoją domenę. Według wstępnych ustaleń atak był wymierzony w stronę jednego, konkretnego klienta, a DebugBear nie widzi oznak włamania do swoich systemów wewnętrznych, choć zapowiada dalsze dochodzenie.
Warto odnotować, że obie analizy niezależnych badaczy, publikowane w pierwszych godzinach po incydencie, określały mechanizm początkowego dostępu jako nieustalony. Wersja z rejestratorem domeny pochodzi więc wyłącznie od samego DebugBear. The Layman Security dodaje, że hosty DebugBear przestały się rozwiązywać jeszcze tego samego dnia.
Przejęcie DNS na poziomie rejestratora jest szczególnie groźne, bo nie wymaga włamania na serwery ofiary. Wystarczy przekierować subdomenę CDN na infrastrukturę napastnika. Przeglądarka użytkownika widzi wtedy dokładnie ten sam, zaufany adres, który znajduje się w kodzie strony i w jej polityce bezpieczeństwa.
Co robił złośliwy kod
Hudson Rock opublikował szczegółową analizę pliku. Najważniejsze ustalenia:
- Złośliwa wersja skryptu ważyła 15 187 bajtów, podczas gdy oryginalny skrypt DebugBear, według The Layman Security, ma 60 493 bajty. Różnica rozmiaru była więc wyraźna, ale nikt jej w czasie rzeczywistym nie monitorował.
- Kod odczytywał z localStorage klucze związane z uwierzytelnieniem Polymarket i mapą kluczy API do handlu.
- Przeszukiwał wewnętrzne struktury komponentów React, żeby znaleźć klienta handlowego aplikacji i użyć jego mechanizmu podpisywania transakcji.
- Działał dwutorowo: przy kontach z klasycznym portfelem przenosił tokeny pozycji, przy kontach opartych na usłudze Magic składał zlecenia sprzedaży po coraz bardziej agresywnych cenach, a potem przelewał uzyskane środki.
- Transakcje trafiały do relayera Polymarket, który płacił za gaz. Jak zauważa The Layman Security, skrypt nigdy nie potrzebował klucza prywatnego ani hasła ofiary.
- Kod raportował wyniki do subdomeny
data.debugbear.com, czyli pod adres, który na pierwszy rzut oka wyglądał jak zwykła telemetria narzędzia monitorującego.
Ten ostatni szczegół jest kluczowy z perspektywy obrony. Według The Layman Security wszystkie hosty, z którymi łączył się skrypt, były już dozwolone w polityce Content Security Policy Polymarket. CSP nie zatrzymała ataku, bo z jej punktu widzenia nic niezwykłego się nie działo.
Skala strat
Liczby wciąż się różnią. The Layman Security, powołując się na analizy on-chain, podaje, że na portfel napastnika trafiło około 28,6 mln POL, czyli mniej więcej 2,6 mln dolarów. Hudson Rock wskazuje na zrzut ekranu z PolygonScan pokazujący około 2,19 mln dolarów pod tym samym adresem, zastrzegając wprost, że nie jest to zweryfikowane rozliczenie. Badacz Ohey naliczył pozycje pochodzące z 33 kont. Polymarket nie podał liczby poszkodowanych.
Według relacji The Layman Security platforma zapewnia, że poszkodowani zostaną w pełni zrekompensowani, a sprawa trafiła do organów ścigania. Nie wiadomo jeszcze, kiedy i w jaki sposób zwroty zostaną wypłacone.
Co to znaczy dla SEO i AIO
Na pierwszy rzut oka to historia z pogranicza kryptowalut i cyberbezpieczeństwa. W praktyce dotyczy każdego, kto odpowiada za stronę i dorzuca do niej kolejne skrypty „tylko do pomiaru”. Oto najważniejsze wnioski dla zespołów SEO.
1. Każdy tag w menedżerze tagów to potencjalny wektor ataku
Zespoły SEO i marketingu mają często szersze uprawnienia do Google Tag Managera niż do repozytorium kodu. To wygodne, ale oznacza, że skrypty monitorujące, piksele i widżety trafiają na produkcję bez przeglądu bezpieczeństwa. Incydent DebugBear pokazuje, że nawet renomowany, wąsko wyspecjalizowany dostawca może z dnia na dzień zacząć serwować obcy kod. Inwentaryzacja tagów powinna stać się stałym punktem każdego audytu SEO, a nie jednorazowym porządkiem.
2. Zaufana domena nie gwarantuje zaufanej treści
Zarówno Hudson Rock, jak i The Layman Security wskazują to samo zabezpieczenie: Subresource Integrity (SRI) w połączeniu z restrykcyjną polityką CSP. SRI polega na dodaniu do znacznika <script> atrybutu integrity z kryptograficznym skrótem pliku. Jeśli zawartość pliku się zmieni, przeglądarka go nie wykona. Jak ujęła to The Layman Security, zaufana domena nie dowodzi, że plik jest tym samym plikiem, który sprawdziłeś.
Haczyk polega na tym, że wiele skryptów RUM i analitycznych jest celowo aktualizowanych przez dostawcę bez zmiany adresu. SRI w takim modelu zepsuje pomiar przy pierwszej aktualizacji. Realne opcje to: wersjonowane adresy plików z hashem, samodzielne hostowanie skryptu z kontrolowanymi aktualizacjami albo przynajmniej automatyczny monitoring sumy kontrolnej i rozmiaru plików zewnętrznych. W tym przypadku różnica była czterokrotna, a prosty alert wykryłby ją w kilka minut.
3. Reakcja na incydent nie może zaszkodzić indeksacji
Search Engine Journal przypomina, że jeśli włamanie zostanie potwierdzone, stronę należy odizolować i wyświetlać statyczną stronę serwisową z kodem odpowiedzi HTTP 503. To ważne z perspektywy SEO: kod 503 sygnalizuje Googlebotowi chwilową niedostępność i chroni indeks przed wymianą treści na komunikat o awarii. Zwracanie kodu 200 ze stroną „przerwa techniczna” albo masowe 404 to najkrótsza droga do utraty pozycji, które budowało się latami.
Osobny wątek to reputacja domeny. Strony serwujące złośliwy kod ryzykują ostrzeżenia w przeglądarkach i oznaczenia w systemach bezpieczeństwa wyszukiwarek, a ich usunięcie wymaga czasu i ręcznej weryfikacji. Szybkie wycięcie skryptu jest więc także decyzją SEO, nie tylko decyzją działu bezpieczeństwa.
4. Monitoring dostępności nie wystarczy
Większość firm monitoruje, czy strona działa i czy odpowiada szybko. Mało kto monitoruje, jakie zasoby ładuje i czy się zmieniły. Warto rozszerzyć istniejące automatyczne alerty uptime o kontrolę integralności skryptów zewnętrznych: listę dozwolonych domen, oczekiwane rozmiary plików i powiadomienie przy każdej zmianie.
5. Kontekst AIO: agenci w przeglądarce zwiększą stawkę
W tym ataku skrypt podszywał się pod zalogowanego użytkownika i wykonywał operacje za niego. To dokładnie ten model działania, w którym coraz częściej funkcjonują przeglądarkowi agenci AI, wykonujący zakupy, rezerwacje i transakcje w imieniu człowieka. Strony, które będą obsługiwać ruch agentowy i operacje transakcyjne, staną się bardziej atrakcyjnym celem dla ataków na łańcuch dostaw. Higiena skryptów zewnętrznych przestaje być detalem technicznym, a staje się warunkiem zaufania, także ze strony platform AI, które decydują, czy dana witryna jest bezpieczna do odwiedzenia.
Co powinni zrobić właściciele stron z kodem DebugBear RUM
Search Engine Journal opublikował listę działań dla zespołów deweloperskich i bezpieczeństwa. W skrócie:
- Natychmiast usuń kod osadzający DebugBear RUM. Sprawdź szablony, wtyczki i menedżery tagów, wyczyść cache stron i zweryfikuj, że skrypt faktycznie przestał się ładować.
- Unieważnij sesje i zresetuj hasła. Zacznij od administratorów i użytkowników z wysokimi uprawnieniami, którzy odwiedzali strony ze skryptem. Unieważnij też potencjalnie ujawnione klucze API. Upewnij się, że stare sesje są odrzucane, bo zmiana hasła nie zawsze je kończy.
- Szukaj nieautoryzowanych zmian. Przejrzyj nowo utworzone konta, zmiany uprawnień, historię menedżera tagów, szablony, wtyczki i wstrzyknięte skrypty, porównując je ze znaną, czystą wersją.
- Zidentyfikuj poszkodowane konta. Przeanalizuj logi pod kątem nietypowych logowań, nowych kont, zmienionych plików i nieoczekiwanych transakcji z okresu, gdy skrypt był aktywny.
- Przy potwierdzonym włamaniu przełącz stronę w tryb serwisowy z kodem 503, oczyść ją lub odtwórz z czystej kopii zapasowej i dopiero po weryfikacji przywróć do działania.
Search Engine Journal zaznacza przy tym, że usunięcie tagu zapobiega tylko nowym załadowaniom. Nie cofa operacji wykonanych przez napastnika ani nie usuwa niczego, co mógł on wcześniej zostawić w systemie. Serwis podkreśla też, że kontrole dotyczące zmian i tylnych furtek to zalecane sprawdzenia, a nie potwierdzone ustalenia u innych klientów.
Reakcje branży
Hudson Rock w swojej analizie zachowuje dużą ostrożność. Firma pisze, że zebrane dowody nie identyfikują napastnika ani nie wskazują na szersze włamanie dotykające innych klientów DebugBear. Badacze podkreślają też, że nie wiadomo, jak długo złośliwy plik był dostępny: nagłówek Last-Modified na CDN wskazywał 27 października, ale autorzy wprost zastrzegają, że nie traktują tej daty jako początku ataku.
The Layman Security idzie w swoich wnioskach dalej i formułuje uniwersalną lekcję: samo dopuszczenie zaufanego CDN w polityce bezpieczeństwa nie weryfikuje bajtów, które ten CDN serwuje. Ta sama myśl pojawia się w analizie Hudson Rock, co sprawia, że SRI i monitoring integralności stają się w tej sprawie rekomendacją niemal jednogłośną.
Search Engine Journal zwraca uwagę, że nie jest jeszcze jasne, czy inni klienci DebugBear również otrzymali złośliwy kod, i że celem mogły być także inne wartościowe serwisy. Sam DebugBear komunikuje się na razie przez LinkedIn i X, ponieważ utrata kontroli nad DNS odcięła firmę od poczty we własnej domenie. To dodatkowy, często pomijany koszt przejęcia domeny: firma traci kanał kontaktu z klientami dokładnie w chwili, gdy najbardziej go potrzebuje.
Warto też pamiętać, że dla Polymarket to nie pierwszy incydent w tym roku. Według The Layman Security, powołującej się na serwis Decrypt, w czerwcu 2026 roku z mniej niż 15 kont skradziono około 3 mln dolarów, a platforma zwróciła środki w całości. Tamten incydent nie miał związku z DebugBear.
Co dalej
Kilka pytań pozostaje otwartych. Po pierwsze, jak dokładnie przejęto konto u rejestratora: czy chodziło o phishing, przejęcie danych logowania, socjotechnikę wobec obsługi rejestratora, czy lukę po stronie samego rejestratora. Od odpowiedzi zależy, jak skutecznie inne firmy SaaS mogą się przed tym bronić, na przykład blokadą rejestru (registry lock), kluczami sprzętowymi czy DNSSEC.
Po drugie, czy podmiana dotyczyła wyłącznie pliku Polymarket. Skoro każdy klient ma unikalny identyfikator skryptu, napastnik mógł celować bardzo precyzyjnie, ale kontrola nad całym DNS dawała mu teoretycznie możliwość podmiany dowolnego pliku. Pełny raport poincydentalny DebugBear powinien to rozstrzygnąć.
Po trzecie, jak zareaguje rynek narzędzi do monitorowania wydajności. Można się spodziewać, że dostawcy RUM zaczną oferować wersjonowane, przypinane skrypty kompatybilne z SRI, a działy bezpieczeństwa w większych firmach zaczną przeglądać kody osadzające dodawane przez marketing. Dla zespołów SEO oznacza to więcej formalności przy wdrażaniu nowych narzędzi pomiarowych, ale też szansę, by uporządkować listę skryptów, które od lat spowalniają strony i psują wyniki INP.
Najbardziej praktyczny wniosek na dziś jest prosty: otwórz menedżera tagów, wypisz wszystkie skrypty zewnętrzne i przy każdym zadaj dwa pytania. Czy nadal go potrzebujemy? I skąd dowiemy się, że jego zawartość się zmieniła?
FAQ
Czy moja strona jest zagrożona, jeśli używam DebugBear tylko do testów laboratoryjnych?
Według dostępnych informacji problem dotyczy modułu RUM, czyli skryptu osadzanego na stronie i ładowanego w przeglądarkach odwiedzających. Testy laboratoryjne uruchamiane z panelu narzędzia nie wymagają umieszczania kodu na stronie. DebugBear prosił o usunięcie właśnie kodu osadzającego RUM.
Co to jest Subresource Integrity i czy ochroniłoby przed tym atakiem?
Subresource Integrity to atrybut integrity w znaczniku skryptu, zawierający skrót kryptograficzny pliku. Przeglądarka odrzuca plik, jeśli jego zawartość nie zgadza się ze skrótem. Podmieniony skrypt DebugBear miał zupełnie inną treść i rozmiar niż oryginał, więc SRI zablokowałoby jego wykonanie. Ograniczeniem jest to, że wiele skryptów RUM i analitycznych jest aktualizowanych przez dostawcę pod tym samym adresem, co wymaga wersjonowania lub samodzielnego hostowania.
Czy usunięcie skryptu wystarczy, żeby zamknąć temat?
Nie. Jak podkreśla Search Engine Journal, usunięcie tagu zapobiega tylko nowym załadowaniom. Trzeba też unieważnić sesje, zresetować hasła i klucze API, przejrzeć logi z okresu aktywności skryptu oraz sprawdzić, czy w systemie nie pojawiły się nowe konta, zmiany uprawnień lub tylne furtki.
Jak przełączyć stronę w tryb serwisowy, nie tracąc pozycji w Google?
Strona serwisowa powinna zwracać kod HTTP 503, najlepiej z nagłówkiem Retry-After. Taki sygnał informuje Googlebota, że niedostępność jest chwilowa, więc wyszukiwarka nie zastępuje w indeksie właściwych treści komunikatem o przerwie. Kod 200 ze stroną „przerwa techniczna” lub masowe błędy 404 mogą natomiast zaszkodzić widoczności.
Ile pieniędzy ukradziono i kto zwróci straty?
Szacunki wahają się od około 2,19 mln dolarów (Hudson Rock, na podstawie niezweryfikowanego zrzutu ekranu) do około 2,6 mln dolarów (The Layman Security, na podstawie analiz on-chain). Według relacji The Layman Security Polymarket zapewnia, że poszkodowani zostaną w pełni zrekompensowani, a sprawa trafiła do organów ścigania. Termin i sposób wypłat nie zostały jeszcze ogłoszone.