EP
← All projectsElements Project

Core Lightning

Modular C implementation of the Lightning Network protocol and node stack.

BitcoinLightning NetworkActive incident
Repository coverage

1979 commits in the local evidence base

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.

184security candidates280second-pass queue1894AI analyses
26commits · 30 days
185commits · 60 days
659commits · 180 days
1641commits · 365 days
Backfill bands
Aug 5 → Feb 61049 seen37 candidatesComplete
Feb 6 → Jun 6579 seen10 candidatesComplete
Jun 6 → Jul 678 seen1 candidatesComplete
Jul 6 → Aug 5147 seen16 candidatesComplete
Commit communication

Does the history explain itself?

Message quality measures whether a commit identifies its scope, purpose, rationale, testing, and supporting references. It does not change the security-severity score.

71/100 average clarity
484Strong · 80–100
1224Adequate · 60–79
241Thin · 40–59
30Opaque · 0–39
Read the scoring rubric →
Developer activity

Who is changing the project?

Public Git author strings; identities are not independently verified.

DeveloperCommitsCandidatesAnalyzedHigh riskMessage avg.
cdecker14910384
Níckolas Goline63844277
Rusty Russell96475958172
daywalker90113895164
Lagrang386578170
Vincenzo Palazzo13411182
dovgopoly15015164
Sangbida Chaudhuri14931146066
Dusty Daemon821378066
ShahanaFarooqui931093063
Peter Neuroth1024101071
Christian Decker36436072
Analysis record

Published AI watches

Last scanned 40 minutes ago

Informational 15 AI analysisMessage 73 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

contrib: add jaonoctus's signing key

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 files
No security note in commit
Informational 15 AI analysisMessage 73 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

wallet: fixed timestamps for invented bookkeeper deposits

This 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 file
No security note in commit
Informational 21 AI analysisMessage 85 · Strong
EP Elements ProjectCore Lightning BitcoinLightning Network

docs: document missing and fix erroneous JSON-RPC error codes

This 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…

Documentation-only change with no executable code modificationsCorrects RPC schema error-code metadata to match actual handler behaviorNo change to input parsing, authorization, cryptography, or network behavior
d1b6963bby daywalker90+204−1224 files
No security note in commit
Low 46 AI analysisMessage 73 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

channeld: initialize tx_sigs_allowed on startup

This 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 …

use of uninitialized variableundefined behavior (invalid bool load)network-triggered code path
c09c4520by Erick Cestari+1−01 file
No security note in commit
Informational 15 AI analysisMessage 100 · Strong
EP Elements ProjectCore Lightning BitcoinLightning Network

ci: fix the coverage nightly's profile handling

This 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 file
No security note in commit
Low 37 AI analysisMessage 78 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

schemas: make required fields match the code

This 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…

Large schema-only change with no accompanying security advisory or CVEOne semantic change to plugin hook response: invoice_payment hook can now reject with only failure_message and no resultMany fields change from optional to required in public RPC/protobuf interfaces
ddbd2963by daywalker90+1786−173950 files
No security note in commit
Informational 15 AI analysisMessage 73 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

doc: document error 313 on every command which can return it

This 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 files
No security note in commit
Low 25 AI analysisMessage 88 · Strong
EP Elements ProjectCore Lightning BitcoinLightning Network

tools/build-release.sh: name the checksum file when verifying the signature

This 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…

Incorrect cryptographic verification logic in release toolingPotential false-positive signature verification with inline-signed .asc substitutionRelease-integrity hardening
8e495707by Peter Neuroth+5−21 file
No security note in commit
Low 42 AI analysisMessage 95 · Strong
EP Elements ProjectCore Lightning BitcoinLightning Network

doc: pass the manifest explicitly to gpg --verify

This 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…

Verification bypass risk in release artifact validationgpg --verify single-argument form can exit 0 without reading the intended manifestDocumentation-only hardening of release process
2dee8699by Peter Neuroth+9−62 files
Vendor flagged security relevance
Low 25 AI analysisMessage 58 · Thin
EP Elements ProjectCore Lightning BitcoinLightning Network

Cargo.lock: update dependencies

This 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…

Routine dependency refresh with no stated security rationaleUpdates to security-sensitive transitive crates (rustls, hyper, h2, tokio, webpki-roots) but no evidence these versions fix known vulnerabilitiesNo source-code changes or patch-specific fixes visible in the diff
c1551c55by daywalker90+298−2761 file
No security note in commit
High 80 AI analysisMessage 85 · Strong
EP Elements ProjectCore Lightning BitcoinLightning Network

common: bound JSON nesting depth when parsing

This 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…

Stack-overflow via deeply nested JSONRecursive JSON traversal without depth boundDenial-of-service vector in JSON-RPC input parsing
83f92e4bby Níckolas Goline+90−22 files
Vendor flagged security relevance
Informational 15 AI analysisMessage 28 · Opaque
EP Elements ProjectCore Lightning BitcoinLightning Network

common: minor typo fixes

This 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 files
No security note in commit
Informational 20 AI analysisMessage 90 · Strong
EP Elements ProjectCore Lightning BitcoinLightning Network

pyln-testing: truncate long testnames

This 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 …

No security-relevant signal: change is in test framework code onlyFixes a test reliability issue, not a runtime vulnerabilityNo input sanitization, authentication, cryptography, or network changes
c4fe4cbaby Peter Neuroth+59−12 files
No security note in commit
Moderate 60 AI analysisMessage 73 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

wallet: exclude immature coinbase outputs from fee rescue selection

This 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…

