Cuando auditar código se vuelve barato: la IA cambió la seguridad de Bitcoin

La inteligencia artificial no creó las vulnerabilidades que sacudieron al ecosistema Bitcoin. Lo que cambió fue la economía para encontrarlas: revisar millones de líneas de código, probar hipótesis y repetir el proceso cuesta cada vez menos. Esa ventaja ya está disponible para atacantes y defensores.

14 de agosto de 2026 · Sovereign Geek

En poco más de dos semanas, varios nombres conocidos del ecosistema Bitcoin aparecieron ligados a incidentes de seguridad: COLDCARD de Coinkite, BTCPay Server, Boltz, LNP2PBot y Trezor. Sin embargo, hay una diferencia importante: no todos fueron “hackeos”, no todos tuvieron fondos robados y, en el caso de Trezor, el incidente ocurrió en un proveedor logístico externo.

El caso de COLDCARD fue el punto de partida de esta conversación. En la entrada anterior, Cuando falla la matemática: dentro de la vulnerabilidad de entropía de COLDCARD, analizamos en detalle cómo el problema redujo el espacio efectivo de las semillas y por qué actualizar el firmware no repara una semilla ya generada.

La ola reúne casos distintos: una debilidad de generación de semillas explotada contra usuarios, credenciales Lightning expuestas por una vulnerabilidad crítica y servicios que reportaron ataques y pérdidas operativas. Meterlos a todos bajo la palabra ataque produciría un titular más dramático, pero un análisis menos útil.

Lo realmente importante no es asumir que hubo una sola campaña coordinada. Tampoco está probado que una IA descubriera cada falla. El hilo común más defendible es otro: el costo marginal de buscar vulnerabilidades con agentes de IA está cayendo rápidamente, mientras que el código abierto de Bitcoin ofrece una superficie pública, valiosa y verificable sobre la cual trabajar.

Primero: ¿qué ocurrió realmente?

Proyecto	Qué ocurrió	Impacto conocido	Estado al 14 de agosto de 2026
Coinkite / COLDCARD	Un error de integración hizo que ciertas versiones usaran un PRNG de MicroPython en la ruta de generación de semillas, en lugar de depender correctamente del TRNG previsto.	Coinkite estima alrededor de 40 bits de entropía efectiva en Mk2/Mk3 afectados y unos 72 bits en Mk4/Q/Mk5 afectados. Actualizar el firmware no repara una semilla existente.[5][6]	Firmware corregido disponible; usuarios afectados deben generar una semilla nueva y migrar, salvo las excepciones específicas por tiradas privadas de dados explicadas por Coinkite.[5]
BTCPay Server	Una vulnerabilidad permitía que un atacante remoto no autenticado obtuviera archivos `.macaroon` de LND.	BTCPay confirmó explotación, usuarios afectados y fondos robados. El riesgo descrito se concentró en despliegues con LND; las wallets on-chain de BTCPay no estaban afectadas por esta falla concreta.[7]	Corregido en BTCPay Server 2.4.2; el proyecto pidió actualizar también LND, revisar actividad y regenerar credenciales.[7][8]
Boltz	El proyecto declaró que varios ataques asistidos por IA tuvieron éxito y produjeron pérdidas operativas.	Según Boltz, los fondos de usuarios no estuvieron en riesgo gracias a su arquitectura no custodial.[16]	Swaps suspendidos mientras se buscaban y corregían vulnerabilidades; faltaban detalles técnicos públicos para una validación independiente completa.[15][16]
LNP2PBot	Su operador informó que ataques sostenidos escalaron y ocasionaron pérdidas asumidas por el equipo.	El equipo prometió cubrir a los usuarios y resolver pagos pendientes; no publicó un análisis técnico suficiente para identificar el vector exacto.[17][18]	El servicio cerró. No debe confundirse este caso con LNbits: no apareció un advisory nuevo de LNbits dentro de la misma ventana.
Trezor / ShipMonk	ShipMonk, proveedor de envíos de Trezor, informó acceso no autorizado a sistemas que contenían datos de pedidos.	11,742 clientes tuvieron exposición completa —nombre, correo, teléfono y dirección— y 1,947 exposición parcial —nombre, ciudad y correo—: aproximadamente 13,689 personas.[26]	Los sistemas y dispositivos de Trezor no fueron comprometidos. El riesgo inmediato es el phishing dirigido por correo, teléfono o incluso correspondencia física.[25][26]

