Eclair v0.14.4 blocks webpages from sending commands to Lightning nodes
In brief
- Eclair v0.14.4, released by ACINQ on Oct. 15, patches a browser-based API vulnerability.
- Exposure required a reachable Eclair API and HTTP Basic credentials already cached in the browser.
- Any request carrying an Origin header now gets HTTP 403 before the API route runs.
- Browser frontends now need an intermediary backend; curl and eclair-cli are unaffected, per maintainers.
- Operators can upgrade and restart without closing Lightning channels, maintainers say.
How the browser route worked
Eclair's node API isn't a read-only dashboard. It can read node state, open and close channels, and send and receive payments, so an unwanted authenticated request matters.
According to the v0.14.4 release notes, cached authentication let a malicious webpage submit a plain HTML form to the node's API. The browser attached the saved credentials automatically. The attacker couldn't read the response, but the authenticated command still reached the node.
What the patch changes
The browser fix merged on Sept. 15 in pull request #3380. It returns HTTP 403 before the API route runs whenever a request carries an Origin header, whatever that header's value happens to be.
That's a blunt rule.
It also hits legitimate browser interfaces, including ones hosted at the same origin as the API. Those frontends now need an intermediary backend sitting between the browser and Eclair. Command-line users shouldn't notice it (the maintainers said curl and eclair-cli don't send the Origin header, so their normal API requests are unaffected).
The Origin check isn't a permission system, though. A non-browser client can simply leave the header out, so a missing header doesn't show that a request is authorized, and authentication and network restrictions remain essential. Eclair maintainer pm47 said the API should stay bound to loopback, which limits network access to the local machine.
Upgrading
Release v0.14.4 also carries the funding-fee and signer repairs that CryptoSlate reported on Oct. 12. The maintainers recommended upgrading and said operators can stop Eclair, install the update and restart without closing their Lightning channels.
For operators running a browser frontend, there's an extra step. They'll need to put that intermediary backend in place, because the new 403 rule applies to their own interface too.
Frequently asked questions
How could a webpage send commands to an Eclair Lightning node?
According to Eclair's v0.14.4 release notes, a malicious webpage could submit a plain HTML form to the node's API. If HTTP Basic credentials were cached, the browser attached them automatically. The attacker couldn't read the response, but the authenticated command still reached the node.
What does the Eclair v0.14.4 patch change?
The patch returns HTTP 403 before the API route runs whenever a request carries an Origin header, whatever its value. That includes legitimate browser interfaces, even those hosted at the same origin as the API. Those frontends now need an intermediary backend between the browser and Eclair.
Are curl and eclair-cli affected by the Eclair update?
No. The maintainers said curl and eclair-cli don't send the Origin header, so their normal API requests are unaffected. Authentication and network restrictions remain essential because a non-browser client can omit the header.
Do Eclair operators need to close channels to upgrade to v0.14.4?
No. The Eclair maintainers recommended upgrading and said operators can stop Eclair, install the update and restart without closing their Lightning channels. Maintainer pm47 also said the API should stay bound to loopback.