Consensus-invalid transaction generation preventedFee rescue / CPFP failure mode mitigatedCoinbase maturity check added to coin selection
34883ff7by cdecker+5−12 files
Vendor flagged security relevance
Moderate 59 AI analysisMessage 91 · Strong
EP Elements ProjectCore Lightning BitcoinLightning Network

askrene: fix crash loading node bias with description

This 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…

Use-after-free / double-take of a tal-allocated string during plugin startupDenial-of-service-like symptom: lightningd aborts before replying to init, node cannot restartFixes publicly reported issue #9433 by endothermicdev
4681177dby Vincenzo Palazzo+2−32 files
No security note in commit
Informational 12 AI analysisMessage 91 · Strong
EP Elements ProjectCore Lightning BitcoinLightning Network

tests: restart the node which owns the layer in node bias test

This 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 file
No security note in commit
High 78 AI analysisMessage 68 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

dualopend: bound the feerates a peer opens at

This 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 …

Missing input validation on wire-parsed feerate fieldsPeer could induce signing and storage of feerate == 0RBF remote path allowed unbounded upward feerate walks
ba08356fby cdecker+140−04 files
Vendor flagged security relevance
High 72 AI analysisMessage 100 · Strong
EP Elements ProjectCore Lightning BitcoinLightning Network

tests: regression coverage for out-of-range feerates

This 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…

Integer overflow in feerate conversion (u32 wrap from 0xFFFFFFFF perkb to 0 perkw)Absurd feerate from external fee source bypassing sanity ceilingDatabase-stored out-of-range feerate causing startup abort/crash loop
65bdbc47by cdecker+137−02 files
No security note in commit
Moderate 64 AI analysisMessage 86 · Strong
EP Elements ProjectCore Lightning BitcoinLightning Network

lightningd: don't assert on funding feerates read from the db

This 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…

Integer overflow in RBF escalation (u32 * 25 / 24) leading to assertion failureAssertion failure in read-only introspection RPC (listpeerchannels) causing crash-loop at startupDatabase value treated as invariant despite originating from external fee estimator
d67c4936by cdecker+72−227 files
Vendor flagged security relevance
Moderate 53 AI analysisMessage 86 · Strong
EP Elements ProjectCore Lightning BitcoinLightning Network

wallet: clamp absurd inflight funding feerates on upgrade

This 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 …

Integer overflow in fee-rate calculation (u32 overflow when multiplying by 25/24)Assertion failure leading to daemon crash loop at startupDatabase migration clamps out-of-range stored funding feerates
f057c692by cdecker+34−01 file
Vendor flagged security relevance
Repository ledger

Explore captured commits

Expand any commit for its author, full message, clarity score, changed files, triage signals, analysis, and source link.

AI review queuedpytest: test for crash when enableoffer called on a used single-use offer.by Rusty Russell · e2d17cea · Feb 2, 2026 · 1 fileMessage 83 · StrongLow 42Details
Commit message · Rusty Russell

pytest: test for crash when enableoffer called on a used single-use offer.

Assertion happens here:

newstatus = offer_status_in_db(s | OFFER_STATUS_ACTIVE_F);

Since OFFER_STATUS_SINGLE_F|OFFER_STATUS_USED_F|OFFER_STATUS_ACTIVE_F
is not a valid combination:

```
lightningd-3 2026-01-28T04:45:21.184Z **BROKEN** lightningd: offer_status_in_db: 7 is invalid
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: FATAL SIGNAL 6 (version v25.12-92-g7fff32d-modded)
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: common/daemon.c:83 (crashdump) 0x5a883759dbb7
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: ./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0 ((null)) 0x79a2b0c4532f
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: ./nptl/pthread_kill.c:44 (__pthread_kill_implementation) 0x79a2b0c9eb2c
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: ./nptl/pthread_kill.c:78 (__pthread_kill_internal) 0x79a2b0c9eb2c
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: ./nptl/pthread_kill.c:89 (__GI___pthread_kill) 0x79a2b0c9eb2c
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: ../sysdeps/posix/raise.c:26 (__GI_raise) 0x79a2b0c4527d
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: ./stdlib/abort.c:79 (__GI_abort) 0x79a2b0c288fe
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: lightningd/log.c:1054 (fatal_vfmt) 0x5a8837509557
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: lightningd/log.c:1064 (fatal) 0x5a88375095fe
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: ./wallet/wallet.h:1451 (offer_status_in_db) 0x5a88375491dc
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: wallet/wallet.c:6160 (offer_status_in_db) 0x5a8837555388
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: wallet/wallet.c:6162 (wallet_offer_enable) 0x5a8837555388
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: lightningd/offer.c:288 (json_enableoffer) 0x5a8837540939
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: lightningd/jsonrpc.c:769 (command_exec) 0x5a8837503198
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: lightningd/jsonrpc.c:910 (rpc_command_hook_final) 0x5a8837503198
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: lightningd/jsonrpc.c:884 (rpc_command_hook_final) 0x5a8837503198
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: lightningd/plugin_hook.c:243 (hook_done) 0x5a8837535383
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: lightningd/plugin_hook.c:343 (plugin_hook_call_next) 0x5a8837535383
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: lightningd/jsonrpc.c:998 (plugin_hook_call_rpc_command) 0x5a8837503c4f
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: lightningd/jsonrpc.c:1123 (parse_request) 0x5a8837503c4f
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: lightningd/jsonrpc.c:1217 (read_json) 0x5a8837503c4f
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: ccan/ccan/io/io.c:60 (next_plan) 0x5a88375eca38
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: ccan/ccan/io/io.c:422 (do_plan) 0x5a88375eca38
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: ccan/ccan/io/io.c:439 (io_ready) 0x5a88375eca38
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: ccan/ccan/io/poll.c:470 (io_loop) 0x5a88375eead5
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: lightningd/io_loop_with_timers.c:22 (io_loop_with_timers) 0x5a8837501f8e
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: lightningd/lightningd.c:1492 (main) 0x5a88374d3c27
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: ../sysdeps/nptl/libc_start_call_main.h:58 (__libc_start_call_main) 0x79a2b0c2a1c9
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: ../csu/libc-start.c:360 (__libc_start_main_impl) 0x79a2b0c2a28a
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: (null):0 ((null)) 0x5a88374d5aa4
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: (null):0 ((null)) 0xffffffffffffffff
```

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

