ACINQ's Eclair v0.14.4 blocks malicious webpages from sending authenticated commands to a Bitcoin Lightning node through an operator's browser. The exposure required an enabled Eclair API reachable by the browser and HTTP Basic credentials already cached for that API. The release was published on Oct. 15, and maintainers recommend upgrading and restarting the node without closing its Lightning channels.
Why it matters
A malicious webpage could submit a plain HTML form to Eclair's API, prompting the browser to attach saved credentials automatically. Although the attacker could not read the response, the authenticated command would still reach the node. Eclair's API can expose node state, open and close channels, and send or receive payments, making the browser route a meaningful operational risk.
Version 0.14.4 rejects API requests carrying an Origin header with HTTP 403 before the API route runs, regardless of the header's value. The change also affects legitimate browser-based interfaces, including frontends hosted on the same origin. Those interfaces now need a backend intermediary between the browser and Eclair.
Market impact
The fix does not interrupt ordinary command-line access. Maintainers say curl and eclair-cli do not send the Origin header, so normal requests from those tools continue to work. The patch was merged on Sept. 15 in pull request #3380 and ships alongside funding-fee and signer repairs.
The Origin check is not a replacement for authentication or network controls. A non-browser client can omit the header, so Eclair recommends binding the API to loopback and limiting access to the local machine. Lightning node operators should upgrade, retain those restrictions, and review any browser-facing tooling before reconnecting it through a backend.
Frequently asked questions
-
What did Eclair v0.14.4 fix for Lightning node operators?
It blocks malicious webpages from sending authenticated commands to an Eclair Lightning node through an operator's browser by rejecting requests carrying an Origin header.
-
What conditions were required for the browser attack?
The Eclair API had to be enabled and reachable by the operator's browser, with HTTP Basic credentials already cached in that browser.
-
What commands could the browser route reach?
Eclair's API can read node state, open and close channels, and send or receive payments, so authenticated commands could affect important node operations.
-
Do curl and eclair-cli stop working after the patch?
No. Maintainers say curl and eclair-cli do not send the Origin header, so their ordinary API requests continue to work.
-
Why are loopback binding and authentication still necessary?
The Origin check is not an authorization system because non-browser clients can omit the header. Eclair recommends keeping the API bound to loopback and maintaining authentication and network restrictions.
CryptoSlate