Alby Hub Security Flaw: How to Check Whether Your Bitcoin Lightning Node Is Reachable From the Internet

If you run your own node on the Lightning Network using the Alby Hub software, you have had one concrete job since September 9, 2026: check the version number. If it reads anything between v1.7.0 and v1.18.5, and the management interface is reachable from the open internet, an attacker can gain unauthorised access and drain funds, according to the provider. Which puts the answer to the central question right at the top: check the version, close off access from the internet, update to v1.24.0, and change the unlock password afterwards.

Everything else in this article answers the questions that follow from there. Who is actually affected by the flaw, how do you tell that your installation was never exposed in the first place, and why is the fix older than the warning now making the rounds in the trade press.

What Alby Hub is and who actually runs this software

Alby Hub is software that lets you run a node on the Lightning Network yourself. The Lightning Network is a payment layer built on top of Bitcoin that moves small amounts almost instantly and at very low fees: two participants open a payment channel and only the opening and closing of that channel are recorded on the blockchain. A node, in that picture, is the machine that keeps such channels open and forwards payments.

The difference from an ordinary wallet app is decisive in this case. An app on your phone connects to somebody else's service and has no address of its own on the network. Alby Hub, by contrast, is a program that runs permanently, on a small machine at home, on a rented server, or as an application on a desktop computer. And a program that runs permanently has an interface through which it is administered.

That interface is precisely what the September 9 report is about. The people affected are therefore those who settle their bitcoin payments themselves rather than having somebody settle them. For the variant hosted by Alby, none of the reports describes a case.

Which Alby Hub versions are affected: v1.7.0 through v1.18.5

The provider has rated the flaw as critical and drawn a clear line around the affected range: versions v1.7.0 up to and including v1.18.5, all of them releases from before August 2025. From the 1.19 series onwards the flaw is fixed. According to reports so far, exactly one user is confirmed as affected.

A CVE number, the internationally standard identifier for a vulnerability, does not appear in the September 9 reports. The provider has announced that technical details will follow later, as is customary with responsible disclosure: first as many operators as possible should update, then the precise workings of the attack are described. For you that means you cannot yet check the provider's assessment for yourself. The recommended course of action does not depend on it.

One point that tends to get lost in the excitement: the version range alone does not decide the matter. An old release on a machine reachable only within your own home network was, by the provider's description, never exposed. The version number is one half of the check, reachability the other.

Why only a publicly reachable management API is exposed

The management API is the interface through which Alby Hub is administered: opening channels, triggering payments, issuing access for apps. A programming interface of this kind is at heart an address that accepts commands. Sitting behind the front door of your own network, it can only be reached by someone already inside that network. Sitting openly on the internet, it can be reached by anyone who knows or finds the address.

By the provider's account, the flaw only becomes exploitable in that second situation. Anyone who has deliberately made their node reachable from outside, say to operate it from a phone while travelling, belongs to the group at risk. Anyone who only operates it inside the home network does not.

That distinction is why the first recommended measure is not the update but the lock-down. An update takes a few minutes and, if it comes to it, a restart. Taking access off the internet takes one move in the router and works immediately.

Checking your Alby Hub version: where the number sits and what it tells you

The Alby Hub interface carries an information page showing the version alongside the node backend in use; the release notes for v1.24.0 point to exactly that page. Read the string off there and compare it against the range above. Anything below 1.19 needs updating, regardless of whether your node was ever reachable from outside.

If you have no access to the interface, the installation itself offers a way in: the file name of the downloaded package carries the version, and with a container installation it is written into the image used. If none of these routes gives an unambiguous answer, treat the installation as affected and update.

The checks in the right order

Reachability first, then the version, then the update. That order is not a formality. Update first and you leave access open throughout the download and the restart. Lock down first and you take away the flaw's precondition, then handle the rest at your own pace.

The fix is a good twelve months older than the warning

This is where the case gets more interesting than a routine call to update. For this article, cryptoticker.io retrieved the project's release overview on September 11, 2026 and evaluated the 40 most recent entries. The result puts the timeline in order.

The last affected release, v1.18.5, was published on July 31, 2025. The first entry of the 1.19 series in that overview is v1.19.1 of August 29, 2025; v1.19.2 followed the same day and v1.19.3 a day later. The current release, v1.24.0, dates from August 14, 2026. Between the first corrected release and the public warning of September 9, 2026 there is therefore a good twelve months.

One observation from the same evaluation belongs here, because it can cause confusion during the check: a standalone release numbered v1.19.0 does not appear in that overview, even though the coverage names it as the first corrected version. So if you search the list for v1.19.0 and come up empty, you have not searched wrong. What matters for you is the current release anyway, not the first corrected one.

cryptoticker.io compiled this evaluation itself on September 11, 2026. Method: retrieval of the project's release overview via the GitHub programming interface, evaluation of the 40 most recent entries by number and publication date. What could not be verified is which code change exactly fixed the flaw, since the technical details have not yet been published. Nor is it possible to establish from outside how many operators are still running an old release today.

