Bitcoin Wallet Update Can’t Undo a Credential Leak
LNbits has shipped two security releases in two days, but the update rotates only one layer of access; three others stay valid until operators revoke them by hand.
Key Takeaways
- 1.7.1 rotates the login signing key only
- Wallet keys and backend credentials need manual rotation
- LND macaroons survive deletion until root key changes
- Rotate from a fresh server, backend first
The warning is LNbits’ own: its November 10 security notice says credentials exposed before the upgrade may still give an attacker access afterwards.
The vulnerability was found on November 8. LNbits’ first public instruction that day was to disable the Paywall extension; within hours it told operators to shut their servers down entirely and took its own hosted instances offline. Version 1.7.0 followed on November 10, and the notice says every earlier version is affected and funds on them are at risk. Creator Ben Arc has said both the project and its users lost money. LNbits has promised a separate report on how the exploit worked, so the mechanism is still undisclosed, and nothing below should be read as describing it.
Version 1.7.1 arrived on November 11. Its release note is a single line, “Rotates auth keys”, with a link back to the recovery notice. The package notes from Start9, which ships LNbits for its StartOS servers, spell out what that means: the authentication signing key is replaced, existing login sessions stop working, and operators still have to reset wallet keys, replace funding-source credentials and reconnect apps and extensions. In Start9’s words, updating alone cannot remove access.
So the update deals with one credential: the key the server uses to sign logins. An attacker holding a session token is logged out. An attacker holding anything else is not.
Three Credentials the Update Does Not Touch
An LNbits deployment runs on three kinds of secret, and each is checked by a different system.
Wallet keys
Every LNbits wallet has an Admin key and an Invoice key. The Admin key can send payments and manage the wallet; the Invoice key can create invoices and read balances and payment history but cannot spend. A copied Admin key is a spending problem. A copied Invoice key is a privacy problem, it shows an outsider exactly how much a wallet holds and when it gets paid. Either key stays valid until the operator resets it from inside LNbits.
Funding-source credentials
LNbits does not hold bitcoin itself. Its architecture tracks balances internally and hands the actual payments to a connected backend, an LND or Core Lightning node, Phoenixd, or one of the other supported funding sources. The credential for that connection lives in LNbits’ settings, and the notice tells operators to treat everything stored there as compromised. Resetting a wallet key does nothing to it, and neither does 1.7.1.
App and device connections
Anything that talks to a wallet from outside carries its own connection string: point-of-sale and terminal extensions such as TPOS, Bleskomat and FOSSA, Bolt Card NFC cards, and wallet-app bridges such as LNDHub and the NWC provider. The notice lists these for review and recreation. Each one was issued a credential at setup time, and that credential remains in whatever file, card or phone it was written to until the connection is recreated.
Why Deleting a Key Is Not the Same as Revoking It
The funding-source layer is where the recovery goes wrong most easily, because the credential is validated by the node, not by LNbits. Lightning Labs’ documentation for LND macaroons, the bearer credentials that authorise node operations, makes the point directly: deleting the macaroon file from disk does not revoke a copy someone else already has. The node keeps accepting it, because the node checks the macaroon against a root key, and the root key has not changed.
Revocation means acting on that root key. Deleting a root-key ID invalidates every macaroon derived from it at once, the attacker’s copy, and also the ones issued to any other service that was using the same root key. An operator who rotates it without first listing those services will find out which ones they forgot when each stops authenticating.
Other backends have their own equivalents, Core Lightning runes, API keys on hosted providers, and the same test applies to all of them: has the system that validates the credential been told to reject the old one, or has the old one merely been removed from the LNbits side?
The Order of Recovery
The notice recommends a fresh server where compromise is suspected, with logs and records from the old one preserved first. The reason is simple: a replacement credential pasted into a server the attacker still controls is a replacement credential the attacker now has. That fixes the sequence.
- Copy logs, database and records off the old server for the investigation, then stop it.
- Build a clean server and install 1.7.1 before anything else runs on it.
- Revoke at the backend, rotate the LND root key, rune or provider API key, and only then issue a new credential to LNbits.
- Reset the Admin and Invoice keys of every wallet.
- Recreate each app, card and terminal connection that is still needed, and leave the rest deleted.
- Test the old credentials, not just the new ones: a request signed with a retired Admin key or an old macaroon should be refused.
Reading the signs after rotation
The new path is live. It says nothing about the old one.
Expected. Its stored credential was retired; reconnect it.
Not evidence. A copied Invoice key reads the same screen.
Revocation did not reach the system that validates it.
The delay between a credential being copied and funds moving is the same pattern Coindoo described in crypto theft that begins months before the money disappears. The difference here is that an API credential can be revoked; a leaked seed phrase can only be abandoned.
If You Use Someone Else’s LNbits
A user on a hosted instance cannot rebuild the server or rotate the node’s keys. What they can do is ask three questions: which version the instance is running, whether their wallet’s Admin and Invoice keys have been reset since the upgrade, and which of their connected apps or cards need to be set up again. If the operator cannot answer the second question, the wallet is in the same position it was in before November 10.
What the Exploit Report Will Settle
LNbits’ promised report should answer which of the three layers the attackers reached and how. Until it lands, the recovery notice is written for the worst case, every stored secret exposed, and an operator who has worked through the list above has done what the project asked. One who has only updated has closed the door the attackers came through and left every key they picked up on the way still working.
Kosta has reported on cryptocurrency markets and blockchain infrastructure since 2020, bringing over six years of hands-on experience in the crypto industry built through daily tracking of markets, trends, and emerging blockchain developments. Specializing in Bitcoin on-chain analysis, institutional ETF flows, and digital asset price action, his work at Coindoo has been cited by other news agencies and consistently covers market developments with a focus on data-driven reporting across Bitcoin, Ethereum, Solana, and XRP. Over the years, Kosta has contributed to multiple crypto media outlets in different regions, authoring over 6,000 articles across the sector. His reporting spans cryptocurrency markets and the broader fintech industry, tracking not only price action but also the technological and regulatory forces shaping the ecosystem. To support his analysis, Kosta actively leverages on-chain data and metrics from leading platforms such as Santiment, Glassnode, and CryptoQuant, enabling deeper, evidence-based market insights. He believes in the power of transparency and the data that underpins the blockchain ecosystem. His academic background in Marketing Management from Denmark further complements his analytical approach, adding a strong understanding of communication strategy and content positioning to his work.
