El Lightning Development Kit (LDK), el conjunto de herramientas para desarrollar aplicaciones sobre la red de pagos 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 nodo desviara pequeñas cantidades de sus fondos durante una operación sobre un canal; el otro podía impedir que recuperase correctamente su estado al reiniciarse.
La actualización está dirigida a los desarrolladores que integran LDK en productos como monederos móviles y servicios de pagos. El kit incorpora una implementación de Lightning dentro de las aplicaciones, mientras que cada equipo decide qué componentes utiliza para el almacenamiento, la gestión del monedero, las comunicaciones y la supervisión de la cadena de bloques.
Un fallo en las operaciones de modificación de canales
La primera vulnerabilidad afectaba a los llamados splices, operaciones que permiten añadir fondos a un canal de pagos o retirarlos sin tener que cerrarlo por completo. En términos técnicos, el nodo gasta la salida que financia el canal y la sustituye por otra transacción de financiación.
El cálculo de las comisiones de esa transacción determina cuánto dinero aporta cada participante a la operación. Según la descripción de la actualización, un interlocutor malicioso podía provocar que se asignase una cantidad excesiva a las comisiones y que ese exceso terminara en una salida controlada por él.
LDK señala que el riesgo afectaba a una cantidad pequeña de fondos cuando el nodo iniciaba un splice, pero no fija un límite numérico. La vulnerabilidad, por tanto, no se presenta como un mecanismo para vaciar por completo un nodo, sino como una vía para desviar parte de los fondos comprometidos en una operación concreta.
Un estado de canal que podía bloquear el reinicio
El segundo problema estaba relacionado con dos contratos de pago que utilizaban el mismo hash de pago. Después de que uno se reenviara correctamente, un nodo podía recibir y rechazar de inmediato otro contrato fraudulento. Esa secuencia podía dejar el estado interno de ChannelManager en una condición que impidiera cargarlo posteriormente.
ChannelManager es el componente de LDK encargado de gestionar los canales y los pagos. Cuando un nodo se reinicia, la aplicación debe recuperar desde el almacenamiento el estado que tenía antes del apagado, un proceso conocido como deserialización. Si ese estado se rechaza durante la carga, el reinicio normal no puede completarse.
La propia acción de rechazar el pago fraudulento no evitaba por sí sola el fallo. De ahí que la corrección sea relevante para las aplicaciones que necesitan mantener operativos sus canales y recuperar su información después de una interrupción.
La actualización recae en las integraciones afectadas
Los dos parches cubren riesgos distintos. El primero busca que la asignación de fondos sea correcta cuando cambia la financiación de un canal; el segundo, que el estado guardado pueda volver a cargarse tras el apagado de un nodo.
Como LDK se compila dentro de las aplicaciones que lo utilizan, la medida de mantenimiento para los equipos afectados consiste en incorporar la versión corregida a sus propias integraciones. El aviso de lanzamiento no informa de pérdidas observadas ni de aplicaciones explotadas. Su contenido identifica las vulnerabilidades y publica las soluciones, pero no cuantifica un impacto real entre los usuarios.
