Skrip Pihak Ketiga Polymarket Dibajak, Pelajaran bagi Situs

Sebuah skrip pihak ketiga untuk mengukur kecepatan halaman menjadi pintu pencurian di Polymarket pada 29 Oktober 2026. Penyerang mengganti skrip milik DebugBear yang dimuat situs itu, lalu memakai sesi pengguna yang sedang masuk untuk menjual posisi dan memindahkan dana. Polymarket kini mengembalikan total 3,9 juta dolar AS kepada para penggunanya.

Kasus ini relevan bagi siapa pun yang mengelola situs web, karena titik masuknya berada di luar sistem Polymarket sendiri, yaitu pada sepotong kode dari pemasok tepercaya yang dimuat di halaman situs.

Kronologi serangan pada 29 Oktober

Polymarket adalah platform pasar prediksi berbasis kripto. Pada 29 Oktober, sejumlah pengguna melaporkan penarikan dana yang tidak mereka lakukan. Polymarket lalu mengalihkan bursanya ke mode cancel-only, yaitu mode yang hanya mengizinkan pembatalan pesanan, dan menghentikan sementara layanan relayer yang meneruskan transaksi pengguna ke blockchain.

Menurut penelusuran blockchain yang dirangkum The Hacker News, dompet penyerang menerima dana pertama pukul 17.10 UTC dan dana terakhir pukul 18.02 UTC. Polymarket mengunggah pembaruan status pertama pukul 17.38 UTC. Peneliti Hudson Rock menemukan build produksi Polymarket bertanda waktu 17.59 UTC yang berisi perubahan untuk menghapus skrip DebugBear, dan mode cancel-only berlaku pukul 18.05 UTC.

SecurityWeek melaporkan perdagangan dibuka kembali sekitar satu jam kemudian. Platform Polymarket untuk pasar Amerika Serikat dilaporkan tidak terdampak. Polymarket menyatakan salah satu penyedia pihak ketiganya telah disusupi dan kasusnya sudah dilaporkan ke aparat penegak hukum.

Cara kerja skrip yang diganti

DebugBear adalah perusahaan asal Inggris yang menyediakan pemantauan kinerja situs. Salah satu produknya adalah skrip real user monitoring (RUM), yaitu kode kecil yang dipasang di halaman untuk mencatat seberapa cepat halaman terbuka di perangkat pengunjung sungguhan. Skrip seperti ini lazim dipasang di banyak situs, bersama skrip analitik, widget obrolan, dan piksel iklan.

Skrip yang dimuat dari domain pemasok berjalan dengan hak yang sama seperti kode situs itu sendiri. Ia dapat membaca isi halaman, data yang disimpan peramban untuk situs tersebut, dan memanggil fungsi yang tersedia bagi pengguna yang sedang masuk.

Hudson Rock menganalisis salinan skrip berbahaya itu tanpa menjalankannya. Hasilnya dirangkum The Hacker News dan SecurityWeek:

• Skrip mencari komponen pemesanan dan portofolio milik pengguna yang sedang masuk, termasuk kunci API perdagangan yang tersimpan di peramban.
• Kunci API saja tidak cukup untuk memasang pesanan karena setiap pesanan juga memerlukan tanda tangan dompet. Skrip lalu meminta penanda tangan milik akun itu sendiri untuk menyetujui permintaannya dan meneruskannya ke relayer Polymarket.
• Untuk akun yang masuk lewat dompet kripto, skrip memindahkan posisi langsung ke dompet penyerang. Untuk akun yang masuk lewat email, skrip menjual posisi dengan harga yang makin buruk, lalu memindahkan hasilnya.
• Hudson Rock tidak menemukan kode yang mengirim kata sandi, seed phrase, atau kunci privat ke server penyerang.

Dengan kata lain, penyerang tidak perlu mencuri kata sandi karena mereka cukup menumpang pada sesi yang sudah sah. Hudson Rock juga mencatat bahwa analisis statis tidak membuktikan setiap langkah berhasil, karena penyedia dompet dapat saja menampilkan konfirmasi atau menolak permintaan.

Penyebabnya berada di DNS pemasok

