Guía para proteger tu nodo de bitcoin del fallo CVE-2026-98432 del núcleo de Linux

Un fallo en el código que abre las conexiones TCP de Linux permite, en el peor de los casos, ejecutar órdenes como administrador en una máquina ajena desde la red. Afecta a casi cualquier núcleo desde la versión 4.4. Debian ya lo ha corregido. A 31/10/2026, Ubuntu, Red Hat y Umbrel todavía no. Esta guía explica qué nodos están de verdad expuestos, cómo comprobar el tuyo y qué medidas recomiendan las fuentes oficiales mientras llega el parche.

El equipo de CVE del núcleo de Linux publicó el 15/10/2026 el aviso de CVE-2026-98432 [1]. El nombre técnico asusta poco, «liberar inet_opt e ireq_opt tras un periodo de gracia RCU», y la descripción tampoco ayuda a quien no lee código del núcleo. Lo que cambió el tono fue la publicación del equipo Frontier Red Team de Anthropic del 27/10/2026, que describía cómo uno de sus modelos internos había escrito un ataque capaz de ejecutar órdenes como root en un servidor Linux con solo enviarle paquetes, sin contraseñas y sin intervención del usuario [4]. Desde entonces el aviso corre por los foros de Umbrel, de Start9 y de quienes mantienen nodos Lightning [16][19][20].

Y es que un nodo de bitcoin es, a efectos prácticos, un servidor que acepta conexiones de desconocidos. Precisamente esa es la parte del sistema donde está el fallo.

Qué falla exactamente

El fallo entró en el núcleo 4.4 y el registro oficial da por corregidas estas series estables [2].

El equipo de CVE del núcleo le asigna una puntuación de 9,8 sobre 10, la máxima franja, porque se alcanza desde la red, con poca complejidad y sin privilegios [2]. La agencia estadounidense NVD todavía no ha publicado su propia valoración [3]. Red Hat la califica de crítica [6], y Amazon, que ya ha corregido sus núcleos, la deja en 8,1 al considerar alta la complejidad del ataque [22]. El fallo de base no afecta a las conexiones por IPv6, según el propio aviso [1].

Qué demostró Anthropic

El ataque que describe Anthropic se dirige a servidores con un servicio que escucha por MPTCP, una extensión de TCP que permite repartir una misma conexión entre varias redes a la vez [4]. Tiene dos fases. Primero aprovecha la carrera para que el núcleo devuelva al atacante unos bytes de su memoria, hasta que entre ellos aparece una dirección que delata cómo está organizado. Después usa el mismo fallo para desviar la ejecución hacia una orden elegida por el atacante, que corre como root [4].

Un dato rebaja el dramatismo y otro lo sube. En su prueba, el ataque tardó 48 minutos en obtener la primera dirección de memoria y otros cinco en llegar a ejecutar la orden [4]. Pero perder la carrera solo hace fallar ese intento de conexión, sin tumbar el sistema, así que el atacante puede repetir cuantas veces quiera [4]. La publicación describe el método y no incluye el código del ataque. A 30/10/2026, el catálogo de vulnerabilidades explotadas de la agencia estadounidense CISA no recogía este fallo, según la consultora CIQ [15].

Por qué importa el MPTCP en un nodo de bitcoin

El equipo de seguridad de Go avisó el 29/10/2026 de que, desde la versión 1.24 del lenguaje, los programas en Go abren por defecto sus puertos de escucha con MPTCP en Linux [5]. LND, el software Lightning más extendido, está escrito en Go. Sus desarrolladores reconocen en las notas de la versión 0.21.6 que las versiones 0.21.x exponían así su puerto de pares, el 9735, y sus puertos gRPC y REST [13].

El mismo equipo de Go deja claro que el fallo de fondo no es exclusivo de MPTCP y que sistemas sin ningún servicio de este tipo podrían ser vulnerables a ataques parecidos [5]. Red Hat va en la misma línea. Afecta a cualquier sistema con un núcleo vulnerable y TCP por IPv4, y los que aceptan conexiones entrantes son los más expuestos [6]. Las pruebas de CIQ lo confirman en la práctica, porque con MPTCP desactivado un servicio TCP corriente seguía procesando las opciones IP que el ataque necesita [15].

Bitcoin Core está escrito en C++ y el aviso de Go no le alcanza. Aun así, un puerto 8333 abierto a internet sigue siendo una puerta TCP como cualquier otra.

Quién está expuesto de verdad

Ordenado de más a menos riesgo, según lo que dicen las fuentes y nuestra lectura de ellas.

