En la segunda semana de agosto de 2026, un desarrollador de Bitcoin pseudónimo conocido como Calle publicó una frase que rebotó por toda la industria: «Everything is broken, Bitcoin is burning» — todo está roto, Bitcoin arde. Detrás de la hipérbole había un conjunto de datos. El Bitcoin Red Team, un equipo voluntario, acababa de hacer pasar Kimi K3 de Moonshot AI — un modelo de frontera chino de pesos abiertos publicado apenas dos semanas antes — por prácticamente todo el ecosistema open source de Bitcoin: monederos, aplicaciones Lightning, bibliotecas de pago y las herramientas que los rodean. Tras unas 108 horas — tiempo de campaña transcurrido, trabajado por un equipo que había crecido hasta veinticinco personas — sobre 501 proyectos, el equipo había registrado 7 958 hallazgos de seguridad potenciales, 1 280 de ellos clasificados altos o críticos.
Esa sola campaña condensa todo lo que trata este artículo: lo que los modelos de IA pueden hacerle ya a una base de código, quién los apunta hacia Bitcoin, qué encuentran — y por qué un reglamento europeo que empieza a morder el 11 de septiembre de 2026 convierte todo esto de una historia de ingeniería en una historia jurídica.
Los atacantes llegaron primero
Antes de que los defensores se industrializaran, lo hicieron los atacantes. La cadena de suministro open source de la que dependen Bitcoin y la industria más amplia de los activos digitales lleva años bajo un asalto sostenido y motivado financieramente — y el ecosistema cripto ha sido consistentemente la víctima buscada.
En septiembre de 2025, unos atacantes suplantaron al mantenedor de chalk, debug y otras
dieciséis utilidades de npm — paquetes que suman miles de millones de descargas semanales — y
distribuyeron un «crypto-clipper» que enganchaba las API del navegador y sustituía en silencio
las direcciones de destino en el momento exacto en que el usuario de un monedero aprobaba una
transacción — eligiendo incluso las direcciones del atacante por similitud visual para eludir la
detección. Semanas después, el gusano Shai-Hulud añadió la autopropagación, convirtiendo
compromisos aislados de mantenedores en reacciones en cadena. En marzo de 2026, la biblioteca
Axios — del orden de cien millones de descargas semanales — fue puerta-traseada durante poco
menos de tres horas a través de una cuenta de mantenedor secuestrada, en paralelo a la campaña
TeamPCP, que comprometió cuatro proyectos open source muy usados en una sola semana. Y en julio
de 2026, unos atacantes colaron una puerta trasera disfrazada de «telemetría» en el SDK de la
blockchain Injective, cableando la exfiltración de frases semilla y claves privadas directamente
en las funciones de derivación de claves de los monederos; la publicación automatizada la
propagó a dieciocho paquetes en minutos.
La dirección del movimiento es medible. El informe State of the Software Supply Chain 2026 de Sonatype contó más de 454 600 nuevos paquetes open source maliciosos solo en 2025 — un salto del 75 % interanual, que empuja su total acumulado de bloqueos por encima de 1,2 millones. Y las herramientas del lado ofensivo también evolucionan: el Threat Intelligence Group de Google informó en 2026 de que, por primera vez, había identificado a un actor de amenazas empuñando un exploit de día cero que cree desarrollado con IA, destinado a un evento de explotación masiva.
Los repositorios open source son objetivo precisamente porque son la capa de confianza. Nadie necesita vulnerar su infraestructura si puede envenenar una dependencia que usted instala voluntariamente. Y en ningún sitio esa palanca es mayor que en software que toca claves y dinero.
La debacle de ColdCard
A finales de julio, el riesgo abstracto se volvió uno que cambia vidas. A partir del 30 de julio de 2026, un atacante empezó a vaciar lo que se suponía el escondite más seguro de Bitcoin: el almacenamiento en frío. En oleadas sucesivas — la mayor barrió 1 082 BTC de 1 196 monederos en solo 41 minutos, según el recuento de Galaxy Research —, la pérdida alcanzó 1 367 BTC — unos 88,6 millones de dólares — en 4 585 direcciones generadas en monederos físicos ColdCard de Coinkite, a fecha del punto de control de Galaxy del 1 de agosto. Recuentos posteriores superaron los 1 800 BTC y se acercaron a los 130 millones de dólares una vez incorporada una cuarta oleada sospechada. (Corrección: una versión anterior de esta nota daba 116 millones de dólares — tomado de la cobertura circulante y, después, imposible de rastrear hasta una fuente que lo enuncie, lo date y lo defina. Los totales mayores incorporan una oleada aún descrita como no confirmada semanas después, y la propia salvedad de Galaxy merece llevarse junto a la cifra: emparejaron direcciones por patrón y no usaron cómputo para probar que esas semillas eran débiles.) Según el mecanismo publicado, nada de esto requirió phishing, un dispositivo robado ni acceso físico de ningún tipo — las claves se reconstruyeron fuera de línea. Esas exclusiones se derivan de cómo funcionaba el fallo; los avisos del fabricante no afirman haber investigado y descartado cada una. Miles de holders de largo plazo que habían hecho todo lo que prescribe la ortodoxia de la autocustodia — monedero físico, claves fuera de línea, aislamiento intacto — vieron los ahorros de una vida salir de direcciones que solo ellos debían controlar. La causa raíz era de una banalidad devastadora: un flag de compilación del firmware, distribuido en marzo de 2021, hacía que los dispositivos afectados se saltaran su chip físico dedicado de aleatoriedad y cayeran a un PRNG de software débil, colapsando la entropía efectiva — hasta unos 40 bits en los Mk3 antiguos —, lo bastante como para que las frases semilla pudieran reconstruirse fuera de línea. Las matemáticas de Bitcoin aguantaron; el software que las envolvía, no. Coinkite distribuyó firmware de emergencia, destruyó el inventario vulnerable y suplicó a los usuarios que migraran — admitiendo a la vez que ningún parche puede reparar una semilla ya generada en firmware vulnerable.
Luego vino la guerra de relatos. El CEO de Coinkite, Rodolfo Novak, enmarcó el exploit como «a sober reality of the new AI paradigm» — una realidad sobria del nuevo paradigma de la IA: la revisión de código asistida por IA sacaría ahora a la superficie fallos latentes más rápido que incluso los expertos humanos más curtidos, y todo firmware que sea o haya sido público debería presumirse bajo escrutinio de máquinas, por atacantes y defensores por igual. Esa afirmación está discutida, y la honestidad exige decirlo. No se ha identificado a ningún atacante. No ha aflorado prueba alguna de que un modelo encontrara el fallo — la propia formulación de Coinkite es que «hay que asumir» («we have to assume») que alguien aplicó IA al firmware publicado, y en el mismo documento la empresa revela que su propia revisión con IA, ejecutada semanas antes, «no encontró este fallo ni nada serio» («did not find this bug or anything serious»). Una versión anterior de esta nota escribía además que especialistas en seguridad habían replicado con dureza — que un flag de compilación que desactiva un RNG físico es un fallo de ingeniería humana que la revisión convencional debió atrapar años antes. No pudimos sostenerlo al reverificar: la única publicación que habíamos rastreado está en una cuenta suspendida, y el comentarista con nombre más cercano que encontramos daba la razón a Coinkite en lugar de objetar. El argumento nos sigue pareciendo correcto — pero ahora es nuestro, no uno atribuido. En un sentido, sin embargo, la disputa es secundaria. Encontrara una IA este fallo o no, el ecosistema sabe ahora que los modelos pueden demostrablemente encontrar fallos exactamente de esta clase exactamente a esta velocidad — y respondió como si la amenaza fuera real. En días, la plataforma Boltz pausó sus operaciones para adelantarse a intentos de ataque impulsados por IA. Y una contrafuerza voluntaria se congregó.
El ascenso del red team en Bitcoin
El Bitcoin Red Team se formó en cuestión de días tras el drenaje de ColdCard: una contrafuerza de emergencia, voluntaria, de dieciséis investigadores liderados por Calle junto al CEO de AnchorWatch, Rob Hamilton, respaldada por unos 40 000 dólares de cómputo de IA y apoyada por OpenSats, cuyo nuevo programa de subvenciones Code RED recompensa ya la divulgación responsable de vulnerabilidades en el ecosistema. El método empareja análisis impulsado por IA con verificación humana — los modelos barren monederos, implementaciones de Lightning y bibliotecas; los investigadores reproducen y valoran; los hallazgos creíbles van en privado a los mantenedores antes de publicar nada.
La trayectoria de sus números cuenta lo que la IA le hace a la economía del descubrimiento de vulnerabilidades. El primer sprint presentó 4 962 hallazgos en 390 proyectos en 27,5 horas — 85 críticos y 635 altos, con una media, según la aritmética de Calle en el lanzamiento, del orden de un exploit crítico por investigador y hora. Días después, el barrido ampliado estaba en 7 958 hallazgos sobre 501 proyectos. El resumen de Calle: el escaneo básico de prácticamente todo el ecosistema open source de Bitcoin está completo, y la fruta madura está recogida.
Los hallazgos llegan con una textura que importa más que los totales. Las vulnerabilidades se concentraban en bases de código antiguas y poco revisadas. El software ligado a Lightning — estructuralmente complejo, sensible al rendimiento, difícil de auditar — cargaba con una exposición desproporcionada. La prevalencia de implementaciones en C se señaló como riesgo estructural persistente. Y la velocidad con que un proyecto respondía a una divulgación privada resultó ser un diagnóstico en sí misma: la velocidad de respuesta, señaló el equipo, es un proxy visible de la salud de un proyecto. Los proyectos sin mantenimiento, advirtieron, no deberían merecer confianza.
La campaña ya ha producido impacto real y verificado. BTCPay Server — uno de los procesadores de pago Bitcoin autoalojados más desplegados — publicó la versión 2.4.2 el 7 de agosto parcheando una elusión crítica de la autenticación de dos factores acreditada en parte a investigadores del Bitcoin Red Team — y confirmó después que el fallo ya había sido explotado en el mundo real para extraer credenciales de monederos Lightning. Esa es toda la tesis en un incidente: la vulnerabilidad era real, se estaba usando, y la revisión asistida por máquinas llegó a ella antes de lo que la mayoría de los humanos lo habría hecho.
Merece la pena decir directamente lo que costó. Dieciséis voluntarios, unos 40 000 dólares de cómputo, unas semanas — y una disciplina que la mayoría de los programas de seguridad financiados nunca logra: divulgación privada primero, publicación solo cuando los mantenedores ya tenían los hallazgos, y su propia tasa de reproducción declarada en público en lugar de enterrada. Cartografiaron un ecosistema que llevaba una década sin cartografiar y regalaron los resultados. Siga lo que siga en este artículo, ese es el estándar de referencia de cómo debe conducirse este trabajo, y el ecosistema Bitcoin es más seguro este mes que el pasado — gracias a ellos.
Una restricción de ese trabajo merece enunciarse con claridad, porque se malinterpreta rutinariamente como una elección metodológica. El equipo informó de que las restricciones de uso de los modelos estadounidenses para investigación de seguridad los bloquearon repetidamente — empujándolos hacia modelos de pesos abiertos como Kimi K3 y GLM 5.2 de Z.ai, ejecutables en local sin porteros de políticas de uso. Kimi K3 no fue un mal menor; para este trabajo, en ese momento, estaba entre los mejores instrumentos que realmente tenían permitido usar.
Eso es un fracaso de políticas, no un fracaso de investigación. La elección de herramientas en la investigación de seguridad la determina hoy menos la calidad del modelo que quién permite el trabajo en absoluto — y un equipo que echa mano del modelo que efectivamente ejecutará la tarea se comporta correctamente. Debería hacer reflexionar a los laboratorios occidentales: la investigación defensiva ocurre de todos modos. La única pregunta es en los modelos de quién — y si quienes la hacen quedan forzados a una caja de herramientas más estrecha que la de los atacantes.
Qué significan realmente 7 958 hallazgos
Aquí se debe honestidad — y el equipo fue el primero en deberla. De los 7 958 hallazgos, el 24,7 % tenía una prueba de concepto reproducible — la expresión es del propio equipo — y el 29,4 % se había reportado upstream en el último recuento, cifras que el equipo publicó por sí mismo en lugar de redondearlas. (Una versión anterior de esta nota escribía «reproducidos dinámicamente»; era glosa nuestra, no suya, y la tasa de reporte son hallazgos enviados a los mantenedores, no hallazgos aceptados por ellos.) Una evaluación conjunta del AI Security Institute británico y el CAISI estadounidense consideró a Kimi K3 capaz pero lejos de infalible — un 32 % en bancos de pruebas de desarrollo de exploits, por delante de GLM-5.2 pero muy por detrás de los modelos cerrados más fuertes, y sin lograr ejecución de código arbitrario en ninguna de las 41 muestras probadas.
Así que esto no es una lista de 7 958 agujeros aprovechables en Bitcoin, y nadie implicado ha afirmado que lo sea. El propio encuadre de Calle fue directo: los candidatos son baratos, y si no puede manejar la sobrecarga de información resultante, use IA para clasificarla. Esa es la lectura correcta, y apunta al desplazamiento real. La IA ha hecho la generación de candidatos casi gratuita. Lo que no ha hecho gratuito es el juicio que separa una vulnerabilidad confirmada, reproducible y correctamente puntuada de una alucinación de apariencia plausible — el mismo problema de «AI slop» en el que los mantenedores de open source, desde curl en adelante, llevan tiempo ahogándose.
El recurso escaso en seguridad se ha desplazado silenciosamente de la detección a la valoración. Es una propiedad de la tecnología, no una carencia de campaña alguna — y un barrido que cartografía un ecosistema entero y una evaluación firmada de una sola base de código son, sencillamente, oficios distintos. El primero le dice dónde mirar. La segunda es lo que un regulador, un comprador o una aseguradora aceptará de verdad. Todo actor serio en este espacio — atacante, defensor, mantenedor, regulador — está ahora aguas abajo de ese cuello de botella.
Bruselas pone el reloj
En esta colisión entra el Cyber Resilience Act de la UE, y su calendario difícilmente podría ser más afilado.
Desde el 11 de septiembre de 2026, el artículo 14 del CRA obliga a los fabricantes de productos con elementos digitales vendidos en la UE a notificar toda vulnerabilidad activamente explotada de la que tengan conocimiento — en 24 horas la alerta temprana, 72 horas la notificación completa y 14 días el informe final — simultáneamente a ENISA y a su CSIRT nacional designado, a través de la plataforma única de notificación. Punto crítico: se aplica a productos que ya están en el mercado, no solo a versiones nuevas. El Reglamento se aplica después íntegramente desde el 11 de diciembre de 2027, trayendo requisitos vinculantes de seguridad desde el diseño, el deber del anexo I de llevar a cabo exámenes y pruebas de seguridad eficaces y periódicos, documentación técnica que contenga los informes de esas pruebas, y obligaciones de conservación que se extienden una década. Las multas del artículo 64 alcanzan los 15 millones de euros o el 2,5 % del volumen de negocios anual mundial total, la cantidad que sea mayor.
Junte ahora las dos mitades de este artículo. Campañas asistidas por IA están sacando a la superficie miles de vulnerabilidades candidatas en ecosistemas open source en cuestión de semanas — y algunas, como el fallo de BTCPay, están siendo activamente explotadas, que es precisamente el disparador de notificación del CRA. Un fabricante cuyo producto incorpora una dependencia comprometida — o un fallo que un barrido de IA hace aflorar y un atacante alcanza primero — ya no afronta una discreta corrección de ingeniería. Afronta un reloj legal de 24 horas. Y un fabricante sin proceso alguno de descubrimiento puede infringir el artículo 14 no por no notificar, sino por no haber sabido nunca que había algo que notificar.
El corolario incómodo: mucho del código que hoy se embarca en esos productos está escrito por máquinas, y mucha de la revisión que se le aplica la realizan los mismos modelos que lo escribieron. Un código escrito por un modelo y revisado por el mismo modelo no ha sido revisado por nadie. Reguladores, compradores, aseguradoras y equipos de seguridad corporativos convergen en la misma pregunta — y «nuestro modelo comprobó su propia salida» no es una respuesta que ninguno de ellos acepte.
La refutación como disciplina: el método CounterProof
Un barrido y una evaluación responden preguntas distintas, y la segunda es donde se sitúa nuestra propia práctica. CounterProof no se diseñó en un taller como producto; se fue acretando mientras asegurábamos nuestra propia infraestructura de pagos con criptografía de umbral — donde un defecto que se cuela no cuesta una relación con un cliente: le cuesta al operador sus propios fondos.
La restricción que le dio forma era la opuesta a la del Red Team. Ellos necesitaban amplitud: 501 proyectos, rápido, en el modelo que ejecutara el trabajo. Nosotros necesitábamos que un solo hallazgo sobreviviera a equivocarse en público, sobre código que custodia nuestro propio dinero. La amplitud perdona un falso positivo; una evaluación firmada, no. Otro problema, otro método — y nosotros teníamos el lujo de elegir instrumentos, que es precisamente lo que las restricciones de políticas descritas arriba les negaba a ellos.
CounterProof toma el cuello de botella de la valoración de frente, con un protocolo moldeado por los modos de fallo descritos arriba. Cada evaluación es una revisión adversarial multi-linaje: familias de modelos independientes — no una segunda pasada del mismo — atacan cada hallazgo e intentan refutarlo, y los desacuerdos se resuelven leyendo el código fuente, no votando.
Ese último punto no es una pretensión de tener mejores modelos. Es una afirmación sobre una propiedad medida de todos ellos: el veredicto de un revisor es una muestra, no una medición. Dele al mismo modelo los mismos bytes dos veces y no siempre devolverá la misma respuesta; plantee una pregunta a varias familias y fallarán en direcciones distintas — la única razón por la que ejecutar varias vale su coste. Hemos visto a un modelo «corregir» con seguridad una referencia regulatoria y equivocarse, mientras un modelo sin acceso a la fuente declinaba, correctamente, responder. La lección no es que un linaje sea superior. Es que un solo linaje — cualquiera — no puede comprobarse a sí mismo. Nada se entrega sin pasar por la refutación. Cada hallazgo que sobrevive se confirma después contra el código fuente real — fichero y línea exactos, ruta de reproducción, clasificación de impacto, con citas resueltas mecánicamente contra la revisión precisa revisada — o se etiqueta explícitamente como solo plausible. Cada hallazgo nombra el peldaño de evidencia que alcanzó realmente — traza en la fuente, prueba de compilación, test o reproducción en vivo — y nunca insinúa uno superior. Y cada informe lleva un compromiso permanente de retractación: si un hallazgo se demuestra erróneo, se retracta por escrito.
En otras palabras: donde la revisión de la era de la IA genera ruido a escala industrial, la producción de CounterProof es deliberadamente lo contrario de una cola de triaje. Es una evaluación firmada, graduada por evidencia, bajo un identificador de encargo persistente — estructurada para entregarse a un equipo de due diligence, a una aseguradora, o para incorporarse a la documentación técnica del CRA como informe de pruebas con el formato del anexo VII, punto 6), acreditando el deber de pruebas. La independencia es estructural: no emitimos evaluación alguna sobre código escrito por CounterProof o por cualquier empresa de nuestro grupo — y nuestra propia base de código, escrita en gran parte por máquinas, pasa continuamente por el mismo registro adversarial. Fuimos nuestro primer cliente, y seguimos siendo el más exigente.
Próximamente lanzaremos un nuevo servicio en CounterProof.io, extendiendo esta práctica a equipos que afrontan exactamente la convergencia que este artículo describe: código escrito por máquinas, adversarios a velocidad de máquina y el reloj de un regulador. Pronto, más.
Hacia dónde va esto
Tres predicciones, sostenidas sin rigidez.
Primera: la brecha de triaje se ensancha antes de cerrarse. Los modelos de pesos abiertos seguirán mejorando, barridos como el del Bitcoin Red Team se repetirán en otros ecosistemas, y la proporción de hallazgos candidatos frente a verificados empeorará antes de que las herramientas de valoración y los métodos disciplinados se pongan al día. Los proyectos serán juzgados cada vez más — por usuarios, aseguradoras y compradores por igual — por su velocidad de respuesta a las divulgaciones, exactamente como observó Calle.
Segunda: el CRA se convierte en la función de forzado que las recompensas por fallos nunca fueron. Las normas voluntarias de divulgación produjeron una cobertura irregular durante una década; una obligación de notificación en 24 horas con multas escaladas por facturación hará en dieciocho meses lo que la buena voluntad no hizo — y la demanda de pruebas de seguridad periódicas, independientes y con calidad de documentación reestructurará el mercado de auditoría en torno a la evidencia y no a las insignias.
Tercera, y la más fundamental para Bitcoin: un ecosistema cuyo modelo de seguridad descansa en la revisión abierta está a punto de descubrir si la revisión de máquinas cuenta. La respuesta honesta: solo cuenta cuando una parte independiente está dispuesta a verificar el hallazgo, graduar la evidencia y firmar. La detección se ha automatizado. La responsabilidad, no — y no puede automatizarse. Ahí viven ahora el valor, y la responsabilidad.
CounterProof es una práctica independiente de revisión adversarial de Clavestra Capital Limited (Malta). Proof atestigua; CounterProof refuta. counterproof.io — Esta página es una traducción del original inglés; en caso de divergencia, prevalece el original.
Fuentes: aviso de seguridad de Coinkite y cobertura de Forbes, Bloomberg, CBC y Galaxy Research sobre el exploit de ColdCard (jul.–ago. 2026); divulgaciones del Bitcoin Red Team vía Bitcoin Magazine, Decrypt, crypto.news, Coinpaper y Metaverse Post (ago. 2026); notas de lanzamiento de BTCPay Server 2.4.2; evaluación conjunta de modelos UK AISI / US CAISI; Sonatype State of the Software Supply Chain 2026; Google Threat Intelligence Group, informe de actividad de amenazas asistida por IA (2026); análisis de StepSecurity del compromiso del SDK de Injective (jul. 2026); cobertura de incidentes de la cadena de suministro de npm (sept. 2025 – mar. 2026); Reglamento (UE) 2024/2847 (Cyber Resilience Act), arts. 13–14, 16, 69, anexos I y VII.