Eclair patch stops web pages from sending commands to Lightning nodes

Update, 21 October 2026, 16:45 UTC: ACINQ released Eclair v0.14.5 on 20 October, five days after v0.14.4. It is another patch of security hardening fixes, with credit for responsible disclosure going to two researchers who sign as Nuhiat-Arefin and mptfire, and ACINQ warns that some of the issues “can be exploited by malicious nodes”. The release notes describe none of the flaws, give no CVE and no list of affected versions, and no attack or loss has been reported, as CryptoSlate noted on 21 October. The maintainers have not tied the new fixes to the browser problem described below. Operators who already installed v0.14.4 have to upgrade again. The procedure does not change: check the signature and the SHA256SUMS file, stop Eclair, install v0.14.5 and restart, with no channel to close.

ACINQ has shipped Eclair v0.14.4, a release that stops web pages from sending commands to a Lightning network node through the browser of the person who runs it. Published on 15 October 2026 at 19:30 UTC, the update makes the node’s control API refuse any request that carries an Origin header, which browsers attach to every cross-site request and to every request other than a plain GET or HEAD. Until now, according to the release notes, any web page the operator visited could have forged authenticated API calls without ever seeing a password.

No theft has been reported. ACINQ has published no security advisory and no CVE number for the issue, and CryptoSlate, which reported the change on 17 October, gave no count of exposed nodes. For the small group of people who run Eclair themselves, though, the patch changes how the software can be used, and the developers recommend upgrading.

What changed in Eclair v0.14.4

Eclair is one of the main open-source implementations of Lightning, the payment network that runs on top of bitcoin. It exposes a JSON API on a local port so that its owner can check balances, open and close channels and send or receive payments from scripts or the bundled command-line tool, eclair-cli.

The new rule fits in one line of the release notes:

“The API now rejects requests that carry an Origin header, which means it cannot be used from a web browser anymore.” (Eclair v0.14.4 release notes)

The work behind it is pull request #3380, titled “Reject API access from browsers”. It was written by the developer who signs as pm47, approved by sstone, and opened and merged on the same day, 15 September 2026. The fix therefore sat in Eclair’s main branch for a month before it reached a tagged release. Per the PR and its commit, any request with an Origin header now receives an HTTP 403 error before the requested command runs, and the CORS headers that told browsers which sites were allowed to talk to the API are gone. The change touches six files, with 111 lines added and 8 removed, and comes with tests for a browser origin with and without credentials, for websocket connections and for the special value Origin: null. Each refused call also leaves a warning in the node’s log. The PR says it fixes the Project Loupe report and, by construction, any other CSRF report aimed at a single endpoint.

It also breaks something on purpose. The API can no longer be called from a browser at all, even from a page served by the same host. Anyone who built a web dashboard that talks straight to Eclair now needs a back-end server of their own between the page and the node. Scripts, curl and eclair-cli are not affected, because they do not send that header.

How a web page could reach your Lightning network node

The attack described in the release notes is what the PR calls browser CSRF, short for cross-site request forgery. The idea: code on one website makes your browser perform an action on another service, using a login your browser already holds. The attacker never needs your password. Your browser supplies it.

Eclair’s API uses HTTP basic authentication, the old scheme where the browser asks for a password once and then remembers it. Browsers attach those cached credentials to later requests, including requests launched by other sites. The API’s endpoints also accept form-encoded parameters, so a plain HTML form hidden in a web page is enough to build a valid call. The notes add the detail that matters: the attacking page cannot read the reply, but by then the command has already been executed.

The chain only works if the operator has, at some point, opened the API in that browser and saved the login. That is the case for people who used a browser-based tool or tested the API by hand. CryptoSlate lists the commands reachable through the API: reading the node’s state, opening and closing channels, and sending and receiving payments. Since payments are part of that list, a forged call could in principle move money out of the node, which keeps its funds in a hot wallet by design. Neither ACINQ nor CryptoSlate documents a case where that happened.

Why binding to loopback was not enough

Node operators are told to keep the API on loopback, the 127.0.0.1 address that only the same computer can reach. That advice still holds, and it blocks strangers on the internet. It does nothing against CSRF, because the browser that carries the forged request runs on that same computer. From the node’s point of view, the call comes from a trusted local client.

The PR notes that checking only for the presence of the header, rather than comparing it with a list of allowed sites, also covers requests sent with Origin: null and DNS rebinding. Rebinding is a trick in which a web page gets the browser to treat a service on your own machine as part of the attacker’s site. With the new rule, the content of the header does not matter: if it is there, the request is refused.

No CVE, no known victims, several unknowns

ACINQ’s GitHub page for security advisories said on 17 October that there were none published. No CVE identifier could be found for this issue. The release credits its security hardening fixes, “most originating from @erickcestari and project Loupe”, and the Origin item points to an entry in Project Loupe’s audit tracker, project-loupe/audit-eclair#223. That entry is how the finding reached the developers; the sources do not say who personally reported it, or when.

Several questions remain open as of 17 October:

