# LNbank Vulnerability Recap

Last week, a critical vulnerability was identified in the LNbank plugin, which I developed as a plugin for BTCPay Server. This post aims to outline what transpired and steps I, as a maintainer of the plugin, and BTCPay Server team are taking to prevent similar occurrences in the future.

# What is LNbank?

LNbank, is a third-party plugin which allows an administrator of a BTCPay Server, to become custodian and allow users of their server to accept Lightning payments. In essence, LNbank is a custodian wallet system built on top of lightning. As the plugin description says, it enables an “Uncle Jim” mode for your family and friends.

# BTCPay Server plugin system

The Plugin system in BTCPay Server, allows third-party developers to develop and build features into the BTCPay Server without being burdened by the reviews of the core team and processes for the core software. This allows developers to innovate quicker, build out features that may not be planned in the current roadmap for BTCPay Server, and users to have access to personalized features, without being a bottleneck to the core software. The plugins don’t undergo the review by the core team and can be published by anyone.

# What happened?

Between December 7th, Thursday evening and December 8th Friday morning, two reports surfaced via BTCPay Server’s Mattermost and Telegram support channels. They pointed to an urgent security issue in LNbank.

Upon receiving these reports, I immediately began an investigation and was assisted by logs provided by the affected users. These logs uncovered that a malicious actor had actively exploited a flaw to withdraw amounts exceeding their LNbank wallet balance. This was achieved through issuing multiple concurrent payments/withdrawals. Due to timing discrepancies, these requests bypassed the wallet’s balance check, which, although had some safeguards around concurrent requests, were not enough.

Here’s the technical breakdown: if a new request was initiated before the previous withdrawal was recorded in the database, the subsequent balance check used outdated information. This loophole enabled the attacker to repeatedly withdraw their wallet balance, refilling and exploiting it several times, draining substantial liquidity from the Lightning node of a custodian server admin.

# Immediate response and version update

Recognizing the severity of the vulnerability, I released LNbank version 1.8.9 on Friday, December 8th afternoon, less than 24 hours after the report to address it. In BTCPay Server or LNBank plugin, there’s no user tracking, so we had to reach out to active users of our community chats that may be running an instance for other users. Assisted by a few other contributors and community members, we alerted these instances privately and then alerted users about the vulnerability through all our public channels, urging them to update immediately and prioritizing the protection of other users who may be impacted.

# Impact

Impacted are users using LNbank plugin versions older than 1.8.9, especially public servers, that allow anyone (including the malicious attacker) to register on their instance and execute the attack.

# Mitigation

If you’re using LNbank plugin <1.8.9 and have public registration opened to your server immediately update to 1.8.9 to mitigate the vulnerability.

# Future safeguards and enhancements

With regards to LNbank there were already plans to restrict the access to vetted users only, in the light of this event this feature will be prioritized. Prior to this incident work was already started to separate banks and offer hosts more fine-grained access control to them. The ability for plugins to have their own CI pipelines for testing is something we want to enable for BTCPay Server plugins as well, but it requires some more infrastructural work to make it happen.

The BTCPay Server core, recognized there are some improvements to be made as well:

  • Improving communication in case of critical vulnerabilities even further, potentially implementing RSS and enhancing our notification system to have the ability to alert users when a critical vulnerability is reported.
  • Ensuring users are aware of the potential dangers of using third-party plugins
  • Outlining dangers that come with opening up instances for public registrations, especially when hot wallets are in play.
  • Fine-graining user registration system and allowing better ways for admins to vet their users.
  • As part of the official roadmap, the biggest focus is introducing a cross-platform application that enables a seamless non-custodial Bitcoin and lightning experience, even on shared instances.

# Saying sorry

I feel sorry for every user of the plugin who was affected by this vulnerability and every sat lost. I am thankful for the user who provided the information to prevent further loss and helped debug this. In the discussions that came up after this vulnerability was announced, it turned out that there is also a case with severe loss. Up to now I haven’t addressed it publicly and I am also sorry for that.

Though I know this won’t make up for it I want everyone to know that I am very sorry about what happened. I don’t want to justify it in any way, yet to be realistic I know that these kind of things can happen. Nevertheless, I want this at least to be more than words and even though it will be more of a symbolic move than substantially helping with the loss, I’d like to do the following …

The LNbank plugin received around 500k sats in donations, at least that’s what I can roughly attribute to it. I will match and double it, so that there are 2.1M sats, which I’ll donate to those impacted. Everyone who feels like they got value out of LNbank can please also donate to that cause.

You can donate to Hugo’s case via hugo@wallets.fyoumoneypod.com or to bc1qz8dxk6h8gha5qvsnw67rjzz3xn6t4k0wmafqz3.