El Equipo Rojo de Bitcoin ha ampliado su revisión de seguridad asistida por IA a 501 proyectos de código abierto relacionados con Bitcoin, registrando 7.958 hallazgos en su último recuento detallado después de 108 horas de trabajo.
Calle, un desarrollador seudónimo de Bitcoin involucrado en el esfuerzo, dijo el 13 de agosto que el equipo ha completado un escaneo básico de casi todo el ecosistema de código abierto de Bitcoin y que gran parte de la superficie de vulnerabilidad más fácil de encontrar ya ha sido examinada.
Las cifras principales requieren una distinción importante. Los 7.958 hallazgos no representan 7.958 vulnerabilidades confirmadas y explotables. El equipo clasificó 1.280 como de alto o crítico, mientras que el 24,7% de todos los hallazgos habían sido reproducidos dinámicamente y el 29,4% habían sido reportados a los mantenedores del proyecto a las 108 horas. La revisión por parte del mantenedor y la reproducción humana siguen siendo parte del proceso de verificación.
Calle dijo que dos semanas de trabajo con Kimi K3 de Moonshot AI expusieron la rapidez con la que los modelos modernos pueden examinar años de código abierto acumulado. Describió la situación como una “colisión masiva” entre software antiguo e IA de vanguardia, añadiendo que “todo está roto, Bitcoin se está quemando”. La redacción es su caracterización y no debe interpretarse como prueba de que Bitcoin Core o cada proyecto de Bitcoin esté comprometido.
Las pruebas independientes respaldan el punto más específico de que Kimi K3 tiene una capacidad significativa en ciberseguridad. Una evaluación conjunta del Instituto de Seguridad de IA del Reino Unido y el CAISI de EE. UU. encontró que el modelo superó a GLM-5.2 en las pruebas de desarrollo de exploits, pero se mantuvo por detrás de los modelos cerrados más potentes de EE. UU. Kimi K3 obtuvo un 32% en ExploitBench y logró la ejecución arbitraria de código en cero de 41 muestras en esa prueba.
Un barrido anterior del Equipo Rojo de Bitcoin encontró 4.962 problemas potenciales en 390 proyectos de Bitcoin, incluyendo 720 clasificados entonces como de alto o crítico. El recuento más reciente muestra que la revisión se amplió sustancialmente después de esa primera ola.
La campaña ha ido más allá del escaneo automatizado. El lanzamiento oficial de GitHub de BTCPay Server acreditó a los investigadores del Equipo Rojo de Bitcoin Bruno García y Ben Carman por reportar una vulnerabilidad crítica que ya estaba siendo explotada. La versión 2.4.2 corrigió un bypass de autenticación de dos factores que afectaba a Greenfield Basic Authentication.
BTCPay confirmó más tarde que los atacantes habían obtenido credenciales de macaroons de administrador de LND de instalaciones afectadas y las habían utilizado para acceder a monederos Lightning conectados. El proyecto dijo que estaba procesando informes adicionales del Equipo Rojo de Bitcoin, Project Loupe, Magic Grants e investigadores independientes, mientras fortalecía sus procesos de escaneo y revisión.
El 14 de agosto, BTCPay anunció otra versión candidata centrada en la seguridad, v2.4.3-rc4, abordando las vulnerabilidades reportadas por esos grupos. En una cobertura relacionada, los partidarios de BTCPay apoyaron una recompensa por recuperación después del exploit anterior y la fundación prometió 0.21 BTC al fondo del Equipo Rojo de Bitcoin.
Esas correcciones proporcionan evidencia concreta de que los mantenedores están validando al menos algunos informes serios del Equipo Rojo. No validan cada elemento del conjunto de datos de 7.958 hallazgos. Las auditorías asistidas por IA pueden producir falsos positivos, informes duplicados y evaluaciones de gravedad que cambian después de una investigación manual, lo que hace que la verificación sea fundamental para interpretar las cifras.
Calle argumentó que los proyectos sin mantenimiento ahora deberían tratarse con mayor precaución porque la IA ha reducido drásticamente el costo de encontrar y probar debilidades. También dijo que el tiempo de respuesta se está convirtiendo en un indicador útil de la salud del proyecto y que los mantenedores necesitarán cada vez más sus propias líneas continuas de auditoría de IA en lugar de revisiones externas ocasionales. Estas son las conclusiones de Calle de la campaña y no reglas de seguridad universales.
El ecosistema más amplio ya se está moviendo en esa dirección. OpenSats ha creado una vía rápida de subvenciones para equipos rojos, centrada en parte en reembolsar a los investigadores los costos de LLM. Más de 40 organizaciones de Bitcoin y activos digitales también han pedido a los principales laboratorios de IA que den a defensores de código abierto verificados acceso controlado a modelos de vanguardia.
Como informó crypto.news, la coalición de la industria advirtió que los desarrolladores de Bitcoin podrían quedarse atrás de los atacantes sin acceso a modelos avanzados de IA. La solicitud no busca acceso sin restricciones. Propone investigadores verificados, entornos seguros, capacidad de cómputo suficiente y canales de comunicación directos con los equipos de seguridad de IA.
Es probable que la siguiente fase avance más lentamente que el barrido inicial. El descubrimiento automatizado puede escalar rápidamente, mientras que la reproducción, la divulgación responsable, el desarrollo de parches y las pruebas de regresión requieren más tiempo. Los proyectos que reciben informes deben determinar qué hallazgos son explotables, con qué urgencia necesitan los usuarios las actualizaciones y cuándo los detalles técnicos pueden hacerse públicos de forma segura.
Para los usuarios de Bitcoin, la conclusión es más limitada de lo que sugieren las cifras más grandes. El Equipo Rojo ha reportado un gran volumen de debilidades potenciales en el software relacionado con Bitcoin, no evidencia de que el protocolo de consenso base de Bitcoin haya fallado. La preocupación inmediata de seguridad se centra en monederos, infraestructura Lightning, software de pago y bibliotecas que contienen código más antiguo o poco revisado.
