CLN Binary Signature Check

On 26-08-2026 I saw a post by calle informing of an urgent critical vulnerability with Core Lightning (CLN) for which users are recommended to turn their nodes offline (with --offline) and updating to a binary for which the source patches are under 14 day embargo (kept private).

This release ships binaries only, the source is embargoed until 2026-09-11. Given it's not possible to build the release yourself I strongly recommend that you run in offline mode (--offline)

I wouldn't update to unreproducible binaries as an emergency fix - a project maintainer's github/signing accounts could be compromised and you end up installing malware.

Given this, I wanted to verify who had signed off on the v26.06.7 release (published 2026-08-28 by @nGoline). The release has four signatures on SHA256SUMS-v26.06.7 - we can check that the signatures are genuine, then we can check that the keys genuinely belong to the people purported to sign, finally we should check with those people that they were the individuals who signed (and not someone who had a copy of their key).

Checking typical release signature policy

CLN has no fixed release-signing policy, looking at the past releases we see a range of signers.

[1] signature asset misnamed SHA256SUMS.ascD9200E6CD1ADB8F1.
[2] machine key only, no human signature.
[3] Andezion's key created the day of signing, never added to contrib/keys.
[4] binary-only release, source embargoed to 2026-09-11.

Notes

• "Farooqui" spans three successive keys
• "Project key" is cln@blockstream.com
• Extracted from each release's SHA256SUMS*.asc with gpg --list-packets, 2026-08-29.

If at all possible projects should have a consistent signing policy. Because this is not the case for CLN it is difficult to know what to expect from a legitimate emergency binary release.

Checking the manifest signatures

We check the release manifest against the in-tree keys by running this following command which clones the repository, imports the GPG keys and checks the signatures.