1. Un VPS o un servidor con IP pública. Todos sus puertos de escucha están al alcance de cualquiera. Si además corre LND con una versión anterior a la 0.21.6 o la 0.20.7, cumple las condiciones del ataque demostrado [13].
2. Un nodo en casa con puertos abiertos en el router. El 8333 de Bitcoin Core, el 9735 de Lightning o el 50002 de un servidor Electrum. El nodo Lightning que anuncia una dirección IP pública aparece además en el listado público de la red, como recuerda la incidencia que abrió el problema en LND [14].
3. Un nodo en casa que solo usa Tor. Desde internet, nadie puede enviarle paquetes directamente. Un desarrollador de la comunidad de Start9 y Umbrel considera que estos nodos no están al alcance de este ataque [21]. Ojo, porque sí lo está para cualquier equipo de tu red local, desde un portátil infectado hasta un aparato doméstico mal protegido.

En cualquier caso, ninguna de las fuentes oficiales ofrece una excepción. Todas acaban en el mismo sitio, actualizar el núcleo y reiniciar.

Cómo saber qué núcleo tienes

En cualquier Linux, desde una terminal o por SSH.

uname -r
uname -v

El primer comando da la versión del núcleo. El segundo, en Debian y en Raspberry Pi OS, suele incluir además la versión exacta del paquete, que es la que hay que comparar con el aviso de la distribución. En Debian también puedes ver los paquetes instalados.

dpkg -l 'linux-image*' | grep ^ii

Ojo con comparar a ciegas con la tabla de versiones del núcleo. Ubuntu y Red Hat numeran sus núcleos a su manera y corrigen fallos sin cambiar la versión principal, así que un 6.8.0 de Ubuntu o un 5.14.0 de Red Hat dicen poco por sí solos. En esos casos manda el aviso de cada distribución.

Para saber si tu sistema tiene MPTCP activo y qué programas lo usan, CIQ y LND proponen estas dos órdenes [13][15].

sysctl net.mptcp.enabled
sudo ss -Mltnp

Un 1 en la primera significa que los servicios pueden aceptar MPTCP. La segunda lista los puertos de escucha que lo usan. Si el sistema responde que la clave no existe, tu núcleo no tiene MPTCP y ese camino concreto no está abierto [13].

Situación de cada sistema a 31/10/2026

Desliza la tabla →

Cómo actualizar en cada plataforma

Debian, Ubuntu y Raspberry Pi OS. Es el procedimiento habitual de paquetes, seguido de un reinicio, porque el núcleo nuevo no entra en funcionamiento hasta que la máquina arranca con él.

sudo apt update
sudo apt full-upgrade
sudo reboot

Tras el reinicio, repite uname -r y uname -v para comprobar que el núcleo cargado es el corregido. En Ubuntu, la herramienta oficial pro permite preguntar por un CVE concreto y aplica el arreglo cuando ya existe. A 31/10/2026 no hay paquete corregido, así que conviene repetirlo en los próximos días.

pro fix CVE-2026-98432

Red Hat, Rocky y AlmaLinux. Cuando salga el núcleo corregido, CIQ indica actualizarlo y reiniciar, y después comprobar que el registro de cambios del núcleo en marcha menciona el CVE [15].

sudo dnf update kernel*
sudo reboot
rpm -q --changelog kernel-core-$(uname -r) | grep -c CVE-2026-98432

Si el último comando devuelve 0, el núcleo cargado todavía no trae el arreglo.

Raspberry Pi con RaspiBlitz o myNode. Las Raspberry Pi usan los núcleos que publica la propia fundación, en su rama 6.18 en la imagen del 06/10/2026, que trae la 6.18.50 [23]. La primera corregida de esa serie es la 6.18.56 [2]. RaspiBlitz y myNode no habían publicado ningún aviso sobre este fallo que hayamos podido encontrar a 31/10/2026. Antes de actualizar paquetes del sistema por tu cuenta, consulta la documentación de tu distribución de nodo.

Umbrel. El sistema se actualiza desde los ajustes de la propia interfaz, y la corrección tiene que llegar en una versión de umbrelOS. A 31/10/2026 no existe. Hay una incidencia abierta desde el 30/10 en su repositorio, en la que un usuario cuenta que su equipo corre el núcleo 6.12.96, anterior al arreglo, y que apt no ofrece uno más nuevo [16]. La app Lightning de su tienda seguía en LND 0.21.5-beta.rc1, anterior a la versión que desactiva MPTCP [18].

