# Creator Pulse: Incydent Polymarket kieruje debatę o bezpieczeństwie na sesję handlową Creator Pulse, wydanie 1. Opublikowano 2026-10-30. 3 min czytania. Strona kanoniczna: https://www.w3match.com/pl/reports/creators-2026-10-30 Incydent Polymarket z 29 października pokazuje, dlaczego warto wspólnie wyjaśniać kod przeglądarki i uprawnienia portfela. Badacze znaleźli skrypt monitorujący zaprojektowany do wykorzystania aktywnej sesji handlowej. Handel wznowiono, lecz obietnica zwrotu środków i działająca platforma odpowiadają na różne pytania. Najważniejszy dalszy materiał powinien wyjaśnić autoryzację, zakres narażenia i faktycznie wypłacone rekompensaty. ## W minutę Incydent Polymarket z 29 października pokazuje, dlaczego warto wspólnie wyjaśniać kod przeglądarki i uprawnienia portfela. Badacze znaleźli skrypt monitorujący zaprojektowany do wykorzystania aktywnej sesji handlowej. Handel wznowiono, lecz obietnica zwrotu środków i działająca platforma odpowiadają na różne pytania. Najważniejszy dalszy materiał powinien wyjaśnić autoryzację, zakres narażenia i faktycznie wypłacone rekompensaty. ## Główny temat ### Znana strona może zawierać nieznane instrukcje Polymarket tymczasowo wstrzymał handel na platformie międzynarodowej 29 października po naruszeniu bezpieczeństwa zewnętrznego dostawcy. Następnie przywrócił handel i obiecał zwrot środków poszkodowanym. [Oświadczenie firmy przytoczone w relacji z dnia incydentu](https://www.bleepingcomputer.com/news/security/polymarket-halts-trading-after-crypto-draining-script-breach-25m-traced/) potwierdza jej reakcję i zobowiązanie. Nie zawiera końcowego rozliczenia strat ani sumy już wypłaconych rekompensat. **Dlaczego teraz:** Przerwa się skończyła, więc pytanie redakcyjne przesuwa się z tego, czy strona działa, na to, co faktycznie potwierdza przywrócenie usługi. W chwili przygotowania [strona statusu Polymarket](https://status.polymarket.com/) oznacza aplikację internetową, uwierzytelnianie, handel kontraktami prognostycznymi i rozliczenia jako działające. Dostępność jest ważna dla użytkowników zarządzających pozycjami. Zielony status nie potwierdza stanu każdej wcześniej otwartej sesji przeglądarki ani otrzymania środków przez wszystkich poszkodowanych. **Wątek wart wyjaśnienia:** Użytkownik może ufać kontraktom rynku, a przy podejmowaniu decyzji o podpisie nadal zależeć od oprogramowania spoza tych kontraktów. Strona wyświetlająca pozycje pośredniczy także w dostępie do funkcji handlu i przenoszenia aktywów. Przydatne wyjaśnienie śledzi ten łańcuch uprawnień: który kod wybiera operację, który komponent prosi o autoryzację i która usługa wysyła wynikową transakcję. [Analiza Hudson Rock z 29 października](https://www.infostealers.com/article/polymarket-breach-alert-wallet-draining-code-found-in-a-third-party-script/) opisuje pobranie i statyczne zbadanie złośliwego skryptu monitorującego. Według badaczy kod szukał aktywnego klienta handlowego i komponentu podpisującego, sprawdzał aktywa oraz próbował transferów lub sprzedaży zależnie od typu konta. Znaleziono też opublikowane metadane kompilacji odnotowujące usunięcie integracji DebugBear. Badacze nie uruchamiali próbki, a metadane nie wyznaczają dokładnego momentu wdrożenia ani opanowania incydentu. To ustalenie zmienia sposób, w jaki twórca może wyjaśnić zdarzenie. Atakujący nie musi przełamywać reguł kontraktu, jeśli złośliwy kod strony potrafi dotrzeć do ścieżki autoryzacji już używanej przez aplikację. Jednocześnie samo żądanie podpisu nie dowodzi, że każdy portfel podpisuje je bez wiedzy użytkownika. Komunikaty potwierdzające, ograniczenia komponentu podpisującego, uprawnienia sesji i wykonanie transakcji mogą wpływać na wynik. Opisanie próby zapisanej w kodzie jako dokonanej kradzieży u wszystkich odwiedzających zacierałoby te różnice. Konkretny przykład pozwala rozdzielić role. Przeglądarka proponuje przeniesienie pozycji; komponent podpisujący dostarcza autoryzację wymaganą przez dane konto; usługa transakcyjna przekazuje żądanie; sieć stosuje własne reguły. To ilustracja procesu, a nie rekonstrukcja każdego poszkodowanego konta. Pokazuje, dlaczego transakcja może spełniać techniczne wymogi autoryzacji, choć właściciel konta kwestionuje operację. Najmocniejszym kontrargumentem wobec szerokich wniosków o bezpieczeństwie jest ograniczona wiedza o zasięgu narażenia. Złośliwe zachowanie w jednej pobranej próbce nie identyfikuje wszystkich dostarczanych wersji, wszystkich odbiorców ani wszystkich udanych transferów. Rzetelny opis rozdziela więc zamierzone działanie od zaobserwowanych skutków. Nie powinien też uznawać wszystkich zewnętrznych integracji za równie groźne: istotne są ich uprawnienia i dostęp do funkcji mających skutki finansowe. Dla zespołów produktowych konsekwencją jest precyzyjniej określona granica do sprawdzenia. Integracja mierząca wydajność służy czemu innemu niż komponent podpisujący, lecz kod działający na tej samej uwierzytelnionej stronie może wchodzić w interakcje z używanymi przez niego obiektami. Ograniczenie tego dostępu i wymaganie ponownego potwierdzenia istotnych operacji to możliwe odpowiedzi projektowe. Ich skuteczność w tym incydencie pozostaje pytaniem do końcowego raportu technicznego, a nie potwierdzonym środkiem zaradczym. Rekompensata za przeniesioną pozycję może rodzić inne pytania o wycenę niż rekompensata salda gotówkowego; opublikowana polityka rekompensat powinna określać, jak platforma rozwiązuje tę różnicę. **Co pozostaje niepewne:** W przejrzanych materiałach nie ustalono pełnej liczby poszkodowanych, przypisanej incydentowi straty netto, metody uzyskania pierwotnego dostępu ani sumy wypłaconych rekompensat. Pobrany skrypt nie identyfikuje sprawcy. Kolejne przydatne ujawnienie powinno połączyć określone okno narażenia z transakcjami poszkodowanych i wyjaśnić, jak przywrócona usługa zabezpiecza ścieżkę autoryzacji. ## Źródła - [Oświadczenie firmy przytoczone w relacji z dnia incydentu](https://www.bleepingcomputer.com/news/security/polymarket-halts-trading-after-crypto-draining-script-breach-25m-traced/), www.bleepingcomputer.com, Nie podano daty publikacji - [strona statusu Polymarket](https://status.polymarket.com/), status.polymarket.com, Nie podano daty publikacji - [Analiza Hudson Rock z 29 października](https://www.infostealers.com/article/polymarket-breach-alert-wallet-draining-code-found-in-a-third-party-script/), www.infostealers.com, Nie podano daty publikacji Każda liczba ma wskazanego dostawcę i datę. To nie jest porada inwestycyjna.