83/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
Why it was queued
second-pass: broader security terminology
AI analysis · Low 42/100

This commit adds a test that exposes a bug in Core Lightning: if you try to re-enable a single-use offer that has already been used, the daemon hits an internal assertion and crashes. The test is marked as expected-to-fail for now, meaning the actual crash is not fixed by this commit—it only documents the failure. A user with RPC access could trigger a denial-of-service by calling enableoffer on a used single-use offer.

AI review queuedfuzz-tests: Make `fuzz-bolt12-offer-decode` roundripby Chandra Pratap · 557a744b · Jan 30, 2026 · 1 fileMessage 91 · StrongInformational 15Details
Commit message · Chandra Pratap

fuzz-tests: Make `fuzz-bolt12-offer-decode` roundrip

Changelog-None: Currently, the `BOLT #12` offer parsing test only
tests the offer decode function. Add a test for the encoding
function as well by making the test roundtrip.

91/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference
Why it was queued
fuzzing or regression evidenceparser or protocol pathsecond-pass: security-sensitive path
AI analysis · Informational 15/100

This commit only changes a fuzz test file. It extends an existing test for BOLT 12 offer decoding to also check that re-encoding the decoded offer produces the same result (a roundtrip test). It does not modify any production code, so it cannot introduce a runtime security vulnerability in the Core Lightning software itself.

AI review queuedfuzz-tests: Add coverage increasing inputs to seed corporaby Chandra Pratap · 461ca686 · Jan 30, 2026 · 31 filesMessage 83 · StrongInformational 15Details
Commit message · Chandra Pratap

fuzz-tests: Add coverage increasing inputs to seed corpora

Improvements in the fuzz-testing scheme of
`fuzz-bolt12-offer-decode` led to the discovery of test inputs
that result in greater in code coverage.

Add these inputs to the test's seed corpus.

83/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
Why it was queued
fuzzing or regression evidenceparser or protocol pathsecond-pass: unusually broad changesecond-pass: security-sensitive path
AI analysis · Informational 15/100

This commit only adds 31 new test input files to a fuzz-testing seed corpus for BOLT12 offer decoding. It does not change any production code, so it cannot introduce or fix a runtime security vulnerability on its own. It is a routine test-data update intended to improve code-coverage during automated fuzzing.

AI review queuedpytest: use old hsm secret whenever a canned database files is usedby Sangbida Chaudhuri · 81d1d4a3 · Jan 26, 2026 · 8 filesMessage 65 · AdequateInformational 17Details
Commit message · Sangbida Chaudhuri

pytest: use old hsm secret whenever a canned database files is used

Anything using a canned db depends on the node ids being generated from the old hsm seed.

65/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Informational 17/100

This commit only changes test files. It tells the test framework to use an older, fixed HSM (wallet seed) secret whenever a test loads a pre-made ('canned') database snapshot. This ensures the test node's public identity matches the one recorded in the snapshot, so database migration and regression tests keep working after a recent change to how random seeds are generated. It is a test-suite maintenance patch, not a fix for a runtime security vulnerability.

AI review queuedlogging: switch to a simple ringbuffer.by Rusty Russell · 4d8f923a · Jan 26, 2026 · 8 filesMessage 76 · AdequateInformational 19Details
Commit message · Rusty Russell

logging: switch to a simple ringbuffer.

We keep a history of logs internally, so we can drop them to disk on a
crash. This "black box recorder" was some of the first code I wrote
for CLN, but I can't remember the last time we use a crash log to
diagnose a problem.

We attempt to prune it to keep it under 10MB, but the complexity
and cost is rarely worth it: simplify it to use a ringbuffer.

Changelog-Changed: lightningd: logging is now more efficient internally (no more pruning, simple ringbuffer).

```
139993 DEBUG lightningd: fixup_scan: block 786151 with 1203 txs
===> 55388 DEBUG plugin-bcli: Log pruned 1001 entries (mem 10508118 -> 10298662)
33000 DEBUG gossipd: Unreasonable timestamp in 0102000a38ec41f9137a5a560dac6effbde059c12cb727344821cbdd4ef46964a4791a0f67cd997499a6062fc8b4284bf1b47a91541fd0e65129505f02e4d08542b16fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d61900000000000d9d56000ba40001690fe262010100900000000000000001000003e8000001f30000000000989680
23515 DEBUG hsmd: Client: Received message 14 from client
22269 DEBUG 024b9a1fa8e006f1e3937f65f66c408e6da8e1ca728ea43222a7381df1cc449605-hsmd: Got WIRE_HSMD_ECDH_REQ
14409 DEBUG gossipd: Enqueueing update for announce 0102002f7e4b4deb19947c67292e70cb22f7fac837fa9ee6269393f3c513d0431d52672e7387625856c19299cfd584e1a3f39e0f98df13c99090df9f4d5cca8446776fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d61900000000000e216b0008050001692e1c390101009000000000000003e800000000000013880000004526945a00
12534 DEBUG gossipd: Previously-rejected announce for 514127x248x1
10761 DEBUG 02e01367e1d7818a7e9a0e8a52badd5c32615e07568dbe0497b6a47f9bef89d6af-channeld-chan#70770: Got it!
10761 DEBUG 02e01367e1d7818a7e9a0e8a52badd5c32615e07568dbe0497b6a47f9bef89d6af-channeld-chan#70770: ... , awaiting 1120
10761 DEBUG 02e01367e1d7818a7e9a0e8a52badd5c32615e07568dbe0497b6a47f9bef89d6af-channeld-chan#70770: Sending master 1020
```

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

