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

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.

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:

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...

[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.

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

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

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

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!

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

What's Changed

This is a hotfix release addressing build and protocol correctness issues found shortly after v26.04.

Fixed

• Gossip: Malformed channel_announcement messages where node_id_1 is not lexicographically less than node_id_2 are now rejected per BOLT spec (lightning/bolts#1333), preventing gossip store corruption and stress on readers. ([#9082])
• Build: Fixed printf format specifiers for splice weight logging (%zu for size_t) across lightningd, channeld, and the spender plugin, resolving -Werror/-Wformat failures in Docker and 32-bit ARM cross-compilation. ([#9083], [#9086])
• Build: Removed __int128 usage from bookkeeper currency rate math, restoring builds on 32-bit targets (armv7). ([#9085])

Contributors

Thanks to the Core Lightning team for their work on this release
An enormous thanks to the Core Lightning team:
@rustyrussell, @ShahanaFarooqui, @sangbida, @cdecker, @nepet, @Lagrang3, @daywalker90, @nGoline and @niftynei

This release has been named by @Chand-ra

Highlights for Users

• bkpr-report introduces a more flexible way to summarize Bookkeeper income, making it easier to break down earnings by category and period.
• New command splicein allows for convenient splicing funds into a channel.
• New command spliceout for easily splicing out of channels.
• New ability to "cross-splice" between two channels by specifying a second channel id as the destination of spliceout.
• You can now add a note when paying (payer-note in xpay).
• listpeerchannels can filter by channel_id, so you can zoom in on one channel without parsing the full list.
• Improved payment reliability through parallel pathfinding and multiple bug fixes in askrene.
• offer now includes a fronting_nodes option, while the new payment-fronting-node config allows you to specify preferred peers that help route payers to your invoices and offers across both BOLT11 and BOLT12 flows.
• Offer-related RPCs now expose decoded descriptions directly, making it easier to inspect, debug, and understand incoming and outgoing offers without manual decoding.
• gossipd offloads gossip_store compaction to a helper, improvin startup time especially for larger nodes while keeping the store around ~200MB.
• New currencyrate plugin exposes a currencyconvert RPC, enabling real-time conversion between Bitcoin and fiat currencies directly within Core Lightning.
• Most binaries are ~20% smaller .
• keysend now uses a final CLTV of 42 (instead of 22), improving compatibility with LDK nodes.

Highlights for Developers

• clnrest-register-path allows plugins to register custom HTTP endpoints at runtime, enabling dynamic REST APIs without restarting the node.
• bcli plugin is now synchronous: Simplifies the codebase and improves reliability of Bitcoin backend interactions by removing async complexity and queueing.
• Core Lightning builds are reproducible/deterministic on Fedora targets.
• Plugin options can now accumulate multiple values ("multi": true).
• STRICT tables and additional safety pragmas improve correctness and catch issues earlier during development.
• Lightningd now uses a more efficient ring buffer for logs, reducing overhead and simplifying log handling.
• Peer messages are now padded to a uniform length, mitigating traffic analysis and making it harder to infer node activity from message sizes.

Protocol Updates

• Splicing is now enabled by default!
• Legacy onion format support is removed (aligned with current interop, e.g. recent LND behavior).
• A splicing fix avoids an occasional hang when there is a pending closing HTLC during splice.

See the changelog for full details

Since v25.12 we’ve had 421 commits in 110 days by 23 authors

A special thanks to our three first time contributors:

@ScuttoZ
@Raimo33
@TatianaMoroz
@dovgopoly
@erdoganishe
@Nazarevsky

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