-
BTCPay Server prometió revelar más detalles de su falla cuando más usuarios actualicen.
-
El 256 Red Team audita ASIC de minería y les dio a los fabricantes 30 días antes de publicar fallos.
Bitcoin atraviesa la que posiblemente sea la peor racha de incidentes de seguridad de sus 17 años de historia, impulsada por ataques asistidos por inteligencia artificial (IA). Esta tendencia creciente, entre otras implicaciones, cambió la forma en que los equipos de desarrollo informan sus propios parches de seguridad.
Que los equipos de desarrollo comiencen a posponer estos detalles no es casual. Esta situación responde a un nuevo dilema de la ciberseguridad: publicar una corrección también puede revelar cómo explotar la vulnerabilidad que acaba de ser solucionada. Comparar el código de un proyecto antes y después de una actualización permite deducir qué falla fue corregida.
Hasta hace poco, convertir ese hallazgo en un ataque funcional podía requerir días o semanas de trabajo humano. Ahora, un modelo de inteligencia artificial puede analizar esa comparación, identificar los cambios relevantes y ayudar a reconstruir la vulnerabilidad original en cuestión de horas.
Parches sin revelar: los casos que derrumbaron una costumbre en Bitcoin
Este cambio de paradigma ayuda a explicar los tres casos que marcaron las últimas semanas dentro del ecosistema de Bitcoin. Ya no alcanza con corregir una vulnerabilidad. Los equipos de desarrollo también deben decidir cuánto revelar sobre ella y cuándo hacerlo, porque una explicación demasiado detallada puede convertirse en una guía para atacantes.
El primer caso es Electrum, una de las wallets más usadas del ecosistema bitcoiner. Este 12 de agosto, sus desarrolladores lanzaron la versión 4.8.1 y especificaron que incluía parches de seguridad importantes, pero explicaron que la divulgación detallada de las fallas corregidas llegaría más adelante, una práctica poco habitual del proyecto.
El segundo caso es BTCPay Server, un procesador de pagos de código abierto y autoalojado. El 7 de agosto, su equipo confirmó una falla crítica que permitía eludir la autenticación de dos factores en su interfaz de programación y la corrigió con la versión 2.4.2.
El equipo explicó el mecanismo general del ataque, pero adelantó que revelaría más detalles técnicos recién cuando una mayor proporción de servidores hubiera actualizado. La razón, según sus propios desarrolladores, es que divulgar todo de inmediato podría facilitar nuevos ataques contra las instalaciones que todavía no aplicaron el parche.
El tercer caso corresponde al 256 Red Team, la iniciativa de auditoría que la organización 256 Foundation lanzó también el 12 de agosto para revisar el firmware, de los equipos de minería. Está liderada por el ingeniero Michael Schmid, quien aseguró que alrededor del 90% de los ASIC ejecutan firmware de código cerrado de un solo proveedor y no recibieron auditorías independientes.
Por ejemplo, la empresa Bitmain, el mayor fabricante de ASIC de Bitcoin y de criptomonedas, tiene el firmware de sus equipos con código cerrado. Es decir, que la compañía no publica el código fuente completo, por lo que los usuarios no pueden auditarlo, modificarlo libremente ni verificar exactamente qué hace.
El 256 Red Teamhalló 41 fallascon pruebas reproducibles y envió tres reportes bajo divulgaciones responsables a los fabricantes de software LuxOS, VNISH y Braiins OS, a quienes dio 30 días de plazo antes de publicar los detalles completos.
Los tres proyectos actúan en plataformas distintas, con usuarios distintos y bajo amenazas distintas, pero coinciden en algo. Ninguno decidió ocultar que había un problema. Todos decidieron, en cambio, administrar el momento y el nivel de detalle con el que lo cuentan, algo que hace apenas un año hubiera sido inusual en un ecosistema acostumbrado a la transparencia inmediata del software libre.
Ataques con IA explican el cambio de paradigma
La decisión de retrasar estos detalles ocurre en medio de lo que ya es la peor crisis de seguridad que atraviesan las redes de criptomonedas, impulsada por ataques con inteligencia artificial que además redujeron las barreras de entrada a los hackeos, permitiendo que atacantes con menos conocimiento técnico logren vulnerar sistemas digitales que antes estaban fuera de su alcance.
Informes de las firmas Blockaid y TRM Labs coinciden en que el primer semestre del 2026 marcó un récord sin precedentes en cantidad de hackeos en el ecosistema de criptomonedas, la enorme mayoría de ellos promovidos por el uso de sistemas de IA: 212 incidentes verificados, lo que implica un aumento del 240% respecto a todo 2025.
Dentro del propio ecosistema de Bitcoin, esa aceleración ya dejó al menos cinco incidentes de seguridad en las últimas dos semanas, entre ellos los ataques que afectaron a BTCPay Server, el que sufrió la wallet ZEUS, la empresa Boltz, la plataforma LNP2Pbot y las wallets Coldcard.
La velocidad con la que se suceden estos episodios es, precisamente, lo que empujó a los equipos de desarrollo a repensar cuánta información conviene publicar sobre sus parches y en qué momento hacerlo.
El Bitcoin Red Team, la coalición de auditores que desde julio escaneó cientos de proyectos de código abierto y reportó cerca de 8.000 vulnerabilidades, señaló que la librería criptográfica base del protocolo de Bitcoin es el repositorio más limpio de todo el ecosistema.
Los problemas se concentran, en cambio, en el software que rodea al protocolo, como las wallets, los procesadores de pago y el firmware de minería, que es justamente donde ocurrieron los tres casos de divulgación pospuesta.
Ninguno de estos casos garantiza que el ecosistema haya adoptado una política uniforme frente al problema. Lo que sí queda claro es que, ante una inteligencia artificial capaz de convertir un parche en un mapa hacia la vulnerabilidad original, revelar todo de inmediato dejó de ser la respuesta automática.
La forma en que los equipos de desarrollo informan sus propios parches de seguridad está cambiando caso por caso, y probablemente siga haciéndolo mientras los ataques asistidos por IA continúen acelerándose.
