El 29 de octubre, usuarios de la plataforma internacional de Polymarket comenzaron a denunciar ventas de posiciones y retiradas que no habían autorizado. La plataforma detuvo temporalmente las nuevas operaciones y su relayer, y después explicó que un proveedor externo había sido comprometido.
Según la estimación de Bitquery, en una hora salieron aproximadamente $2,73 millones de 737 cuentas. No es una cifra oficial de Polymarket: la plataforma no ha publicado el número final de afectados ni el importe total.
Bitquery no encontró un contrato inteligente roto. Las retiradas tenían autorizaciones válidas y pasaron por la infraestructura habitual de Polymarket. Para el sistema parecían operaciones autorizadas, aunque sus propietarios afirmaban no haberlas solicitado.
La cronología del incidente
El análisis on-chain sitúa las primeras retiradas a las 17:10 UTC. Cinco cuentas fueron vaciadas en el primer grupo, una de ellas por unos $75.000. Tras una pausa de 13 minutos, la actividad llegó a 40 retiradas por minuto.
A las 18:10 UTC, Bitquery contabilizaba 737 cuentas afectadas. La mayor pérdida individual fue de unos $358.000. El 39% perdió menos de $100, pero cuatro cuentas concentraron el 43% del importe rastreado. También se transfirieron posiciones abiertas desde 33 cuentas.
A las 18:05 UTC, la página oficial de estado anunció el modo cancel-only: se podían cancelar órdenes existentes, pero no colocar ni ejecutar otras nuevas. El relayer también quedó suspendido.
A las 18:37 UTC, Polymarket afirmó haber identificado y corregido el problema. Lo atribuyó a un proveedor externo comprometido, remitió el caso a las autoridades y prometió compensar íntegramente a los afectados. A las 19:05 UTC, el incidente figuraba como resuelto.
Cómo un script externo pudo alcanzar los fondos
Una plataforma moderna carga componentes externos para analítica, control de rendimiento, asistencia o detección de errores.
La integración la instala el propietario del sitio, no cada usuario. En este caso, las investigaciones apuntan a un script de monitorización integrado en la web de Polymarket. Al abrir la plataforma, el navegador lo cargaba automáticamente con el resto de la página. Los usuarios no instalaban ninguna aplicación ni extensión de DebugBear.
Ese código se ejecuta dentro de una página en la que el usuario ya confía. Si el proveedor queda comprometido, código malicioso puede llegar a través de la integración normal e interactuar con una sesión autenticada.
Polymarket no identificó públicamente al proveedor. Sin embargo, Associated Press y otros medios relacionaron el incidente con DebugBear. La propia empresa informó ese día de un problema de seguridad y recomendó retirar su código de Real User Monitoring.
BleepingComputer analizó una copia del JavaScript malicioso. Según su informe, comprobaba si había una sesión activa, evaluaba saldos y posiciones e intentaba utilizar las funciones normales de Polymarket para transferirlos.
No es lo mismo que explotar un contrato inteligente. El contrato puede verificar correctamente una autorización y ejecutar exactamente la instrucción recibida. El problema aparece antes, en la interfaz que prepara la acción en nombre de un usuario autenticado.
Deposit wallet, approval y relayer
El deposit wallet guarda los fondos de la cuenta en Polygon. Según Bitquery, contenía pUSD respaldado uno a uno por USDC.
Un approval autoriza una acción. Para la blockchain es una instrucción criptográficamente válida, pero la red no sabe si la persona comprendió la operación, si la interfaz fue alterada o si código externo abusó de la sesión.
El relayer envía la transacción y paga la comisión de red. Así, el usuario no necesita pagar cada acción por separado con la moneda nativa.
Bitquery concluye que esta ruta funcionó con normalidad técnica el 29 de octubre. Lo que cambió fue el destino: los fondos llegaron a una dirección controlada por el atacante.
Por eso, una autorización válida no equivale a una retirada voluntaria. La primera describe la verificación de la blockchain; la segunda, la intención humana.
Una anomalía visible en la cadena
La oleada principal terminó casi al mismo tiempo que se pausó el relayer. Durante las dos semanas anteriores, la mediana era de unas 47 retiradas diarias convertidas a POL mediante Relay. El 29 de octubre, una única dirección recibió 981 transferencias.
Un sistema de control podría combinar varias señales: cientos de cuentas, un mismo destino, un salto brusco en la frecuencia, posiciones vendidas justo antes de retirar y una desviación extrema respecto a la actividad habitual.
Según Bitquery, los fondos se convirtieron a POL, se concentraron en una dirección y después se repartieron entre nuevas carteras y comenzaron a cruzar hacia Ethereum. Una nueva cuenta de Polymarket también habría servido para vender o canjear posiciones robadas.
En la última captura del análisis, a las 19:49 UTC, la mayor parte de los fondos rastreados seguía en Polygon. Es una fotografía temporal, no un balance definitivo.
Por qué las cifras siguen siendo estimaciones
Los datos on-chain muestran direcciones, importes y horas, pero no identifican por sí solos al atacante ni explican cómo se obtuvo cada autorización. Bitquery contabilizó la ruta que pudo rastrear; otras direcciones o métodos podrían modificar el total.
La formulación correcta es: Bitquery estimó $2,73 millones de pérdidas rastreadas en 737 cuentas. Polymarket no ha confirmado oficialmente esas cifras.
Compensación y responsabilidad
Polymarket prometió compensar íntegramente a todos los afectados. Al publicarse este artículo todavía no había comunicado el número final de cuentas, el total de reembolsos ni un calendario completo.
Para el cliente, un proveedor externo forma parte del producto. No utiliza de manera aislada un contrato, un relayer o una herramienta de monitorización. Si una dependencia se ejecuta dentro de la interfaz de confianza y accede a una sesión autenticada, su seguridad también es responsabilidad de la plataforma.
En junio de 2026 Polymarket ya informó de otro incidente en el que un proveedor comprometido introdujo código malicioso en el frontend de algunos usuarios. Los dos casos comparten la categoría de riesgo, pero no hay pruebas suficientes para afirmar que tuvieron el mismo mecanismo o que estuvieran conectados.
Un contrato seguro no protege todo el sistema
Una blockchain puede confirmar que una transacción cumple las reglas técnicas. No puede confirmar que la persona vio una interfaz honesta, entendió la dirección de destino y quiso realizar esa operación.
La cadena completa de seguridad es:
código externo → sesión del navegador → autorización → relayer → contrato inteligente → dirección de destino
El 29 de octubre, el final de esa cadena funcionó como estaba diseñado. Bastó comprometer el inicio para que una ejecución correcta produjera un resultado equivocado para los usuarios.
Polymarket limitó las operaciones, restauró la negociación y prometió compensaciones. Ahora faltan la confirmación de esos pagos y una explicación de las medidas que impedirán que otra dependencia externa vuelva a generar transacciones válidas, pero no deseadas.