76/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
Why it was queued
signing or wallet pathsecond-pass: broader security terminologysecond-pass: security-sensitive path
AI analysis · Informational 19/100

This commit rewrites Core Lightning's internal log storage from a dynamically pruned array into a fixed 16 MB ring buffer. It is a refactoring/cleanup change: the old pruning logic is removed, the log size is now hard-capped, and the 'SKIPPED' entries in the getlog RPC are eliminated. There is no direct security fix described by the author, and the diff does not show an obvious exploitable vulnerability. The main security-relevant side effect is that crash logs and the getlog output now contain only the most recent 16 MB of messages, which could slightly reduce forensic information after an incident.

AI review queuedlightningd: remove `decodepay`.by Rusty Russell · 592f8586 · Jan 20, 2026 · 24 filesMessage 58 · ThinInformational 19Details
Commit message · Rusty Russell

lightningd: remove `decodepay`.

Changelog-Removed: JSON-RPC: `decodepay` (use `decode`), deprecated v24.11.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

58/100 · ThinMessage clarity
✓ Descriptive subject✓ Provides detailed explanatory context
Why it was queued
parser or protocol pathsecond-pass: unusually broad changesecond-pass: security-sensitive path
AI analysis · Informational 19/100

This commit removes the old 'decodepay' JSON-RPC command from Core Lightning. It was already marked as deprecated and users are directed to use the newer 'decode' command instead. There is no security bug being fixed here; it is a routine cleanup of an obsolete API.

AI review queuedmsggen: add string_map typeby daywalker90 · 8bc2e76f · Jan 19, 2026 · 7 filesMessage 35 · OpaqueInformational 15Details
Commit message · daywalker90

msggen: add string_map type

35/100 · OpaqueMessage clarity
✓ Descriptive subject! No meaningful explanatory body
Why it was queued
second-pass: opaque commit message
AI analysis · Informational 15/100

This commit adds a new data type called 'string_map' to the code generator used for converting between Core Lightning's JSON-RPC interface and its gRPC/Rust interfaces. It is a feature addition for the message generator and testing schema validator, not a security fix or vulnerability patch.

AI review queuedclnrest: add clnrest-register-path method for dynamic pathsby daywalker90 · d03cf820 · Jan 19, 2026 · 25 filesMessage 65 · AdequateLow 39Details
Commit message · daywalker90

clnrest: add clnrest-register-path method for dynamic paths

Changelog-Added: clnrest: add clnrest-register-path rpc method to register dynamic paths

65/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body
Why it was queued
second-pass: unusually broad change
AI analysis · Low 39/100

This commit adds a new feature to Core Lightning's REST plugin that lets plugin developers register custom web API paths. It is a feature addition rather than a fix for a known vulnerability. The change expands the attack surface of the REST API by allowing dynamic path registration, but it also includes optional rune-based access controls. There is no direct evidence in the commit of a security bug, though any dynamic routing feature introduces risks if paths are registered carelessly or if input validation is flawed.

AI review queuedwallet: change dev_listaddrs to also list bip86 addressesby Sangbida Chaudhuri · e19fd5d6 · Jan 14, 2026 · 1 fileMessage 83 · StrongInformational 17Details
Commit message · Sangbida Chaudhuri

wallet: change dev_listaddrs to also list bip86 addresses

listaddrs is dev only and used in tests so it's okay if we change the API here, the usage is by positional arguments in tests so we're okay. Also changing est_option_upfront_shutdown_script to handle both old hsmsecret and the newer mnemonic one.

83/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Informational 17/100

This is a small developer-only change to a wallet debugging command. It makes the internal `dev_listaddrs` tool also work with newer BIP86-style wallets (mnemonic/seed-based), instead of only older BIP32-style wallets. There is no direct evidence this fixes an exploitable security bug; it appears to be a compatibility/API improvement for tests.

AI review queuedwallet: use correct derivation for elements when using mnemonic hsm_secret.by Rusty Russell · 29465f52 · Jan 14, 2026 · 1 fileMessage 73 · AdequateModerate 57Details
Commit message · Rusty Russell

wallet: use correct derivation for elements when using mnemonic hsm_secret.

Even though we don't do taproot addresses on elements yet, use the
same scheme for simplicity and for future when we *do* do taproot.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Moderate 57/100

This change fixes how Core Lightning derives Bitcoin/Elements addresses when creating change outputs or PSBT outputs from a wallet seed phrase (mnemonic). Previously, on Elements sidechains, the code derived the public key one way and then built a SegWit address from it directly. Now it uses a dedicated helper that follows the same derivation path used elsewhere (including the future Taproot path). The practical risk is that change outputs could have been sent to addresses the wallet did not fully recognize or could not later spend from, which can lock up funds.

