El Lightning Development Kit (LDK), un conjunto de herramientas para desarrollar aplicaciones sobre la red Lightning de Bitcoin, publicó el 9 de septiembre la versión 0.2.6 para corregir dos fallos de seguridad. Uno podía permitir que un participante malicioso desviara pequeñas cantidades de fondos durante una operación de splice; el otro podía impedir que un nodo recuperase su estado guardado al reiniciarse.
La actualización afecta a los equipos que mantienen aplicaciones construidas con LDK, una implementación de Lightning que se integra en productos como monederos móviles o infraestructuras de servicios de pagos. El aviso de lanzamiento no informa de pérdidas observadas ni de aplicaciones explotadas. La descripción identifica las vulnerabilidades y las correcciones, pero no cuantifica un impacto real entre los usuarios.
Un fallo en las operaciones de splice podía desviar comisiones
Un splice permite añadir o retirar fondos de un canal de pago ya existente sin cerrarlo por completo. En términos técnicos, el nodo consume la salida que financia el canal y la sustituye por otra mediante una nueva transacción de financiación. El cambio modifica la cantidad comprometida por las partes en ese canal.
La operación genera costes que se reparten entre los participantes. El nodo que la inicia asume las comisiones correspondientes a determinadas partes comunes de la transacción, además de las asociadas a sus propias entradas y salidas. Por tanto, el cálculo de esas comisiones determina cuánto dinero del nodo se destina a la operación.
El fallo corregido podía permitir que un interlocutor malicioso provocase una asignación excesiva de comisiones. Ese importe adicional terminaría en una salida controlada por el propio interlocutor. La documentación de la versión 0.2.6 señala que el riesgo se limitaba a una pequeña cantidad de fondos cuando el nodo iniciaba un splice, pero no establece un límite numérico.
Un estado imposible de cargar tras un pago manipulado
La segunda vulnerabilidad afectaba a la gestión del estado interno de los canales y los pagos. Podía producirse cuando dos contratos de pago compartían el mismo hash de pago. Después de que uno de ellos se reenviase correctamente, un participante podía enviar otro contrato falso y provocar su rechazo inmediato.
Ese comportamiento podía dejar en un estado inválido al ChannelManager, el componente de LDK encargado de administrar los canales y los pagos. El problema aparecía al reiniciar el nodo: la aplicación debe leer el estado guardado y cargarlo en memoria, un proceso conocido como deserialización. Si ese estado era rechazado durante la carga, el reinicio normal no podía completarse.
El aviso aclara que rechazar el contrato de pago falso no bastaba para evitar este fallo concreto. En consecuencia, la incidencia no se limitaba a una operación individual, sino que podía afectar a la capacidad del nodo para volver a funcionar después de una interrupción o un apagado.
La corrección debe incorporarse a las aplicaciones integradas
LDK se compila dentro de las aplicaciones, mientras que los desarrolladores eligen por separado componentes como el almacenamiento, el monedero, las comunicaciones y la supervisión de la cadena de bloques. Por eso, instalar la versión corregida en los proyectos que utilizan el kit es el paso relevante para las integraciones potencialmente afectadas.
Los dos parches cubren problemas distintos: el primero busca que la asignación de fondos sea correcta cuando cambia la financiación de un canal; el segundo garantiza que el estado conservado pueda recuperarse después del cierre y posterior arranque del nodo. La publicación de la versión 0.2.6 no aporta cifras sobre usuarios afectados ni pérdidas económicas derivadas de estos fallos.
