La actualización de seguridad de Bitcoin Lightning cierra una puerta, pero un fallo crítico de Linux permanece sin resolver
La actualización de Bitcoin Lightning aborda vulnerabilidades de seguridad, pero los fallos críticos del kernel de Linux permanecen sin corregir, dejando a los operadores en riesgo.
Vulnerabilidad Crítica en Bitcoin Lightning
Los operadores de Bitcoin Lightning que ejecutan un kernel de Linux afectado y sin parches siguen expuestos a una vulnerabilidad crítica tras actualizar LND, el software utilizado para operar sus nodos de pago. Las versiones del 30 de octubre, v0.20.7-beta y v0.21.6-beta, desactivan los oyentes de Multipath TCP (MPTCP) por defecto, lo que cierra la ruta demostrada CVE-2026-98432 a través de esos oyentes.
Detalles de la Vulnerabilidad
Sin embargo, el fallo del kernel permanece y no cubre otros servicios en la misma máquina. Otro servicio MPTCP expuesto en la misma máquina sin parches puede preservar la ruta demostrada, incluso después de que los oyentes por defecto de LND hayan sido modificados. Este fallo implica el uso de memoria liberada durante el manejo de conexiones TCP IPv4 en Linux y puede permitir a un atacante ejecutar código en un host afectado. Ubuntu le asigna una puntuación crítica de CVSS 3.1 de 9.8.
Las notas del operador de LND indican que Go 1.24 y versiones posteriores habilitaron oyentes MPTCP por defecto en Linux, lo que LND 0.21.x expuso en sus puertos de pares, gRPC y REST. Estos incluyen las conexiones del nodo a otros nodos y sus interfaces de aplicación. El aviso del Equipo de Seguridad de Go explica por qué ese cambio no puede completar la tarea.
Explotación y Recomendaciones
La explotación demostrada requiere un oyente MPTCP expuesto, pero el error del kernel es más amplio.
Ataques similares contra sistemas sin oyentes MPTCP pueden ser posibles; el aviso no establece una explotación no MPTCP demostrada. Go también advierte que deshabilitar MPTCP un programa a la vez es frágil. Un único oyente expuesto restante deja al sistema vulnerable a esa ruta, y la configuración de socket explícita puede anular la configuración por defecto de Go.
Los avisos describen una explotación demostrada de Linux, pero no hay evidencia de que los atacantes hayan utilizado este fallo contra nodos LND o hayan robado Bitcoin. CryptoSlate cubrió anteriormente las implicaciones de la misma CVE para los validadores de Solana.
Estado de los Parches y Actualizaciones
Las correcciones del canal Core Lightning y de comandos remotos reportadas el 6 de noviembre se refieren a fallos de aplicación separados. El rastreador de Ubuntu, revisado el 9 de noviembre y actualizado por última vez el 7 de noviembre, aún etiquetaba el paquete estándar de Linux para Ubuntu 24.04 LTS como vulnerable, con trabajo en progreso en 6.8.0-149.149.
Su entrada para Ubuntu 22.04 LTS tenía el mismo estado para 5.15.0-203.213. La disponibilidad de parches varía según el paquete. En su aviso del 2 de noviembre, Canonical dijo que las correcciones del kernel para esta CVE estaban disponibles en el repositorio -proposed para usuarios que ejecutan sus propias pruebas de aceptación del kernel, mientras que las pruebas de calificación continuaban.
Recomendaciones para los Operadores
Los mantenedores de LND recomiendan actualizar la aplicación, deshabilitar MPTCP en el host e instalar un kernel parcheado tan pronto como la distribución lo haga disponible. Su guía utiliza el comando sudo sysctl -w net.mptcp.enabled=0 para la configuración del host, con una configuración persistente para mantenerlo.
La configuración se aplica por espacio de nombres de red, por lo que las implementaciones de Docker necesitan atención separada a la configuración de red del contenedor. Cambiar solo el host no es un sustituto para verificar ese alcance.
Los operadores que no pueden actualizar LND de inmediato pueden iniciar su binario existente con GODEBUG=multipathtcp=0 para deshabilitar los oyentes MPTCP por defecto de Go. Los mantenedores advierten contra reactivar ese valor por defecto antes de parchear el kernel.
Canonical aconseja verificar el kernel que realmente se está ejecutando con uname -r. Después de instalar su actualización de seguridad del kernel, se requiere un reinicio. Un binario LND actualizado y un paquete de kernel instalado son hitos diferentes; completar la reparación del sistema operativo requiere ejecutar el kernel parcheado.