Tres tarjetas con la parte de nodos de Bitcoin Core accesibles que, en la instantánea de btcnodes.io del 11 de noviembre de 2026, anunciaban una versión sin cada arreglo: el 21,7 % (3.935 de 18.147) sin el del procesado de bloques (CVE-2025-62859), el 10,4 % (1.887 de 18.147) en el rango del fallo de minería (CVE-2025-62861) y el 18,9 % de los nodos Core por Tor (1.584 de 8.384) sin el arreglo de Tor (CVE-2025-62860).
Gráfica propia con los datos de este artículo: recuento de nodos accesibles de Bitcoin Core en la instantánea de btcnodes.io del 11 de noviembre de 2026, a las 10:12 (hora de Madrid).

Bitcoin Core destapa tres fallos de seguridad: ¿le afectan a tu nodo? Guía versión por versión

Equipo NodeWitness 11 min de lectura

Bitcoin Core hizo públicos el 10 de noviembre tres fallos que llevaban un año corregidos. Uno, de severidad alta, deja a un minero sin poder crear bloques tras una reorganización. Los otros dos, medios, permiten frenar el procesado de bloques o dan permisos de confianza a cualquiera que entre por Tor. Si tienes la 30.0 o posterior, o la 29.2 en adelante, estás cubierto. Si sigues en la serie 28, no del todo.

El 10 de noviembre de 2026, a las 21:39 (hora de Madrid), Antoine Poinsot anunció en la lista de correo de desarrollo de Bitcoin los tres avisos, ya colgados en bitcoincore.org [1][2][3][4]. No llegaron por sorpresa. Las notas de la 32.1 avisaron el 28 de octubre de que en dos semanas se publicarían tres vulnerabilidades de severidad media y alta corregidas en la 30.0 [5], y en nuestra guía de Bitcoin Core 32.1 contábamos con esa fecha. La política del proyecto es publicar los detalles dos semanas después de que la última serie afectada llegue al fin de vida, y la 29.x lo hizo el 27 de octubre [6].

La pregunta útil no es qué dice cada aviso, sino si tu nodo está en una versión con los arreglos. Esa respuesta cabe en una tabla.

¿Me afecta? La tabla, versión por versión

Tu versión de Bitcoin Core Bloques frenados por un par (CVE-2025-62859, media) Minería bloqueada tras una reorganización (CVE-2025-62861, alta) Pares de Tor con permisos de confianza (CVE-2025-62860, media)
30.0 o posterior (30.x, 31.x, 32.x) No No No
29.2 a 29.5 No No No
29.0 o 29.1 Sí Sí Sí, si usas whitelist
28.3 o 28.4 Sí No No
28.0 a 28.2 Sí Sí Sí, si usas whitelist
27.x o anterior Sí No Sí, si usas whitelist

Fuentes de la tabla: los tres avisos [2][3][4] y las notas de la 28.3, la 28.4 y la 29.2 [7][8][9].

La fila que más sorprende es la de la 28.3 y la 28.4. Esas dos versiones sí recibieron los arreglos de Tor y de las reorganizaciones, pero no el del procesado de bloques, que solo se llevó a la serie 29 [2][7][8]. La serie 28 dejó de recibir parches el 19 de abril de 2026, así que ese arreglo ya no va a llegar [6]. Y aunque la 29.2 en adelante está limpia de estos tres fallos, la 29.x llegó al fin de vida el 27 de octubre: el siguiente fallo que aparezca no se corregirá ahí. Las series con soporte son la 30.x, la 31.x y la 32.x, con la 30.4, la 31.2 y la 32.1 como últimas versiones [6].

Cómo mirar qué versión corre de verdad tu nodo

La forma fiable es preguntárselo al nodo que está en marcha:

bitcoin-cli getnetworkinfo

El campo version da un número como 320100 (32.1.0) o 280300 (28.3.0), y subversion lo da en texto, como /Satoshi:32.1.0/. Ojo con bitcoin-cli -version: dice la versión del programa bitcoin-cli que has escrito, no la del nodo que corre, y despues de una actualización a medias pueden no coincidir. En la interfaz gráfica sale en la ventana de Información del nodo, en el menú Ventana.

Para el fallo de Tor hay una segunda comprobación, en el bitcoin.conf:

grep -E '^(whitelist|whitebind)=' bitcoin.conf

Si sale alguna línea whitelist= con un rango que incluye la dirección de tu Tor (casi siempre 127.0.0.1 o una red interna de Docker) y tu versión es anterior a la 28.3 o a la 29.2, estás en el caso del aviso [3]. Con bitcoin-cli getpeerinfo puedes ver además qué pares tienen "network": "onion", "inbound": true y algo en permissions: en un nodo con el parche esa lista de permisos debe salir vacía para ellos.

Qué versión traen los sistemas de nodo más usados

