News

How a flood of pings could knock a Lightning node over

A researcher found he could crash someone else's Lightning node by asking it the same question thousands of times and then refusing to listen to the answers. The fix shipped a year ago. He only explained how it worked in August.

4 min readCore Lightning
How a flood of pings could knock a Lightning node over

What happened

On 27 August 2026 a developer named Erick Cestari published how he crashed a Lightning node by being annoying at it. He connected to the node, asked it the same simple question over and over, and then plugged his ears. The node kept writing down answers nobody was collecting until it ran out of memory and the computer killed it.

He found it by accident, while building his own version of the software that Lightning nodes use to talk to each other. He reported it privately on 25 August 2025 and waited a year before saying anything in public.

What it changes

Lightning is a network of computers that pass bitcoin payments to each other, so that small payments do not each need their own space in a block. Those computers are called nodes, and they are constantly checking that the neighbours they are connected to are still alive.

The way they check is a ping. One node sends a ping, the other sends back a pong, and the first one knows the line is still up. There is one odd detail in the rules: the node sending the ping gets to say how big the reply should be. It can ask for a pong of up to 65,531 bytes, which is about as much text as a short chapter of a book.

Cestari's attack uses that. Connect to a node, ask for the biggest possible pong, and ask again, thousands of times, without ever reading a single reply. The node is polite. It writes every pong and stacks them up waiting to send them. The stack has no limit. On a small server with 2 GB of memory, one attacker was enough to fill it; a hundred pretend neighbours did it faster.

The interesting part is why the node had no limit here and does everywhere else. Core Lightning splits its work between several programs. The one that owns the connection is called connectd, and when it hands a message to one of the others it waits for that program to be ready first. Engineers call that backpressure: you stop taking new work until you have finished the last lot. A supermarket does the same thing when it stops letting people onto a full escalator.

Pings never went to another program. connectd answered them itself, so it never passed through the gate, so nothing ever told it to slow down. One shortcut around one gate was the whole bug.

The attacker needs almost nothing to do this. No open payment channel, no bitcoin, not even a real identity: just enough of a handshake to be treated as a neighbour.

What it does not change

Nobody's coins were taken, and this bug could not take them. Crashing a node is not the same as spending from it. The keys stay where they were, and the node comes back up when someone restarts it.

The fix is also old news. It went out in Core Lightning v25.09 on 2 September 2025, eight days after the report, and anyone who has updated in the last year has been safe the whole time. The release notes did not mention it, which is normal: naming a security fix in a changelog tells attackers exactly where to look while most people are still running the old version.

It is not nothing, though, and it would be wrong to file being knocked offline under harmless. A Lightning node that is down cannot watch the chain, and watching the chain is part of how it protects itself. If the neighbour you have a channel with tries to close it by publishing an old, more favourable version of your shared balance, you get a window to catch them and take the whole channel as a penalty. You cannot catch anything while your node is being restarted. Knocking someone offline first is a real step in a real attack, even when the crash on its own steals nothing.

Context

The gap here is a year: fixed in eight days, explained twelve months later. That is deliberate, and it is the same argument Blockstream made in August when it shipped a Core Lightning security release with the source code held back for two weeks. A fix is a map. Publishing the map before people have moved tells the wrong readers where the treasure was.

Cestari found this while writing his own implementation of the same protocol, which is the ordinary way these things get found. Somebody reads the rules closely enough to build from them and notices a sentence that nobody had pushed on. That is an argument for more than one implementation existing, and it is a better one than any of the tribal versions.

Newsletter

Bitcoin, without the noise

What happened in Bitcoin, what it actually changes, and the sources so you can check us. One issue at a time, straight to your inbox.

  • One email per issue, never a drip campaign
  • No tracking pixels and no shared addresses
  • Unsubscribe from any issue in one click

Get the next issue

One email per issue, no tracking pixels, and unsubscribe from any of them. We do not share your address. Privacy policy