ACINQ's Eclair has merged fixes for two vulnerabilities that let a node lose Bitcoin to mining fees during channel funding and splicing. The first repair closed a peer-initiated replace-by-fee (RBF) hole in dual-funded channel opens and splices; the second hardened Eclair-signer mode against a lying Bitcoin Core backend. Both landed on the master branch — PR #3388 on Oct. 2 and PR #3390 on Oct. 5.
The timing matters for anyone running a build from the project's release page. As of Oct. 12, Eclair's release page still pointed to September's v0.14.3 as the latest packaged version, so the October fixes aren't in a tagged release yet. Operators need to check whether their installed build actually contains the changes.
The RBF overcharge
Dual funding and splicing let two peers jointly contribute to a channel's funding transaction. PR #3388 deals with what happens when one side tries to bump the fee. Without the fix, a malicious peer could force an arbitrary mining fee rate onto the contributing node while putting nothing of its own into the transaction. The node's money doesn't go to the attacker — it goes to miners as fees. Still gone, just not stolen directly.
The repair rejects RBF attempts above the maximum funding fee rate Eclair recommends to its peer. Two exceptions survive: when the peer buys liquidity and pays the fees for Eclair's inputs, or when the Eclair node contributes no funds to the transaction. Bitcoin Optech's Oct. 9 newsletter flagged both changes as closing protection gaps during dual funding and splicing.
The signer that could lie
PR #3390 covers a separate configuration. In Eclair-signer mode, Bitcoin Core's backend (bitcoind) picks coins and builds transactions while Eclair keeps the keys and signs. That split is the point — but it assumes the backend tells the truth about fees.
A compromised backend could report a fee inside budget while constructing a transaction that actually paid more, including by dropping the change output. The unassigned input value then becomes a miner fee, spending funds without paying an attacker's address.
When a fee budget is supplied, the repair calculates the actual fee from the amounts of the coins being spent, fetched by transaction ID to authenticate their values. It checks the backend's reported fee against that calculation, applies the budget to the actual fee, verifies that Eclair's rebuilt contributions pay the same verified fee, and rejects invalid change-output positions.
Not the September bug
These are distinct from the cooperative-closing fee flaw covered in CryptoSlate's September report and the restart denial-of-service issues covered Oct. 2. Different attack surfaces, different code paths.
The affected configurations are Eclair's dual-funding, splicing, and signer setups — not every node runs them, but the ones that do are the ones the patches are for.
The next concrete thing is a tagged release. Until Eclair ships a version dated after Oct. 5, the release page remains the wrong place to check. Operators building from master can confirm the October changes are in; everyone else is waiting on ACINQ to cut the next version.
