LNbits lanza la actualización de seguridad urgente 1.7.0 tras los ataques del 8 de noviembre
Puntos clave
- •LNbits lanzó la versión 1.7.0 el 10 de noviembre como una actualización de seguridad urgente tras los ataques del 8 de noviembre; todas las versiones anteriores a la 1.7.0 están afectadas y los fondos sobre versiones previas corren riesgo de robo.
- •El operador Kevin Ravensberg reportó que los atacantes abrieron cuentas nuevas en su instancia de BitTipBot y retiraron 2.285.545 satoshis, aproximadamente 0,0229 BTC, entre aproximadamente las 09:22 y las 14:00 UTC del 8 de noviembre.
- •Como la actualización no revoca el acceso que un atacante ya pueda tener, LNbits indica a los operadores preservar los registros, desplegar un servidor nuevo con la 1.7.0, rotar la clave privada de cada wallet de usuario, reemitir las credenciales de la fuente de financiamiento y reconstruir las conexiones de extensiones.
- •La versión 1.7.0 refuerza la autenticación, la gestión de extensiones y el manejo de pagos junto con actualizaciones de dependencias, y añade funciones como soporte de wallet on-chain, pagos con ofertas BOLT12, autenticación de dos factores TOTP y soporte de facturas de retención.
- •La vulnerabilidad no ha sido nombrada y no se ha publicado ningún total agregado de pérdidas; LNbits confirmó que se publicará un informe técnico completo y no afirmó ningún compromiso de la red Bitcoin ni del protocolo Lightning.

LNbits lanza la actualización de seguridad urgente 1.7.0 tras los ataques del 8 de noviembre
LNbits, la plataforma de código abierto de wallets Lightning y cuentas, lanzó la versión 1.7.0 el 10 de noviembre como una actualización de seguridad urgente, e instruyó a todos los operadores a instalar el parche antes de volver a poner en línea sus servidores. La cuenta oficial de X del proyecto describió el lanzamiento como una "SECURITY UPDATE" y dirigió a los operadores a las notas de la versión en GitHub para ver la lista completa de cambios.
Fundado en 2019 por Ben Arc como un proyecto libre y de código abierto, LNbits ofrece cuentas multiusuario y una amplia gama de extensiones sobre cualquier fuente de financiamiento Lightning, incluidos LND y Core Lightning. Se implementa tanto en instalaciones autoalojadas como a través de instancias administradas.
Los ataques comenzaron el 8 de noviembre
La cronología del incidente comenzó durante el fin de semana. El 8 de noviembre, el proyecto instó públicamente a los usuarios a apagar sus servidores de inmediato, indicando que prefería actuar con cautela mientras se preparaban los parches de seguridad. LNbits también desactivó todas las instancias de su propio servicio alojado.
Los reportes de operadores describieron la creación de cuentas no autorizadas seguida de retiros de los saldos de los usuarios. Kevin Ravensberg, que opera el servicio de propinas de Telegram BitTipBot, reportó que los atacantes abrieron cuentas nuevas en su instancia y retiraron 2.285.545 satoshis —aproximadamente 0,0229 Bitcoin (BTC)— entre aproximadamente las 09:22 y las 14:00 UTC del 8 de noviembre.
Según la guía oficial de actualización publicada junto con el lanzamiento, todas las versiones anteriores a la 1.7.0 están afectadas, y los fondos que funcionen sobre versiones previas corren riesgo de robo. El equipo confirmó que la 1.7.0 contiene correcciones en respuesta al incidente descubierto el 8 de noviembre y dijo que se publicará un informe técnico completo sobre el exploit. El anuncio no nombra la vulnerabilidad, y no se ha publicado ningún total agregado de pérdidas entre las instancias afectadas.
Rotación de claves y reconstrucción de servidores comprometidos
Instalar el parche y recuperarse de un compromiso son tareas separadas. LNbits advirtió que la actualización no revoca automáticamente ningún acceso que un atacante ya haya obtenido, lo que significa que un servidor actualizado puede seguir siendo inseguro si fue tocado durante la ventana del ataque. La guía dirige a los operadores que sospechen de una brecha a preservar primero los registros y archivos, y luego desplegar un servidor nuevo con la versión 1.7.0 en lugar de confiar en la máquina antigua. Conservar esos registros es importante para la investigación forense posterior, ya que el informe técnico prometido se basará en evidencia de la ruta de ataque.
Desde el servidor nuevo, el Super Admin debe rotar la clave privada de la wallet de cada usuario, lo que invalida la clave antigua, y cada aplicación conectada debe actualizarse con la clave de reemplazo. Las credenciales de la fuente de financiamiento, como las API keys o los macaroons, deben revocarse y reemitirse en la fuente, y otros secretos almacenados en la configuración del servidor también deben rotarse. Las conexiones de extensiones existentes —incluidas NWC Provider, LNDHub, Bolt Cards, TPOS, Bleskomat y FOSSA— deben eliminarse y reconstruirse con las nuevas credenciales.
Qué cambia en la versión 1.7.0
Las notas de la versión describen mejoras de seguridad en autenticación, gestión de extensiones y manejo de pagos, junto con actualizaciones de dependencias, aunque el cambio específico que cierra la ruta de ataque aún no se ha hecho público. La versión 1.7.0 también introduce nuevas funciones: soporte de wallet on-chain, pagos con ofertas BOLT12, autenticación de dos factores TOTP, soporte de NIP-17, un programador de tareas, actualizaciones automáticas de extensiones y soporte de facturas de retención (hold invoice) para la fuente de financiamiento de LNbits.
El registro de incidentes de SlowMist enumera la misma cifra de 2.285.545 satoshis como un caso de pérdida en una sola instancia, y el anuncio no afirma ningún compromiso de la red Bitcoin ni del protocolo Lightning mismo. El daño confirmado hasta ahora recae en los servidores de los operadores, no en la capa del protocolo.
Según COINOTAG, la causa raíz no revelada es el aspecto más crítico de esta historia. LNbits funciona por diseño como una hot wallet, y la guía oficial indica a los operadores mantener en línea solo los saldos operativos mientras mueven el excedente a claves fuera de línea. Hasta que el informe técnico prometido identifique la ruta de ataque, cada instancia sin parchear o recién actualizada debe tratarse como un objetivo potencial: es la razón por la que el parche llega junto con un procedimiento completo de rotación de credenciales.
El informe original fue publicado por COINOTAG.