El caso de Trezor pertenece a una categoría distinta. No fue una vulnerabilidad del hardware wallet ni una extracción de semillas: fue una brecha en la cadena de suministro de datos. BleepingComputer reportó que ShipMonk atribuyó el acceso a la explotación de una vulnerabilidad crítica de inyección SQL en Metabase; Trezor, por su parte, comunicó que la investigación seguía en curso.[25][26]

La diferencia técnica no reduce el riesgo humano. Con nombre, correo, teléfono y domicilio, un atacante puede construir mensajes mucho más convincentes, hacerse pasar por Trezor, un exchange o un banco y presionar a la víctima para que revele su respaldo. Trezor fue explícito: sus dispositivos siguen seguros y ningún usuario debe escribir o compartir su wallet backup en línea.[26]

La atribución a IA: plausible no significa demostrada

En el incidente de COLDCARD, Coinkite escribió que, dado que el código era público, tenía que asumir que alguien utilizó IA para revisar versiones anteriores del firmware. También reconoció que una revisión propia con uno de los mejores modelos disponibles no había encontrado el error.[6]

Jameson Lopp fue todavía más explícito en el blog de Casa: investigadores “ahora creen” que la vulnerabilidad fue most likely encontrada por un modelo frontera. Esa frase importa. “Presumiblemente” o “muy probablemente” no significa “confirmado”.[1]

La hipótesis es creíble porque el ataque encaja con una nueva capacidad: un agente puede recorrer repositorios públicos, seguir rutas de ejecución, comparar supuestos con la implementación y buscar patrones repetibles sin cansarse. Pero no tenemos una atribución forense pública que pruebe quién usó qué modelo, con qué instrucciones y en qué momento.

El artículo de Casa acierta en la conclusión operativa aunque la atribución siga abierta: los equipos deben actuar como si las máquinas ya estuvieran leyendo su código, porque la capacidad existe y seguirá abaratándose.[1]

No es un problema del código abierto; es una carrera de velocidad

Sería fácil sacar una conclusión equivocada: “si el código público puede ser analizado por atacantes, entonces hay que cerrarlo”. Eso confunde visibilidad con inseguridad.

El código abierto permite que investigadores independientes auditen, reproduzcan y corrijan fallas. También reduce la dependencia de promesas imposibles de verificar. El problema no es que el atacante pueda leer el código; el problema aparece cuando puede hacerlo continuamente mientras el defensor sólo audita una vez al año.

Durante años, una auditoría profunda exigía especialistas escasos, semanas de trabajo y presupuestos que muchos proyectos comunitarios no podían pagar. Hoy un agente de IA puede automatizar el primer barrido, ejecutar herramientas, producir casos de prueba y repetir el análisis después de cada cambio. El AI Index de Stanford encontró que el costo de inferencia de un sistema con desempeño equivalente a GPT‑3.5 cayó más de 280 veces entre noviembre de 2022 y octubre de 2024.[11]

Eso no significa que una auditoría completa sea 280 veces más barata. El análisis de seguridad también consume infraestructura, diseño de harnesses, ejecución de pruebas y tiempo humano para separar hallazgos reales de falsos positivos. Pero sí significa que su materia prima económica —la inferencia— se ha vuelto radicalmente más accesible.

Hay señales más directas. En un estudio de penetración sobre una red universitaria real de unos 8,000 hosts, el agente ARTEMIS encontró nueve vulnerabilidades válidas, superó a nueve de diez participantes humanos y algunas de sus variantes costaron 18 dólares por hora, frente a 60 dólares por hora para pentesters profesionales. Los autores también observaron más falsos positivos y dificultades con interfaces gráficas: barato no significa infalible.[21]

En Firefox, Anthropic y Mozilla ofrecieron una demostración defensiva especialmente clara. Claude Opus 4.6 encontró 22 vulnerabilidades en dos semanas; Mozilla clasificó 14 como de alta severidad y publicó correcciones. Anthropic gastó aproximadamente 4,000 dólares en cientos de intentos posteriores de explotación y sólo obtuvo dos exploits rudimentarios, concluyendo que encontrar fallas era alrededor de un orden de magnitud más barato que convertirlas en exploits.[12][13]

Esa diferencia abre una ventana para los defensores. Pero es una ventana, no una garantía permanente.

Bitcoin Red Team: intentar llegar antes que el atacante