The release notes for v1.24.0 also list a series of hardening measures that all point in the same direction: sensitive calls such as access to the recovery words and to the log now require a key with full access; the limit on failed unlock attempts was moved from the individual address to the installation as a whole; the silent acceptance of an empty unlock password inherited from old releases was removed; and a security policy was added to the documentation. Whether any of these changes is connected to the flaw now reported, the provider does not say.

Updating to v1.24.0: these steps in this order

The provider recommends raising the installation to v1.24.0. The routes there differ depending on how you run it, but the pattern stays the same.

1. End reachability from the internet before you do anything else.
2. Check that you have a backup of the recovery words and the channel data. A node with open payment channels is not a program you can simply reinstall at will.
3. Apply the update and restart the installation.
4. Look at the information page to see whether the new number is actually there.
5. Change the unlock password if the node was ever openly reachable.

A warning that comes from running Lightning nodes in general rather than from this report: restoring a node with open channels from an old backup risks publishing an outdated channel state. That can cost you funds. So read the provider's notes on backups before the update instead of working from memory.

Port forwarding, reverse proxy, tunnel: where reachability actually comes from

Hardly anyone makes their node public by accident. It happens at three typical points, and all three are deliberate decisions that are later forgotten.

The first is port forwarding in the router. It passes requests from the internet through to a device on the home network, and it stays in place until somebody removes it. The second is a web server placed in front, publishing the interface under an address of its own, often set up so the connection runs encrypted. The third is a tunnelling service that builds a connection from outside to inside without anything being changed on the router. The third route in particular is convenient and leaves no trace in the router to remind you later.

If you genuinely need access while out and about, you are better off putting it inside a private network that the phone dials into, rather than placing the management interface openly on the net. And anyone holding meaningful amounts sensibly separates the sum kept ready for everyday payments from the rest, which belongs on a device with no network connection. Which devices qualify and what sets them apart is covered in the hardware wallet comparison.

Changing the unlock password: why the update alone is not enough

The unlock password protects the running installation: without it, the software does not release its keys. The provider explicitly recommends changing it after the update if the installation was openly reachable before, and contacting the provider's security address on any suspicion of an incident.

The thinking behind it is simple. An update closes the door. What it does not undo is that somebody may have walked through that door beforehand and taken a key with them. Raise the version and leave the password as it is, and you have fixed the cause while leaving the possible consequence in place.

The same goes for the access you have granted to individual apps. Go through the list of those connections once after the update and remove anything you no longer use or cannot place.

What happens if you do nothing

Two things should be kept apart. Funds in payment channels are tied to keys that sit on your device; they do not vanish because a report appears, and they do not hang on a deadline either. There is no deadline in this case, unlike with a delisting at an exchange.

The risk is a different one: for as long as an affected release sits openly on the net, the route the provider describes stays open. And the technical details can be expected to be published at some point. From that moment the flaw is reproducible for anyone who cares to look for it. Anyone who has updated by then is out of it.

Run it yourself or have it held for you: what this case says about self-hosting

It would be the wrong conclusion to take from this report that running things yourself is a mistake. A node you run yourself makes you independent of a provider's opening hours, freezes and withdrawal deadlines. The price is the duty to keep software current, and that duty is exactly what has become visible here.

What the case shows is something more modest: the attack surface does not arise from holding the keys, but from being operable remotely. Add convenience and you add attack surface. That equation cannot be configured away, only entered into knowingly.

For most readers, a sober split follows from it. The amount you pay with day to day belongs in a software wallet or in a node that is conveniently reachable. The rest belongs on a device that is not attached to the network and makes nothing operable.

Ledger, BitBox02 and Core Lightning: the fourth wallet incident in four weeks

The case is one in a series. On August 21, 2026, BitBox closed three security holes with firmware 9.26.5; on August 25, Ledger fixed a flaw in its Ethereum app where the display could show something other than what was actually signed; and at the end of August a vulnerability in Core Lightning became known that forced node operators to act. Now Alby Hub joins them.

The cluster is no proof that self-custody has become less safe. It suggests rather that this field is now being searched and disclosed systematically. For you as an operator, one unspectacular habit follows: once a month, check whether a new release exists for every device and every piece of software that holds keys. That costs ten minutes and deals with most such reports before they reach you.

If you want first-hand evidence: the September 9 report is documented at The Hacker News, among other places, and the current release together with its release notes sits in the project's overview for v1.24.0.

Closing the Alby Hub flaw: what to take away

1. Check reachability today, then the version. If the management interface is reachable from the internet and a release below 1.19 is running, take it off the net immediately. If you would rather keep your everyday amount in a lean application than in a node of your own, you will find the candidates in the software wallet comparison.
2. Update to v1.24.0 and change the unlock password. Back up first, then update, then read the version number back. And separate the amount you move daily from the amount that just sits there; the devices for that are in the hardware wallet comparison.
3. Put a monthly update slot in the calendar. Four incidents in four weeks are not an outlier but the normal state of an industry where people are actively looking. Ten minutes a month for every device and program that holds keys, plus a look at the software wallet comparison if you want to replace an application.

(As of September 11, 2026. This article is not investment advice. Prices and fee structures change; check the terms with the provider before you buy.)