Modular C implementation of the Lightning Network protocol and node stack.
Every captured commit receives deterministic security triage and a separate communication-quality score. Security candidates and broader second-pass signals receive full-patch Ollama analysis.
Aug 5 → Feb 61049 seen37 candidatesCompleteFeb 6 → Jun 6579 seen10 candidatesCompleteJun 6 → Jul 678 seen1 candidatesCompleteJul 6 → Aug 5147 seen16 candidatesCompleteMessage quality measures whether a commit identifies its scope, purpose, rationale, testing, and supporting references. It does not change the security-severity score.
Public Git author strings; identities are not independently verified.
Last scanned 24 minutes ago
This commit simply adds a new person's PGP public-key fingerprint to the list of trusted release signers in two documentation files. It does not change any code, fix any bug, or alter any security behavior of the software itself.
41278b4eby jaonoctus+2−02 filesThis is a tiny internal fix to make a bookkeeping migration produce stable event ordering. It changes the timestamp used when creating historical 'deposit' records during a one-time database migration, so the records sort consistently with…
498e5086by daywalker90+2−01 fileThis commit is a documentation-only cleanup of the JSON-RPC command help files. It corrects which numeric error codes are listed for each command so the published schemas match what the software actually returns. No program logic, validati…
d1b6963bby daywalker90+204−1224 filesThis commit fixes a bug where a setting that controls whether unexpected transaction signatures are allowed was not initialized when the channel daemon starts. If a peer sent such signatures before the channel was fully ready, the program …
c09c4520by Erick Cestari+1−01 fileThis commit fixes the project's internal nightly code-coverage CI workflow. It changes how test coverage files are collected, ensures the same LLVM compiler version is used to generate and merge coverage data, and uploads a Codecov-compati…
5685c9a3by cdecker+12−211 fileThis commit is a large cleanup of Core Lightning's API schemas, generated RPC bindings, and related plugin code. The stated goal is to make the documented 'required' fields match what the C code actually always produces or expects. In prac…
ddbd2963by daywalker90+1786−173950 filesThis commit only updates documentation. It adds error code 313 to the documented error lists for several Core Lightning commands (fundpsbt, utxopsbt, txprepare, multiwithdraw, and upgradewallet). The error code already existed in the code …
a34b9758by Peter Neuroth+30−86 filesThis commit fixes a release-script check that verifies the cryptographic signature on a file of checksums. Previously, the script only told GPG to verify the signature file itself. If someone replaced that signature file with an inline-sig…
8e495707by Peter Neuroth+5−21 fileThis commit updates Core Lightning's release documentation to tell users and release managers to run gpg --verify with both the signature file and the manifest file named explicitly. The old one-argument form can silently succeed even if t…
2dee8699by Peter Neuroth+9−62 filesThis commit is a routine update to the Rust dependency lock file (Cargo.lock), bumping many third-party libraries to newer patch or minor versions. The commit message gives no security reason for the update, and no verified references link…
c1551c55by daywalker90+298−2761 fileThis commit fixes a stack-overflow risk in Core Lightning's JSON parser. Before the fix, an attacker could send a valid JSON-RPC message containing thousands of nested brackets or braces. The parser's own helper functions used recursion fo…
83f92e4bby Níckolas Goline+90−22 filesThis commit only fixes typos and comment style. It changes two C-style comments from // to /* */ and corrects a grammar error in a documentation comment ('element' to 'elements'). There are no code behavior changes, no bug fixes, and no se…
273d7f02by w3lld1+3−32 filesThis change fixes a test-infrastructure bug in Core Lightning's Python testing helpers. When running tests against a PostgreSQL database, very long test names could be silently shortened by PostgreSQL, causing different test runs or nodes …
c4fe4cbaby Peter Neuroth+59−12 filesThis fix prevents Core Lightning from trying to use freshly created bitcoins (immature coinbase rewards) as emergency funds for fee-bump transactions. Such a transaction would be invalid under Bitcoin's rules and would be rejected by the n…
34883ff7by cdecker+5−12 filesThis commit fixes a bug in Core Lightning's askrene plugin that could prevent a node from restarting. When a saved routing layer contained a node bias with a description, the plugin accidentally freed the description's memory while using i…
4681177dby Vincenzo Palazzo+2−32 filesThis commit only fixes a test case so it actually exercises the intended code path. It does not change any production code, so it cannot introduce or fix a real-world security vulnerability by itself. The test change is a reproducer for a …
0f3f67a0by Vincenzo Palazzo+3−21 fileThis commit fixes a bug in Core Lightning's experimental dual-funded channel feature. When another node tried to open a channel, Core Lightning was not checking whether the proposed transaction fees were reasonable. A peer could request a …
ba08356fby cdecker+140−04 filesThis commit adds regression tests for three related bugs where wildly wrong Bitcoin transaction feerates could enter Core Lightning. In the worst case, a malicious or broken fee source could make the node think a feerate was zero (due to a…
65bdbc47by cdecker+137−02 filesThis update fixes a crash bug in Core Lightning. When the software tried to list details of a channel opening in progress, it could crash if a stored fee rate was extremely large or zero. The crash happened because the code used an interna…
d67c4936by cdecker+72−227 filesThis commit fixes a bug where Core Lightning nodes could get stuck in a crash loop. If a node had previously stored an extremely high or zero fee rate for an in-progress channel funding operation (a 'splice' or dual-funded channel RBF), a …
f057c692by cdecker+34−01 fileExpand any commit for its author, full message, clarity score, changed files, triage signals, analysis, and source link.
d2123a94 · Jan 14, 2026 · 2 filesLow 29lightning-hsmtool: fix dumponchaindescriptors for mnemonic hsm_secrets.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Fixed: `lightning-hsmtool`: handle mnemonic hsm_secret files (nodes created >= v25.12).
This commit fixes a bug in the lightning-hsmtool utility's 'dumponchaindescriptors' command. For newer Core Lightning nodes created with a mnemonic seed (version 25.12 and later), the tool was deriving the wrong Bitcoin wallet descriptors, which would not match the actual on-chain addresses the node uses. The fix makes the tool follow the correct key derivation path for mnemonic-based secrets. It is a correctness/reliability bug rather than a remote-exploitable vulnerability, but it could cause users to generate incorrect backup descriptors and fail to recover or monitor funds.
bf43fbb7 · Jan 14, 2026 · 1 fileModerate 54lightningd: Fix penalty tx output derivation for BIP86 wallets
When using the new BIP39 mnemonic HSM secret format, the wallet uses
BIP86 derivation for taproot addresses. However, onchaind_tx_unsigned() was always using bip32_pubkey() to derive the final key for penalty transaction outputs.
This fix corrects how Core Lightning derives wallet addresses used in penalty transactions when a newer BIP39-style secret is in use. Previously, the code always used the older BIP32 derivation even when the wallet was configured for BIP86 (taproot) addresses. That mismatch could cause penalty transaction outputs to be sent to addresses the wallet does not recognize or cannot spend, potentially making recovered funds inaccessible after a channel breach.
0269d0c0 · Jan 14, 2026 · 1 fileLow 34jsonrpc: fix recover command for BIP86 wallets
The recover command checks if a node has already issued bitcoin
addresses before allowing recovery. This check only looked at
bip32_max_index, but with BIP86 wallets, newaddr() increments
bip86_max_index instead.
Also, the recover test asserted on hex but now it's asserting on codex32 instead. We should probably go in and fix the end point. @rustyrussell what do you think?
This commit fixes the 'recover' command in Core Lightning so it correctly detects whether a wallet has already generated Bitcoin addresses. Previously, the check only looked at one counter used by older wallets, but a newer type of wallet (BIP86) uses a separate counter. As a result, a BIP86 wallet that had already issued addresses could wrongly be allowed to run recovery, which could overwrite or confuse wallet state. The fix adds the missing check.
5fdc56c5 · Jan 14, 2026 · 3 filesLow 28wallet/hsmd: fix signmessagewithkey for BIP86 wallets
The signmessagewithkey RPC was failing for BIP86 (mnemonic-based)
wallets because:
1. The wallet RPC was iterating through BIP32-derived addresses only,
so it couldn't find BIP86-derived addresses.
2. The HSM's handle_bip137_sign_message always used bitcoin_key()
(BIP32 derivation) regardless of wallet type.
This commit fixes a bug where the `signmessagewithkey` RPC command did not work for newer BIP86-style wallets. Previously, the wallet RPC only searched through older BIP32-derived addresses, and the HSM signing code always used BIP32 key derivation. The fix makes both the wallet lookup and the HSM signing aware of BIP86 derivation, so users can sign messages with keys from BIP86 wallets. This is a functionality bug, not a clear security vulnerability, but it could have caused user confusion or application failures.
35e703bf · Jan 14, 2026 · 1 fileLow 42askrene: don't crash if refining flow which has capacity greaater than max it should have.
```
1767724611265 2026-01-06T18:36:51.265Z plugins/libplugin.c:1073
1767724611265 2026-01-06T18:36:51.265Z 0x55fc0c1428ac handle_rpc_reply
1767724611264 2026-01-06T18:36:51.264Z plugins/askrene/askrene.c:801
1767724611264 2026-01-06T18:36:51.264Z 0x55fc0c13174c listpeerchannels_done
1767724611264 2026-01-06T18:36:51.264Z plugins/askrene/askrene.c:669
1767724611264 2026-01-06T18:36:51.264Z 0x55fc0c130f55 do_getroutes
1767724611264 2026-01-06T18:36:51.264Z plugins/askrene/mcf.c:1636
1767724611264 2026-01-06T18:36:51.264Z 0x55fc0c138bd7 default_routes
1767724611264 2026-01-06T18:36:51.264Z plugins/askrene/mcf.c:1415
1767724611264 2026-01-06T18:36:51.264Z 0x55fc0c1382ec linear_routes
1767724611264 2026-01-06T18:36:51.264Z plugins/askrene/refine.c:510
1767724611264 2026-01-06T18:36:51.264Z 0x55fc0c13b110 refine_flows
1767724611264 2026-01-06T18:36:51.264Z plugins/askrene/refine.c:449
1767724611264 2026-01-06T18:36:51.264Z 0x55fc0c13ac9f increase_flows
1767724611264 2026-01-06T18:36:51.264Z abort+0xde:0
```
Fixes: #8823
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Fixed: plugins: `askrene` can crash on a corner case in increase_flows.
This patch fixes a crash in the `askrene` routing plugin for Core Lightning. In rare cases, the plugin's route-refinement logic could produce a payment flow that exceeded the estimated capacity of a path. The old code then called `abort()`, crashing the plugin. The fix replaces the crash with a warning log and a safe skip, so the node keeps running.
9c6430c0 · Jan 14, 2026 · 1 fileModerate 60plugins/pay: don't crash if erring index is past route array end.
I assume this happens with multi-hop routehints?
```
1768169599027 2026-01-11T22:13:19.027Z pay: plugins/libplugin-pay.c:1199: payment_result_infer: Assertion `i <= len' failed.
1768169599027 2026-01-11T22:13:19.027Z pay: FATAL SIGNAL 6 (version 25.12)
1768169599036 2026-01-11T22:13:19.036Z 0x5562816bcaa4 send_backtrace
1768169599036 2026-01-11T22:13:19.036Z common/daemon.c:38
1768169599036 2026-01-11T22:13:19.036Z 0x5562816bcb40 crashdump
1768169599036 2026-01-11T22:13:19.036Z common/daemon.c:83
1768169599036 2026-01-11T22:13:19.036Z 0x7f5fca29d32f ???
1768169599036 2026-01-11T22:13:19.036Z ???:0
1768169599036 2026-01-11T22:13:19.036Z 0x7f5fca2f6b2c ???
1768169599036 2026-01-11T22:13:19.036Z pthread_kill+0x11c:0
1768169599036 2026-01-11T22:13:19.036Z 0x7f5fca29d27d ???
1768169599036 2026-01-11T22:13:19.036Z gsignal+0x1d:0
1768169599036 2026-01-11T22:13:19.036Z 0x7f5fca2808fe ???
1768169599036 2026-01-11T22:13:19.036Z abort+0xde:0
1768169599036 2026-01-11T22:13:19.036Z 0x7f5fca28081a ???
1768169599036 2026-01-11T22:13:19.036Z ???:0
1768169599036 2026-01-11T22:13:19.036Z 0x7f5fca293516 ???
1768169599036 2026-01-11T22:13:19.036Z __assert_fail+0x46:0
1768169599037 2026-01-11T22:13:19.037Z 0x5562816ae9f6 payment_result_infer
1768169599037 2026-01-11T22:13:19.037Z plugins/libplugin-pay.c:1199
1768169599037 2026-01-11T22:13:19.037Z 0x5562816b4acd payment_waitsendpay_finished
1768169599037 2026-01-11T22:13:19.037Z plugins/libplugin-pay.c:1653
1768169599037 2026-01-11T22:13:19.037Z 0x5562816aca60 handle_rpc_reply
1768169599037 2026-01-11T22:13:19.037Z plugins/libplugin.c:1062
1768169599037 2026-01-11T22:13:19.037Z 0x5562816acc86 rpc_conn_read_response
1768169599037 2026-01-11T22:13:19.037Z plugins/libplugin.c:1377
1768169599037 2026-01-11T22:13:19.037Z 0x5562816f0e87 next_plan
1768169599037 2026-01-11T22:13:19.037Z ccan/ccan/io/io.c:60
1768169599037 2026-01-11T22:13:19.037Z 0x5562816f1358 do_plan
1768169599037 2026-01-11T22:13:19.037Z ccan/ccan/io/io.c:422
1768169599037 2026-01-11T22:13:19.037Z 0x5562816f1415 io_ready
1768169599037 2026-01-11T22:13:19.037Z ccan/ccan/io/io.c:439
1768169599037 2026-01-11T22:13:19.037Z 0x5562816f2e23 io_loop
1768169599037 2026-01-11T22:13:19.037Z ccan/ccan/io/poll.c:470
1768169599037 2026-01-11T22:13:19.037Z 0x5562816ae114 plugin_main
1768169599037 2026-01-11T22:13:19.037Z plugins/libplugin.c:2429
1768169599037 2026-01-11T22:13:19.037Z 0x5562816a894c main
1768169599037 2026-01-11T22:13:19.037Z plugins/pay.c:1581
1768169599037 2026-01-11T22:13:19.037Z 0x7f5fca2821c9 ???
1768169599037 2026-01-11T22:13:19.037Z ???:0
1768169599037 2026-01-11T22:13:19.037Z 0x7f5fca28228a ???
1768169599037 2026-01-11T22:13:19.037Z __libc_start_main+0x8a:0
1768169599037 2026-01-11T22:13:19.037Z 0x5562816a4eb4 ???
1768169599037 2026-01-11T22:13:19.037Z _start+0x24:0
1768169599037 2026-01-11T22:13:19.037Z 0xffffffffffffffff ???
1768169599037 2026-01-11T22:13:19.037Z ???:0
1768169599136 2026-01-11T22:13:19.136Z 2026-01-11T22:13:19.136Z INFO plugin-pay: Killing plugin: exited during normal operation
69599136 2026-01-11T22:13:19.136Z 2026-01-11T22:13:19.136Z **BROKEN** plugin-pay: Plugin marked as important, shutting down lightningd!
```
Reported-by: michael1011
Fixes: https://github.com/ElementsProject/lightning/issues/8828
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Fixed: plugins: `pay` can crash on errors returned from deep inside routehints.
This commit fixes a crash in Core Lightning's `pay` plugin. When processing a payment failure, the plugin assumed that the reported error location was always within the known payment route. In some cases—likely involving multi-hop route hints—the reported index could be larger than the route array, causing an assertion failure that killed the plugin and, because the plugin is marked as important, shut down the entire `lightningd` node. The fix replaces the crash with a safe early return.
8d807be6 · Jan 14, 2026 · 1 fileInformational 15pytest: fix reconnect flake in test_route_by_old_scid
We restart l2, then try to connect to l1. But l1 will be trying to
reconnect (and it can, since it was initially given l2's address), so
it can race us and we end up disconnecting because of simultaneous
connect:
```
2026-01-13T04:06:10.7490260Z > l2.rpc.connect(l1.info['id'], 'localhost', l1.port)
2026-01-13T04:06:10.7490667Z
2026-01-13T04:06:10.7490828Z tests/test_splicing.py:554:
...
2026-01-13T04:06:10.7525780Z > raise RpcError(method, payload, resp['error'])
2026-01-13T04:06:10.7527464Z E pyln.client.lightning.RpcError: RPC call failed: method: connect, payload: {'id': '0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518', 'host': 'localhost', 'port': 46813}, error: {'code': 402, 'message': 'disconnected during connection'}
2026-01-13T04:06:10.7528832Z
...
2026-01-13T04:06:10.9411680Z lightningd-2 2026-01-13T03:59:59.463Z DEBUG 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-connectd: Connect OUT
2026-01-13T04:06:10.9412178Z lightningd-2 2026-01-13T03:59:59.463Z DEBUG 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-connectd: peer_out WIRE_INIT
2026-01-13T04:06:10.9412551Z lightningd-2 2026-01-13T03:59:59.463Z DEBUG 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-connectd: Connect IN
2026-01-13T04:06:10.9412947Z lightningd-2 2026-01-13T03:59:59.464Z DEBUG 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-connectd: peer_out WIRE_INIT
2026-01-13T04:06:10.9413342Z lightningd-2 2026-01-13T03:59:59.464Z DEBUG 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-connectd: peer_in WIRE_INIT
2026-01-13T04:06:10.9413624Z lightningd-2 2026-01-13T03:59:59.487Z TRACE lightningd: Calling peer_connected hook of plugin chanbackup
2026-01-13T04:06:10.9414057Z lightningd-2 2026-01-13T03:59:59.534Z DEBUG 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-connectd: Handed peer, entering loop
2026-01-13T04:06:10.9414451Z lightningd-2 2026-01-13T03:59:59.534Z DEBUG 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-connectd: peer_in WIRE_INIT
2026-01-13T04:06:10.9414851Z lightningd-2 2026-01-13T03:59:59.574Z DEBUG 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-lightningd: peer reconnected
2026-01-13T04:06:10.9415250Z lightningd-2 2026-01-13T03:59:59.609Z DEBUG 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-lightningd: peer_disconnected
2026-01-13T04:06:10.9415527Z lightningd-2 2026-01-13T03:59:59.685Z TRACE lightningd: Calling peer_connected hook of plugin chanbackup
2026-01-13T04:06:10.9415957Z lightningd-2 2026-01-13T03:59:59.687Z DEBUG 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-connectd: Handed peer, entering loop
2026-01-13T04:06:10.9416364Z lightningd-2 2026-01-13T03:59:59.757Z DEBUG 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-lightningd: peer_disconnected
2026-01-13T04:06:10.9417067Z lightningd-2 2026-01-13T03:59:59.830Z DEBUG 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-connectd: Will try reconnect in 4 seconds
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is a one-line change to a test file that fixes an occasional test failure (a 'flake'). It swaps which test node initiates a connection after a restart to avoid a race where both nodes try to connect to each other at the same time. It does not change any production code or fix a security bug.
3be25d48 · Jan 14, 2026 · 6 filesInformational 15pytest: don't rely on sleep to ensure wait commands have been submitted.
Seems like sleep(1) isn't always enough. Give in and put a log
message there, and use that:
```
waitfut = executor.submit(l2.rpc.wait, subsystem='forwards', indexname='deleted', nextvalue=1)
time.sleep(1)
l2.rpc.delforward(scid12, 1, 'failed')
waitres = waitfut.result(TIMEOUT)
> assert waitres == {'subsystem': 'forwards',
'deleted': 1,
'forwards': {'in_channel': scid12,
'in_htlc_id': 1,
'status': 'failed'}}
E AssertionError: assert {'subsystem': 'forwards', 'deleted': 1} == {'subsystem': 'forwards', 'deleted': 1, 'forwards': {'in_channel': '103x2x0', 'in_htlc_id': 1, 'status': 'failed'}}
E
E Common items:
E {'deleted': 1, 'subsystem': 'forwards'}
E Right contains 1 more item:
E {'forwards': {'in_channel': '103x2x0', 'in_htlc_id': 1, 'status': 'failed'}}
E
E Full diff:
E {
E 'deleted': 1,
E - 'forwards': {
E - 'in_channel': '103x2x0',
E - 'in_htlc_id': 1,
E - 'status': 'failed',
E - },
E 'subsystem': 'forwards',
E }
tests/test_misc.py:3599: AssertionError
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit fixes flaky automated tests, not the Core Lightning server itself. The tests were using a one-second sleep to guess that a background 'wait' command had been submitted, but sometimes the command wasn't ready in time and the test would fail. The patch adds a log line when a wait command is registered and changes the tests to wait for that log line instead of sleeping. There is no security fix here.
c10c54ff · Jan 14, 2026 · 2 filesInformational 15pytest: don't record IO when we kill nodes
```
ERROR tests/test_connection.py::test_channel_persistence - json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)
```
Similarly:
```
ERROR tests/test_opening.py::test_sendpsbt_crash - json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This change only adjusts two test cases so they no longer save plugin input/output logs before deliberately crashing a test node. It fixes flaky test failures where reading a partially-written JSON file produced a decode error. It does not change any production code or affect real users.
b0f8077e · Jan 14, 2026 · 1 fileInformational 15pytest: fix flake in test_gossip_query_channel_range
If l4 sends a WIRE_QUERY_SHORT_CHANNEL_IDS at the wrong time, we will
get that and be upset the response is wrong:
```
2026-01-13T14:45:55.9059786Z E AssertionError: assert ['010806226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910f00000000000f42400100110000006800000100000000690000010000', '010506226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910f001100000068000001000000006900000100000103000402'] in (['010806226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910f00000000000f42400100110000006800000100000000690000010000'], ['010806226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910f00000000000f42400100110000006900000100000000680000010000'])
2026-01-13T14:45:55.9063357Z
2026-01-13T14:45:55.9063527Z tests/test_gossip.py:762: AssertionError
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit fixes a flaky test in Core Lightning's test suite. A test about gossip protocol messages sometimes failed because another node would send an unexpected extra message type during the test. The fix adds that message type to the list of messages the test should ignore, making the test more reliable. There is no security issue in the actual Lightning node software.
84afe579 · Jan 14, 2026 · 3 filesInformational 13pytest: disable autoreconnect on test_sql to avoid reconnect race.
Because l1 and l3 allow localhost as a broadcastable address, they can
try to reconnect. Disable reconnections, so we don't race:
```
> l2.rpc.connect(l3.info['id'], 'localhost', l3.port)
tests/test_plugin.py:4146:
...
elif "error" in resp:
> raise RpcError(method, payload, resp['error'])
E pyln.client.lightning.RpcError: RPC call failed: method: connect, payload: {'id': '035d2b1192dfba134e10e540875d366ebc8bc353d5aa766b80c090b39c3a5d885d', 'host': 'localhost', 'port': 45035}, error: {'code': 402, 'message': 'disconnected during connection'}
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit is a test-only fix. It changes three test files to make automated tests more reliable: it disables automatic reconnections in one test to avoid a timing race, fixes a typo in a log message another test waits for, and adds a short sleep in a third test. There is no change to the actual Core Lightning node software that users run, so it does not affect real network security.
fd64bb11 · Jan 14, 2026 · 2 filesInformational 19lightningd: fix bogus memleak report.
We do our own leak detection on a reply from a subd, but the reply
code set subd->conn to NULL (saving it temporarily, in case the subd
is freed), resulting in it being seen as a leak:
```
lightningd-2 2026-01-12T14:11:12.677Z DEBUG 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-channeld-chan#1: billboard perm: Reconnected, and reestablished.
lightningd-2 2026-01-12T14:11:12.677Z DEBUG 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-channeld-chan#1: billboard: Channel ready for use. Shutdown messages exchanged.
lightningd-1 2026-01-12T14:11:12.705Z DEBUG 022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59-closingd-chan#1: pid 100718, msgfd 87
lightningd-1 2026-01-12T14:11:12.705Z DEBUG 022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59-channeld-chan#1: Status closed, but not exited. Killing
...
lightningd-1 2026-01-12T14:11:32.546Z **BROKEN** lightningd: MEMLEAK: 0x55f61eb4d848
lightningd-1 2026-01-12T14:11:32.546Z **BROKEN** lightningd: label=ccan/ccan/io/io.c:92:struct io_conn
lightningd-1 2026-01-12T14:11:32.546Z **BROKEN** lightningd: alloc:
lightningd-1 2026-01-12T14:11:32.840Z **BROKEN** lightningd: ccan/ccan/tal/tal.c:488 (tal_alloc_)
lightningd-1 2026-01-12T14:11:32.845Z **BROKEN** lightningd: ccan/ccan/io/io.c:92 (io_new_conn_)
lightningd-1 2026-01-12T14:11:32.845Z **BROKEN** lightningd: lightningd/subd.c:785 (new_subd)
lightningd-1 2026-01-12T14:11:32.845Z **BROKEN** lightningd: lightningd/subd.c:839 (new_channel_subd_)
lightningd-1 2026-01-12T14:11:32.846Z **BROKEN** lightningd: lightningd/channel_control.c:1714 (peer_start_channeld)
lightningd-1 2026-01-12T14:11:32.847Z **BROKEN** lightningd: lightningd/peer_control.c:1390 (connect_activate_subd)
lightningd-1 2026-01-12T14:11:32.847Z **BROKEN** lightningd: lightningd/peer_control.c:1516 (peer_connected_hook_final)
lightningd-1 2026-01-12T14:11:32.847Z **BROKEN** lightningd: lightningd/plugin_hook.c:243 (hook_done)
lightningd-1 2026-01-12T14:11:32.847Z **BROKEN** lightningd: lightningd/plugin_hook.c:343 (plugin_hook_call_next)
lightningd-1 2026-01-12T14:11:32.847Z **BROKEN** lightningd: lightningd/plugin_hook.c:299 (plugin_hook_callback)
lightningd-1 2026-01-12T14:11:32.851Z **BROKEN** lightningd: lightningd/plugin.c:701 (plugin_response_handle)
lightningd-1 2026-01-12T14:11:32.851Z **BROKEN** lightningd: lightningd/plugin.c:790 (plugin_read_json)
lightningd-1 2026-01-12T14:11:32.851Z **BROKEN** lightningd: ccan/ccan/io/io.c:60 (next_plan)
lightningd-1 2026-01-12T14:11:32.851Z **BROKEN** lightningd: ccan/ccan/io/io.c:422 (do_plan)
lightningd-1 2026-01-12T14:11:32.851Z **BROKEN** lightningd: ccan/ccan/io/io.c:439 (io_ready)
lightningd-1 2026-01-12T14:11:32.851Z **BROKEN** lightningd: ccan/ccan/io/poll.c:470 (io_loop)
lightningd-1 2026-01-12T14:11:32.851Z **BROKEN** lightningd: lightningd/io_loop_with_timers.c:22 (io_loop_with_timers)
lightningd-1 2026-01-12T14:11:32.851Z **BROKEN** lightningd: lightningd/lightningd.c:1492 (main)
lightningd-1 2026-01-12T14:11:32.852Z **BROKEN** lightningd: ../sysdeps/nptl/libc_start_call_main.h:58 (__libc_start_call_main)
lightningd-1 2026-01-12T14:11:32.852Z **BROKEN** lightningd: ../csu/libc-start.c:360 (__libc_start_main_impl)
lightningd-1 2026-01-12T14:11:32.852Z **BROKEN** lightningd: parents:
lightningd-1 2026-01-12T14:11:32.852Z **BROKEN** lightningd: lightningd/lightningd.c:108:struct lightningd
lightningd-1 2026-01-12T14:11:32.853Z DEBUG lightningd: channel_gossip: no longer in startup mode
lightningd-1 2026-01-12T14:11:32.856Z DEBUG hsmd: new_client: 1
```
The workaround is to do our own leak detection on a timer (making the
conn notleak() would leave us open to a real leak in future!).
We also move the `struct leak_detect` definition inside the C file
where it belongs.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit fixes a false alarm in Core Lightning's internal memory-leak checker. When the node asked a sub-process to report its memory usage, the reply handling briefly set aside a connection pointer, making the leak detector wrongly report that connection as leaked. The fix delays the final leak check until after the reply handling is finished, so the temporary pointer state is no longer visible. It is a diagnostic/robustness fix, not a security vulnerability fix, and does not create a way for an attacker to exploit the node.
c0c88549 · Jan 14, 2026 · 1 fileInformational 15pytest: another flake in test_important_plugin.
There's one more complaint we can see when plugins get upset:
```
lightningd-1 2026-01-12T06:10:49.317Z **BROKEN** plugin-cln-xpay: askrene-create-layer failed with {"code":-4, "message":"Plugin terminated before replying to RPC call."}
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit is a one-line change to a test file. It adds another expected log message to a test that already tolerates several 'broken' log lines when a node is deliberately started with a missing important plugin. There is no change to production code, no security fix, and no vulnerability.
b219214a · Jan 14, 2026 · 2 filesInformational 15doc: Update docs to reflect new hsm secret format
Changelog-Changed - Updated backup and hsm secret docs to reflect mnemonic based hsm secret
This commit only updates user documentation to describe a new mnemonic-based backup format for Core Lightning's wallet secret. It does not change any code, commands, or security behavior. There is no security vulnerability here.
4f5e5aad · Jan 13, 2026 · 2 filesInformational 17common: expose validate_mnemonic so the option can use it.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit is a small internal code cleanup: it makes an existing BIP39 mnemonic validation helper function visible outside its source file so other parts of the program can reuse it. The function's behavior is unchanged; it still checks whether a 12-word recovery phrase is valid. There is no indication this fixes a security bug or introduces a vulnerability.
779a4784 · Jan 13, 2026 · 9 filesLow 28lightningd: allow --recover / recover JSON RPC to take mnemonic.
In fact, you *must* use mnemonic to successfully recover a modern node!
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Changed: JSON-RPC: `recover` takes a 12-word mnemonic for nodes created by v25.12 or later.
This commit updates Core Lightning's recovery feature so it can accept a 12-word mnemonic phrase, which is now the required way to recover nodes created with version 25.12 or later. Older nodes can still be recovered using the previous codex32 or hex formats. The change is a feature enhancement to support a new wallet backup format, not a fix for an active security vulnerability. However, because recovery material directly controls the node's secret keys, any bugs in how mnemonics are parsed, validated, or written to disk could have serious security consequences. The patch appears careful: it rejects encrypted/password-protected mnemonics during recovery and validates input, but it is a partial view of a larger change so we cannot fully assess the surrounding key-derivation code.
f975bb37 · Jan 13, 2026 · 5 filesInformational 20lightning-hsmtool: support extracting the mnemonic from hsm_secret.
We cannot use the codex32 or raw hex for recovery of 25.12 nodes,
since they will then use the incorrect derivation for all paths, and
be unable to spend (or even find!) their funds.
So implement `getsecret` to replace `getcodexsecret`.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Changed: `lightning-hsmtool`: `getsecret` replaces `getcodexsecret` for modern nodes (gives mnemonic).
Changelog-Deprecated: `lightning-hsmtool`: `getcodexsecret`. Use `getsecret`.
This commit updates the Core Lightning wallet recovery tool so it can extract the correct backup phrase (mnemonic) used by newer nodes. The old command only produced a codex32 string, which would cause v25.12+ nodes to derive the wrong keys and potentially be unable to find or spend funds during recovery. There is no vulnerability being fixed; it is a usability and correctness improvement for wallet backups.
a0cc50cf · Jan 13, 2026 · 1 fileModerate 58askrene: regression test that triggers assertion
cln-askrene: plugins/askrene/mcf.c:474: combine_cost_function: Assertion `fcost != INFINITE' failed.
cln-askrene: FATAL SIGNAL 6 (version v25.12-131-gb15f386-modded)
0x55703f242fd1 send_backtrace
common/daemon.c:38
0x55703f24305b crashdump
common/daemon.c:83
0x7f548b421def ???
./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0x7f548b47695c __pthread_kill_implementation
./nptl/pthread_kill.c:44
0x7f548b421cc1 __GI_raise
../sysdeps/posix/raise.c:26
0x7f548b40a4ab __GI_abort
./stdlib/abort.c:73
0x7f548b40a41f __assert_fail_base
./assert/assert.c:118
0x55703f234491 combine_cost_function
plugins/askrene/mcf.c:474
0x55703f2358b6 single_path_flow
plugins/askrene/mcf.c:1213
0x55703f235fa2 linear_routes
plugins/askrene/mcf.c:1411
0x55703f236804 single_path_routes
plugins/askrene/mcf.c:1656
0x55703f22edad do_getroutes
plugins/askrene/askrene.c:689
0x55703f22f269 json_getroutes
plugins/askrene/askrene.c:910
0x55703f2411a7 ld_command_handle
plugins/libplugin.c:2155
0x55703f2413b1 ld_read_json
plugins/libplugin.c:2231
0x55703f271a4d next_plan
ccan/ccan/io/io.c:60
0x55703f271ed8 do_plan
ccan/ccan/io/io.c:422
0x55703f271f91 io_ready
ccan/ccan/io/io.c:439
0x55703f27391b io_loop
ccan/ccan/io/poll.c:470
0x55703f2417fd plugin_main
plugins/libplugin.c:2429
0x55703f22f753 main
plugins/askrene/askrene.c:1452
0x7f548b40bca7 __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58
0x7f548b40bd64 __libc_start_main_impl
../csu/libc-start.c:360
0x55703f22baa0 ???
_start+0x20:0
0xffffffffffffffff ???
???:0
Changelog-None
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
This commit adds a skipped regression test that demonstrates a crash in Core Lightning's routing plugin (askrene). When a user-defined channel has an unusually high routing fee, the plugin's single-path solver hits an internal assertion and aborts. The test is currently disabled with @unittest.skip, so it documents the bug rather than fixing it. A remote user who can call the getroutes RPC with crafted layer parameters could likely trigger the plugin to crash, causing a denial of service.
118e4746 · Jan 13, 2026 · 2 filesLow 44askrene: fix payment crash
Changelog-Fixed: askrene: fix a plugin crash triggered during single path payments when a channel fees doesn't fit u32.
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
This commit fixes a crash in Core Lightning's 'askrene' routing plugin. The bug occurred when calculating fees for a single payment path: if a channel fee was too large to fit in a 32-bit unsigned integer, the code would skip adding the arc to the network, leaving it uninitialized. Later code could then hit an assertion and crash the plugin. The fix uses the full 64-bit fee value directly instead of trying to squeeze it into a smaller integer type. A previously-skipped regression test is now re-enabled.
b895700f · Jan 13, 2026 · 1 fileInformational 15tools: Update libsodium version for Ubuntu Noble
Changelog-None: Fixes release process only.
This commit updates a single recorded checksum for a library package (libsodium-dev) used in Core Lightning's reproducible build script. The old package version no longer exists in the new Ubuntu Noble release environment, so the build script's pinned checksum is being replaced with the one for the updated package. There is no code change, no runtime behavior change, and no security vulnerability being fixed.
1741e166 · Jan 8, 2026 · 1 fileInformational 19lightningd: fix occasional memleak when we detach subd from channel.
Do this by setting notleak when we do the detach!
```
**BROKEN** lightningd: MEMLEAK: 0x60f0000bbb38
**BROKEN** lightningd: label=ccan/ccan/io/io.c:92:struct io_conn
**BROKEN** lightningd: alloc:
**BROKEN** lightningd: /home/runner/work/lightning/lightning/ccan/ccan/tal/tal.c:488 (tal_alloc_)
**BROKEN** lightningd: /home/runner/work/lightning/lightning/ccan/ccan/io/io.c:92 (io_new_conn_)
**BROKEN** lightningd: /home/runner/work/lightning/lightning/lightningd/subd.c:781 (new_subd)
**BROKEN** lightningd: /home/runner/work/lightning/lightning/lightningd/subd.c:835 (new_channel_subd_)
**BROKEN** lightningd: /home/runner/work/lightning/lightning/lightningd/channel_control.c:1715 (peer_start_channeld)
**BROKEN** lightningd: /home/runner/work/lightning/lightning/lightningd/peer_control.c:1390 (connect_activate_subd)
**BROKEN** lightningd: /home/runner/work/lightning/lightning/lightningd/peer_control.c:1516 (peer_connected_hook_final)
**BROKEN** lightningd: /home/runner/work/lightning/lightning/lightningd/plugin_hook.c:243 (hook_done)
**BROKEN** lightningd: /home/runner/work/lightning/lightning/lightningd/plugin_hook.c:343 (plugin_hook_call_next)
**BROKEN** lightningd: /home/runner/work/lightning/lightning/lightningd/plugin_hook.c:299 (plugin_hook_callback)
**BROKEN** lightningd: /home/runner/work/lightning/lightning/lightningd/plugin.c:701 (plugin_response_handle)
**BROKEN** lightningd: /home/runner/work/lightning/lightning/lightningd/plugin.c:790 (plugin_read_json)
**BROKEN** lightningd: /home/runner/work/lightning/lightning/ccan/ccan/io/io.c:60 (next_plan)
**BROKEN** lightningd: /home/runner/work/lightning/lightning/ccan/ccan/io/io.c:422 (do_plan)
**BROKEN** lightningd: /home/runner/work/lightning/lightning/ccan/ccan/io/io.c:439 (io_ready)
**BROKEN** lightningd: /home/runner/work/lightning/lightning/ccan/ccan/io/poll.c:470 (io_loop)
**BROKEN** lightningd: /home/runner/work/lightning/lightning/lightningd/io_loop_with_timers.c:22 (io_loop_with_timers)
**BROKEN** lightningd: /home/runner/work/lightning/lightning/lightningd/lightningd.c:1492 (main)
**BROKEN** lightningd: ../sysdeps/nptl/libc_start_call_main.h:58 (__libc_start_call_main)
**BROKEN** lightningd: ../csu/libc-start.c:392 (__libc_start_main_impl)
**BROKEN** lightningd: parents:
**BROKEN** lightningd: lightningd/lightningd.c:108:struct lightningd
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit fixes a false-positive memory leak report inside Core Lightning's internal process manager. When a background helper process (subdaemon) detaches from a payment channel, the cleanup can briefly leave the helper object without an obvious owner. The memory leak detector would flag this as a leak and crash the node in testing builds. The fix marks the object as 'not a leak' during this cleanup window. It is a reliability/debugging fix, not an exploitable security vulnerability.
21d4f684 · Jan 8, 2026 · 1 fileInformational 19hsmd: check *all* anchor inputs for short sigs.
Anchors will have one input from the commitment tx, and at least on
more (in this case, 3 more); we were only checking the first one for
short signatures.
```
total_feerate_perkw = total_fees / total_weight * 1000
> check_feerate([l3, l2], total_feerate_perkw, feerate)
tests/test_closing.py:4064:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
nodes = [<fixtures.LightningNode object at 0x7f3e9a2c74f0>, <fixtures.LightningNode object at 0x7f3e991d5f30>]
actual_feerate = 14006.105538595726, expected_feerate = 14000
def check_feerate(nodes, actual_feerate, expected_feerate):
# Feerate can't be lower.
assert actual_feerate > expected_feerate - 2
if actual_feerate >= expected_feerate + 2:
if any([did_short_sig(n) for n in nodes]):
return
# Use assert as it shows the actual values on failure
> assert actual_feerate < expected_feerate + 2
E AssertionError
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit fixes a test-only diagnostic check in Core Lightning's hardware signing daemon (HSM). The code warns developers if a Bitcoin signature is unusually short (a sign of 'overgrinding' during signature creation), but it only checked the first input of an anchor-spending transaction. Anchor transactions can have multiple inputs, so the check missed short signatures on the other inputs. This is a testing/quality fix, not a vulnerability that attackers can exploit.
8a60a276 · Jan 8, 2026 · 1 fileInformational 17pytest: fix feerate check in test_peer_anchor_push
We didn't log when anchor transactions had short signatures,
which causes this test to not assert (did_short_sig):
```
total_feerate_perkw = total_fees / total_weight * 1000
> check_feerate([l3, l2], total_feerate_perkw, feerate)
tests/test_closing.py:4063:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
nodes = [<fixtures.LightningNode object at 0x7f0fb322bb20>, <fixtures.LightningNode object at 0x7f0fb1b5ead0>]
actual_feerate = 14006.105538595726, expected_feerate = 14000
def check_feerate(nodes, actual_feerate, expected_feerate):
# Feerate can't be lower.
assert actual_feerate > expected_feerate - 2
if actual_feerate >= expected_feerate + 2:
if any([did_short_sig(n) for n in nodes]):
return
# Use assert as it shows the actual values on failure
> assert actual_feerate < expected_feerate + 2
E AssertionError
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit fixes a test-only logging issue. A developer warning flag (dev_warn_on_overgrind) was not logging when an anchor transaction signature was shorter than expected, causing a pytest test to fail its feerate assertion. The fix adds a log message so the test can detect the short signature and skip the strict feerate check. There is no production security vulnerability here.
c056a478 · Jan 8, 2026 · 1 fileInformational 11pytest: expect slow commands with giant commando test
```
2025-12-10T02:51:06.2435409Z [gw1] [ 77%] ERROR tests/test_plugin.py::test_commando
...lightningd-1: had BROKEN messages
...
2025-12-10T03:00:26.0440311Z lightningd-1 2025-12-10T02:51:01.548Z UNUSUAL jsonrpc#69: That's weird: Request checkrune took 5961 milliseconds
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit only adjusts a test so that a known slow operation no longer causes test failures. It is not a security fix and does not change any production code.
fd21b329 · Jan 8, 2026 · 1 fileInformational 15pytest: fix test_bitcoin_backend_gianttx flake.
signpsbt could be the one which takes a long time, so allow any
psbt event.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is a one-line change to a test file. It widens the expected log message pattern in a flaky test so that either 'fundpsbt' or 'signpsbt' slow operations are accepted, rather than only 'fundpsbt'. It does not change production code, user behavior, or security boundaries.