Start9. Lo mismo, el arreglo tiene que llegar con una versión de StartOS. Un usuario del foro oficial informó el 30/10 de que la 0.4.0.4 corre el núcleo 7.2.9, y la primera corregida de esa serie es la 7.2.10 [19][2]. Las notas de la 0.4.1, publicada el 31/10, no mencionan el núcleo ni el CVE [20].

Mientras llega el parche

Hay dos medidas con respaldo oficial. Ninguna sustituye a la actualización.

Si usas LND, actualiza a la 0.21.6 o a la 0.20.7. Las dos salieron en la noche del 30 al 31/10/2026 y desactivan los puertos MPTCP de LND por defecto [13]. Sus desarrolladores piden además desactivar MPTCP en todo el sistema, porque esa versión no protege al resto de servicios de la máquina.

sudo sysctl -w net.mptcp.enabled=0
echo 'net.mptcp.enabled = 0' | sudo tee /etc/sysctl.d/90-disable-mptcp.conf

El primer comando lo aplica al momento y el segundo lo mantiene tras reiniciar. Las notas de LND advierten de que el ajuste es por espacio de red, así que no llega solo a un LND que corre dentro de Docker, como en Umbrel [13]. Si no puedes actualizar todavía, LND indica arrancar el programa con la variable GODEBUG=multipathtcp=0 [13].

Filtrar las opciones IP en el cortafuegos. El boletín de Red Hat propone una regla de nftables que descarta los paquetes TCP por IPv4 con opciones IP, justo lo que necesita el atacante. Según Red Hat, el tráfico normal no debería notarlo, porque las opciones habituales de TCP viajan en otra cabecera, aunque pide probarla antes [6]. Se guarda este contenido en un fichero llamado cve-2026-98432.nft.

table inet cve_2026_98432 {
    chain input {
        type filter hook input priority -310; policy accept;
        ip protocol tcp ip hdrlength > 5 counter drop
    }
}

Y se comprueba y se aplica así [6].

sudo nft --check --file cve-2026-98432.nft
sudo nft --file cve-2026-98432.nft
sudo nft list table inet cve_2026_98432

Cuando el núcleo ya esté corregido, se retira con una sola orden [6].

sudo nft delete table inet cve_2026_98432

Esta regla actúa sobre el tráfico que entra al propio sistema. Para los puertos publicados por contenedores Docker, las notas de LND remiten a una regla en la etapa previa del cortafuegos que, según el equipo, cubre todos los espacios de red [13][14].

sudo iptables -t raw -I PREROUTING -p tcp -m u32 --u32 "0>>24&0xF=6:15" -m comment --comment CVE-2026-98432 -j DROP

Esta regla desaparece al reiniciar. En Umbrel y en Start9, tocar el cortafuegos o los ajustes del sistema por SSH queda fuera de lo que esos sistemas gestionan por sí solos, así que hazlo solo si te manejas con soltura. La alternativa más sencilla es cerrar en el router los puertos abiertos hacia el nodo y quedarte solo con Tor hasta que llegue la actualización.

Lo que está en juego, y lo que no

Un atacante con root en la máquina del nodo puede leer todo lo que hay en ella. Ahí entran el monedero de LND, con los fondos de los canales y su saldo en la cadena, cualquier monedero cargado en Bitcoin Core y las credenciales que permiten mover esos fondos desde otras aplicaciones. Es decir, lo que el nodo guarda en caliente.

Lo que no está en esa máquina queda fuera de su alcance. Una semilla que solo existe en un monedero físico y en papel no pasa por el nodo, como recordábamos en nuestra pieza sobre DarkSword, y tampoco se altera la cadena. Tus bitcoins siguen donde estaban, y lo que se protege actualizando es la llave de lo que el nodo guarda en caliente.

No se han publicado indicios concretos para saber si una máquina ha sido atacada. Si tu nodo estuvo expuesto a internet con un núcleo sin corregir y guarda fondos que te importan, la opción prudente, una vez actualizado, es pasar esos fondos a un monedero nuevo creado en otro equipo.

Dos avisos en una semana

Entre el 27 y el 28/10/2026 se conocieron los detalles de dos fallos hallados con ayuda de modelos de lenguaje que tocan de lleno a quien mantiene un nodo. El 28/10/2026 Bitcoin Core publicó tres avisos de seguridad, uno de ellos sobre datos TCP urgentes capaces de tumbar nodos con Windows, macOS o BSD, que en Linux no aplicaba, como contamos en nuestra guía de Bitcoin Core 32.1. Esta vez el fallo está debajo, en el propio Linux, y afecta a cualquier software que escuche en la red.

