Lightning Labs lanza una mitigación en LND para una vulnerabilidad crítica del kernel de Linux
SeguridadLayer 2
Neutral

Lightning Labs lanza una mitigación en LND para una vulnerabilidad crítica del kernel de Linux

Lightning Labs publicó LND v0.21.6-beta y v0.20.7-beta para desactivar por defecto los listeners de Multipath TCP tras la divulgación de una vulnerabilidad crítica del kernel de Linux, CVE-2026-98432. Las versiones cierran la vía de explotación a través de LND, pero los operadores siguen necesitando un kernel parcheado para resolver por completo el fallo subyacente.

4 nov 20263 min de lectura

Escrito por la redacción de IA de CoinArticle · a partir de 2 fuentes citadas. Cómo trabajamos

Qué ocurrió

Lightning Labs publicó versiones de emergencia de su software de nodos Lightning LND el 30 de octubre, lnd v0.21.6-beta y la versión retroportada v0.20.7-beta, para desactivar por defecto los listeners de Multipath TCP (MPTCP). El cambio responde a CVE-2026-98432, un fallo en el código de handshake TCP IPv4 del kernel de Linux que tiene una puntuación de gravedad CVSS de 9,8. Lightning Labs describió la versión como una mitigación y no como una solución definitiva.

El fallo fue señalado el mismo día por Matt Corallo, desarrollador de Bitcoin Core y Lightning, quien criticó la respuesta tardía de Ubuntu, y por Peter Todd, quien aconsejó a los operadores que ejecutan LND en Linux con puertos abiertos que apagaran sus nodos hasta que el kernel estuviera parcheado o mitigado. El Frontier Red Team de Anthropic ha demostrado que el fallo puede convertirse en un exploit remoto de root contra sistemas que exponen un listener MPTCP. Esa demostración no ha sido publicada.

Por qué LND estaba expuesto

La vía de explotación depende de MPTCP, que Go 1.24 y versiones posteriores activan por defecto. Dado que LND está escrito en Go, las versiones recientes escuchaban con MPTCP en sus puertos de peers, gRPC y REST siempre que el kernel del host tuviera activada esta función. Las versiones de LND eliminan esa vía de listener concreta.

La mitigación no cubre el resto de la máquina. Otros servicios del mismo host siguen expuestos hasta que MPTCP se desactive en todo el sistema o se actualice el kernel.

Estado de los parches en las distintas distribuciones

Las fuentes difieren en cuanto al alcance de la corrección del kernel. Bitcoin Magazine informa de que Canonical ha puesto a disposición kernels corregidos en el canal proposed de adhesión voluntaria para Ubuntu 22.04, 24.04 y 26.04, pero todavía no en el canal de actualizaciones habitual. Red Hat distribuyó las correcciones para RHEL 8, 9 y 10 el 1 de noviembre, y Debian y Amazon Linux ya habían publicado parches anteriormente. El informe de The Defiant no aborda el calendario de parches a nivel de distribución.

En despliegues domésticos y embebidos, UmbrelOS 2.0.1 incluyó la corrección del kernel el 1 de noviembre para dispositivos x86. En Raspberry Pi, donde todavía no había un kernel corregido disponible, aplicó en su lugar una mitigación mediante bloqueo de tráfico.

Informes de escaneo y explotación

Bitcoin Magazine informa de que no se ha observado explotación confirmada en entornos reales y de que la vulnerabilidad no se ha añadido al catálogo de Vulnerabilidades Explotadas Conocidas de CISA. También cita al investigador de seguridad Marcus Hutchins, quien encontró alrededor de 2,1 millones de servidores accesibles por MPTCP en el puerto 443 durante un escaneo a nivel de internet, compatible con actores de amenazas que buscan sistemas expuestos. International Cyber Digest amplificó ese hallazgo el 4 de noviembre. La cobertura de The Defiant no incluye los datos del escaneo.

La exposición es mayor en servidores accesibles desde internet con listeners TCP públicos. Según Bitcoin Magazine, los equipos de escritorio domésticos tras NAT y cortafuegos habituales se ven considerablemente menos afectados.

Qué deben esperar los operadores

Los operadores de nodos Lightning en Linux deberían instalar la versión de LND y aplicar un kernel parcheado allí donde esté disponible. Mientras el kernel no se actualice, el cambio en LND elimina una vía de exposición, pero deja el fallo subyacente presente para otros servicios de la misma máquina.

Por qué importa

Para los traders

Los operadores de nodos que todavía no han actualizado LND ni parcheado sus kernels pueden sufrir caídas o interrupciones en los próximos días, así que conviene vigilar las interrupciones a nivel de nodo en los canales Lightning.

Para los inversores

El incidente pone de manifiesto cómo un único fallo a nivel de kernel puede llegar a la infraestructura de Bitcoin a través de un valor por defecto de una dependencia de Go, un riesgo en la cadena de suministro que podría atraer un escrutinio más estrecho sobre las operaciones de nodos Lightning.

Para los desarrolladores

Cualquier servicio en Go que se enlace a interfaces de red debería auditar si MPTCP está activado por defecto en su runtime y desactivarlo explícitamente allí donde no sea necesario el listener.

Este artículo es solo informativo y no constituye asesoramiento financiero. Lee el aviso legal completo.

Artículos relacionados

Últimas noticias