Alby warns a critical flaw drained self-hosted Lightning wallets left exposed online
On September 9, 2026, Alby disclosed that its self-hosted Lightning wallet Alby Hub shipped, up to v1.18.5, a critical flaw that let an attacker take over an internet-exposed node and move its funds. If you self-host a Lightning node, check your version and close the public exposure before you patch.
September 9, 2026. Alby published a security warning for Alby Hub, its self-hosted Lightning wallet: a critical flaw could let an attacker take over a node exposed to the internet and send its funds elsewhere. September 7, 2026. A documentation change admitted that the guides described the server as “running on localhost when it actually listens on all network interfaces.” August 29, 2025. The first fixed release, v1.19.0, had already shipped — yet thousands of nodes still run a vulnerable build. Why it matters: self-hosting a Bitcoin wallet inverts the trust model, and with it, the security burden.
One flaw, one known victim — and a long silent window
Alby Hub is a self-hosted Lightning wallet. The owner runs it on their own machine or server and holds the funds directly, with no third-party custodian in between. That is the entire promise of self-hosting applied to money — and the exact reason a flaw like this cannot be fixed by a vendor pushing a silent remote update.
The flaw affects versions v1.7.0 through v1.18.5, all released before August 2025. Versions v1.19.0 and later are not affected. Alby says one user has been affected so far, and did not say whether that user lost money; the victim reported the details to the company themselves. Alby has not disclosed the technical nature of the flaw — it will publish full details later under responsible disclosure — and thanked the researchers who reported other issues fixed in the latest release.
What should hold your attention is not the victim count but the window. The flaw shipped in v1.7.0, the fix landed on August 29, 2025, and the public alert only came on September 9, 2026. A full year passed between the patch and the disclosure, during which unpatched nodes sat exposed without knowing it.
The real problem was never the code — it was the network binding
The exploitation condition reframes the risk entirely: the flaw is only reachable if the Hub is reachable from the internet. A Hub listening only on the local machine gives an attacker no entry point. This is where the story becomes a self-hosting case study.
Alby Hub’s web server does not listen only on 127.0.0.1 — it listens on every network interface the machine has. Documentation claiming “it runs on localhost” was therefore wrong in practice, which is exactly what the documentation change merged on September 7, 2026 acknowledged. The same change flipped the project’s Docker file to publish port 8080 only to the machine (127.0.0.1:8080:8080) instead of exposing it to all addresses (8080:8080).
The consequence is mechanical: anyone who followed a cloud-server deployment guide and then opened port 8080 in the firewall exposed their wallet to the entire internet. The Hub requires a password to unlock, but a takeover flaw bypasses exactly that protection — which is the difference between a critical vulnerability and a mere misconfiguration.
The guides still pointed at the exposure
The most troubling part is that exposure was not just a user accident — it was documented. On September 9, 2026, the day of the alert, Alby’s own cloud-server deployment guides still described a setup open to the internet.
The DigitalOcean guide tells the reader to keep the server’s public address switched on because it is “needed so you can open Alby Hub in your browser,” then to open the Hub at that address. The Hetzner guide walks through a firewall rule for port 8080 with the source set to “Any IPv4 and Any IPv6, or your own IP address for better security” — total exposure presented as the default, restriction as an optimization. The guide’s example Docker file publishes the port to every address.
That asymmetry is the core lesson: self-hosted software can be fixed in code while its installation paths — guides, Compose files, firewall presets — never are. The binary had been patched for a year; the instructions that expose the binary were still live on the day of the alert.
A precedent in November 2025
This is not the first exposed Hub to be drained. In November 2025, replying to a user whose Hub had been emptied, Alby said the machine was “reachable publicly on the clearnet, so it could be accessed from the outside.” By Alby’s account that was a different problem: the setup had never been completed, no unlock password existed yet, and the attacker simply finished the configuration themselves.
After that case, a change to the Umbrel app put Alby Hub behind Umbrel’s own login, which had been disabled for it until then. The Umbrel app store now installs v1.24.0, and Alby’s own Umbrel listing installs v1.21.4, both newer than the fixed version — though that describes what those stores install today, not what an already-deployed node actually runs.
The November 2025 and September 2026 episodes echo each other: in both, the vulnerability was not in the idea of self-hosting, but in the reflex of exposing a money service to the public network when it was designed to live on a private one.
What to do now
The steps Alby published come in a specific order, and the order matters:
- Check your version — if it is v1.18.5 or older, you are inside the affected range;
- Close the exposure first — in Docker, publish
127.0.0.1:8080:8080, not8080:8080; on a cloud server, restrict the port 8080 firewall rule to your own address; - Update to v1.24.0, the current release — Alby recommends it even for unaffected nodes;
- If your node was affected and exposed, change your unlock password after updating and contact
[email protected].
Updating alone does not revoke access an attacker may already have on an exposed Hub. Cut the exposure first, then patch, then rotate the secret — that is the sequence that neutralizes both the flaw and its consequence.
Verdict
The Alby Hub story is a reminder of what “being your own bank” actually means. Self-hosting removes the intermediary that would normally patch on your behalf and absorb the breach on your behalf — it leaves you the keys, and the full responsibility for the door.
If you self-host a Lightning wallet, adopt a production-service posture, not a lab-gadget one: bind to 127.0.0.1, never listen on 0.0.0.0, and reach it remotely only through a private tunnel — Tailscale or WireGuard — rather than a reverse proxy exposed in the clear. Pin your versions, watch the project’s announcements, and treat any public exposure as an exception to justify, not the default setting.
If you run a Lightning node that is not your own — an Umbrel, a Start9, a shared server — verify that port 8080 is not open outward, even on a current version: that is the first line of defense, the one that makes the next critical flaw unexploitable before it is even announced.