Critical Alby Hub Flaw Left Internet-Exposed Bitcoin Wallets Open to Takeover
Alby has issued a security warning about a critical vulnerability in its self-hosted Lightning wallet software, Alby Hub, that could allow attackers to seize control of a wallet and drain its funds. The catch: you had to have done something you probably shouldn't have done anyway, which is stick the management interface on the public internet.
The flaw spans versions v1.7.0 through v1.18.5, all predating August 2025. Version v1.19.0 patched it, with that fix first shipping on August 29. Alby recommends everyone update to v1.24.0 regardless. One user has reportedly been affected, though Alby hasn't confirmed whether any funds were lost.
Alby hasn't disclosed the technical specifics of the vulnerability yet, citing responsible disclosure. That's fair enough, but it does leave affected users in the dark about exactly what they're dealing with.
What you should actually do
If you're running v1.18.5 or older, the priority is cutting off external access before anything else. In Docker terms, that means your port binding should read `127.0.0.1:8080:8080`, not `8080:8080`. On a cloud server, tighten the firewall rule for port 8080 so only your own IP gets through. Then update to v1.24.0.
If your Hub was both running a vulnerable version and publicly reachable, Alby says to change your unlock password after updating and email [email protected]. What exactly that password change is supposed to undo, Alby hasn't explained publicly.
How this happens in the first place
Alby Hub is designed to sit on a private network. Its server binds to all network interfaces on the host machine rather than just localhost, which means that if the machine is reachable from the internet, so is the Hub. That's a fairly significant detail to bury in the documentation.
Alby updated its docs on September 7 to explicitly warn against public exposure and switched its Docker configuration to bind only to localhost. The commit message candidly admitted that previous setup guides had described the server as running on localhost when it actually listens on all interfaces. A meaningful difference.
Before that change, at least two of Alby's own cloud server guides were describing setups that left the Hub open to the internet. The DigitalOcean guide told users to keep the server's public address active because it's "needed so you can open Alby Hub in your browser," while the Hetzner guide walked users through a firewall rule allowing any IPv4 and IPv6 source, with the more cautious option of restricting to your own IP framed as optional.
So yes, users were getting exposed in part by following official documentation.
This has happened before
Back in November 2025, Alby responded to a user whose Hub had been emptied after being left publicly accessible. That incident was attributed to a different problem: the Hub's initial setup had never been completed, meaning no unlock password had been set, and the attacker simply finished the setup themselves. Grim.
Following that, Umbrel put Alby Hub behind its own authentication layer, which had previously been disabled for it. Umbrel's app store now installs v1.24.0 and Alby's own Umbrel listing ships v1.21.4, both post-fix versions, though what's installed on any given Hub depends on when it was last updated.
What's still unanswered
Alby's advisory doesn't clarify whether Alby Cloud users are already covered. It also identifies v1.7.0 as the start of the affected range without saying anything about what happens to users on even older releases going back to v1.0.2. The Register reports it has put these questions to Alby directly.
For a piece of software holding actual money, the documentation gaps here are uncomfortable. The vulnerability itself may be serious, but the configuration advice that led users to expose their Hubs in the first place is the longer-term problem worth watching.