v26.06.10 Quantum-Resistant Lightning Channel VII

This 26.06.10 point release includes fixes for vulnerabilities responsibly reported by a number of sources, alongside a set of bug fixes. We strongly recommend upgrading to this release.

As with 26.06.8 and 26.06.9, there is no embargo period: the release and it's fixes are available immediately. We have again temporarily withheld the tests for the security fixes, to make it harder to quickly turn the fixes into working exploits and to give users and network participants more time to upgrade before more technical detail is published.

The full list of changes is in the CHANGELOG.

We strongly encourage everyone to upgrade to 26.06.10 as soon as practical.

Highlights

• Security fixes in dual funding and splicing (including signature checks on the peer's tx_signatures), onchaind HTLC resolution, gossip resource limits, connectd, runes and commando, plugin hooks and hsmd, plus a number of remote-crash and hardening fixes.
• xpay now budgets the number of hops so a payment's onion fits, and fails early when it can't. askrene slightly prefers shorter routes and fewer parts.
• Reproducible amd64, arm64 and armv7 binaries for Ubuntu 22.04, 24.04 and 26.04 (amd64 also for Fedora 40), each architecture with its own signed manifest.

Notes for operators

• Channel opens: a peer's dust_limit_satoshis above 5000sat is refused, and for dual-funded opens a peer dust_limit_satoshis above the channel reserve is refused too. A v2 open requesting option_zeroconf is refused unless you're configured to accept zero-conf channels from that peer, as v1 opens already were.
• bkpr-dumpincomecsv: csv_file must now be a plain filename ending in .csv. The file is written in the node's network directory, and never through a symlink.
• connect with a host name now resolves it without blocking, and fails when --disable-dns is set.
• Plugins: a hook handler that fails or panics (pyln-client, cln-plugin) now gets a safe default reply instead of crashing or hanging lightningd. commitment_revocation and db_write failures still stop the node.
• Splicing: an RBF of a pending splice now uses at least 25/24 of its feerate, which peers such as Eclair require.
• currencyrate: IPv6 proxy addresses are now rejected.
• Offers: CLN now limits recurrence parameters to reasonable values; see the offer and fetchinvoice documentation.
• Dual funding (--experimental-dual-fund) remains experimental. Zero-conf channels with peers you do not trust are discouraged.
• Nodes that have run development (master) builds cannot downgrade to a 26.06.x release: the database schema is newer.

Recommended rune practices

Several fixes in this release concern runes and commando, so this is a good moment to review the runes issued on your node:

• Bind runes used over commando to the node that uses them, with an id restriction, so they can't be used from anywhere else: lightning-cli createrune restrictions='[["id=<nodeid of the app>"]]'.
• Rotate runes you can't account for: blacklist them with blacklistrune and issue new ones with tighter restrictions.

Docker images

Multi-platform images (linux/amd64, linux/arm64, linux/arm/v7) are on Docker Hub:

• elementsproject/lightningd:v26.06.10 (also tagged latest)
• elementsproject/lightningd:v26.06.10-vls, with the VLS remote signer (also tagged latest-vls)

docker pull elementsproject/lightningd:v26.06.10

Verifying the release

Check the signatures against the manifest explicitly (pass both files), then the checksums:

gpg --verify SHA256SUMS-v26.06.10.asc SHA256SUMS-v26.06.10
sha256sum -c SHA256SUMS-v26.06.10 --ignore-missing

Use SHA256SUMS-v26.06.10-arm64 / -armv7 and their .asc for the ARM tarballs. The maintainers' keys are listed in SECURITY.md; instructions for reproducing the builds are in the reproducible builds guide.

Thanks

This point release includes fixes for issues responsibly reported by:

• Vincenzo Palazzo
• labrat-guy
• Erick C
• Paul Lamb
• Kyle W. Santiago
• The Bitcoin Red Team
• 0xaudron
• whkim0 and Ahmadsm2005
• Ben Carman
• Michael1011
• Nishant Bansal
• Nuhiat Arefin
• Matt Morehouse
• Niklas Gögge
• 3cola
• Project Loupe
• haoxucu
• moinaiagent
• and others who prefer not to be named

And to the core-maintaining team and open source contributors who have triaged, analyzed, reproduced, fixed, verified, reviewed, tested over and over and over every.single.day: fix after fix after fix:

• nGoline
• Andezion
• cdecker
• Daywalker90
• EduardMikhrin
• Jaonoctus
• Lagrang3
• Sangbida

v26.06.9 Quantum-Resistant Lightning Channel VI

This 26.06.9 point release includes a set of bug fixes alongside fixes for vulnerabilities responsibly reported by a number of sources, and fixes a gossip regression introduced in 26.06.8. We strongly recommend upgrading to this release.

As with 26.06.8, there is no embargo period: the release and its fixes are available immediately. We have again temporarily withheld the tests for the security fixes, to make it harder to quickly turn the fixes into working exploits and to give users and network participants more time to upgrade before more technical detail is published.

The full list of changes is in the CHANGELOG.

We strongly encourage everyone to upgrade to 26.06.9 as soon as practical.

Highlights

• Security fixes in channel reestablishment, splicing, HTLC handling during shutdown, onion handling, onchaind, gossip range queries, runes and setconfig, plus several remote-crash and hardening fixes.
• Gossip CPU throttle regression fixed: in 26.06.8, busy nodes could throttle their peers on ordinary gossip, pings and onion messages, delaying channel traffic. Now only gossip queries count against the budget.
• New: reproducible arm64 and armv7 binaries for Ubuntu 22.04, 24.04 and 26.04, alongside the existing amd64 builds. Each architecture has its own signed manifest: SHA256SUMS-v26.06.9 (amd64 and source zip), SHA256SUMS-v26.06.9-arm64 and SHA256SUMS-v26.06.9-armv7, each with an .asc carrying the maintainers' signatures.

Notes for operators

• Runes: a rune with restrictions can no longer create a new rune without them (createrune without a rune), nor relist blacklisted runes (blacklistrune with relist). Use an unrestricted rune for those. invokerune and destroyrune are now checked as createrune and blacklistrune.
• listconfigs now shows ... instead of the value of wallet, recover, tor-service-password, bitcoin-rpcpassword and the old bookkeeper-db, for every caller.
• Splicing: when we accept a splice, we now enforce the negotiated feerate on the splice transaction.
• Dual funding (--experimental-dual-fund) remains experimental. Zero-conf channels with peers you do not trust are discouraged.
• Nodes that have run development (master) builds cannot downgrade to a 26.06.x release: the database schema is newer.

Verifying the release

Check the signatures against the manifest explicitly (pass both files), then the checksums:

gpg --verify SHA256SUMS-v26.06.9.asc SHA256SUMS-v26.06.9
sha256sum -c SHA256SUMS-v26.06.9 --ignore-missing

Use SHA256SUMS-v26.06.9-arm64 / -armv7 and their .asc for the ARM tarballs. The maintainers' keys are listed in SECURITY.md; instructions for reproducing the builds are in the reproducible builds guide.

Thanks

This point release includes fixes for issues responsibly reported by:

• The Bitcoin Red Team
• Michael1011
• Daywalker90
• erickcestiari
• Ouicate
• rustyrussell
• Project Loupe
• moinaiagent
• vincenzopalazzo
• NishantBansal
• Morehouse
• ksedgwic
• dergoegge
• StartOS
• Amperstrand
• ZezzebbulTheMysterious

Thanks to our Open Source Contributors for their assistance with the fixes included in .9

• rustyrussell
• w3lld1
• niftynei
• vincenzopalazzo
• dovgopoly
• erickcestiari
• enaples
• NicolasDorier

And to the maintaining team who worked tirelessly on this release:

• nGoline
• cdecker
• Daywalker90
• lagrang3
• sangbida
• Andezion
• jaonoctus
• EduardMikhrin
• nepet

v26.06.8 Quantum-Resistant Lightning Channel V

This 26.06.8 point release includes a set of bug fixes alongside fixes for vulnerabilities responsibly reported by a number of sources. We strongly recommend upgrading to this release.

There is no embargo period for 26.06.8. The release and the associated fixes are available immediately. However, we have temporarily withheld a small number of tests to make it more difficult for prospective attackers to identify, reverse-engineer, and exploit the underlying vulnerabilities.

This measure is intended to give users and network participants more time to upgrade before additional technical detail becomes available.

Notes for operators

• Dual funding (--experimental-dual-fund) remains experimental. Zero-conf channels with peers you do not trust are discouraged.
• Nodes that have run development (master) builds cannot downgrade to a 26.06.x release: the database schema is newer.

Thanks

This point release includes fixes for issues responsibly reported by:

• Bitcoin Red Team
• @0xaudron
• @erickcestari
• @Ahmadsm2005
• @whkim0
• @ksedgwic
• @jaonoctus
• @vincenzopalazzo
• @labrat-guy
• @michael1011
• @project-loupe
• @Crypt-iQ
• @btweenthebars
• and reporters who chose to remain anonymous

To the open source contributors who assisted with fixes and reviews:

• @rustyrussell
• @ksedgwic
• @ddustin
• @niftynei
• @vincenzopalazzo
• @Amperstrand
• @morehouse
• @ThomsenDrake
• @w3lld1

And to the maintaining team who worked on this release:

• @nGoline
• @cdecker
• @daywalker90
• @Lagrang3
• @Andezion
• @sangbida
• @jaonoctus
• @nepet

v26.06.7 Quantum-Resistant Lightning Channel VII

This point release includes fixes for vulnerabilities responsibly reported by a number of sources. It also comes at a time when increasingly capable AI models are being used to identify potential vulnerabilities in open-source code, significantly increasing the volume and pace of security reports.

The potential impact and associated risks are front of mind for everyone involved, not least the remediation team who have worked tirelessly to triage, resolve, and compile this release.

This embargo period will last for two weeks. The source code will not be published until 14 days have passed. During this time, we strongly encourage everyone to upgrade. At the end of this two-week period, the full release details will be made available.

This delay is designed to reduce the chances of prospective attackers reverse-engineering the fixes and exploiting them before the network can update.

The embargo has ended. The source for this release was published on 2026-09-11T11:42Z. The v26.06.7 tag now points at the commit these binaries were built from, and the source archive clightning-v26.06.7.zip is attached below.

Upgrading

Download the tarball for your platform below, verify it (see next section), then unpack it over your existing installation:

sudo tar -xvf <release>.tar.xz -C /usr/local --strip-components=2

Restart lightningd afterwards. No database migration steps are required beyond the automatic ones applied at startup.

Docker users

Docker images for this release are published and correct.

Tag	Digest
v26.06.7, latest	sha256:0421a5f0d1b2e1ad639edfa17d777816040e3850d91bae7f2d32186d9c1e6da4
v26.06.7-vls, latest-vls	sha256:6a5e05c13a65613f8c0fe3830c60248a6724e7206c1c23dd26ac2e98a3e72c1f

Platforms: linux/amd64, linux/arm64, linux/arm/v7.

If you pulled v26.06.7, latest, v26.06.7-vls or latest-vls before reading this, check the digest and re-pull if it does not match the table above.

Between 28 August 16:04 UTC and 1 September, those tags served images that reported v26.06.7 on startup but did not contain the fixes in this release. They were published automatically by CI from a placeholder tag. They have been replaced, and the incorrect manifests are no longer referenced by any tag.

Check what you are running:

docker image inspect --format '{{index .RepoDigests 0}}' elementsproject/lightningd:v26.06.7

If the digest does not match the table above, re-pull:

docker pull elementsproject/lightningd:v26.06.7
docker pull elementsproject/lightningd:latest

Users pinned to v26.06.6 or earlier were never affected.

VLS users

v26.06.7-vls carries the same signer as v26.06.6-vls, VLS v0.14.0, unchanged by this release.

The signer requires VLS_CLN_VERSION to match the node it talks to. Update it from v26.06.6 to v26.06.7 when you upgrade, or remote_hsmd_socket will refuse to start.

Notes on these images

• They are assembled from the signed release tarballs above rather than compiled from source, so the binaries in the container are the ones covered by the signed manifests.
• linux/arm/v7 has no release tarball. Its binaries are cross-compiled separately and are not covered by a signed manifest.
• The images carry no provenance or SBOM attestations.
• CLN now installs to /usr/bin and /usr/libexec/c-lightning; previous images used /usr/local. Symlinks from the old locations are included, so hardcoded paths keep working.

Verifying your download

Every binary is covered by a signed manifest. Check the checksums first:

sha256sum -c SHA256SUMS-v26.06.7 --ignore-missing

Then the signatures:

gpg --verify SHA256SUMS-v26.06.7.asc SHA256SUMS-v26.06.7

SHA256SUMS-v26.06.7 covers the amd64 tarballs and is signed by maintainers. SHA256SUMS-v26.06.7-arm64 covers the arm64 tarballs and has its own signature file. Signing keys:

Signer	Fingerprint
nGoline	4E4A 142F 8BD3 C38A 56B3 62ED 578C AC08 4725 45C5
Christian Decker	B731 AAC5 21B0 1385 9313 F674 A26D 6D9F E088 ED58
Peter Neuroth	653B 19F3 3DF7 EFF3 E9D1 C94C C3F2 1EE3 87FF 4CD2
daywalker90	8A07 9421 A871 D0B1 0835 1193 7AB4 802E D5A6 39F3

Fetch them with gpg --recv-keys <fingerprint>, or from the contrib/keys/ directory of the repository once the source is published.
Fetch these keys from a keyserver, for example gpg --recv-keys <fingerprint>. Two of the four, Christian Decker's and Peter Neuroth's, are also in the contrib/keys/ directory of the source. The other two were added on master; the tree at this tag cannot change, since these artifacts are built from it.

A signature may report a fingerprint that differs from the one listed above. Signers use signing subkeys, and the reported fingerprint is the subkey of the listed primary. That is expected and is not a verification failure. gpg --verify resolves it for you once the primary key is imported.

Reproducing these binaries

The source for this release is now published: the v26.06.7 tag points at the tree these artifacts were built from.

These tarballs were not built with the repository's default optimisation level. configure defaults to -Og, and the release binaries were built at -O3. Checking out the tag and running the normal reproducible build will produce binaries that do not match the checksums above. COPTFLAGS=-O3 has to be passed explicitly.

tools/build-release.sh cannot pass it through, because it forwards only FORCE_MTIME, FORCE_VERSION and MAKEPAR into the build containers. The containers have to be invoked directly.

Start from a clean checkout of the tag with submodules initialised:

git clone https://github.com/ElementsProject/lightning && cd lightning
git checkout v26.06.7
git submodule update --init --recursive

This covers the amd64 tarballs. See the arm64 note below.

Build the base images once (contrib/cl-repro.sh, or docker build from contrib/reprobuild/Dockerfile.<dist>), then:

mkdir -p release
for d in jammy noble resolute; do
  docker run --rm -v "$(pwd)":/repo \
    -e FORCE_MTIME=2026-08-26 -e FORCE_VERSION=v26.06.7 -e MAKEPAR=8 \
    -e COPTFLAGS=-O3 cl-repro-$d
done

For Fedora:

DOCKERFILE=contrib/docker/Dockerfile.builder.fedora
FV=$(grep -oP '^FROM fedora:\K[0-9]+' $DOCKERFILE)
docker build --no-cache -f $DOCKERFILE -t fedora --load .
docker run --rm -v "$(pwd)":/src:ro -v "$(pwd)/release":/release \
  -e COPTFLAGS=-O3 fedora \
  /src/tools/build-release.sh --inside-docker v26.06.7 Fedora $FV amd64 8

Confirm the flag actually reached the compiler. The build log must contain:

Setting COPTFLAGS... -O3 -ffunction-sections

Do not infer it from tarball size. You can also check a finished binary:

strings -a usr/bin/lightningd | grep 'GNU C11'
# expect: GNU C11 ... -g -O3 -std=gnu11 ... -ffunction-sections

Then compare against the signed manifest:

sha256sum -c SHA256SUMS-v26.06.7 --ignore-missing

The arm64 tarballs cannot be reproduced from this tag

SHA256SUMS-v26.06.7-arm64 covers the three arm64 tarballs, and those signatures verify normally. Rebuilding them does not work from this source, because the tooling that produced them is not in this tree: the arm64 build script, the arm64 signing script, and the arm64 support in the contrib/reprobuild/ Dockerfiles are not part of the v26.06.7 source. That work is being upstreamed separately and is not included here.

Until it lands, the arm64 tarballs are verifiable by signature but not independently reproducible. The amd64 tarballs and the source archive are both.

Known caveats

• Fedora may not reproduce. build-release.sh rebuilds the Fedora builder image with --no-cache, and that image is FROM fedora:40 with a live dnf update and a wget of Bitcoin Core. Two people building days apart can pick up different toolchains. If every Ubuntu target matches and only Fedora differs, this is why. It predates this release.
• linux/arm/v7 has no release tarball. The Docker image for that platform is cross-compiled separately and is not covered by any manifest.
• Only linux/amd64 is reproducible from this source, per the arm64 note above.
• -O3 is a one-off for this release. It is deliberately not committed to the tree, so it cannot silently become permanent tooling. Future releases build at the default.

Verifying the source itself

Reproducing the binaries takes hours. Verifying that the source now published is the source that was signed in August takes minutes and needs no compiler.

SHA256SUMS-v26.06.7 has always contained a line for clightning-v26.06.7.zip, the complete source archive including submodules. That manifest was signed on 28 August, before the source was public, so the signature is a commitment made in advance to exactly the bytes published now.

git clone https://github.com/ElementsProject/lightning && cd lightning
git checkout v26.06.7
git submodule update --init --recursive
tools/build-release.sh --force-version=v26.06.7 --force-mtime=2026-08-26
sha256sum release/clightning-v26.06.7.zip
# b313d207e53f1e2dbf9fbac79d5af48c352e874a653390bddb81b52795a153dc

No extra flags are needed: the archive is source only, so -O3 does not apply, the file order comes from git ls-files, and permissions and timestamps are normalised by the script. It requires GNU coreutils, so it will not run on stock macOS.

Do not use GitHub's automatically generated "Source code (zip/tar.gz)" links for this. They are not signed, they are not covered by any manifest, they omit submodule contents, and their bytes depend on the tag object rather than only on the source. Use the `cli...

v26.06.6 Quantum-Resistant Lightning Channel VI

[26.06.6] - 2026-07-20: "Quantum-Resistant Lightning Channel VI"

v26.06.3, v26.06.4, and v26.06.5 had issues during publishing with the pypi releases and were deleted.

Fixed

• update pyln-proto's coincurve to a v21 fork to fix Python build environments (#9325)
• reject a channel that reuses an existing funding outpoint (#9318)

Contributors

Thanks to the Lightning team and our community contributors for their work on this release.

And, of course, to the core-Core Lightning team: @cdecker, @ShahanaFarooqui, @Lagrang3, @sangbida, @daywalker90, @nGoline, and @niftynei — carrying forward the work started by @rustyrussell, whose technical leadership and long-standing care for the project remain central to Core Lightning.

v26.06.2 Quantum-Resistant Lightning Channel II

This point release if recommended for all minimal OS setups, including docker images, that have no root certificates for TLS installed.

Fixed

• cln-currencyrate: include root certificates to fix the builder error on OS's without root certificates. (#9255)

Contributors

Thanks to the Lightning team and our community contributors for their work on this release.

Special thanks to @ddustin—still splicing, still appreciated! 🙌

And of course, to the core-Core Lightning team: @rustyrussell, @ShahanaFarooqui, @sangbida, @cdecker, @nepet, @Lagrang3, @daywalker90, @nGoline and @niftynei

v26.06.1 Quantum-Resistant Lightning Channel I

What's Changed

This point release fixes the bwatch plugin failure at registration.

Fixed

• Plugins: bwatch failed to register on startup after make install ([#9192])

Check out the updated Changelog

Contributors

Thanks to the Lightning team and our community contributors for their work on this release.

Special thanks to @ddustin—still splicing, still appreciated! 🙌

A shutout to the core-Core Lightning team: @rustyrussell, @ShahanaFarooqui, @sangbida, @cdecker, @nepet, @Lagrang3, @daywalker90, @nGoline and @niftynei

v26.06 Quantum-Resistant Lightning Channel

This release has been named by @enaples

Highlights for Users

• graceful command to prepare CLN for shutdown... gracefully!
• Added sendamount command, to make a payment specifying the desired amount to send instead of the amount to be received.
• We've started the cycle to deprecate pay and focus our efforts on xpay. xpay now handles pay command by default (use xpay-handle-pay=false to prevent this) and we now use xpay not pay for paying invoices made with invoicerequest().
• xpay now accepts label and localinvreqid parameters (like pay).
• xpay will now update for the current payment if it gets a channel_update in an error message.
• xkeysend command for keysend with modern routing support.
• invoice_creation notification now includes offer_id when the invoice is associated with a BOLT 12 offer.
• Removed fields no longer present in documentation / GRPC interfaces.
• Experimental payment proof implementation updated to latest draft
• gossipd made more robust against channel_update spamming.

Highlights for Developers

• JSON-RPC: createproof to create a payment proof for a (successful) BOLT12 payment.
• JSON-RPC: decode now supports the lnp payer proof format.
• Plugins: bwatch plugin (enable using plugin=bwatch)

Protocol Updates

• message-padding defaults to false, due to poor detection of broken implementations.
• We now wait 72 blocks, not 12, before closing channels (BOLT update)

See the changelog for full details

Since v26.04 we’ve had 236 commits in 42 days by 19 authors

A special mention to our three first time contributors:

@nGoline
@MSimeZ
@Andezion

A huge shout-out to @ddustin for his ongoing contributions and support. We truly appreciate your splicing—you really know how to keep things together! 🧬

An enormous thanks to the core-Core Lightning team:
@rustyrussell, @ShahanaFarooqui, @sangbida, @cdecker, @nepet, @Lagrang3, @daywalker90, @nGoline and @niftynei

v26.06rc2 Quantum-Resistant Lightning Channel

This release has been named by @enaples

Release Candidate 2 for cln v26.06

This RC builds upon RC1, with these changes:

• Removed fields no longer present in documentation / GRPC interfaces.
• Experimental payment proof implementation updated to latest draft
• gossipd made more robust against channel_update spamming.

See the changelog for full details

An enormous thanks to the core-Core Lightning team:
@rustyrussell, @ShahanaFarooqui, @sangbida, @cdecker, @nepet, @Lagrang3, @daywalker90, @nGoline and @niftynei

And of course, our invaluable open-source community!

v26.06 Release Candidate 1

Release Candidate 1 for Core Lightning v26.06

Highlights for Users

• graceful command to prepare CLN for shutdown... gracefully!
• Added sendamount command, to make a payment specifying the desired amount to send instead of the amount to be received.
• We've started the cycle to deprecate pay and focus our efforts on xpay. xpay now handles pay command by default (use xpay-handle-pay=false to prevent this) and we now use xpay not pay for paying invoices made with invoicerequest().
• xpay now accepts label and localinvreqid parameters (like pay).
• xpay will now update for the current payment if it gets a channel_update in an error message.
• xkeysend command for keysend with modern routing support.
• invoice_creation notification now includes offer_id when the invoice is associated with a BOLT 12 offer.

Highlights for Developers

• JSON-RPC: createproof to create a payment proof for a (successful) BOLT12 payment.
• JSON-RPC: decode now supports the lnp payer proof format.
• Plugins: bwatch plugin (enable using plugin=bwatch)

Protocol Updates

• message-padding defaults to false, due to poor detection of broken implementations.
• We now wait 72 blocks, not 12, before closing channels (BOLT update)

See the changelog for full details

Since v26.04 we’ve had 211 commits in 22 days by 17 authors.

A special mention to our three first time contributors:

@nGoline
@MSimeZ
@Andezion

An enormous thanks to the core-Core Lightning team:
@rustyrussell, @ShahanaFarooqui, @sangbida, @cdecker, @nepet, @Lagrang3, @daywalker90, @nGoline and @niftynei