Eclair 0.14.4 Blocks Every Browser Request to a Lightning Node API

ACINQ released Eclair 0.14.4 on Thursday 15 October, and the change node operators have to plan around is a refusal. The Lightning implementation's API now answers 403 to any request that arrives carrying an Origin header, before that request reaches the route it asked for. Browsers attach the header; curl and eclair-cli do not. The point is to close a path by which a web page an operator happened to visit could issue authenticated commands to their own node. It also breaks every browser-based front end, including ones served from the same origin as the API.

How a visited page could reach the node

Eclair's API uses HTTP basic authentication, and browsers cache those credentials. A hostile page could submit a plain HTML form aimed at the API, and the browser would attach the saved credentials on its own. The attacker could not read what came back. The command still ran. That API can read node state, open and close channels, and send and receive payments, on CryptoSlate's reading of what sits behind it. Cross-site request forgery of this kind rides the victim's own session, so a strong password does nothing against it.

Some of the issues fixed in the release "can be exploited by malicious nodes," the announcement said, with a strong recommendation to upgrade.

A header check, not an authentication check

Pull request #3380, "Reject API access from browsers", filed by the maintainer pm47, describes the change as a defence against browser request forgery and not as authentication. The check tests only whether the header is present, so it also catches Origin: null and DNS-rebinding attempts, where a hostile page tricks a browser into treating an internal address as its own. A non-browser client can simply omit the header and go through. The maintainer's position is that the API should stay bound to loopback, reachable only from the machine it runs on. Shutting off a capability outright is the blunt version of a fix, and Bitcoin Core took the same route when it blocked a signing mode that let payments be redirected.

What the patch breaks

Browsers can no longer call the API at all. A same-origin web front end is blocked along with everything hostile, so anyone running one needs their own back end sitting between that front end and the node. Command-line tooling is untouched. The pull request closes one finding from project Loupe's audit of Eclair and, by its own account, any other forgery report filed against an individual endpoint. CryptoSlate dates the merge to 15 September, a month before the release went out, and says it cannot explain the gap; no other account carries that date.

The rest of the changelog

0.14.4 is a patch release credited mostly to the contributor erickcestari and to project Loupe, landing 31 days after v0.14.3. The changelog runs to about 20 commits. Among the security items: seed files of invalid length are rejected, interactive-transaction funding is hardened against a malicious bitcoind, remote closing-script updates are validated, onion per-hop lengths longer than the packet carrying them are refused, and unpublishable splices are turned away. The release is compatible with earlier versions, so an operator stops the node, installs and restarts without closing any channels.

What operators are left holding

No CVE identifier, severity score or reporter has been published for the browser issue beyond the audit that produced it. The other large implementation handled its own report differently this year, when Core Lightning confirmed AI-found bugs and held the details for 14 days. What this release does not do is make the API safe to expose, and the maintainers say so themselves. The header check guards against one class of caller. Anyone who has left the API reachable past their own machine still has the older problem, and no patch in this version touches it.