Hemos mirado los repositorios y las publicaciones de cada proyecto el 11 de noviembre. No todos lo dicen igual de claro, así que va lo que se puede comprobar.

  • Umbrel. La app Bitcoin Node 1.5.0, del 30 de octubre, deja elegir entre la 32.1, la 31.2, la 30.4 y la 29.5; si tienes marcada la opción de usar siempre la última, ya corre la 32.1 [10]. Las versiones 1.0.x de la app llevaban la 29.1, que tiene los tres fallos [10]. El código actual de la app da los permisos de confianza con whitebind, ligado a un puerto interno, y no con un whitelist por rango [11].
  • Start9. El paquete de Bitcoin Core para StartOS publicó el 9 de noviembre la 31.2, la 30.4, la 29.5 y también la 28.4 [12]. Quien haya elegido la 28.4 sigue expuesto al fallo del procesado de bloques.
  • RaspiBlitz. Su última versión, la 1.12.1 del 3 de marzo de 2026, instala la 29.2 [13]. Tiene los tres arreglos, pero es una serie ya sin soporte.
  • myNode. Su repositorio pasó a la 32.1 el 8 de noviembre, salvo en equipos con un Debian anterior al 12, donde se queda en la 27.2 [14]. Su bitcoin.conf por defecto incluye whitelist=127.0.0.1, y el Tor del equipo entra desde esa misma dirección [15]. Con la 27.2, es exactamente el caso que describe el aviso de Tor.

En los cuatro casos, la versión que corre tu equipo es la que diga getnetworkinfo, no la que figure en la tienda de apps.

Los tres fallos, en palabras llanas

Bloques frenados (CVE-2025-62859, severidad media). Cuando llega un bloque nuevo, el nodo suele recibirlo en versión comprimida y lo reconstruye con las transacciones que ya tiene. Las versiones afectadas borraban el estado de la descarga antes de comprobar que los datos de testigo (la parte segwit) no estaban manipulados. Si esa comprobación fallaba, volvían a pedir el bloque entero al mismo par y le daban diez minutos de margen [2]. Un par malicioso que anuncia el bloque primero puede aprovecharlo para retrasar al nodo; si controla sus tres pares de alta velocidad, o si el nodo corre con -blocksonly, puede repetirlo sin fin [2]. Lo descubrió Eugene Siegel. Para un nodo de casa significa ver los bloques tarde; para quien tiene Lightning encima, ir por detrás de la cadena no es indiferente.

Minería bloqueada tras una reorganización (CVE-2025-62861, severidad alta). Las transacciones TRUC, o versión 3 (BIP 431), solo pueden tener un padre y un hijo sin confirmar en la mempool. Es una regla de retransmisión, no de consenso: un bloque válido puede traer cualquier forma [4]. Cuando la cadena se reorganiza, las transacciones de los bloques descartados vuelven a la mempool sin aplicarles límites, pero en la 28.0 a 28.2 y la 29.0 a 29.1 la expulsión de hermanos de TRUC seguía activa. Podía sacar una transacción y dejar a sus hijas dentro, gastando salidas que ya no existían [4]. Con la mempool así, la plantilla de bloque no pasa su propia comprobación y el nodo no puede producir bloques hasta que se reinicia [4]. Lo encontró Niklas Gögge. Afecta a quien mina con su propio nodo, incluido quien mina en solitario desde casa y arma su plantilla; a un nodo que no mina, en la práctica, no.

Pares de Tor con permisos de confianza (CVE-2025-62860, severidad media). Para Bitcoin Core, un par que entra por Tor llega desde la dirección del propio Tor, que suele estar en la misma máquina [3]. La opción -whitelist sirve para dar confianza a una red, y quita límites contra ataques de denegación de servicio y protecciones de privacidad. Si su rango incluía la dirección de Tor, todos los pares de Tor recibían esa confianza [3]. Según el anuncio, se podía usar para tumbar un nodo o hacerle soltar información interna [1]. Varios fabricantes empaquetaban Bitcoin Core con Tor y ese whitelist puesto, y eso dejó a miles de nodos accesibles aceptando a cualquier par de Tor como de confianza [3]. Lo descubrieron Martin Zumsande y Antoine Poinsot, que avisaron tambien al mantenedor de Bitcoin Knots en septiembre de 2025 [3].

Lo que vio nuestro nodo

Si tu nodo corre la 29.2, la 30.0 o una posterior, ninguno de los tres fallos te afecta. A las 11:13 del 11 de noviembre (hora de Madrid), en el bloque 975.425, tenía diez conexiones salientes con otros nodos [16]. Cinco de ellos se anunciaban con versiones de Bitcoin Core anteriores a la 29.2 y fuera de la serie 30 o posterior: 28.0, 27.0, 22.0, 0.21.0 y 0.20.0 [16]. Es una muestra pequeña, y la versión la declara cada par, pero da una idea de cuánto software viejo sigue en la red.