AI review queuedlightning-hsmtool: fix dumponchaindescriptors for mnemonic hsm_secrets.by Rusty Russell · d2123a94 · Jan 14, 2026 · 2 filesMessage 73 · AdequateLow 29Details
Commit message · Rusty Russell

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

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Low 29/100

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.

AI review queuedplugins/pay: don't crash if erring index is past route array end.by Rusty Russell · 9c6430c0 · Jan 14, 2026 · 1 fileMessage 81 · StrongModerate 60Details
Commit message · Rusty Russell

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

81/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
Why it was queued
second-pass: broader security terminology
AI analysis · Moderate 60/100

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.

AI review queuedaskrene: don't crash if refining flow which has capacity greaater than max it should have.by Rusty Russell · 35e703bf · Jan 14, 2026 · 1 fileMessage 81 · StrongLow 42Details
Commit message · Rusty Russell

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

81/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
Why it was queued
second-pass: broader security terminology
AI analysis · Low 42/100

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.

AI review queuedlightning-hsmtool: support extracting the mnemonic from hsm_secret.by Rusty Russell · f975bb37 · Jan 13, 2026 · 5 filesMessage 73 · AdequateInformational 20Details
Commit message · Rusty Russell

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

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Informational 20/100

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.

AI review queuedaskrene: fix payment crashby Lagrang3 · 118e4746 · Jan 13, 2026 · 2 filesMessage 58 · ThinLow 44Details
Commit message · Lagrang3

askrene: 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>

58/100 · ThinMessage clarity
✓ Descriptive subject✓ Provides detailed explanatory context
Why it was queued
second-pass: broader security terminology
AI analysis · Low 44/100

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.

AI review queuedpytest: fix timing flake in test_invoice_expiry.by Rusty Russell · 56a32c9f · Jan 8, 2026 · 1 fileMessage 78 · AdequateInformational 15Details
Commit message · Rusty Russell

pytest: fix timing flake in test_invoice_expiry.

Under Postgres, this actually takes more than 2 seconds, so w2
really has timed out already:

```
time.sleep(2) # total 2
assert not w1.done()
> assert not w2.done()
E assert not True
E + where True = done()
E + where done = <Future at 0x7fe14e54fee0 state=finished raised RpcError>.done

tests/test_invoices.py:420: AssertionError
```

So space the timeouts out more, and sleep one second too short; the
.result() (which sleeps) will catch up if we were extremely slow.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

78/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
Why it was queued
second-pass: broader security terminology
AI analysis · Informational 15/100

This commit only adjusts timing values in a single test file to prevent a flaky test failure under slow CI runners (specifically Postgres). It does not change production code, protocol behavior, or any security-relevant logic.

AI review queuedpytest: work around pay flakiness.by Rusty Russell · 2333f024 · Jan 8, 2026 · 1 fileMessage 86 · StrongInformational 12Details
Commit message · Rusty Russell

pytest: work around pay flakiness.

pay sometimes ignores exclusions. WONTFIX.

```
with pytest.raises(RpcError, match=r'is not reachable directly and all routehints were unusable.'):
> l1.rpc.pay(inv, exclude=[scid12])

tests/test_pay.py:5279:
...
elif "error" in resp:
> raise RpcError(method, payload, resp['error'])
E pyln.client.lightning.RpcError: RPC call failed: method: pay, payload: {'bolt11': 'lnbcrt1230n1p54mma3sp5x7uerjgyg7ws6fnzdwxc7pgpj6j25uhpqp5uvx3fk8dkcqm37m2spp5k02racjc9knux958u5rgtva24jfvxtr5w3t53pfeavn3thmyny0qdq8v3jhxccxqyjw5qcqp9rzjqgkjyd3q5dv6gllh77kygly9c3kfy0d9xwyjyxsq2nq3c83u5vw4jqqqvuqqqqgqqqqqqqqpqqqqqzsqqc9qxpqysgqcmv875mmzcjl8mwxxndy9an6p870ffpdxdtypmgf5gzsydnt2d68n4kjph0rcprye6tfz0ex0c5clgj3zwm8jgd5vs0fdv7hf7dqr8cqdrg3gf', 'exclude': ['103x2x0/1']}, error: {'code': 210, 'message': 'Ran out of routes to try after 6 attempts: see `paystatus`', 'attempts': [{'status': 'failed', 'failreason': 'No path found', 'partid': 0, 'amount_msat': 123000}, {'status': 'pending', 'failreason': 'No path found', 'partid': 1, 'amount_msat': 123000, 'parent_partid': 0}, {'status': 'failed', 'failreason': 'No path found', 'partid': 2, 'amount_msat': 57006, 'parent_partid': 1}, {'status': 'failed', 'failreason': 'No path found', 'partid': 4, 'amount_msat': 57006, 'parent_partid': 2}, {'status': 'failed', 'failreason': 'No path found', 'partid': 3, 'amount_msat': 65994, 'parent_partid': 1}, {'status': 'failed', 'failreason': 'No path found', 'partid': 5, 'amount_msat': 65994, 'parent_partid': 3}]}
```

The logs show that it doesn't exclude the routehint early: in successful runs we get "After filtering routehints we're left with 0 usable hints". Perhaps this is something to do with the timing of our own notifications?

