Core Lightning's 26.06.9 release of October 7, 2026 includes security fixes and repairs a gossip-throttling regression introduced in 26.06.8. Maintainers recommend upgrading. The immediate task for an operator is to identify the software actually running and follow the matching upgrade procedure; downloading an archive is not evidence that a live node has been updated.
Separate the release notice from your deployment record
A release page describes a published version. Your node has its own installation method, architecture and existing state. Keep those facts together before choosing a package or asking a hosting provider whether maintenance is complete. A web dashboard can remain familiar even when its underlying daemon differs from the release someone intended to install.
| Your situation | Evidence to obtain | Why it matters |
|---|---|---|
| You operate the node | Running version and deployment-specific update record | A downloaded file does not identify the running process |
| A provider operates it | That provider's applicable version and maintenance confirmation | A general upstream release is not its completion notice |
| You use an ARM build | Architecture-matched release and signed manifest | A different architecture has a different verification set |
| You ran development master builds | The official compatibility instructions for that database state | The release warns against downgrading newer schemas to 26.06.x |
| A payment was already in progress | Its identifier and actual payment record | Maintenance does not establish success or failure |
The table is an inventory, not a universal upgrade command. For example, a file labelled for one processor family should not be treated as verified merely because a checksum was copied from another release entry. Package selection, authenticity checks and deployment confirmation answer separate questions. Preserve all three in the maintenance record.
A checksum and a signed manifest serve different purposes
Core Lightning's reproducible-build documentation explains the release manifest, its file hashes and maintainer signatures. The 26.06.9 notes provide architecture-specific verification instructions. Follow the applicable signature checks and then the file checks, using the project's trusted verification procedure rather than a checksum pasted by an unknown sender.
A hash comparison can show that a file matches the manifest you possess. By itself, it does not establish who supplied that manifest. Equally, recognizing a familiar filename does not verify its contents. If a deployment service performs these checks for you, ask what release and verification record its maintenance confirmation covers.
The release fixes several things, not one universal payment error
The release describes changes affecting security, gossip handling and operator permissions. It does not diagnose every delayed payment as the 26.06.8 regression. Record a concrete symptom and the installed version before assigning a cause. Do not attach an invented vulnerability identifier or assume a different Lightning implementation needs the same package.
Review application permissions as part of maintenance
Operator notes include changes to rune permission handling. If another application accesses your node through restricted credentials, its maintainer should review the applicable behavior after upgrading. Do not solve an unexpected rejection by simply handing the application unrestricted authority. The desired operation and its permitted scope should remain explicit.
- Identify the actual deployment, architecture and running Core Lightning version.
- Read the official release and compatibility requirements for that installation, including development-build warnings.
- Use its trusted package-verification and maintenance procedure rather than a command from a private message.
- After deployment, record the version actually running and review affected integrations with their intended permissions.
- For any pre-existing payment, inspect its own result before deciding whether another payment is necessary.
A useful non-secret support record contains the running version, platform, time of maintenance, visible error and relevant payment identifier. It should not include recovery secrets, private keys or unrestricted access credentials. If a provider controls the installation, ask that provider for the deployment evidence instead of trying to replace its wallet from a local backup.
A timeout remains a payment question
Imagine a request timed out before maintenance. The software being newer afterward does not tell you whether that original request completed, remained pending or failed. Check its durable payment record. Treating the update itself as permission to pay again can turn an unresolved observation into a second, separate operation. This example is hypothetical, not a reported customer case.
Return to a later exchange with its own evidence
For an ordinary swap, read the supported assets and exchange process. The Core Lightning release does not establish KOT.CASH deployment details, Lightning-route availability or a change to an existing order. A payment's actual status and the receiving order's conditions remain the relevant evidence.
Check whether a later stable release or advisory supersedes this dated notice. This review reproduces no attack procedure and has not downloaded a binary, inspected a private node, tested an exploit or carried out an upgrade. Its purpose is to make the operator's verification record precise enough to distinguish a release from a completed deployment.
FAQ
Does a Core Lightning GitHub download prove my node was updated?
No: package verification and the version actually running are separate checks. Keep a deployment record covering the live installation.
Who should check the Core Lightning node security release?
The operator responsible for the actual installation should assess the official requirements. If a provider runs it, ask that provider for the relevant maintenance confirmation.
Does updating a Core Lightning wallet settle an earlier payment timeout?
The update alone does not determine the original payment's result. Inspect that payment's record before creating another operation.