Eclair patches browser attack that submits commands to Lightning nodes

A webpage can act through an operator’s logged-in browser, which puts channel funds and payment flows in reach of a plain HTML form. Eclair’s fix changes how browser-based dashboards connect to the node, so anyone running a Lightning node needs the details.

• Eclair v0.14.4, released Oct. 15, returns HTTP 403 to any API request carrying an Origin header.
• Exposure requires an enabled API reachable by the browser, with HTTP Basic credentials already cached there.
• Operators should upgrade and keep the API on loopback; restarting does not require closing channels.

• 403 HTTP status returned on any Origin-bearing request, instead of running the command
• Oct. 15 v0.14.4 release date, one month after the browser fix merged
• Sept. 15 date pull request #3380 merged, a month before release shipped
• v0.14.4 release bundling browser fix with funding-fee and signer repairs, not standalone

Eclair, ACINQ’s Bitcoin Lightning node software, shipped v0.14.4 on Thursday (October 15), two days ago, to stop malicious webpages from issuing authenticated node commands through an operator’s browser, CryptoSlate reported. The v0.14.4 release is the version operators are being told to install now.

A cached login lets a webpage submit a plain HTML form to the node

The exposure depends on an enabled Eclair API that the operator’s browser can reach. HTTP Basic authentication must also be cached in that browser. Eclair’s node API can read node state, open and close channels, and send and receive payments.

Eclair’s v0.14.4 release notes explain the mechanism. Cached authentication lets a malicious webpage submit a plain HTML form to the node’s API, and the browser attaches the saved credentials automatically.

The attacker cannot read the response. The authenticated command still reaches the node.

Any request with an Origin header now gets HTTP 403 before the API route runs

The patch returns HTTP 403 whenever a request carries an Origin header, regardless of its value. The check fires before the API route runs. The browser fix merged on Sept. 15 in pull request #3380, one month before the release.

The restriction also affects legitimate browser interfaces, including those hosted at the same origin as the API. Those frontends now need an intermediary backend between the browser and Eclair. The reporting does not include comment from developers of browser frontends affected by the change.

Ordinary command-line access continues. The maintainers say curl and eclair-cli do not send the Origin header, so their normal API requests are unaffected.

Operators can upgrade without closing channels, and pm47 still wants loopback binding

The Origin check does not replace authentication or network restrictions. A non-browser client can omit the header, so its absence does not establish that a request is authorized.

Eclair maintainer pm47 says the API should remain bound to loopback, restricting network access to the local machine.

The browser fix is included in v0.14.4 alongside the funding-fee and signer repairs CryptoSlate covered on Monday (October 12). Maintainers recommend upgrading. They say operators can stop Eclair, install the update and restart without closing their Lightning channels.

The BlockWest read. We read this as a cost shift onto anyone who built a dashboard on Eclair’s API. Node operators absorb a restart-only upgrade, while frontend developers must stand up a backend between the browser and the node. For operators, the Origin check is one layer, and loopback binding plus authentication still carry the rest of the protection.

The open question is how frontend maintainers respond, since none are quoted in the reporting. Operators running a browser dashboard against Eclair must add a backend intermediary before it works on v0.14.4. Until they do, the command-line tools are the path that keeps working.

BlockWest is a news publication. Nothing here is investment advice. Read our disclaimer and editorial policy.