Como reacción a la situación de COLDCARD, una iniciativa voluntaria conocida como Bitcoin Red Team comenzó a revisar masivamente repositorios del ecosistema. Sus líderes públicos, Calle y Rob Hamilton, describieron un proceso que combina agentes de IA con especialistas humanos: seleccionar repositorios, lanzar análisis, reproducir los hallazgos graves en entornos locales y comunicarlos en privado a los mantenedores.[3]

Las primeras cifras fueron llamativas: 390 proyectos analizados, 4,962 hallazgos iniciales, 85 clasificados como críticos y 635 como altos.[3][22] Pero hay que interpretar esos números correctamente: un hallazgo clasificado por una herramienta no equivale a una vulnerabilidad confirmada. La validación, reproducción y divulgación coordinada siguen siendo trabajo humano.

El equipo tampoco “parcha” automáticamente todo lo que encuentra. Normalmente entrega evidencia y pruebas de concepto; los mantenedores evalúan el reporte, corrigen su proyecto y publican una actualización. Ésa es la forma responsable de reducir el tiempo entre descubrimiento y reparación sin regalar una guía de explotación antes de que exista un parche.

OpenSats convirtió el esfuerzo en infraestructura más estable mediante un Red Team Fund: un fondo para pagar a investigadores que encuentren y divulguen fallas, y para reembolsar los costos mensuales de tokens de los modelos.[24] Esto es importante porque el cuello de botella no será sólo computacional. También harán falta personas que comprendan Bitcoin, reproduzcan resultados, coordinen divulgaciones y acompañen a mantenedores pequeños.

La primera campaña demuestra que el costo del screening masivo ha caído. No demuestra que 390 repositorios hayan recibido 390 auditorías profesionales equivalentes. Confundir ambas cosas sería precisamente el tipo de exceso de confianza que una buena práctica de seguridad debe evitar.

Lo que Casa está haciendo —y lo que otras empresas pueden copiar

El artículo de Casa ofrece un modelo más maduro que “conectar un chatbot al repositorio”. Su harness recurrente usa tres fases: descubrir, verificar y reportar. Cada posible falla debe citar archivo y líneas exactas, incluir el código correspondiente y producir formatos integrables en el flujo de ingeniería. Los hallazgos verificados generan tickets y los críticos alertan al personal de guardia.[1]

Casa combina esta capa con revisiones humanas, protección de ramas, commits firmados, pruebas de regresión, pruebas end-to-end, QA exploratorio, pentests externos y auditorías enfocadas en cambios importantes. Además, utiliza multisig de múltiples proveedores para que el compromiso de una sola llave o dispositivo no sea suficiente para mover fondos.[1]

La lección general no es “comprar el modelo más caro”. Es construir un sistema donde la IA pueda proponer, pero tenga que demostrar.

Un plan práctico para una empresa

Inventariar lo que realmente protege valor. Repositorios, dependencias, secretos, pipelines de CI/CD, imágenes, firmware, APIs, llaves y rutas administrativas. Sin inventario no existe un alcance defendible.
Definir invariantes de seguridad. Ejemplos: “ninguna credencial Lightning puede servirse por HTTP”, “una llave nunca abandona el dispositivo”, “un fallback criptográfico debe fallar de forma cerrada”. Estas reglas sirven como contexto para humanos, pruebas y agentes.
Ejecutar análisis de IA en un entorno aislado. Nunca enviar repositorios privados, secretos, bases de datos o credenciales a un proveedor sin revisar contratos, retención, residencia y uso de datos. Preferir sandboxes sin acceso a producción y credenciales desechables.
Exigir verificadores. Cada hallazgo debe incluir un caso mínimo reproducible, evidencia concreta y, cuando sea posible, una prueba que falle antes del parche y pase después. Mozilla destacó precisamente los casos mínimos y pruebas reproducibles como la diferencia entre reportes útiles y ruido.[12][13]
Separar descubrimiento, explotación y remediación. No dar automáticamente a un agente permisos para desplegar, rotar llaves o ejecutar exploits fuera del laboratorio. Hallar una falla no autoriza una acción de producción.
Mantener revisión humana obligatoria. Ningún parche de IA debe saltarse code review, pruebas de regresión, controles de cambio y aprobación del dueño del sistema.
Analizar cada cambio, no sólo cada aniversario. Integrar revisión en pull requests, ejecutar barridos semanales y disparar revisiones extraordinarias cuando aparezca una falla relevante en la industria.
Diseñar para que una capa pueda fallar. Segmentación, mínimo privilegio, límites de retiro, separación de funciones, múltiples llaves y proveedores, monitoreo y procedimientos de recuperación reducen el daño cuando una vulnerabilidad inevitablemente escapa.
Preparar divulgación e incident response antes del incidente. Publicar un SECURITY.md, un canal de contacto, reglas de safe harbor, responsables de triage y un procedimiento para avisar a usuarios sin revelar prematuramente el exploit.
Medir resultados útiles. Tiempo de detección, tiempo de validación, tiempo de parche, porcentaje de falsos positivos, regresiones evitadas y vulnerabilidades reproducidas. “Tokens consumidos” o “hallazgos generados” no son métricas de seguridad por sí solos.

