Bitcoin Core levanta el embargo: «el compromiso equivocado» en las fallas fáciles de encontrar

Bitcoin Core ha cambiado las reglas por las que las fallas de seguridad del principal software de Bitcoin se hacen públicas. Quien notifica una falla que puede volver a encontrarse con poco esfuerzo ya no desencadena meses de silencio, sino una versión de corrección para cada versión principal todavía mantenida y un aviso de seguridad el mismo día. El cambio se incorporó a la política de divulgación de bitcoincore.org el 22 de octubre de 2026 a las 16:06.

Para ti como tenedor de Bitcoin esto no es una nota al margen del mundo de los desarrolladores. La política decide con qué rapidez te llega un error corregido del software, y decide cuánta ventaja tiene un atacante entretanto. A unos 81.400 dólares por bitcoin el 23 de octubre de 2026, de esa cuestión depende el contravalor de carteras enteras.

Qué cambió Bitcoin Core en la política el 22 de octubre

Bitcoin Core es el software de referencia de la red Bitcoin. Comprueba los bloques, mantiene la blockchain y contribuye a determinar qué transacciones son válidas. Quien opera un nodo propio ejecuta, en la mayoría de los casos, exactamente este software.

Según su propia exposición, la política distingue cuatro clases de vulnerabilidades. Lo que se ha añadido no es una quinta clase, sino un atributo transversal: en la primera revisión, Bitcoin Core puede clasificar una falla notificada como easily discoverable, es decir, fácil de encontrar. Cuando ese atributo acompaña a un aviso, desaparece el plazo de espera vigente hasta ahora.

El procedimiento en sí está documentado de forma verificable. El desarrollador Antoine Poinsot presentó el cambio el 16 de octubre de 2026 como pull request 1281, bajo el título «Update security policy for easy-to-find vulnerabilities». Tras quince comentarios se fusionó el 22 de octubre por otro responsable de Core. Se modificó un único archivo, con diez líneas nuevas y una suprimida. No se trata, pues, ya de una propuesta, sino de la política vigente.

«Easily discoverable»: el nuevo atributo en los términos de la política

Easily discoverable significa en la política: una vulnerabilidad que puede descubrirse con un esfuerzo mínimo, por ejemplo mediante una consulta sencilla a un modelo de lenguaje. Esa es toda la definición, y es deliberadamente amplia. La clasificación no se limita expresamente a los hallazgos realizados de verdad con un modelo de lenguaje; la consulta sencilla sirve de vara de medir para el esfuerzo, no de prescripción sobre la herramienta.

Si un aviso lleva ese atributo, la política establece: Bitcoin Core publica para cada versión principal mantenida, lo antes posible, una versión de corrección con el arreglo, junto con un aviso de seguridad, y no aplica los plazos de embargo habituales, que dependen de la gravedad. Sigue habiendo un anuncio previo dos semanas antes de la publicación de los detalles, pero solo para las fallas que están efectivamente bajo embargo.

Un año de embargo frente a una versión de corrección el mismo día

Para entender lo grande que es esa diferencia, conviene mirar los plazos que siguen rigiendo al lado. Para las fallas sin el nuevo atributo todo queda como estaba.

Una vulnerabilidad de gravedad baja se divulga dos semanas después de la publicación de una versión principal que contenga la corrección. En gravedad media y alta, la divulgación llega solo dos semanas después de que la última versión afectada haya alcanzado el fin de su mantenimiento. La propia política cifra ese punto: aproximadamente un año después de que apareciera por primera vez una versión principal con la corrección.

De ahí se deriva la verdadera dureza de la regla antigua, y la política la nombra abiertamente. Como Bitcoin Core apuesta por un embargo largo, las correcciones de seguridad no pueden por regla general retroportarse a versiones más antiguas. Llegan a los usuarios solo con la siguiente versión grande. Quien está, por tanto, en una versión principal mantenida pero no la más reciente podía quedarse meses sin recibir una corrección.

Antoine Poinsot llama al embargo en los hallazgos fáciles el compromiso equivocado