git clone --depth 1 https://github.com/ElementsProject/lightning
for k in lightning/contrib/keys/*.txt; do gpg --import "$k"; done
curl -LO https://github.com/ElementsProject/lightning/releases/download/v26.06.7/SHA256SUMS-v26.06.7
curl -LO https://github.com/ElementsProject/lightning/releases/download/v26.06.7/SHA256SUMS-v26.06.7.asc
gpg --verify SHA256SUMS-v26.06.7.asc SHA256SUMS-v26.06.7

We check when each of these keys were added to the contrib/keys/ folder.

Christian Decker's key has been present since 2021, and Peter Neuroth's key since 2023. The other keys were added within the last 3 months - while not an outright issue we should take care to carefully review these keys as they could have been added by a malicious party in anticipation of releasing a malicious binary with their signatures.

Next up, can must verify whether the keys belong to the people they claim to (and could those keys have been substituted recently).

Verifying Decker's key

Decker's key (B731 AAC5 21B0 1385 9313 F674 A26D 6D9F E088 ED58) was created 2015-11-20. The subkey that signed v26.06.7 also signed CLN commits from November 2016 through June 2018 (5 commits).

The key carries 38 third-party certifications. Fetching each certifier key from public keyservers and running gpg --check-sigs gives 31 VALID certifications. The dates cluster around real events (the 2018-03-07 to 03-13 block is the CoreDev Tokyo keysigning).

Keyservers are unauthenticated, so a valid certification only proves that a key labeled "Pieter Wuille" signed Decker's key. To reduce the risk of these keys being fake we need to cross verify these keys too. We can compare the certifier fingerprints against key registries maintained by a different project with different maintainers:

• bitcoin/bitcoin contrib/gitian-keys/keys.txt at tag v0.21.0, frozen since January 2021
• bitcoin/bitcoin contrib/verify-commits/trusted-keys
• bitcoin-core/guix.sigs builder-keys

Eleven certifier keys are a match:

Forging this chain would require compromising bitcoin/bitcoin's git history plus roughly a dozen Bitcoin Core developers' keys, years before this release existed.

Decker's signature on v26.06.7 is therefore established independently of anything that happened in 2026 and independently of the ElementsProject GitHub org.

However, we can not rule out the possibility that Decker's computer was compromised, and his key was stolen and used by a malicious party to push a malicious binary signed with his genuine key. This is why it's important to check additional keys.

The other three keys

Peter Neuroth

His key dates from August 2021 and he committed it to contrib/keys himself in November 2023. Matching copies sit on his GitHub account and keyserver.ubuntu.com. The key signed five release manifests between v23.05 and v24.02.1 (on the latter it was the only signature) then produced nothing observable for 29 months - none of the twelve intervening manifests, and no signed commits in either lightning or greenlight (he doesn't sign commits, his 391 across both repos are all unsigned).

daywalker90

Daywalker90 has years of CLN commits and a well-known plugin catalogue but the key signing this release was created on 2026-06-04 and added to contrib/keys the same day, by him. The key has only self-signatures. It signed the v26.06.1 and v26.06.6 manifests and one commit in July, and copies match on his GitHub account and keyserver.ubuntu.com. An attacker who took over this account in June could have manufactured the above evidence.

nGoline

First contributed in May 2026 and joined the core team with v26.06; his key predates that (June 2025), and its signing subkey signed nine CLN commits from 2026-05-12 and the v26.06.1 manifest before being added to contrib/keys on 2026-06-05. It's on keys.openpgp.org with a verified email. Its one third-party certification (present only in the copy he uploaded to his own GitHub account) was made the day the key was created, by a key absent from both major keyservers, so it can't be verified or attributed. The copy in the repo has an expired signing subkey (the refreshed copy on his GitHub account runs to 2027). Same manufacturability window as daywalker90.

Other Notes

• The v26.06 through .2 tags carried Blockstream's Madeline Paech signature, whereas the v26.06.7 git tag is lightweight commit unsigned.
• The v26.06.6 manifest carries a signature from Vladyslav Doronchenkov (@Andezion), a first-time contributor whose key was created and used the same day and was never added to contrib/keys .

What the signatures do not cover

Assuming the signatures are authentic this says nothing about the build machine, the toolchain, or the contents of the withheld diff. Nobody outside the team can review the code during the embargo and the binaries cannot be reproduced today. They may be possible to reproduce when the embargo is lifted on 2026-09-11.

Also, note that the release notes state that the binaries were not built with default optimisation settings, so build parameters will also be needed.

The signed manifest does include a sha256 checksum commitment (b313d207e53f1e2dbf9fbac79d5af48c352e874a653390bddb81b52795a153dc) for the future source archive (clightning-v26.06.7.zip), which will allow after-the-fact verification that the published source matches what was committed to now.

Conclusion

Of the four signatures

• Decker's key has longstanding provenance since 2015
• Neuroth's key had been dormant for 29 months before this release, but has existed since 2021 with five release signatures in 2023–24)
• Daywalker90 & nGoline have only recently been active (the last 3 months).

As such, the release's authenticity rests primarily on Decker's key. We should seek confirmation from Decker that he made his signature. While an in person verification would be preferable, we have a verification from an x post.

Trust

Remember, the verification performed here was of the signatures only. For a binary-only, source-embargoed, currently-irreproducible release, you are fully trusting the team and their build infrastructure.

Appendix A: certification audit of Decker's key

Status per certifier after importing all certifier keys from keyserver.ubuntu.com and keys.openpgp.org. VALID means gpg --check-sigs verified the certification cryptographically.

Appendix B: reproducing the checks

# Key provenance inside the repo (needs full history)
git -C lightning fetch --unshallow --filter=blob:none
git -C lightning log --follow -- contrib/keys/pneuroth.txt      # added 2023-11-29
git -C lightning log --author=Decker --format='%H %GK %ad' | awk '$2!=""'  # signed since 2016

# Prior-release continuity
curl -L https://github.com/ElementsProject/lightning/releases/download/v26.06.1/SHA256SUMS-v26.06.1.asc \
  | gpg --list-packets | grep "issuer key ID"

# Audit certifications on Decker's key
gpg --list-sigs --with-colons B731AAC521B013859313F674A26D6D9FE088ED58 \
  | awk -F: '$1=="sig"{print $5}' | sort -u | while read k; do
    curl -s "https://keyserver.ubuntu.com/pks/lookup?op=get&search=0x$k" | gpg --import
    curl -s "https://keys.openpgp.org/vks/v1/by-keyid/$k" | gpg --import
  done
gpg --check-sigs B731AAC521B013859313F674A26D6D9FE088ED58

# Cross-match certifier fingerprints against Bitcoin Core registries
curl -sO https://raw.githubusercontent.com/bitcoin/bitcoin/v0.21.0/contrib/gitian-keys/keys.txt
curl -sO https://raw.githubusercontent.com/bitcoin/bitcoin/master/contrib/verify-commits/trusted-keys
git clone --depth 1 https://github.com/bitcoin-core/guix.sigs
# then compare full 40-hex fingerprints from `gpg --list-keys --with-colons`