Polymarket reanudó las operaciones el 29 de octubre tras una interrupción causada por un proveedor de terceros comprometido en el mercado de predicciones internacional. El incidente marcó el segundo ataque de seguridad multimillonario de Polymarket en cuatro meses. El registro oficial de incidentes de Polymarket sitúa el inicio de las restricciones de operación a las 18:05 UTC y la resolución a las 19:05 UTC. Polymarket indicó que el problema había sido solucionado y que se había notificado a las autoridades. Polymarket también prometió una compensación completa para los usuarios afectados.
Bubblemaps, una empresa de análisis de cadena de bloques, estimó que el ataque del 29 de octubre afectó a más de 700 usuarios de Polymarket y comprometió aproximadamente $3,46 millones en activos. Los atacantes intercambiaron aproximadamente $2,7 millones por POL y retiraron los fondos. Otros $750,000 permanecieron en Polymarket cuando se realizó la evaluación.
Polymarket reveló el 25 de junio que un proveedor comprometido había habilitado la inyección de un script malicioso. Polymarket indicó que la dependencia afectada había sido eliminada y prometió reembolsos completos. Source Defense reportó pérdidas de aproximadamente $3 millones por el ataque de junio. Source Defense rastreó la entrega hasta una etiqueta de marketing que obtenía una biblioteca de identidad externa, la cual el atacante sustituyó por un drainer adaptado a Polymarket. Los investigadores de Source Defense dijeron que la carga útil de junio tenía como objetivo monederos con más de $100,000 y buscó repetidamente autorización digital. Una autorización aprobada pasaba por el relayer de Polymarket, que envía acciones firmadas.
El análisis de octubre de Hudson Rock describió código obtenido de una URL asociada con DebugBear que buscaba el cliente de operaciones activo y el firmante dentro de una sesión iniciada. El firmante es el componente que solicita autorización criptográfica. Hudson Rock descubrió que el comportamiento programado del script variaba según el tipo de cuenta. Una rama solicitaba transferencias de tokens de posición; otra solicitaba ventas seguidas de transferencias de los ingresos. Hudson Rock también identificó metadatos de compilación de producción que documentaban la eliminación del script de monitoreo de DebugBear. Sin embargo, el análisis estático de Hudson Rock no demostró que el código se ejecutara, obtuviera firmas en silencio o robara claves privadas. El análisis tampoco estableció una traza completa desde las víctimas hasta los receptores. Los metadatos de eliminación no determinan con precisión cuándo terminó la exposición de los usuarios.
La dependencia de marketing de junio y el script asociado al monitoreo de octubre proporcionaron rutas diferentes hacia una interfaz financieramente sensible. El mecanismo de junio dependía, según se informó, de autorizaciones aprobadas, mientras que el código de octubre buscaba herramientas de negociación y solicitaba firmas. Reemplazar únicamente a un proveedor comprometido no resuelve el problema más amplio de que código malicioso acceda a funciones financieras dentro del sitio web. Las brechas repetidas plantean preguntas sobre la autoridad financiera que el código externo puede acceder a través del navegador de un operador.
La documentación del navegador de MDN indica que un script de terceros cargado directamente en una página puede acceder a otros scripts y datos de esa página. MDN explica que alojar el script en otro lugar no elimina ese acceso, mientras que el contenido de origen cruzado en un marco separado tiene un límite de seguridad diferente. Reducir el código externo, limitar las solicitudes de firma y verificar los archivos descargados abordan distintas etapas de la cadena de ataque. Eliminar integraciones innecesarias de las páginas de operaciones y firma reduce el código externo permitido en esos entornos. Revisar el acceso del firmante e identificar las acciones que requieren confirmación fresca del usuario restringe las solicitudes que el código puede realizar tras obtener acceso.
La Integridad de Subrecursos permite a los navegadores verificar los scripts descargados contra una huella criptográfica esperada y rechazar archivos alterados. La Integridad de Subrecursos también puede proteger un recurso adecuadamente anclado alojado en un dominio de confianza. Un informe detallado de postmortem que cubra el período de exposición, las cuentas afectadas y las rutas de autorización ayudaría a evaluar el riesgo restante. Queda sin resolver si otra integración comprometida podría convertir el acceso a la interfaz de operación en una autorización financiera utilizable.
Polymarket sufre su segunda brecha de seguridad de varios millones de dólares en cuatro meses
CryptoSlateCompartir
Resumen
Polymarket sufrió una segunda brecha de seguridad importante el 29 de octubre de 2026, tras la compromisión de un proveedor de terceros. El ataque afectó a más de 700 usuarios y $3.46 millones en activos, con $2.7 millones retirados. El volumen de trading descendió bruscamente durante el incidente. Polymarket se comprometió a compensar completamente a los afectados y alertó a las autoridades. Bubblemaps informó sobre la brecha, mientras que Hudson Rock rastreó el script malicioso hasta DebugBear. Esto sigue a un incidente similar en junio de 2026, también vinculado a un proveedor. El índice de miedo y codicia para los mercados de criptomonedas ha caído desde entonces a un nivel bajista.
Fuente:Mostrar original
Descargo de responsabilidad: La información contenida en esta página puede proceder de terceros y no refleja necesariamente los puntos de vista u opiniones de KuCoin. Este contenido se proporciona solo con fines informativos generales, sin ninguna representación o garantía de ningún tipo, y tampoco debe interpretarse como asesoramiento financiero o de inversión. KuCoin no es responsable de ningún error u omisión, ni de ningún resultado derivado del uso de esta información.
Las inversiones en activos digitales pueden ser arriesgadas. Evalúa con cuidado los riesgos de un producto y tu tolerancia al riesgo en función de tus propias circunstancias financieras. Para más información, consulta nuestras Condiciones de uso y la Declaración de riesgos.