Poinsot justifica el paso con una ponderación presente en toda política de seguridad. Transparencia y tiempo para actualizar tiran en direcciones distintas: la apertura iguala a atacantes y defensores, pero puede hacer pública una falla antes de que los usuarios hayan actualizado. Por la naturaleza del proyecto y por una cultura de actualización lenta, dice, Bitcoin Core se decidió por el embargo más largo.

Para los errores fáciles de encontrar, esa ponderación ya no se sostiene. Poinsot escribe literalmente que se trata del «wrong tradeoff», el compromiso equivocado, y añade: «The embargo period achieves little but it delays the availability of a fixed release». El embargo lograría, pues, poco, pero retrasaría la disponibilidad de una versión corregida. Como motivo cita un aumento de los avisos sobre fallas que vuelven a descubrirse con facilidad, y lo atribuye a que los modelos de lenguaje bajan notablemente el listón para encontrar ciertas clases de errores o para detectar correcciones ocultas.

La segunda parte de esa frase es la más incómoda. Un arreglo introducido en silencio en código abierto era antes difícil de reconocer como tal. Si eso se puede rastrear de forma automatizada, el embargo delata la falla que intenta ocultar.

Los modelos de lenguaje bajan el listón, y la ronda del red team lo muestra en cifras

Cuánto se ha desplazado la situación lo muestra una ronda de la que informó CoinDesk el 23 de octubre de 2026. Un grupo de voluntarios llamado Bitcoin Red Team, dieciséis desarrolladores según ese informe, hizo pasar modelos de inteligencia artificial por 390 proyectos de Bitcoin a finales de julio de 2026, en torno a un día según la exposición del informe. Se registraron 4.962 hallazgos, de ellos 85 clasificados como críticos.

Esas cifras son hallazgos en bruto y no fallas confirmadas, y los informes sobre la ronda difieren entre sí; una versión habla solo de alrededor de una quinta parte de hallazgos confirmados. Como orden de magnitud, el punto se sostiene igualmente: lo que antes costaba a un especialista semanas de trabajo manual hoy corre de un día para otro y a lo ancho.

Que de ello surja daño está acreditado por el mismo informe. Una vulnerabilidad de BTCPay Server, que el grupo había notificado antes de forma confidencial, se explotó según ese informe en cuestión de días en servidores de comercios en funcionamiento y vació nodos de Lightning. Core Lightning pidió a sus operadores en agosto de 2026 que cortaran conexiones, después de que avisos generados por inteligencia artificial dirigidos al pequeño equipo resultaran auténticos. La revisión por personas sigue siendo necesaria, porque una parte de los avisos generados por la máquina al final no describe vulnerabilidad alguna.

Que una falla no tiene que ser encontrada por un modelo de lenguaje para salir cara lo muestra un caso del mismo verano. En el firmware de la cartera hardware Coldcard dormía, según el informe, un error presente desde 2021 por el que el 30 de julio se retiraron 594 bitcoins en 25 minutos; a lo largo de cuatro retiradas la pérdida sumó casi 114 millones de dólares. Quien quiera comparar los modelos de distintos proveedores y sus vías de actualización encontrará el repaso en la comparativa de carteras hardware.

Tres versiones principales cuentan como mantenidas: 29.x, 30.x y 31.x

«Cada versión principal mantenida» es el inciso decisivo de la nueva regla, porque te dice si una versión de corrección llega hasta ti. Bitcoin Core se atiene aquí a un compromiso escueto: se mantienen siempre las tres últimas versiones principales, tal como figura en el plan de ciclo de vida del proyecto en bitcoincore.org.

Ahora mismo son tres estados. La versión 31.x apareció el 19 de abril de 2026 y es la edición actual. La versión 30.x es del 10 de octubre de 2025 y la 29.x del 14 de abril de 2025. El fin del mantenimiento está ligado en cada caso a las próximas versiones principales y no a una fecha fija. La versión 28.x salió del mantenimiento el 19 de abril de 2026 y, por tanto, tampoco recibe una versión de corrección al amparo de la nueva regla.

Así compruebas qué versión de Core ejecuta tu propio nodo

