La brecha de Polymarket del 29 de octubre llegó a los traders a través de un proveedor de sitios web comprometido. Los investigadores encontraron código que intentaba usar cuentas con sesión iniciada para vender posiciones y mover activos, exponiendo la confianza que los traders depositan en la pantalla que usan para gestionar su dinero.
Resumen
- Polymarket confirmó un proveedor comprometido y restableció el trading internacional tras una interrupción de 1 hora.
- Los investigadores vincularon el incidente con un script de monitoreo de rendimiento cargado por el sitio web.
- El código recuperado buscaba acceso al cliente de trading y al firmante dentro de una sesión activa.
- Una brecha separada de un proveedor en junio ya había provocado la promesa de reembolsos completos.
- La última promesa de reembolso aún no explica cómo se valorarán las posiciones vendidas.
Un trader que usa el nombre Car dijo que aproximadamente $800,000 habían desaparecido de su cuenta de Polymarket y que todas sus posiciones habían sido vendidas. Dijo que siguió operando en un dispositivo separado y evitó enlaces desconocidos.
Otros traders reportaron pérdidas mientras Polymarket restringía su exchange internacional el 29 de octubre. La compañía confirmó posteriormente que un proveedor externo había sido comprometido y prometió reembolsar a los clientes afectados.
El relato técnico que está surgiendo apunta a software cargado dentro del sitio web de trading genuino. Los investigadores de seguridad encontraron un script de monitoreo que intentaba alcanzar las herramientas que un trader con sesión iniciada usa para colocar órdenes y autorizar acciones de la wallet.
Para esos usuarios, el peligro podría llegar a través de la página que ya habían abierto para operar. La investigación concierne al software que opera dentro de esa página y a los permisos de cuenta que podía alcanzar.
El aviso de incidente de Polymarket registra una interrupción desde las 18:05 hasta las 19:05 UTC. La compañía dijo que había solucionado el problema y remitió el incidente a las autoridades, pero no ha publicado su investigación completa ni un total final de pérdidas.
La brecha se produjo 4 meses después de que otro proveedor comprometido introdujera código malicioso en el sitio web. Polymarket también prometió reembolsos después de ese incidente.
Los traders reportaron posiciones vendidas antes de que Polymarket detuviera el trading
Un trader que usa el nombre Car dijo que su cuenta había sido vaciada de aproximadamente $800,000 y que un amigo había perdido otros $600,000. Dijo que todas sus posiciones habían sido vendidas.
En publicaciones que describen el incidente, Car dijo que separaba su actividad personal, el desarrollo de software y el trading en distintos dispositivos. Sospechaba un problema con el sitio web de la plataforma porque otros usuarios también parecían haber sido afectados.
Su cuenta describió pérdidas sufridas mientras usaba el servicio de trading, en lugar de una transferencia que él dijera haber aprobado deliberadamente. La declaración posterior de Polymarket confirmó un proveedor comprometido, aunque no publicó hallazgos sobre su cuenta individual.
Otra cuenta, StarPlatinum, rastreó una wallet receptora sospechosa y estimó que había acumulado $2.68 millones. La cuenta dijo que el saldo había crecido durante aproximadamente una hora de retiros.
La cronología del observador situó los primeros recibos alrededor de las 17:05 UTC, antes de que la compañía publicara su restricción inicial del servicio. Afirmó que la wallet tenía $412,000 a las 17:25 UTC y $2.02 millones a las 17:50 UTC.
Como crypto.news informó anteriormente, los informes iniciales de pérdidas incluían alegaciones de que los fondos habían pasado por la infraestructura de wallets de depósito de Polymarket. Esas descripciones provinieron de traders y observadores de blockchain mientras la compañía aún estaba investigando.
La compañía dijo posteriormente que había solucionado el problema y que reembolsaría a los usuarios afectados. No confirmó los montos individuales de las pérdidas ni adoptó la estimación del observador como su contabilidad final.
Una captura de pantalla que circuló durante el incidente mostraba una solicitud de firma de wallet asociada con el dominio de Polymarket. Mostraba un campo de datos DepositWallet y el identificador de cadena de Polygon, pero no mostraba una transacción completada ni los detalles completos necesarios para reconstruir la actividad de una cuenta individual.
Los informes de usuarios incluían tanto activos transferidos fuera de las cuentas como posiciones vendidas antes de que sus propietarios tuvieran la intención de cerrarlas. Polymarket no ha dicho si todos los usuarios afectados experimentaron ambas cosas.
Polymarket restableció el servicio tras una interrupción de una hora
Polymarket inicialmente puso el exchange en modo de solo cancelación y pausó las acciones del relayer mientras su equipo investigaba. La restricción permitía a los usuarios cancelar órdenes existentes mientras las nuevas órdenes y operaciones dejaban de procesarse.
A las 18:37 UTC, la compañía dijo que había identificado y solucionado el problema que afectaba a su plataforma internacional. Indicó que un proveedor externo había sido comprometido y que las operaciones permanecían temporalmente detenidas como precaución.
La página de estado publicó otra actualización a las 18:55 UTC en la que señalaba que las operaciones se reanudarían aproximadamente a las 3 p.m. hora del Este. El incidente se marcó como resuelto a las 19:05 UTC, o 3:05 p.m. hora de verano del Este.
El mensaje de restablecimiento de la compañía reiteró su compromiso de reembolsar a los traders afectados. El aviso no anunció que todos los reembolsos ya se hubieran pagado cuando se reanudaron las operaciones.
El relayer de Polymarket forma parte de la infraestructura utilizada para enviar acciones firmadas de la cartera a la blockchain. La pausa de esas acciones acompañó a las restricciones sobre su libro de órdenes durante la investigación.
Su documentación de trading describe un sistema en el que los usuarios crean órdenes firmadas, un operador empareja compradores y vendedores, y los contratos liquidan las operaciones on-chain. El aviso del incidente de octubre identificó la Predictions Trading API, comúnmente llamada CLOB, entre los servicios afectados.
La compañía siguió publicando actualizaciones a través de su servicio de estado público a medida que avanzaba la respuesta. El acceso a la cuenta, los datos de mercado y la ejecución de órdenes se enumeran por separado allí.
La restricción anunciada el 29 de octubre concernía a la plataforma internacional. Polymarket no nombró a su exchange estadounidense separado como un venue afectado en el aviso del incidente.
El servicio se reanudó mientras continuaba la investigación sobre las transacciones no autorizadas. Las actualizaciones públicas no nombraron a un atacante ni describieron cómo fue comprometido inicialmente el proveedor.
Polymarket remitió el incidente a las autoridades del Reino Unido, según su declaración y reportes posteriores. DebugBear tiene su sede en el Reino Unido.
Los investigadores vincularon la brecha a un script de monitoreo
Los productos de DebugBear ayudan a los operadores de sitios web a medir la velocidad de carga y otros aspectos de la experiencia del visitante. Su servicio de monitoreo de usuarios reales utiliza JavaScript incrustado en el sitio web de un cliente.
El proveedor reconoció un incidente de seguridad en curso y aconsejó a los clientes que utilizan ese producto que eliminaran su código de inserción. Reuters identificó a DebugBear como el proveedor involucrado en el incidente de Polymarket, citando a una persona familiarizada con el asunto.
El propio aviso de estado de Polymarket se refirió a un proveedor externo sin nombrarlo. La compañía dijo que el problema había sido solucionado pero no publicó un informe técnico completo con ese anuncio.
La firma de seguridad Hudson Rock examinó un archivo JavaScript servido desde la infraestructura de DebugBear. En su investigación, los investigadores dijeron que el archivo buscaba en la aplicación en ejecución de Polymarket el cliente de trading y el firmante utilizados por una cuenta con sesión iniciada.
La firma dijo que el código inspeccionaba balances y posiciones antes de intentar mover valor a un destinatario configurado. Encontró diferentes rutas para transferir tokens de posición y vender posiciones antes de intentar transferir las ganancias.
Hudson Rock dijo que el código buscaba reutilizar el acceso disponible dentro de una sesión autenticada. Su revisión no identificó una rutina que enviara una frase semilla, contraseña o clave privada al endpoint de reporte del script.
Los investigadores encontraron una referencia a la eliminación de la integración de DebugBear en los metadatos de la compilación de producción de Polymarket. Dijeron que la entrada respaldaba la eliminación de la integración, aunque dejaba sin resolver el período exacto de exposición de los usuarios.
BleepingComputer examinó por separado una copia del script y describió los intentos de utilizar sesiones de trading existentes para realizar pedidos y transferir activos. Su revisión de la blockchain siguió aproximadamente 28,6 millones de POL desde el presunto receptor hasta tres carteras adicionales.
La publicación valoró ese movimiento en aproximadamente 2,57 millones de dólares en el momento de su examen. Hudson Rock citó una instantánea separada del saldo del receptor cercana a 2,19 millones de dólares, mientras que otros observadores informaron totales cercanos a 2,7 millones de dólares.
Polymarket no ha conciliado esas estimaciones en un estado de pérdidas de la empresa. Los informes utilizaron observaciones y momentos de valoración diferentes durante una investigación que aún estaba en desarrollo.
Ninguna de las actualizaciones públicas de la empresa identificó a la persona que controlaba la cartera receptora. El compromiso del proveedor, los informes de trading no autorizado y las transferencias posteriores siguen siendo objeto de la investigación remitida a las autoridades.
La promesa de reembolso incluye a los traders cuyas posiciones fueron vendidas
Polymarket dijo que los usuarios afectados serían resarcidos y reiteró que reembolsaría completamente a los traders después de que se restableciera el servicio. La declaración no fijó un plazo para presentar reclamaciones ni exigió a cada cliente retirar fondos dentro de un período determinado.
La empresa no ha publicado una política de reembolso detallada para el incidente de octubre. Aún no ha declarado si los pagos serán automáticos en todos los casos o si algunos usuarios deberán proporcionar información sobre la actividad disputada.
El informe de Car de que sus posiciones fueron vendidas plantea una cuestión que va más allá de un saldo de cartera faltante. Un trader puede mantener contratos sobre un evento que aún no ha ocurrido, venderlos antes de la resolución o conservarlos hasta que se determine el resultado.
La documentación de posiciones de Polymarket describe las tenencias de Sí y No por separado de la garantía utilizada para comprarlas. Un conjunto completo está respaldado por 1 pUSD, mientras que el pago final de un resultado individual depende del resultado registrado.
Las reglas de la plataforma permiten a los traders vender posiciones antes de la resolución. Cuando se produce una venta no autorizada, el historial de trading de la cuenta puede registrar tanto los contratos retirados como los ingresos recibidos antes de cualquier retiro posterior.
Polymarket no ha dicho si restaurará los contratos vendidos, compensará a los clientes utilizando un precio de mercado particular o aplicará otro método. Su promesa pública abarca a los traders afectados sin especificar cómo se manejará cada tipo de actividad de la cuenta.
La documentación de pedidos de la plataforma registra las etapas entre el envío de un pedido y la confirmación de una operación liquidada. Los pedidos pueden permanecer abiertos, emparejarse con otro trader, expirar o no liquidarse.
La empresa puede recurrir tanto a los registros de trading como a los de blockchain al revisar la actividad disputada. Los informes de los usuarios sobre ventas no deseadas se refieren al historial de pedidos, mientras que las transferencias fuera de la cartera dejan un registro de transacciones separado.
No apareció ningún calendario de pagos para toda la empresa en el aviso de restablecimiento. La declaración de la empresa no pidió a los clientes pagar un cargo por recuperación ni revelar credenciales de recuperación de la cartera para obtener un reembolso.
La brecha de junio llevó a una promesa anterior de reembolsos completos
La promesa de reembolso anterior de la empresa siguió a una estimación del analista de blockchain Specter de que al menos 11 carteras habían perdido aproximadamente 2,94 millones de dólares. El analista describió a usuarios que tenían PUSD cuyos activos fueron posteriormente convertidos en ETH.
Specter caracterizó el incidente como phishing a través de la interfaz afectada. La divulgación de la empresa identificó a un proveedor comprometido como la vía por la que el script llegó a algunos usuarios.
AMLBot elevó posteriormente las pérdidas estimadas de junio a 3,1 millones de dólares. Su relato del 27 de junio describió PUSD tomados en Polygon, convertidos a través de Relay, transferidos a Ethereum e intercambiados por ETH.
El compromiso de Polymarket en junio fue reembolsar completamente a los usuarios afectados. La declaración de octubre de la empresa hizo una nueva promesa de reembolso en relación con el último incidente.
La empresa no ha dicho que las dos brechas involucraran al mismo proveedor o atacante. La divulgación de junio y la investigación de octubre se refieren ambas a software externo utilizado por la plataforma, pero describen eventos separados con cuatro meses de diferencia.
El incidente anterior ocurrió mientras Polymarket ampliaba el uso de PUSD en toda su infraestructura de trading. Su declaración de junio se refería a los usuarios afectados por el script malicioso, sin anunciar una suspensión de todos los mercados ofrecidos bajo la marca Polymarket.
La respuesta de octubre incluyó nuevamente la eliminación o corrección de la integración comprometida y la restricción de la actividad mientras el equipo investigaba. Los detalles técnicos y los totales de víctimas publicados en cada caso han seguido cronogramas diferentes.
Los informes de junio no proporcionaron un relato transacción por transacción que mostrara la finalización de cada reembolso. El aviso más reciente de Polymarket tampoco publica una lista de los reembolsos de octubre completados.
Los investigadores examinaron el software que se ejecuta dentro de la página de trading
La investigación se ha centrado en el código cargado por un sitio web que los usuarios ya reconocían. El relato de Hudson Rock describió intentos de localizar el cliente de trading dentro de la aplicación en ejecución, en lugar de una instrucción para que los usuarios visitaran un exchange con una marca separada.
La documentación del navegador mantenida por Mozilla explica que el JavaScript incluido directamente en una página puede acceder a otros scripts y datos dentro de esa página. Un script de monitoreo cargado de esa manera se ejecuta con un acceso que difiere del contenido aislado dentro de un marco separado.
Los operadores de sitios web utilizan tales integraciones para análisis, informes de errores y medición del rendimiento. DebugBear describe su producto de monitoreo de usuarios reales como la recopilación de información sobre cómo los visitantes experimentan un sitio web.
La interfaz de trading de Polymarket realiza un conjunto diferente de tareas, incluida la visualización de posiciones, la preparación de órdenes y la interacción con un firmante. Los investigadores dijeron que el archivo recuperado contenía lógica dirigida a esas funciones de trading.
La documentación de billeteras de Polymarket describe varios tipos de cuentas, incluidas las Deposit Wallets y las billeteras heredadas Proxy y Safe. Su documentación asigna las Deposit Wallets a las cuentas implementadas el 4 de mayo de 2026 o después.
La plataforma permite a un propietario de billetera autorizar a un firmante separado para una actividad de trading específica. Su documentación beta sobre claves de sesión indica que dicha clave puede operar para una Deposit Wallet pero no puede retirar sus fondos.
La empresa no ha identificado las claves de sesión como la causa de la brecha de octubre. El relato de los investigadores describe intentos de utilizar el cliente y el firmante ya disponibles en la aplicación.
La guía de órdenes de Polymarket indica que los usuarios firman mensajes estructurados que contienen el identificador de resultado de la operación, el lado, el precio, el tamaño y otros términos. El operador valida las firmas, los saldos y las autorizaciones antes de emparejar una orden.
Las operaciones emparejadas pasan luego a los contratos de liquidación, y la plataforma registra si la ejecución se confirmó o falló. El aviso de estado de octubre no informó de una falla del consenso de Polygon ni anunció que todos los contratos de liquidación hubieran sido comprometidos.
La respuesta pública de la empresa ha identificado hasta ahora el compromiso del proveedor y ha prometido una compensación sin publicar un relato completo de cada ruta de firma y transferencia.
Las protecciones del navegador dependen de en qué código confía el sitio web
Un sitio web puede cargar el software de un proveedor sin enviar al visitante a otra dirección. El navegador obtiene el archivo como parte de la apertura de la página, junto con el código de la propia aplicación del exchange.
La documentación del navegador de Mozilla explica que un script incrustado directamente en una página puede operar con el acceso de la página. El rol comercial del proveedor como monitor de rendimiento no impone por sí mismo una restricción del navegador que confine su código a medir los tiempos de carga.
El contenido colocado en un marco aislado por separado tiene límites diferentes. Un script incluido en la aplicación de trading no adquiere ese aislamiento simplemente porque otra empresa lo suministre.
La investigación de octubre sitúa esa distinción dentro de una aplicación financiera. La página de Polymarket muestra saldos y posiciones mientras se conecta a servicios que preparan órdenes y solicitan firmas.
La empresa no ha publicado un inventario completo del código externo autorizado a ejecutarse en ese entorno. Su declaración sobre el incidente identifica un compromiso del proveedor sin describir la revisión de permisos que precedió a la integración.
Los navegadores proporcionan controles destinados a limitar esta exposición. La documentación sobre Integridad de Subrecursos de Mozilla describe un método para verificar un script descargado contra una huella criptográfica especificada por el sitio web.
Si el archivo descargado difiere de la huella esperada, el navegador se niega a ejecutarlo. Por lo tanto, un proveedor que cambie el archivo requeriría que el sitio web apruebe la nueva versión antes de que pudiera ejecutarse bajo esa verificación.
La protección depende de que el sitio web la implemente para el recurso en cuestión. El aviso de Polymarket no indica si la integración afectada utilizó dicha verificación ni publica hallazgos sobre por qué se aceptó el código recuperado.
La guía sobre Política de Seguridad de Contenidos de Mozilla describe otro conjunto de controles sobre scripts ejecutables. Una política puede restringir fuentes o autorizar código particular mediante nonces y hashes.
El permiso para el host de un proveedor no verifica por sí mismo cada archivo que ese host sirve. Un host puede permanecer igual mientras el contenido entregado desde él cambia.
Esos controles operan antes de que el código se ejecute en el navegador o en el momento en que lo hace. Cumplen un propósito diferente al de la vigilancia de intercambios que examina las órdenes después de que un cliente de trading las ha enviado.
La autoridad de trading y la autoridad de retiro tienen límites diferentes
La propia documentación de Polymarket describe los esfuerzos por limitar lo que un firmante delegado puede hacer. Su sistema de claves de sesión en versión beta permite al propietario de una billetera autorizar una clave separada para operar dentro de límites especificados.
La documentación indica que una clave de sesión no puede retirar fondos. Sus permisos pueden abarcar el libro de órdenes central, las operaciones combinadas o los venues de trading compatibles, y el propietario concede la autorización por un período definido.
Un permiso de trading sigue permitiendo actividad que modifica una cartera. La distinción importa para los clientes que reportan posiciones vendidas sin su consentimiento, incluso antes de que cualquier producto salga de la billetera.
Polymarket no ha identificado el sistema de claves de sesión beta como el punto de entrada en octubre. Los investigadores describieron intentos de localizar el cliente activo y el firmante disponibles para la aplicación, mientras que la empresa aún no ha explicado qué permisos se utilizaron con éxito en cada cuenta afectada.
La guía del ciclo de vida de las órdenes de la plataforma describe órdenes firmadas fuera de la cadena antes de que un operador las valide y las empareje. Las verificaciones cubren la firma, los saldos de las cuentas y las asignaciones, entre otras condiciones.
La liquidación se produce entonces mediante contratos de blockchain. Los registros distinguen una orden emparejada de una cuya liquidación ha sido confirmada o ha fallado.
Una firma válida es parte de ese proceso, pero no establece que la persona que ve la pantalla quisiera la transacción. El ataque reportado buscaba utilizar la autorización disponible a través de la aplicación que prepara esas solicitudes.
Los hallazgos públicos no establecen que todos los tipos de billetera permitieran la firma silenciosa ni que todas las acciones intentadas tuvieran éxito. Polymarket admite varias configuraciones de billetera, y la investigación de la empresa aún no ha mapeado las cuentas afectadas a esas configuraciones.
El incidente de junio de la empresa ya había expuesto una dependencia similar del código de sitios web externos. Su brecha anterior en el frontend involucró un script malicioso entregado a algunos visitantes a través de una dependencia comprometida.
La respuesta de octubre volvió a requerir acción a nivel de la plataforma: una restricción de trading, acciones de relayer pausadas y una corrección para la integración afectada. Los dispositivos de trading separados de los clientes no les dieron control sobre el software que el sitio web eligió cargar.
Los reembolsos deben abordar las operaciones así como el efectivo faltante
Polymarket ha prometido resarcir a los usuarios afectados, pero su aviso de estado no explica cómo valorará las posiciones cerradas sin la aprobación de sus propietarios. Restaurar un saldo en efectivo y restaurar una posición abierta en un evento pueden producir tenencias de cuenta diferentes.
Un operador cuyos contratos fueron vendidos puede haber tenido la intención de mantenerlos hasta que se resolviera un resultado electoral u otro evento. Los registros de venta muestran qué obtuvieron los contratos en ese momento, mientras que su valor de mercado posterior puede cambiar antes del reembolso.
La empresa no ha dicho si reemplazará contratos, usará el precio inmediatamente anterior a la venta disputada o aplicará otro método de valoración. No ha anunciado que los usuarios deban esperar a que se resuelvan los eventos subyacentes.
Los registros de operaciones y el historial de billetera de Polymarket proporcionan partes separadas de esa cuenta. El historial de órdenes registra cambios en las posiciones, mientras que los registros de blockchain pueden mostrar transferencias posteriores de colateral o tokens.
El saldo de una billetera receptora no puede por sí solo identificar la pérdida de cada cliente. Las reclamaciones individuales pueden involucrar una serie de operaciones, transferencias y movimientos posteriores a través de otras direcciones.
La investigación anterior de junio siguió activos desde Polygon a través de un puente y hacia ETH en Ethereum. Su estimación de pérdida revisada aumentó después del anuncio inicial de reembolso a medida que los analistas rastrearon más actividad.
Polymarket no ha publicado una fecha límite de reclamaciones de octubre ni un calendario de pagos. Su servicio de soporte internacional permanece separado del exchange estadounidense, que el aviso del incidente no identificó como afectado.
La plataforma restableció las operaciones a las 19:05 UTC del 29 de octubre. Su aviso público registra el incidente de servicio como resuelto mientras mantiene el compromiso de compensar a los clientes afectados.
Qué observar
Hallazgos técnicos: Qué permisos de cuenta utilizó con éxito el script y qué tipos de billetera se vieron afectados.
Controles de proveedores: Los hallazgos de la empresa sobre cómo el software externo llegó a la aplicación de trading.
Contabilidad de pérdidas: Un total de la empresa que concilie las cuentas afectadas y las transacciones no autorizadas.
Condiciones de reembolso: Cómo valora Polymarket las posiciones vendidas y cuándo reciben los clientes la compensación.
Preguntas frecuentes
¿Qué le sucedió a Polymarket el 29 de octubre?
Polymarket dijo que un proveedor externo fue comprometido y restringió temporalmente su plataforma internacional. El comercio volvió tras un incidente de servicio de 1 hora.
¿Cuánto perdieron los comerciantes?
Un observador estimó 2,68 millones de dólares, y otros informes de rastreo produjeron cifras cercanas a 2,7 millones de dólares. Polymarket no ha anunciado un total final de pérdidas ni confirmado el número de cuentas afectadas.
¿Ha prometido Polymarket reembolsar a los usuarios?
Sí. La empresa dijo que los comerciantes afectados por el incidente del 29 de octubre serían compensados en su totalidad y reiteró su compromiso de reembolso cuando se reanudó el comercio.
¿Qué informaron los comerciantes afectados?
Un comerciante que usa el nombre Car dijo que se habían tomado aproximadamente 800.000 dólares y que todas sus posiciones fueron vendidas. Dijo que un amigo había perdido otros 600.000 dólares, aunque Polymarket no ha confirmado esas afirmaciones individuales.
¿Qué proveedor estuvo vinculado a la brecha?
Informes e investigadores de seguridad vincularon el incidente al script de monitoreo de DebugBear. La declaración de estado de Polymarket del 29 de octubre confirmó un proveedor comprometido sin nombrarlo.
¿Fue esta la misma brecha que la de junio?
No. La divulgación del 25 de junio concernía a un incidente de un proveedor separado, con pérdidas estimadas posteriormente en 3,1 millones de dólares. La empresa no ha anunciado un atacante o proveedor común entre los dos casos.
¿Dijo el aviso que Polymarket US se vio afectado?
No. El aviso del incidente del 29 de octubre nombra la plataforma internacional, mientras que el exchange estadounidense opera por separado.
¿Qué sucede con las posiciones vendidas sin la aprobación del propietario?
Polymarket no ha publicado un método de compensación para las posiciones vendidas en su declaración del 29 de octubre. Su promesa es compensar en su totalidad a los comerciantes afectados. Este es un análisis educativo, no asesoramiento de inversión.