```
2026-01-07T05:51:10.7902502Z lightningd-1 2026-01-07T05:31:29.706Z DEBUG plugin-pay: cmd -c:pay#64/cln:pay#121 partid 0: Received getchaininfo blockcount=108, headercount=108
2026-01-07T05:51:10.7903334Z lightningd-1 2026-01-07T05:31:29.715Z DEBUG plugin-pay: cmd -c:pay#64/cln:pay#121 partid 0: waitblockheight reports syncheight=108
2026-01-07T05:51:10.7904256Z lightningd-1 2026-01-07T05:31:29.734Z DEBUG plugin-pay: cmd -c:pay#64/cln:pay#121 partid 0: Updated a channel hint for 103x2x0/1: enabled true, estimated capacity 978718000msat
2026-01-07T05:51:10.7905355Z lightningd-1 2026-01-07T05:31:29.734Z DEBUG plugin-pay: cmd -c:pay#64/cln:pay#121 partid 0: Updated a channel hint for 7269357x11669990x33910/1: enabled false, estimated capacity UNKNOWN
2026-01-07T05:51:10.7906580Z lightningd-1 2026-01-07T05:31:29.735Z DEBUG plugin-pay: cmd -c:pay#64/cln:pay#121 partid 0: Updated a channel hint for 103x2x0/1: enabled false, estimated capacity UNKNOWN
2026-01-07T05:51:10.7907665Z lightningd-1 2026-01-07T05:31:29.735Z INFO plugin-pay: cmd -c:pay#64/cln:pay#121 partid 0: Payment fee constraint 615msat is below exemption threshold, allowing a maximum fee of 5000msat
2026-01-07T05:51:10.7908845Z lightningd-1 2026-01-07T05:31:29.752Z DEBUG plugin-pay: Received a channel_hint {.scid = 103x2x0/1, .enabled = 1, .estimate = 978718000msat, .capacity = 1000000000msat }
2026-01-07T05:51:10.7909710Z lightningd-1 2026-01-07T05:31:29.754Z INFO plugin-pay: cmd -c:pay#64/cln:pay#121 partid 0: Filtering out 1 routehints
2026-01-07T05:51:10.7910544Z lightningd-1 2026-01-07T05:31:29.779Z DEBUG plugin-pay: cmd -c:pay#64/cln:pay#121 partid 0: Checking hint {.scid=103x2x0/1, .enabled=1, .estimate=978718000msat}
2026-01-07T05:51:10.7911470Z lightningd-1 2026-01-07T05:31:29.780Z DEBUG plugin-pay: cmd -c:pay#64/cln:pay#121 partid 0: After filtering routehints we're left with 1 usable hints
2026-01-07T05:51:10.7912385Z lightningd-1 2026-01-07T05:31:29.780Z DEBUG plugin-pay: cmd -c:pay#64/cln:pay#121 partid 0: Checking hint {.scid=103x2x0/1, .enabled=1, .estimate=978718000msat}
2026-01-07T05:51:10.7913471Z lightningd-1 2026-01-07T05:31:29.780Z DEBUG plugin-pay: cmd -c:pay#64/cln:pay#121 partid 0: Using routehint 022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59 (103x1x0) cltv_delta=6
```

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

86/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference
Why it was queued
second-pass: broader security terminology
AI analysis · Informational 12/100

This commit only adds a test-flakiness workaround. It marks an existing test as flaky so the test suite will retry it if it fails. The underlying behavior being tested—a payment command sometimes ignoring an excluded route—was already known and labeled WONTFIX by the project. No production code was changed, and there is no indication this is treated as a security issue.

AI review queuedlightningd: fix segfault when parse_filter failsby dovgopoly · a1a4affe · Dec 22, 2025 · 1 fileMessage 68 · AdequateHigh 72Details
Commit message · dovgopoly

lightningd: fix segfault when parse_filter fails

We need to initialize ->json_cmd *before* complaining about malformed
filters.

```
lightningd: FATAL SIGNAL 11 (version v25.12-21-g3851187-modded)
0x1042d2023 ???
send_backtrace+0x4f:0
0x1042d20cb ???
crashdump+0x43:0
0x19fe3b743 ???
???:0
0x104180173 command_log
lightningd/jsonrpc.c:1406
0x10420d8f7 command_fail_badparam
common/json_command.c:25
0x104181a07 parse_request
lightningd/jsonrpc.c:1075
0x104181a07 read_json
lightningd/jsonrpc.c:1216
0x10424c65b next_plan
ccan/ccan/io/io.c:60
0x10424c65b do_plan
ccan/ccan/io/io.c:422
0x10424c587 io_ready
ccan/ccan/io/io.c:439
0x10424dd9b io_loop
ccan/ccan/io/poll.c:470
0x10417ede7 io_loop_with_timers
lightningd/io_loop_with_timers.c:22
0x104183a33 main
lightningd/lightningd.c:1492
```

Co-authored-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Fixed: JSON-RPC: malformed filters no longer crash lightningd.

68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
second-pass: broader security terminology
AI analysis · High 72/100

This commit fixes a bug where a malformed JSON-RPC filter could crash the Core Lightning daemon (lightningd) with a segmentation fault. The crash happened because the code tried to report the malformed filter before it had looked up the command it was processing. The fix moves the command lookup earlier, so the error can be reported safely without dereferencing a null pointer.

AI review queuedplugins: lsps: remove anyhow from tlvsby Peter Neuroth · 4a1c9220 · Dec 16, 2025 · 1 fileMessage 68 · AdequateInformational 12Details
Commit message · Peter Neuroth

plugins: lsps: remove anyhow from tlvs

Remove anyhow as a dependency from the tlv module. This allows for a
cleaner error handling

Changelog-None

Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>

68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
second-pass: broader security terminology
AI analysis · Informational 12/100

This commit is a routine code cleanup in a Core Lightning plugin. It swaps one Rust error-handling library (anyhow) for another (thiserror) in the TLV (type-length-value) parsing module. The actual parsing logic and security checks remain the same; only the way errors are represented and reported is changed. There is no indication this fixes a security bug.

