Lightning Network: LND cierra una vía de ataque, pero una falla crítica del kernel Linux sigue abierta

Los operadores de nodos de Lightning Network que usan LND tienen una tarea pendiente que va más allá de actualizar el software. Las versiones publicadas el 30 de octubre bloquean una ruta de explotación ya demostrada contra una vulnerabilidad del kernel de Linux vinculada a MPTCP. Sin embargo, la falla de fondo sigue presente en el sistema operativo hasta que cada servidor instale un kernel corregido y se reinicie.

El matiz importa. Un parche en la aplicación reduce la exposición, pero no elimina el error en la capa inferior. Cualquier otro servicio expuesto en esa misma máquina podría seguir siendo una puerta de entrada.

Publicidad

Estabilidad respaldada en Bitcoin

Descubre Dollar on Chain →

Qué corrigen las nuevas versiones de LND

Lightning Labs, el equipo detrás de LND (Lightning Network Daemon, la implementación más usada de la red de pagos de segunda capa de Bitcoin), publicó dos actualizaciones en paralelo: v0.20.7-beta y v0.21.6-beta. Lanzar parches para dos ramas a la vez permite que los nodos que todavía no migraron a la serie más reciente también queden cubiertos.

Ambas versiones cierran el camino concreto por el que se demostró que la vulnerabilidad podía explotarse a través de un nodo LND. Las notas para operadores de la versión 0.21.6 recogen los cambios y las indicaciones para quienes administran nodos.

Conviene leerlo con precisión: LND no repara Linux. Lo que hace es dejar de ofrecer esa vía de acceso al atacante. El error en el kernel continúa ahí.

El problema de fondo: MPTCP y el kernel de Linux

MPTCP (Multipath TCP) es una extensión del protocolo TCP que permite que una misma conexión use varias rutas de red al mismo tiempo, por ejemplo, wifi y datos móviles. Está integrada en el kernel de Linux, el núcleo del sistema operativo, y ahí reside la vulnerabilidad registrada como CVE-2026-98432.

El rastreador de seguridad de Ubuntu mantiene el seguimiento del fallo en sus distintas versiones. Canonical publicó además un aviso el 2 de noviembre en el que informó que las correcciones están disponibles en el repositorio «proposed», el canal donde Ubuntu deja las actualizaciones en fase de prueba antes de distribuirlas de forma general. El tema también figuró en el boletín semanal de Ubuntu del 1 al 7 de noviembre.

Que el parche esté en «proposed» tiene consecuencias prácticas. Un servidor configurado para recibir solo las actualizaciones estables no lo instalará automáticamente. El administrador debe habilitar ese canal de forma deliberada o esperar a que la corrección pase a los repositorios habituales.

Por qué hace falta reiniciar

Actualizar el paquete del kernel no basta. El sistema sigue ejecutando el kernel antiguo, el vulnerable, hasta que la máquina se reinicia. Para un nodo de Lightning Network eso implica una breve desconexión, algo que muchos operadores evitan porque sus canales quedan inactivos durante ese tiempo y pueden perder enrutamientos de pagos.

Ese costo operativo explica por qué este tipo de fallos suele quedar abierto más tiempo del deseable en servidores de producción.

Qué deben revisar los operadores de Lightning Network

La recomendación que se desprende de las publicaciones de LND y de Ubuntu tiene dos pasos y ninguno sustituye al otro:

• Actualizar LND a v0.20.7-beta o v0.21.6-beta, según la rama que use el nodo.
• Instalar un kernel de Linux corregido para CVE-2026-98432 y reiniciar el equipo para que entre en funcionamiento.

Quienes ejecutan nodos en otras distribuciones de Linux deberían consultar los avisos de seguridad de su proveedor, ya que la falla está en el kernel y no es exclusiva de Ubuntu. Los servicios de nodo administrado y las plataformas de tipo «node in a box» dependen, a su vez, de que sus desarrolladores integren el kernel corregido en sus imágenes.

Una red de pagos que depende de servidores comunes

El episodio recuerda una realidad poco visible de Lightning Network: buena parte de su infraestructura corre en servidores Linux convencionales, alquilados en la nube o instalados en casa. La seguridad de los fondos en canales depende tanto del software del nodo como del sistema operativo, la red y la configuración del equipo que lo aloja.

Esa superficie de ataque amplia preocupa a los grandes tenedores. Algunas ballenas de bitcoin han optado por el IBIT de BlackRock ante el temor a hackeos, mientras incidentes recientes como el de Mercado Bitcoin, que aún no tiene fecha para reanudar retiros, muestran el costo de una brecha en plataformas con activos en línea.

En el caso de LND, la respuesta rápida del equipo de desarrollo redujo el riesgo inmediato. El cierre definitivo, en cambio, queda en manos de cada operador y de cuándo decida reiniciar su máquina.