¿Qué puede hacer una persona común sin convertirse en especialista?

La educación continua será importante, pero no tiene que convertirse en vigilancia permanente ni en una dieta de miedo. Una rutina sencilla de 20 minutos por semana puede ser suficiente:

Haz una lista corta de lo que usas. Wallet, hardware wallet, nodo, servidor Lightning, exchange y aplicaciones conectadas. Si un producto no está en tu inventario, sus alertas no deberían ocupar tu atención.
Sigue primero las fuentes oficiales. Activa avisos de seguridad, RSS, correo y notificaciones de lanzamientos de cada proyecto. En GitHub puedes observar sólo Releases y Security alerts para evitar el ruido de cada commit.
Añade una fuente curada. El newsletter de Bitcoin Optech resume desarrollos técnicos y mantiene un archivo consultable.[14] Para productos concretos, conserva además el blog o canal oficial del fabricante.
Usa IA como filtro, no como autoridad. Pídele resumir qué productos están afectados, qué versiones corrigen el problema y qué acción recomienda la fuente. Después abre el advisory original. Una captura de pantalla o un post viral no sustituye al comunicado primario.
Verifica tres datos antes de actuar: producto y modelo exactos, versión instalada y acción oficial recomendada. Los estafadores aprovechan incidentes reales para distribuir “actualizaciones” falsas o pedir semillas.
Nunca introduzcas tu frase semilla, passphrase, llave privada, macaroon, API key o archivo de respaldo en un chatbot. Una IA puede ayudarte a comprender instrucciones públicas; no necesita tus secretos para hacerlo.
Descarga actualizaciones desde el sitio oficial y verifica firmas cuando el proyecto las ofrezca. No uses enlaces enviados por mensajes directos.
Mantén poco valor en sistemas calientes. Una wallet móvil, un servidor Lightning o un servicio experimental debe contener sólo el monto necesario para su función.
Para ahorros significativos, elimina el punto único de falla. Multisig con dispositivos de distintos proveedores puede evitar que la falla de una sola implementación baste para robar los fondos, siempre que la configuración y la recuperación estén bien comprendidas.[1]
Practica la recuperación. Una arquitectura sofisticada que nadie sabe restaurar puede ser más peligrosa que una sencilla y bien probada.

Una regla particularmente útil durante una emergencia es ésta:

No actualices desde el pánico; actualiza desde la fuente primaria. Nunca escribas tu semilla para “verificar” si está afectada.

El cambio más profundo: la seguridad deja de ser un evento

La conclusión de Casa resume bien la transición: una auditoría es una fotografía, no una película.[1] La IA vuelve económicamente posible revisar más código, con mayor frecuencia y desde más ángulos. Al mismo tiempo, permite a un atacante hacer exactamente lo mismo.

El resultado no será un mundo sin vulnerabilidades. Será un mundo donde el tiempo entre introducir una falla y descubrirla se comprime. Las empresas que conviertan la revisión adversarial en una rutina, verifiquen la salida de los modelos y diseñen sus sistemas para tolerar fallas tendrán una ventaja. Las que confundan una auditoría anual con un estado permanente de seguridad quedarán expuestas.

Para las personas, la respuesta tampoco es aprender explotación ofensiva ni perseguir cada rumor. Es mantener un inventario pequeño, seguir fuentes oficiales, entender el diseño de las herramientas que custodian su dinero y practicar cómo recuperarse.

La IA está abaratando tanto el ataque como la defensa. La ventaja no pertenecerá automáticamente a quien tenga el modelo más poderoso, sino a quien convierta sus resultados en aprendizaje, parches y resiliencia con mayor rapidez.