Wprowadzenie do problemu / definicja
Ataki typu supply chain na warstwę JavaScript należą dziś do najpoważniejszych zagrożeń dla aplikacji webowych obsługujących dane wrażliwe i operacje finansowe. W takim scenariuszu napastnik nie musi bezpośrednio włamywać się do infrastruktury ofiary. Wystarczy przejęcie zaufanego zasobu zewnętrznego, który strona ładuje w przeglądarce użytkownika.
W opisywanym incydencie ofiarą została platforma predykcyjna Polymarket, a nośnikiem złośliwego kodu był skrypt związany z usługą monitorowania wydajności DebugBear. Skutkiem ataku były straty szacowane na około 2,7 mln USD oraz naruszenie bezpieczeństwa setek aktywnych sesji użytkowników.
W skrócie
Złośliwy skrypt został załadowany na stronę Polymarket 29 października 2026 roku. Według dostępnych informacji atak dotknął 726 portfeli i umożliwił przejmowanie wartości z kont użytkowników korzystających z aktywnych sesji.
- wektorem ataku był przejęty zewnętrzny skrypt JavaScript,
- incydent nie wynikał z bezpośredniego włamania do backendu Polymarket,
- napastnicy nadużyli uprawnień już dostępnych w kontekście przeglądarki,
- platforma po wykryciu problemu usunęła skrypt i zresetowała aktywne sesje.
Kontekst / historia
Polymarket korzystał z osadzonego komponentu zewnętrznego do monitorowania rzeczywistej wydajności serwisu. Tego typu skrypty są szeroko stosowane do analizy czasu ładowania, responsywności interfejsu i jakości doświadczeń użytkownika. Problem pojawia się wtedy, gdy aplikacja produkcyjna ufa kodowi pobieranemu dynamicznie z zewnętrznej domeny.
W tym przypadku ustalono, że kompromitacja miała związek z przejęciem rekordów DNS dostawcy skryptu za pośrednictwem rejestratora domeny. W rezultacie użytkownicy odwiedzający Polymarket pobierali zmodyfikowaną wersję skryptu, która wykonywała nieautoryzowane działania w kontekście ich zalogowanej sesji. To podręcznikowy przykład ataku supply chain na frontend aplikacji.
Analiza techniczna
Atak nie polegał na klasycznej kradzieży fraz seed, prywatnych kluczy czy haseł. Złośliwy kod działał bezpośrednio w przeglądarce użytkownika, korzystając z już aktywnej sesji i zaufanego kontekstu aplikacji. Dzięki temu mógł odczytywać dane dostępne po stronie klienta oraz wykorzystywać mechanizmy służące do inicjowania operacji handlowych.
Kluczowy element ataku polegał na ponownym użyciu funkcji strony odpowiedzialnych za składanie zleceń i interakcję z modułami autoryzacyjnymi. Skrypt wyszukiwał komponenty odpowiadające za operacje transakcyjne i próbował wykonywać akcje przy użyciu istniejącego kontekstu uwierzytelnienia. W praktyce oznaczało to możliwość przejęcia pozycji lub sprzedaży aktywów bez potrzeby zdobywania sekretów w tradycyjnym rozumieniu.
W przypadku użytkowników logujących się przez portfel kryptowalutowy skutkiem miało być przenoszenie pozycji do portfela kontrolowanego przez napastników. Przy logowaniu przez e-mail złośliwy kod miał wyprzedawać pozycje po coraz mniej korzystnych cenach, a następnie transferować uzyskane środki. Taki model działania pokazuje, że przejęcie sesji aplikacyjnej bywa równie niebezpieczne jak kompromitacja danych uwierzytelniających.
Polymarket poinformował po incydencie o usunięciu skryptu, wyczyszczeniu pamięci podręcznej, zresetowaniu sesji logowania i czasowym ograniczeniu działania platformy. Firma zapowiedziała również przywracanie skryptów stron trzecich z dodatkowymi zabezpieczeniami, w tym silniejszą polityką CSP, pinningiem wersji oraz sandboxingiem.
Konsekwencje / ryzyko
Incydent pokazuje, że aplikacje finansowe i kryptowalutowe są szczególnie narażone na skutki kompromitacji zewnętrznych zależności frontendowych. Nawet jeśli backend pozostaje nienaruszony, złośliwy JavaScript uruchomiony w przeglądarce może uzyskać realny wpływ na majątek użytkownika i procesy biznesowe.
- przejęcie lub likwidacja pozycji użytkowników w ramach aktywnej sesji,
- transfer środków przy użyciu legalnych mechanizmów autoryzacji,
- utrudnione wykrycie incydentu, ponieważ ruch przypomina zwykłą aktywność użytkownika,
- spadek zaufania do platformy i wysokie koszty działań naprawczych,
- ryzyko rozszerzenia podobnego scenariusza na inne serwisy korzystające z tych samych zależności.
Z perspektywy bezpieczeństwa to ważne przypomnienie, że granica zaufania w przeglądarce obejmuje każdy załadowany skrypt. Jeśli ma on dostęp do sesji, interfejsów transakcyjnych lub komponentów podpisujących, jego przejęcie może oznaczać częściowe przejęcie całej aplikacji.
Rekomendacje
Organizacje utrzymujące aplikacje webowe o wysokiej wrażliwości powinny ograniczać obecność skryptów zewnętrznych wszędzie tam, gdzie dochodzi do logowania, podpisywania operacji lub zarządzania aktywami. Ochrona backendu nie wystarcza, jeśli kod wykonywany po stronie klienta ma szerokie uprawnienia.
- usunąć zbędne komponenty third-party z obszarów uwierzytelnionych,
- stosować Subresource Integrity tam, gdzie możliwe jest przypięcie konkretnej wersji zasobu,
- wdrożyć restrykcyjną politykę Content Security Policy,
- stosować pinning wersji zamiast dynamicznego pobierania najnowszych skryptów,
- odseparować funkcje transakcyjne od kodu telemetrycznego i marketingowego,
- monitorować zmiany DNS, certyfikatów i zachowania zewnętrznych zależności,
- analizować, jakie operacje może wykonać kod działający w kontekście zalogowanego użytkownika,
- wymuszać dodatkowe potwierdzenie dla operacji wysokiego ryzyka.
Po stronie użytkowników końcowych kluczowe znaczenie ma ostrożność wobec nieoczekiwanych żądań podpisu i nietypowych działań w aktywnej sesji. W środowisku kryptowalutowym dobrą praktyką pozostaje rozdzielanie portfeli operacyjnych od portfeli przechowujących większą wartość aktywów.
Podsumowanie
Atak na Polymarket pokazuje, jak groźna może być kompromitacja zaufanego skryptu JavaScript w aplikacji obsługującej aktywa cyfrowe. Napastnicy nie musieli przejmować całej infrastruktury ofiary ani kraść klasycznych sekretów. Wystarczyło przejęcie kanału dostarczania kodu do przeglądarki użytkownika.
Dla zespołów bezpieczeństwa to wyraźny sygnał, że ochrona aplikacji webowych musi obejmować również zarządzanie zależnościami frontendowymi, model zaufania do usług stron trzecich oraz ograniczanie możliwości wykonywania operacji wysokiego ryzyka w kontekście przeglądarkowej sesji użytkownika.