Eclair disclosure shows why network parsers need explicit resource limits

A disclosure of already-fixed vulnerabilities

Researcher Matt Morehouse disclosed two Eclair denial-of-service vulnerabilities on 24 September 2026. According to the post, affected versions were 0.13.1 and earlier, and fixes were included in 0.14.0. One issue involved expensive feature parsing; the other involved accepting compressed gossip data without an appropriate expansion limit. This article covers the later public disclosure, not a newly shipped September patch. The supplied version guidance should be checked against the project’s current supported releases before an operator chooses an update target.

The defensive lesson is amplification of work

A network service can receive a small input that causes disproportionately expensive computation or memory use. Our interpretation is that message correctness and processing affordability need separate tests. Rejecting malformed data is useful, but a syntactically acceptable message can still consume more resources than the operator intended. Defensive review should therefore ask how many objects are created, how decompression is bounded and whether one peer can monopolize work needed to keep other connections healthy.

Why old compatibility paths deserve attention

Software sometimes stops sending an old format while continuing to accept it for compatibility. That leaves a path whose maintenance burden can become less visible. A useful engineering inventory would identify retained formats, their active users and the cost of removing or constraining them. This is not an argument to delete compatibility indiscriminately. It is a recommendation to give every accepted path an explicit owner and tests, rather than assuming that infrequent use makes it harmless.

What a node operator should verify

Identify the installed Eclair version through the normal administrative interface and compare it with official release guidance. Plan an update using the project’s backup and recovery procedures. After the change, confirm normal peer connectivity and the service’s expected payment operations. Record those observations separately from vulnerability remediation. A process starting successfully does not prove every dependent workflow works. Avoid running public proof-of-concept traffic against another operator or a live payment node merely to demonstrate that a historical flaw existed.

What this report does not claim

The disclosure describes the researcher’s findings and experiments. BijliCoin has not reproduced them, and this article does not establish how many nodes were exploited or whether any specific operator suffered an incident. A denial-of-service issue is also different from a demonstrated theft of funds. The practical outcome is a clear maintenance question: whether an exposed node runs a version containing the published fixes. Keeping the history precise prevents an old vulnerable version and a recent disclosure date from being conflated.

Sources and reading

• Matt Morehouse: Eclair denial-of-service disclosure (2026-09-24)