1. Which versions were exposed. The release notes describe a design (basic authentication plus form-encoded endpoints) that appears to predate v0.14.4, but no source names a first affected version.
2. Whether the API is switched on by default, and with what password policy. The project tells operators not to make it reachable from outside, and that is as far as the documents go.
3. How many nodes run the API in a way a browser could reach, and whether anyone tried the attack. Nothing has been reported.
4. Whether a bug bounty was paid for the finding.

The developers are clear about the limits of their own fix. In PR #3380, pm47 writes: “This is a defence against browser CSRF, not an authentication mechanism.” A program that is not a browser can simply leave the header out. The same text adds that the API “should still never be exposed beyond loopback”, a point CryptoSlate also attributes to pm47.

A busy autumn for Eclair security fixes

The API change is one item in a longer list. The same release bundles hardening work that, in ACINQ’s words, matters because “some of these issues can be exploited by malicious nodes”. The changelog entries, numbered #3387 to #3401, cover validation of the seed file’s length, protection against a malicious bitcoind back-end, checks on the closing scripts sent by a channel partner, a length check on onion packets, and fixes to splicing and to on-the-fly channel funding. For operators, those are reasons to upgrade on their own, whether or not they ever touched the API from a browser.

It is also the fourth Eclair release since late July. Earlier this month, CryptoSlate (republished by KuCoin News on 2 October) described a memory-exhaustion bug linked to records of unfunded channels, present in v0.14.0 and earlier and fixed in v0.14.1 on 29 July. In one laboratory test on v0.14.0, a 4 GB memory heap ran out after about 48 minutes, and because the records stayed on disk, a restart crashed the node again. Researcher Erick Cestari published the details on 30 September, and v0.14.3 was the version operators were told to run. The same report mentioned a second bug, LNF-2026-0003, found by Matt Morehouse with his lnfuzz tool, which left orphaned channel processes eating memory until a disconnect or restart.

Lightning has had bigger scares. In October 2023, developer Antoine Riard disclosed “replacement cycling”, an attack on forwarding nodes that affected every implementation, Eclair included, as Bitcoin Optech reported on 25 October 2023. The implementations shipped mitigations, such as more frequent rebroadcasting and, in Eclair and LND, mempool scanning, though LDK developer Matt Corallo said they were “not expected to fix this issue”. Optech reported no use of the attack in the wild. The Eclair API issue is narrower: it needs the operator’s own browser, a saved login and a malicious page visited at the wrong moment.

Three Eclair security releases in five weeks

With v0.14.5, Eclair has put out three releases labelled as security hardening in a little more than five weeks. v0.14.3 arrived on 14 September with fixes mostly from Project Loupe, v0.14.4 on 15 October with fixes mostly from erickcestari and Project Loupe, and v0.14.5 on 20 October with the two new researchers credited. The two earlier 0.14 patches, v0.14.1 on 29 July and v0.14.2 on 26 August, are listed on the project’s release page as bug-fix releases.

All three security releases carry the same advice from ACINQ: upgrade. The cost for an operator is a restart each time, since none of them requires closing channels. The difference this time is how little is said. The code of v0.14.5 is public, but its notes do not explain what was fixed, and ACINQ has not said when it will. The release concerns Eclair alone; LND, Core Lightning and LDK ship their own patches on their own schedules.

What operators must do before restarting

The upgrade itself is simple. ACINQ says v0.14.5, now the latest release, is fully compatible with earlier versions, as v0.14.4 was, and that channels do not need to be closed: stop Eclair, install the new version, start it again. Releases are signed with the key E04E48E72C205463 and builds are deterministic, so the binary can be checked against the published source.

1. Check the signature of the downloaded release against the ACINQ signing key before installing it.
2. Stop Eclair, replace the binaries and restart; existing channels and funds stay in place.
3. Confirm that the API still listens only on 127.0.0.1 and that its password is not reused anywhere else.
4. If a browser dashboard used to call the API directly, move those calls behind a small server of your own, since the browser route now returns 403.
5. Clear any basic-auth login for the API saved in your browser, which no longer has a use.

Running a Lightning node means keeping keys online so the node can sign payments at any time. That trade-off, explained in our guide to how crypto wallets work, is why a local API that can spend deserves the same care as the seed itself.

Who is concerned by the Eclair update

The change concerns people who run Eclair as a server and use its JSON API: routing node operators and merchants or developers who built their own setup on it. Eclair is a minority implementation by node count, but its developer matters on the network: ACINQ runs one of the largest routing nodes and makes the Phoenix mobile wallet.

The issue is about the operator’s API, not about mobile wallet apps. ACINQ has not published a statement on Phoenix, and nothing in the release notes says its users need to act. People who pay over Lightning through a custodial app or another implementation have nothing to do here. Readers new to second-layer networks can start with our layer-2 glossary entry.

What comes next for Eclair node runners

No date is set for anything further. The audit-eclair#223 entry may lead to a fuller write-up from Project Loupe once disclosure is complete; no timetable has been given. ACINQ has not said when it will describe the flaws fixed in v0.14.5. The release to install is now v0.14.5, on GitHub since 20 October, which replaces v0.14.4 as the version ACINQ recommends.