AI review queuedplugins: lsps: replace heavy transportby Peter Neuroth · 462ca844 · Dec 16, 2025 · 6 filesMessage 68 · AdequateLow 27Details
Commit message · Peter Neuroth

plugins: lsps: replace heavy transport

We replace the legacy transport by a slim custommsg hook that makes use
of the lightweight multiplexed transport and avoids deserialization and
serialization through this extra layer

Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>

68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
second-pass: broader security terminology
AI analysis · Low 27/100

This commit refactors the LSPS (Lightning Service Provider Specification) plugin in Core Lightning to replace a heavier custom-message transport layer with a slimmer one. It removes a 536-line transport module and introduces a simpler hook-based multiplexer. The change is a code-quality/architecture refactor; there is no direct evidence in the commit or supplied references that it fixes a security vulnerability.

AI review queuedlightningd: fix db constraint error when fixing up old blocks.by Rusty Russell · cef11ea3 · Dec 11, 2025 · 3 filesMessage 85 · StrongLow 43Details
Commit message · Rusty Russell

lightningd: fix db constraint error when fixing up old blocks.

It's very hard to reproduce, since we only consider UTXOs we are watching, but scanning
from the first block we know about is wrong, because we don't care about blocks which
we only put in the db in response to old gossip queries.

I'm not sure how Sjors got into the state where they see their own UTXO spend in a block
they don't have in the database, but we shouldn't crash:

```
2025-12-07T11:25:18.163Z **BROKEN** lightningd: Error executing statement: wallet/wallet.c:4913: UPDATE outputs SET spend_height = ?, status = ? WHERE prev_out_tx = ? AND prev_out_index = ?: FOREIGN KEY constraint failed
2025-12-07T11:25:18.163Z **BROKEN** lightningd: Error executing statement: wallet/wallet.c:4913: UPDATE outputs SET spend_height = ?, status = ? WHERE prev_out_tx = ? AND prev_out_index = ?: FOREIGN KEY constraint failed
2025-12-07T11:25:18.179Z **BROKEN** lightningd: FATAL SIGNAL 6 (version v25.12)
2025-12-07T11:25:18.180Z **BROKEN** lightningd: backtrace: common/daemon.c:46 (send_backtrace) 0x5e263feb9292
2025-12-07T11:25:18.180Z **BROKEN** lightningd: backtrace: common/daemon.c:83 (crashdump) 0x5e263feb92e1
2025-12-07T11:25:18.180Z **BROKEN** lightningd: backtrace: (null):0 ((null)) 0x70ee6f64532f
2025-12-07T11:25:18.180Z **BROKEN** lightningd: backtrace: (null):0 ((null)) 0x70ee6f69eb2c
2025-12-07T11:25:18.180Z **BROKEN** lightningd: backtrace: (null):0 ((null)) 0x70ee6f64527d
2025-12-07T11:25:18.180Z **BROKEN** lightningd: backtrace: (null):0 ((null)) 0x70ee6f6288fe
2025-12-07T11:25:18.180Z **BROKEN** lightningd: backtrace: lightningd/log.c:1054 (fatal_vfmt) 0x5e263fe38e10
2025-12-07T11:25:18.180Z **BROKEN** lightningd: backtrace: wallet/db.c:95 (db_error) 0x5e263fe6f7ef
2025-12-07T11:25:18.180Z **BROKEN** lightningd: backtrace: db/utils.c:326 (db_fatal) 0x5e263feaa797
2025-12-07T11:25:18.180Z **BROKEN** lightningd: backtrace: db/utils.c:200 (db_exec_prepared_v2) 0x5e263feaab85
2025-12-07T11:25:18.180Z **BROKEN** lightningd: backtrace: wallet/wallet.c:4924 (wallet_outpoint_spend) 0x5e263fe7de2f
2025-12-07T11:25:18.180Z **BROKEN** lightningd: backtrace: lightningd/chaintopology.c:929 (topo_update_spends) 0x5e263fe0af81
2025-12-07T11:25:18.180Z **BROKEN** lightningd: backtrace: lightningd/chaintopology.c:1532 (fixup_scan_block) 0x5e263fe0c268
2025-12-07T11:25:18.180Z **BROKEN** lightningd: backtrace: lightningd/bitcoind.c:503 (getrawblockbyheight_callback) 0x5e263fe09280
2025-12-07T11:25:18.180Z **BROKEN** lightningd: backtrace: lightningd/plugin.c:701 (plugin_response_handle) 0x5e263fe5bf2b
2025-12-07T11:25:18.180Z **BROKEN** lightningd: backtrace: lightningd/plugin.c:790 (plugin_read_json) 0x5e263fe610e7
2025-12-07T11:25:18.180Z **BROKEN** lightningd: backtrace: ccan/ccan/io/io.c:60 (next_plan) 0x5e263fef3629
2025-12-07T11:25:18.180Z **BROKEN** lightningd: backtrace: ccan/ccan/io/io.c:422 (do_plan) 0x5e263fef3afa
2025-12-07T11:25:18.180Z **BROKEN** lightningd: backtrace: ccan/ccan/io/io.c:439 (io_ready) 0x5e263fef3bb7
2025-12-07T11:25:18.180Z **BROKEN** lightningd: backtrace: ccan/ccan/io/poll.c:470 (io_loop) 0x5e263fef55c5
2025-12-07T11:25:18.180Z **BROKEN** lightningd: backtrace: lightningd/io_loop_with_timers.c:22 (io_loop_with_timers) 0x5e263fe308e9
2025-12-07T11:25:18.180Z **BROKEN** lightningd: backtrace: lightningd/lightningd.c:1492 (main) 0x5e263fe363ce
2025-12-07T11:25:18.180Z **BROKEN** lightningd: backtrace: (null):0 ((null)) 0x70ee6f62a1c9
2025-12-07T11:25:18.180Z **BROKEN** lightningd: backtrace: (null):0 ((null)) 0x70ee6f62a28a
2025-12-07T11:25:18.180Z **BROKEN** lightningd: backtrace: (null):0 ((null)) 0x5e263fe06bf4
2025-12-07T11:25:18.180Z **BROKEN** lightningd: backtrace: (null):0 ((null)) 0xffffffffffffffff
```