Pada awalnya, DebugBear hanya mengonfirmasi bahwa mereka terdampak insiden keamanan dan meminta pelanggan produk RUM untuk mencabut kode sematan dari situs masing-masing. Pada 2 November, SecurityWeek mengutip temuan awal perusahaan itu: “Our DNS server records were compromised through our domain registrar.”

DNS bekerja seperti buku alamat internet: ia menentukan server mana yang menjawab ketika peramban meminta sebuah alamat. Registrar adalah tempat domain itu didaftarkan dan catatan DNS-nya diatur. Bila akses ke registrar jatuh ke tangan penyerang, alamat resmi pemasok dapat diarahkan ke server lain tanpa menyentuh server pemasok sama sekali.

The Hacker News melaporkan bahwa skrip DebugBear yang normal sebelumnya dilayani dari Google Cloud Storage. Pada pukul 18.13 UTC, alamat DebugBear dijawab oleh server yang berbeda. Setiap pelanggan DebugBear memuat salinan skripnya sendiri, dan file yang ditukar adalah milik Polymarket. Temuan awal DebugBear menyebut serangan tampaknya hanya menyasar situs satu pelanggan, dan sejauh ini tidak ada tanda sistem internalnya dibobol. DebugBear belum menjelaskan bagaimana penyerang mendapat akses di tingkat registrar. Saat artikel ini disusun, halaman utama DebugBear masih menampilkan pemberitahuan bahwa layanannya untuk sementara tidak tersedia karena insiden keamanan.

Dana yang dikembalikan

Dalam pembaruan 30 Oktober, Polymarket mencatat 726 dompet terdampak dengan kerugian langsung sekitar 2,7 juta dolar AS. Pada hari itu, semua dompet kecuali 37 sudah menerima penggantian penuh, dan sisanya dibayar setelah datanya diverifikasi. Firma keamanan GoPlus memberi angka sedikit berbeda, yaitu sekitar 2,71 juta dolar AS lewat 710 dompet deposit.

Polymarket juga membayar 1,19 juta dolar AS kepada sekitar 5.500 dompet yang merugi akibat penghentian perdagangan atau posisinya dijual dan dipindahkan oleh skrip. Totalnya mencapai 3,9 juta dolar AS. Menurut Hackread, pengguna tidak perlu mengajukan klaim karena dompet yang berhak diidentifikasi dari data transaksi.

Ini bukan kali pertama. Pada Juni 2026, Polymarket melaporkan kasus serupa: skrip berbahaya disisipkan ke tampilan situsnya lewat pemasok pihak ketiga, dengan kerugian sekitar 3 juta dolar AS.

Apa artinya bagi pengelola situs web?

Hampir setiap situs memuat kode dari pihak lain. Toko online memasang widget obrolan dan piksel iklan, portal layanan publik memasang analitik, dan aplikasi web perbankan memakai alat pemantau kinerja. Semua skrip itu ikut berjalan di halaman masuk, keranjang belanja, atau formulir data pribadi bila tidak diatur. Kasus Polymarket memperlihatkan bahwa kepercayaan kepada pemasok tidak cukup, karena pemasok yang jujur pun dapat kehilangan kendali atas domainnya.

Inventarisasi dan kurangi skrip di halaman sensitif

Mulailah dengan daftar semua skrip yang dimuat dari domain lain, siapa pemasoknya, untuk apa, dan di halaman mana skrip itu muncul. Hudson Rock menyarankan agar kode pihak ketiga yang tidak diperlukan tidak dimuat di halaman tempat pengguna bertransaksi atau memberi persetujuan. Halaman masuk, pembayaran, dan pengisian data pribadi sebaiknya hanya memuat kode milik sendiri.

Kunci isi file yang dimuat

Subresource Integrity (SRI) membuat peramban memeriksa sidik digital (hash) sebuah file sebelum menjalankannya. Bila isinya berubah, peramban menolak file itu. Cara ini efektif untuk pustaka dengan versi tetap. Gareth Bowker dari Jscrambler, seperti dikutip Hackread, menilai manfaat SRI terbatas untuk skrip RUM karena pemasok sering memperbaruinya. Ia menyarankan organisasi juga memantau perilaku kode pihak ketiga saat berjalan di peramban. Jalan tengah lain adalah menyalin versi tertentu ke server sendiri dan memperbaruinya secara terkendali. Polymarket sendiri menyatakan akan memasang kembali skrip pihak ketiga dengan Content Security Policy (CSP) yang lebih ketat, versi yang dikunci, dan sandboxing.