Si operas un nodo propio, el número de versión es el único dato que decide tu situación. Figura en la interfaz de Bitcoin Core bajo el apartado de información del programa, y en la línea de comandos lo entrega la llamada bitcoin-cli -version. Si la primera cifra es menor que 29, estás fuera del mantenimiento y ninguna de las correcciones aquí descritas te alcanzará.

Otros dos puntos son ahora más importantes que antes. Primero, merece la pena seguir los avisos de seguridad del proyecto, porque aviso y versión corregida aparecerán en adelante el mismo día y falta el margen previo. Segundo, el tiempo de reacción se ha acortado en tu contra: con la publicación los detalles son públicos, y quien no actualiza sigue adelante con una falla conocida. El mismo principio vale para la cartera de software de tu ordenador o tu móvil, cuyas vías de actualización están una al lado de otra en la comparativa de carteras de software.

Para los tenedores sin nodo propio se desplaza la responsabilidad

La gran mayoría de los inversores en Alemania no opera un nodo propio. Para ellos el cambio actúa de forma indirecta, a través de los servicios que ejecutan Bitcoin Core en segundo plano. Entre ellos están exchanges, custodios, proveedores de pago y los servidores que hay detrás de algunas aplicaciones de cartera.

Allí la nueva regla es ante todo una buena noticia. Un operador que hasta ahora tenía que esperar a una versión grande recibe ahora la corrección como versión de corrección para el estado que ya ejecuta de todas formas. Eso baja la barrera para actualizar siquiera. Al mismo tiempo sube la presión para hacerlo rápido, porque los detalles de la falla se hacen públicos en el mismo momento.

Carteras hardware y exchanges dependen de la misma divulgación

Una salvedad corresponde aquí, para que el alcance de este cambio no se sobrestime. Afecta a Bitcoin Core, no a toda la caja de herramientas de Bitcoin. Carteras hardware, aplicaciones de cartera, servidores de pago e implementaciones de Lightning tienen cada uno sus propias políticas, y los casos de este verano proceden en su mayor parte precisamente de esos proyectos. La pregunta de con qué rapidez un proveedor actualiza firmware y aplicación sigue siendo una pregunta para el proveedor.

Para ti eso significa: la decisión de custodiar tú mismo o dejar que custodien solo desplaza quién asume la actualización. No quita la tarea. Quien custodia por su cuenta carga con el mantenimiento de versiones del nodo y de la cartera. Quien tiene sus saldos en un custodio confía en que su técnica instale a tiempo las versiones de corrección, y cambia control por responsabilidad ajena.

Queda todavía un punto abierto. Hasta el 23 de octubre de 2026, según el informe de CoinDesk, no se había clasificado ninguna falla al amparo de la nueva regla. Cuán corto resulta en la práctica «lo antes posible» se verá solo en el primer caso real. También Poinsot admite que tales correcciones tienen menos tiempo para madurar antes de llegar a los usuarios. En cambio, rechazó una propuesta de renunciar por completo al aviso de seguridad: informar a los usuarios de una falla sin nombrar detalles podría crear un riesgo adicional innecesario.

Bitcoin Core: versión de corrección y aviso llegan el mismo día

1. Averigua el número de versión. Si tienes un nodo propio, comprueba si la primera cifra es 29, 30 o 31. Si está por debajo, actualiza a un estado mantenido. Para el lado de la cartera, la comparativa de carteras de software ayuda con la cuestión de cómo entrega sus actualizaciones el proveedor.
2. Pon al día el firmware de la cartera hardware. La falla de Coldcard estuvo cuatro años en el firmware según el informe. Comprueba cuándo actualizaste por última vez y cómo recibe actualizaciones tu modelo; la comparativa de carteras hardware pone a los proveedores uno al lado del otro.
3. Aclara de quién es la tarea. Decide quién asume en tu caso la actualización. Si una parte de tus saldos está en un custodio, revisa sus indicaciones técnicas; una valoración de los proveedores está en la comparativa de exchanges.

(23 de octubre de 2026. Este artículo no constituye asesoramiento de inversión. Los precios y las tarifas cambian; comprueba las condiciones con el proveedor antes de comprar.)