Security · Analysis
If Your Alby Hub Predates August 2025, Take It Off the Internet
Alby says a critical flaw in older builds of its self-hosted Lightning wallet could let an attacker take a Hub over and spend from it — but only where the owner had made the management interface reachable from the open internet. The release that closed it came out more than a year ago.
Alby Hub is a Lightning node and wallet you run yourself. That is the whole proposition: the software sits on your own machine or your own server, the bitcoin is yours, and no company stands between you and your channels. It is the arrangement the entire self-custody argument points at.
It also means that when Alby finds a critical bug, Alby cannot fix your copy. It can only tell you.
On September 9 it told everyone. The company disclosed a flaw in Alby Hub that, in its own framing, could have let an attacker take over a wallet and send its funds — with one significant qualifier attached, which is that the bug only becomes exploitable where the owner had made the Hub's management interface reachable from the internet.
The version numbers are the story
The affected range is v1.7.0 through v1.18.5. Every one of those releases predates August 2025. Version v1.19.0 and everything after it is unaffected, and v1.19.0 was published on August 29, 2025, per The Hacker News. The current release is v1.24.0.
Set those two dates beside each other. The code that removes this vulnerability has been publicly available for more than twelve months. The warning that you needed it arrived this week.
Where your build sits
| Version | Released | Status |
|---|---|---|
| v1.7.0 – v1.18.5 | before Aug 2025 | Affected — exploitable if internet-exposed |
| v1.19.0 | Aug 29, 2025 | First release without the flaw |
| v1.24.0 | current | The version Alby is telling users to move to |
Alby has not said whether the v1.19.0 change was shipped as a security fix. It has said it will publish full details later, in line with responsible disclosure. In the meantime the repository is public, so this desk went and read it.
Six lines, filed as a chore
Fifty-nine commits separate tag v1.18.5 from tag v1.19.0. The first one in the range is titled "chore: check password before node start." It changes one file, http/http_service.go, and it adds six lines.
What those six lines add is a password check to startHandler — the HTTP endpoint that starts the node. Before the patch, the handler took the incoming request and proceeded directly to createJWT, issuing a session token. After it, the handler first calls CheckUnlockPassword on the submitted value and returns 401 Unauthorized with the message "Invalid password" if it does not match.
Read plainly, that means the start endpoint would mint a valid session token without verifying the unlock password against it. Every element lines up with what Alby disclosed this week: the impact is wallet takeover and the ability to spend, the precondition is that the attacker can reach the management interface, and the HTTP service is the management interface. The commit sits at the front of the exact version range Alby identified, which is consistent with v1.19.0 being the first release without the flaw.
Two caveats belong on that, and they are not small. Alby has not confirmed which commit closed the hole, and this desk is identifying the most likely candidate from a public diff rather than reporting a confirmed fact. It is also possible that more than one change contributed. What is not in doubt is the label: the commit was filed as a chore, authored by Matjaž Lipuš, opened on August 1, 2025 and merged three days later — a six-line authentication check, carried into a release under the category reserved for housekeeping.
The version they want you on has its own quiet list
There is a second thing the repository shows, and it complicates the advice. Alby is telling users to move to v1.24.0, published August 14, 2026. That release's changelog runs to roughly thirty entries under "Fixes," and a substantial cluster of them are security hardening in everything but name.
Among them: preventing backup restore from writing outside the restore directory, validating return_to redirect URLs, removing request bodies from error logs, dropping raw Postgres error details from a duplicate-key response, requiring a full-access API key for the log endpoint and for swaps and mnemonic access, removing legacy acceptance of an empty unlock-password check, and switching the unlock rate limiter from per-IP to global.
Those last two are worth dwelling on, because they concern the same unlock password this story is about. A per-IP rate limiter on an unlock endpoint is close to no rate limiter at all against anyone with more than one address to try from, and "legacy acceptance of an empty unlock password" describes a code path that accepted nothing as an answer. None of these carry a CVE, a security label, or a line in the release summary, which describes v1.24.0 as adding "a number of UX/UI improvements."
One more detail sits underneath all of this. GitHub lists a tag for v1.19.0, but no release. The published releases run v1.18.5, then v1.19.1 — the version Alby now identifies as the first safe build has no release notes page of its own at all.
"One user," and what that number can and cannot mean
Alby says that to its knowledge, one user has been affected. It has not said whether that user lost money.
Read that carefully, because "to its knowledge" is doing real work in a self-hosted context. Alby does not operate these Hubs. It has no fleet telemetry, no server-side logs of your node, no ability to scan for compromised instances. The only way it learns that a Hub was drained is if the person running it comes and says so. A count of one is a count of reports, not a count of incidents, and the population of people running an eighteen-month-old build on an exposed interface is precisely the population least likely to be reading Alby's X account today.
That is not a criticism of the disclosure. It is the honest limit of what any self-custody vendor can know, and Alby stating the figure with the qualifier attached is the correct way to handle it.
The precondition everybody will argue about
The bug requires the Hub's management interface to be reachable from the open internet. The instinctive response is that nobody should ever have done that, and the instinctive response is too easy.
People expose management interfaces because they want to use their node from their phone, from work, from anywhere that is not the room the box is in. That is not recklessness; it is the ordinary desire to actually use the thing you self-hosted. The alternative — a VPN, a Tor hidden service, a reverse proxy with authentication in front — is well understood by people who administer servers for a living and genuinely unobvious to everyone else. Self-custody software is marketed to the second group and secured on the assumptions of the first.
What to do, in order
Alby's guidance, as reported, runs in a specific sequence, and the order matters more than it looks.
First, check your version. Second, if you are on v1.18.5 or older and the Hub is reachable from outside your network, cut that access off before anything else — the exposure is the live risk, and closing it takes seconds while an update takes longer. Third, update to v1.24.0. Fourth, and this is the step most people will skip: if your Hub was running an affected version and was internet-reachable, change your unlock password after updating, and contact [email protected]. Patching does not evict someone who already has what they took.
The Take
The uncomfortable arithmetic of self-hosting is that the security of your wallet is bounded by your own patch cadence, and almost nobody's patch cadence is good. A hosted wallet's operator can push a fix to every user in an afternoon whether they read the announcement or not; that centralisation is exactly what self-custody exists to refuse, and the price of refusing it is that a fix published in August 2025 is still not installed on your machine in September 2026. Both halves of that trade are real, and the ecosystem is much louder about the first half than the second. What Alby could do better is not mysterious. A Hub that knows its own version could tell its owner, in the interface, that it is running a build sixteen releases behind — not a changelog nobody opens, a persistent and slightly annoying banner. It could notice that its management port is answering from a public address and say so plainly the first time it happens. Neither of those is a centralising move; neither requires Alby to touch anyone's keys or funds. They are just the difference between shipping a fix and landing one, and this disclosure is a fairly precise measurement of how wide that difference currently is.