Pahami batas Content Security Policy

CSP membatasi dari domain mana skrip boleh dimuat dan ke mana data boleh dikirim. Dalam kasus ini, menurut Bowker, skrip berbahaya mengirim data ke server di domain DebugBear sendiri, sehingga CSP yang mengizinkan domain pemasok tetap meloloskan trafik itu. CSP tetap berguna untuk mempersempit pintu, tetapi perlu dipadukan dengan kontrol lain.

Lindungi domain dan siapkan langkah darurat

Pelajaran dari sisi DebugBear berlaku untuk domain Anda sendiri. Akun registrar perlu dilindungi dengan autentikasi dua faktor, akses yang dibatasi, dan kunci perubahan domain bila registrar menyediakannya. Siapkan juga prosedur darurat: cara mencabut satu skrip dari semua halaman dalam hitungan menit, membersihkan cache, dan mengakhiri semua sesi pengguna. Polymarket menempuh ketiga langkah itu untuk menghentikan kerugian.

Bila tim internal belum sempat memetakan semua skrip yang berjalan di situs, audit oleh layanan keamanan siber dapat menjadi titik awal. Untuk situs baru, aturan pemuatan skrip sebaiknya ditetapkan sejak tahap pengembangan aplikasi web. Pengamanan di sisi peramban juga berkaitan dengan celah lain yang pernah kami bahas dalam pelajaran dari celah tautan berbagi ChatGPT.

Pertanyaan yang sering muncul

Apakah situs lain yang memakai DebugBear ikut terdampak?

Temuan awal DebugBear menyebut serangan tampaknya hanya menyasar satu pelanggan, dan Hudson Rock tidak menemukan tanda pelanggan lain menjadi sasaran. Penyelidikan masih berjalan, dan DebugBear tetap meminta pelanggan RUM mencabut kode sematannya sampai ada pemberitahuan lanjutan.

Apakah kata sandi pengguna Polymarket ikut dicuri?

Analisis Hudson Rock tidak menemukan kode yang mengirim kata sandi, seed phrase, atau kunci privat. Skrip memakai sesi yang sedang aktif. Polymarket juga telah mengakhiri semua sesi masuk yang aktif setelah skrip dihapus.

Apa yang dapat dilakukan pengguna layanan seperti ini?

Bowker menyarankan pengguna memeriksa riwayat transaksi dan mencabut izin token yang tidak dikenali. Hudson Rock menyarankan pengguna menolak setiap permintaan tanda tangan yang tidak mereka harapkan. Bowker juga menilai pengguna hampir tidak mungkin mengenali skrip berbahaya di situs tepercaya, sehingga tanggung jawab utama berada pada pengelola platform.

Penutup

Serangan di Polymarket berlangsung kurang dari satu jam, tetapi kerugiannya mencapai jutaan dolar karena satu skrip pemasok mendapat hak penuh di halaman yang sensitif. Bagi pengelola situs, langkah awalnya adalah mengetahui skrip apa saja yang berjalan, membatasi halaman tempat skrip itu dimuat, dan menyiapkan cara mencabutnya dengan cepat. Tim Merakit siap membantu memetakan dan menata skrip pihak ketiga di situs Anda.

Sumber

• Hackers Steal About $2.7 Million From Polymarket Traders via Hijacked DebugBear Script, The Hacker News, 1 November 2026
• Polymarket Returns $3.9 Million to Traders as DebugBear Cites DNS Hijack, SecurityWeek, 2 November 2026
• $2 Million+ Drained From Polymarket Traders in New Supply Chain Attack, SecurityWeek, 30 Oktober 2026
• Polymarket Users Lose $2.7 Million in Third-Party Script Hack, Hackread, 31 Oktober 2026
• DebugBear Security Incident, pemberitahuan di situs DebugBear, diakses 3 November 2026
• Subresource Integrity, MDN Web Docs