La foto grande la da el rastreador de nodos accesibles btcnodes.io. A las 10:12 (hora de Madrid) del 11 de noviembre contaba 20.244 nodos, y 18.147 se anunciaban como Bitcoin Core sin Knots [17]. De ellos, 3.935, el 21,7 %, llevaban una versión sin el arreglo del procesado de bloques, y 1.887, el 10,4 %, estaban en el rango del fallo de minería [17]. De los 8.384 nodos de Bitcoin Core accesibles por Tor, 1.584 no tenían el arreglo de Tor; desde fuera no se puede saber cuántos usan whitelist, que es lo que de verdad los expone [17].

Qué hacer

  1. Mira tu versión con getnetworkinfo. Si es la 30.0 o posterior, o la 29.2 en adelante, de estos tres fallos no tienes que hacer nada.
  2. Si estás en la serie 28 (también la 28.4) o en una 29.0 o 29.1, actualiza. Mejor a una serie con soporte, 30.4, 31.2 o 32.1, que a la 29.5, porque la 29.x ya no recibe parches [6]. Pasar a la 32.1 no exige reindexar ni migrar la cartera, como explicamos en la guía de la 32.1.
  3. Si tu sistema de nodo te deja fijar una versión, revisa cuál tienes fijada. Las tiendas de apps ofrecen todavía versiones con fallos conocidos.
  4. Si no puedes actualizar ya y tienes un whitelist que cubre a Tor, cambia esa línea por un whitebind en un puerto propio para tus programas internos, o quítala.
  5. Si minas con tu propio nodo, la actualización es prioritaria: una reorganización con transacciones TRUC puede dejarte sin plantillas hasta reiniciar.

Ninguno de los tres fallos toca el consenso ni pone en riesgo los fondos de una cartera por sí solo. Pero son públicos desde el 10 de noviembre, con explicación detallada incluida, y Core ya avisa de que los fallos fáciles de encontrar se publicarán en cuanto haya versiones corregidas [5]. Es la misma lección que con el fallo del núcleo de Linux de octubre: un nodo se mantiene, no se instala y se olvida. Las alturas y el estado de la red, en vivo, en Red y minería. Y si te interesa por qué Core y Knots reparten estos avisos por separado, lo contamos en Bitcoin Core vs. Knots.

Fuentes

Entre paréntesis, el tipo de fuente. Consultadas el 11 de noviembre de 2026. Horas en hora de Madrid (UTC+1) salvo que se diga otra cosa.

  1. Antoine Poinsot, «Three Bitcoin Core security advisories», lista bitcoindev, 10/11/2026, 20:39 UTC. (Primaria, lista de correo de desarrollo)
  2. Bitcoin Core, aviso CVE-2025-62859, «Block processing stall via witness malleation», 10/11/2026. (Primaria, web oficial del proyecto)
  3. Bitcoin Core, aviso CVE-2025-62860, «Inbound Tor connections wrongly receive -whitelist permissions», 10/11/2026. (Primaria, web oficial del proyecto)
  4. Bitcoin Core, aviso CVE-2025-62861, «Block template creation halted by TRUC sibling eviction during reorg», 10/11/2026. (Primaria, web oficial del proyecto)
  5. Bitcoin Core, anuncio de la 32.1 en la lista bitcoindev, 28/10/2026. (Primaria, lista de correo de desarrollo)
  6. Bitcoin Core, política de ciclo de vida y política de seguridad. (Primaria, web oficial del proyecto)
  7. Bitcoin Core, notas de la 28.3. (Primaria, repositorio oficial)
  8. Bitcoin Core, notas de la 28.4. (Primaria, repositorio oficial)
  9. Bitcoin Core, notas de la 29.2. (Primaria, repositorio oficial)
  10. Umbrel, ficha de la app Bitcoin Node en umbrel-apps y su historial. (Primaria, proyecto)
  11. Umbrel, configuración de bitcoind en umbrel-bitcoin. (Primaria, proyecto)
  12. Start9, versiones del paquete de Bitcoin Core para StartOS. (Primaria, proyecto)
  13. RaspiBlitz, versión 1.12.1 y su script de instalación de Bitcoin Core. (Primaria, proyecto)
  14. myNode, versiones de las apps. (Primaria, proyecto)
  15. myNode, bitcoin.conf por defecto y bitcoin_tor.conf. (Primaria, proyecto)
  16. NodeWitness, lectura de nuestro nodo (Bitcoin Core completo, sin pruning) con getpeerinfo y getnetworkinfo, 11/11/2026 a las 11:13, bloque 975.425. (Primaria, dato propio)
  17. Bitnodes, instantánea de nodos accesibles (servida desde btcnodes.io), 11/11/2026, 09:12 UTC; recuento propio por versión anunciada. (Secundaria, rastreador de la red)

Los tres avisos no cambian ninguna regla de la cadena: un nodo con la 28.4 y otro con la 32.1 siguen el mismo bloque. Lo que los separa es cuánto tarda cada uno en enterarse y qué le pueden hacer sus pares. La altura de nuestro nodo, comparada con la de la red, está siempre en Red y minería.

Más en Red y minería

Ver los 19 artículos de Red y minería →

Última actualización: 11 de noviembre de 2026