Changelog-Fixes: lightningd: crash on fixup scan with old blocks.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

85/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode
Why it was queued
signing or wallet pathsecond-pass: broader security terminologysecond-pass: security-sensitive path
AI analysis · Low 43/100

This commit fixes a crash in Core Lightning (a Bitcoin Lightning Network node implementation) that could occur during a one-time database repair scan. The node would start scanning from the oldest block it had ever stored, including blocks saved only for old network gossip queries. If one of those early blocks contained a spend of the node's own funds, the code tried to update a database record referencing a block height that did not exist in the main chain-tracking table, triggering a foreign-key constraint failure and crashing the daemon with SIGABRT. The fix makes the scan start from the oldest contiguous block in the main chain record instead, skipping the gossip-only backfilled blocks.

AI review queuedlightningd: fix crash on fixup scan if block unavailable.by Rusty Russell · 22f7a620 · Dec 10, 2025 · 1 fileMessage 83 · StrongModerate 54Details
Commit message · Rusty Russell

lightningd: fix crash on fixup scan if block unavailable.

```
lightningd: FATAL SIGNAL 11 (version v25.12rc3-1-g498c5b6)
0x5cc2f620ce4c send_backtrace
common/daemon.c:38
0x5cc2f620cee8 crashdump
common/daemon.c:83
0x7e3ac1e4532f ???
./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0x5cc2f615f186 fixup_scan_block
lightningd/chaintopology.c:1531
0x5cc2f615c22c getrawblockbyheight_callback
lightningd/bitcoind.c:484
0x5cc2f61aee87 plugin_response_handle
lightningd/plugin.c:701
0x5cc2f61b4043 plugin_read_json
lightningd/plugin.c:790
0x5cc2f6248d8b next_plan
ccan/ccan/io/io.c:60
0x5cc2f624925c do_plan
ccan/ccan/io/io.c:422
0x5cc2f6249319 io_ready
ccan/ccan/io/io.c:439
0x5cc2f624ad24 io_loop
ccan/ccan/io/poll.c:470
0x5cc2f618381a io_loop_with_timers
lightningd/io_loop_with_timers.c:22
0x5cc2f61892ff main
```

This happens intermittantly on in a few tests:

tests/test_invoices.py::test_invoice_botched_migration
tests/test_pay.py::test_pay_bolt11_metadata
tests/test_runes.py::test_id_migration

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Fixed: lightningd: potential crash on startup if bitcoind isn't up-to-date.

83/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
Why it was queued
second-pass: broader security terminology
AI analysis · Moderate 54/100

This commit fixes a bug where Core Lightning could crash with a segmentation fault (FATAL SIGNAL 11) during startup if the connected Bitcoin node could not provide a requested block. The crash occurred because a function tried to use a block that was not actually loaded. The fix adds a simple check: if the block is missing, log a warning and try again on the next restart instead of crashing.

AI review queuedgit: Remove generated binaryby Christian Decker · 686ce989 · Dec 8, 2025 · 1 fileMessage 35 · OpaqueInformational 15Details
Commit message · Christian Decker

git: Remove generated binary

35/100 · OpaqueMessage clarity
✓ Descriptive subject! No meaningful explanatory body
Why it was queued
second-pass: opaque commit message
AI analysis · Informational 15/100

This commit simply deletes a generated binary file (devtools/check-bolt) that had been accidentally committed to the Git repository. There is no code change, no bug fix, and no security-relevant behavior change. It is a repository hygiene cleanup.

AI review queueddoc: Update release instructionsby ShahanaFarooqui · c03288cf · Dec 5, 2025 · 1 fileMessage 35 · OpaqueInformational 15Details
Commit message · ShahanaFarooqui

doc: Update release instructions

35/100 · OpaqueMessage clarity
✓ Descriptive subject! No meaningful explanatory body
Why it was queued
documentation-only discountsecond-pass: opaque commit message
AI analysis · Informational 15/100

This commit only updates the project's internal release checklist documentation. It changes wording and commands used by maintainers when publishing a new version, such as pushing a specific tag to the origin remote instead of pushing all tags. There is no change to the actual Core Lightning software, its network behavior, or any user-facing functionality, so it has no security impact on users.

AI review queuedpytest: add test that we correctly scan back for missed UTXOs.by Rusty Russell · 9d4a150b · Nov 28, 2025 · 2 filesMessage 83 · StrongInformational 15Details
Commit message · Rusty Russell

pytest: add test that we correctly scan back for missed UTXOs.

I took the node from the original test which missed the UTXO, and
added some more blocks.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

83/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Informational 15/100

This commit only adds a new regression test for an existing wallet fix. It does not change any production code, so it cannot introduce a new security vulnerability or directly fix one in the shipped software. The test verifies that Core Lightning correctly rescans older blocks to find UTXOs it previously missed after a database upgrade.