Core Lightning recomendó instalar la versión 26.06.10 para corregir fallas en canales, pagos y comandos remotos. La actualización también reaviva una tarea clave para los operadores: revisar y restringir las credenciales que permiten controlar sus nodos.
***
- La versión 26.06.10 incorpora verificaciones de firmas para la apertura de canales con doble financiación y el splicing, además de correcciones para pagos y límites de canal.
- Core Lightning también cierra fallas en commando, el mecanismo que permite a pares conectados solicitar la ejecución de comandos con credenciales llamadas runes.
- Los mantenedores aconsejan vincular esos runes al nodo autorizado y reemplazar o bloquear las credenciales que los operadores no puedan justificar.
⚡ Core Lightning pide actualizar los nodos a la v26.06.10
Corrige fallas en canales, pagos y comandos remotos.
Los mantenedores recomiendan revisar los runes y bloquear credenciales no justificadas.
El aviso no reporta explotación ni pérdidas confirmadas. pic.twitter.com/hBtM0m0oma
— Diario฿itcoin (@DiarioBitcoin) November 6, 2026
Core Lightning refuerza sus canales y pide revisar las credenciales remotas
Core Lightning recomendó a los operadores instalar cuanto antes la versión 26.06.10, una actualización que corrige problemas de seguridad en canales de Bitcoin Lightning, resolución de pagos y comandos remotos. El aviso de los mantenedores abarca tanto cambios en el software como medidas de administración de acceso, por lo que actualizar el nodo no reemplaza la revisión de las credenciales que permiten interactuar con él.
La publicación no afirma que estas fallas hayan sido explotadas ni que se hayan vaciado canales en la práctica. Según la información difundida por CryptoSlate, los mantenedores retuvieron temporalmente detalles de las correcciones de seguridad para dificultar que terceros conviertan los parches en exploits funcionales y dar más tiempo a los operadores para actualizarse.
Qué corrige la actualización en los canales
La versión agrega verificaciones de las firmas de transacciones de la contraparte durante la apertura de canales con doble financiación y el splicing, dos operaciones que permiten gestionar la financiación o modificar la capacidad de un canal. El changelog de Core Lightning señala que las comprobaciones siguen BOLT 2, una especificación del protocolo Lightning que establece reglas para la interacción entre los participantes de un canal.
Otra corrección aborda la resolución de pagos mediante HTLC, contratos condicionales que permiten completar pagos en Lightning si se cumplen ciertas condiciones. Un HTLC que acababa de eliminarse podía confundirse con otro aún activo cuando ambos compartían hash de pago, monto y vencimiento; en ese escenario, el nodo podía fallar el pago activo aguas arriba aunque su contraparte todavía tuviera la posibilidad de reclamarlo.
Ese comportamiento no equivale necesariamente a que un canal haya sido drenado, pero sí podía alterar el resultado de un pago y dejar al operador ante una situación que la corrección busca evitar. La distinción importa: la información disponible describe un fallo técnico y su parche, no evidencia de pérdidas confirmadas ni de ataques consumados contra usuarios de Lightning.
La actualización también endurece las reglas sobre los límites de polvo, que fijan cantidades mínimas para que ciertos montos puedan incluirse de manera útil en transacciones. El nodo ahora rechaza aperturas si un par propone un límite superior a 5.000 satoshis; el changelog indica que el comportamiento previo podía permitir que la contraparte convirtiera el saldo del nodo en comisiones durante un cierre forzado.
Reglas adicionales para financiar y cerrar canales
En canales con doble financiación, la versión también rechaza el límite de polvo de la contraparte cuando supera la reserva del canal. Esa medida busca evitar que un parámetro propuesto por el otro participante deje al nodo en una posición vulnerable frente a las condiciones de gasto de una transacción de cierre.
La doble financiación sigue siendo experimental, según los mantenedores, que desaconsejan usar canales de confirmación cero con pares no confiables. En este tipo de configuración, las partes pueden operar antes de que la financiación alcance confirmaciones en la cadena; por eso, aceptar contrapartes sin confianza añade riesgos que la actualización no elimina por sí sola.
Core Lightning también cambia el tratamiento de las aperturas v2 de confirmación cero: el nodo las rechazará salvo que el operador haya configurado expresamente su aceptación para ese par. La regla deja la decisión en manos de quien administra el nodo, pero evita que esa modalidad se acepte sin una configuración deliberada.
Los operadores deben considerar además las limitaciones para volver a versiones anteriores. Quienes hayan ejecutado la rama master no pueden retroceder a la serie 26.06.x, porque el esquema de su base de datos es más reciente; en consecuencia, la actualización requiere tener en cuenta el estado del software y de la base de datos del nodo, no solo instalar un paquete y asumir que la reversión estará disponible.
Comandos remotos y revisión de credenciales
La otra superficie importante es commando, la interfaz que permite a un par conectado directamente solicitar que un nodo ejecute un comando. Por lo general, ese par necesita un rune, una credencial de autorización que define qué acciones puede solicitar; por ello, la seguridad depende tanto de las correcciones del programa como de los permisos que los operadores hayan concedido.
La versión 26.06.10 impide una forma de eludir restricciones de runes sobre nombres de parámetros duplicados o escritos con variantes de puntuación. También corrige un fallo de commando provocado por reutilizar el identificador de un comando después de que otro hubiera fallado, y rechaza runes excesivamente grandes que podían exigir un trabajo cuadrático para decodificarse.
Los mantenedores recomiendan vincular cada rune utilizado por commando al identificador del nodo de la aplicación autorizada mediante una restricción de ID. Además, aconsejan bloquear con la función blacklistrune las credenciales que el operador no pueda justificar y emitir reemplazos con restricciones más estrictas, en vez de dejar en uso permisos cuyo origen o alcance no esté claro.
Estas prácticas complementan el parche, pero no permiten concluir que todas las credenciales existentes ya estén restringidas correctamente. La recomendación exige una revisión propia: identificar qué aplicaciones están autorizadas, verificar a qué nodo corresponde cada permiso y retirar los runes que no puedan atribuirse a un uso legítimo.
Disponibilidad y pasos para los operadores
Los mantenedores recomendaron actualizar a la v26.06.10 lo antes posible y señalaron que la versión ya estaba disponible. El registro presenta una pequeña diferencia de fecha: GitHub muestra el 4 de noviembre para el lanzamiento, mientras que el changelog etiquetado asigna el 5 de noviembre a la misma versión.
La publicación llega después de la versión 26.06.9, que también incluyó correcciones de seguridad, y de un fallo independiente relacionado con un disparador almacenado, reportado el 2 de noviembre. Estos antecedentes forman parte de la secuencia de mantenimiento de Core Lightning; no deben confundirse con las vulnerabilidades específicas que la nueva versión aborda.
Para los operadores, las medidas concretas son instalar la actualización, revisar las credenciales de commando y confirmar que las configuraciones de apertura de canales reflejen el nivel de confianza en cada par. También conviene tener presente que el soporte para doble financiación continúa en fase experimental y que la aceptación de aperturas de confirmación cero debe responder a una decisión explícita.
El alcance del aviso es preventivo: documenta correcciones de software y recomendaciones operativas, pero no demuestra que cada nodo estuviera expuesto de la misma manera ni que se haya producido una explotación. Separar el riesgo técnico confirmado de las consecuencias no verificadas permite entender la urgencia del parche sin presentar como hecho un vaciamiento de canales que la información disponible no reporta.
Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público.
Este artículo fue escrito por un redactor de contenido de IA y revisado por un editor humano para garantizar calidad y precisión.
ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.
Suscríbete a nuestro boletín
Artículos Relacionados
Criptomonedas
Gate informa cobertura en frío de 104,58%, pero las fechas separadas dejan dudas
Blockchain
Optimism propone 30 días de aviso antes de ceder el control de actualizaciones
Empresas
Apple habría ocultado miles de frases a su teclado predictivo, según un investigador
Binance