Hay una lectura tranquilizadora. Anthropic avisó a los responsables del núcleo antes de contar nada, y cuando describió el ataque el arreglo ya estaba en todas las ramas estables [4]. Debian lo empaquetó al día siguiente de publicarse el CVE [9]. Para quien tiene un nodo en casa, el trabajo pendiente cabe en una tarde, comprobar el núcleo, aplicar las medidas que correspondan y estar pendiente de la actualización de su sistema. El caso de Electrum, en el que bastaba actualizar la cartera, está en nuestra pieza sobre la versión 4.8.3.

Fuentes

Entre paréntesis, el tipo de fuente.

1. Equipo de CVE del núcleo de Linux, CVE-2026-98432: ipv4: free inet_opt and ireq_opt after an RCU grace period, lista linux-cve-announce, 15/10/2026. (Primaria, aviso oficial del núcleo)
2. CVE Program, registro de CVE-2026-98432, actualizado el 30/10/2026. Versiones corregidas, puntuación 9,8 y escenario del ataque. (Primaria, registro oficial)
3. NIST, ficha de CVE-2026-98432 en la NVD, consultada el 31/10/2026. (Primaria, base de datos oficial)
4. Anthropic Frontier Red Team, Discovering and exploiting vulnerabilities in critical, real-world software with Claude, 27/10/2026. (Primaria, publicación de quien halló el ataque)
5. Equipo de seguridad de Go, Protecting against CVE-2026-98432, reenviado a la lista oss-security, 29/10/2026. (Primaria, aviso oficial del lenguaje)
6. Red Hat, RHSB-2026-016 Use-after-free - kernel IPv4 (CVE-2026-98432), 30/10/2026. Gravedad, alcance y regla de nftables. (Primaria, boletín oficial)
7. Red Hat, ficha de CVE-2026-98432, consultada el 31/10/2026. Productos afectados. (Primaria, registro oficial)
8. Debian, rastreador de seguridad, CVE-2026-98432, consultado el 31/10/2026. (Primaria, registro oficial)
9. Debian, DSA-6568-1 linux security update, 16/10/2026. (Primaria, aviso oficial)
10. Debian LTS, DLA-4841-1 linux security update, 17/10/2026. (Primaria, aviso oficial)
11. Debian LTS, DLA-4850-1 linux-6.12 security update, 22/10/2026. (Primaria, aviso oficial)
12. Canonical, Ubuntu, CVE-2026-98432, actualizada el 30/10/2026 y consultada el 31/10/2026. (Primaria, registro oficial)
13. LND, notas de la versión 0.21.6 y publicación de la 0.20.7, 30-31/10/2026. (Primaria, repositorio oficial)
14. LND, incidencia #11455, Disable MPTCP on listeners by default, 30/10/2026. Regla de cortafuegos para todos los espacios de red. (Primaria, repositorio oficial)
15. CIQ, Mitigating CVE-2026-98432 on Rocky Linux 8, 9, 10, and LTS Variants, 30/10/2026. (Primaria, base de conocimiento del fabricante)
16. Umbrel, incidencia #2292, CVE-2026-98432, abierta el 30/10/2026. (Primaria, repositorio oficial, testimonio de usuarios)
17. Umbrel, versiones de umbrelOS, consultadas el 31/10/2026. (Primaria, repositorio oficial)
18. Umbrel, manifiesto de la app Lightning Node, consultado el 31/10/2026. (Primaria, repositorio oficial)
19. Comunidad de Start9, MPTCP exploit (CVE-2026-98432), 30/10/2026. (Secundaria, foro oficial, testimonio de usuarios)
20. Start9, notas de StartOS 0.4.1, 31/10/2026. (Primaria, repositorio oficial)
21. PaulsCode, Linux kernel bug CVE-2026-98432 and your Lightning node, 30/10/2026. (Secundaria, foro de un desarrollador de la comunidad)
22. Amazon Linux, CVE-2026-98432, actualizada el 30/10/2026. (Primaria, registro oficial)
23. Raspberry Pi, notas de Raspberry Pi OS, imagen del 06/10/2026. (Primaria, notas oficiales)

Más en Privacidad y autocustodia

Actualidad

Chainalysis confirma que un atacante con técnicas de IA accedió a nombres, correos y roles de sus clientes

Actualidad

Un cliente de Indonesia denuncia un implante espía en un Trezor comprado a CryptoBilis

Actualidad

Coinbase atribuye a su proveedor Amplitude la exposición de datos de contacto de algunos clientes

Ver los 30 artículos de Privacidad y autocustodia →

Última actualización: 31 de octubre de 2026