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 29 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.
41278b4e · Sep 21, 2026 · 2 filesInformational 15contrib: add jaonoctus's signing key
Add jaonoctus's PGP fingerprint to the "Signatures For Releases" table
in both SECURITY.md and the security-policy doc, which are kept in sync.
Changelog-None
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.
d1b6963b · Sep 11, 2026 · 24 filesInformational 21docs: document missing and fix erroneous JSON-RPC error codes
Audit the `errors` sections of the RPC schemas against the error codes
the handlers actually raise, and fix the discrepancies.
FUNDING_STILL_SYNCING_BITCOIN (304) is only raised by `fundpsbt` and
`utxopsbt` (wallet/reservation.c), and is forwarded verbatim by every
other command which can return it. Document it on `fundpsbt`,
`utxopsbt`, `txprepare`, `withdraw`, `multiwithdraw`, `upgradewallet`,
`fundchannel` and `multifundchannel`. Conversely, `fundchannel_start`
and `openchannel_init` do not call either: when the node is not synced
they delay via topology_add_sync_waiter() and retry, so drop their
stale 304.
Also fix the remaining discrepancies:
- `delpay` documented 211 for a status mismatch, but that path returns
208 (PAY_NO_SUCH_PAYMENT); 211 is never raised by `delpay`, so replace
it;
- document missing codes: `createinvoice` 907 (INVOICE_OFFER_INACTIVE),
`enableoffer` 1007 (OFFER_USED_SINGLE_USE), `getroutes` 217
(PAY_USER_ERROR) and `addpsbtoutput` 302/309;
- add `errors` sections to `splice_init`, `splice_update` and
`splice_signed` (351-356), `disableoffer` and `disableinvoicerequest`
(1001), `preapproveinvoice` (213), `preapprovekeysend` (214) and
`recover` (1600).
The splice commands can also fail asynchronously, after the command has
gone pending, through the channeld message handlers in channel_control.c
which resolve the pending command via splice_command_for_chan().
Document those codes too: 350 (SPLICE_BROADCAST_FAIL) on `splice_signed`;
357/359/360 (SPLICE_FUNDING_LOW/SPLICE_LOW_FEE/SPLICE_HIGH_FEE) on
`splice_update`; and 358/362/363 (SPLICE_STATE_ERROR/SPLICE_ABORT/
SPLICE_CHANNEL_ERROR) on all three.
Changelog-None
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, validation, or behavior was changed, so it cannot be exploited or cause runtime failures. It mainly helps developers and automated tools build correct clients.
c09c4520 · Sep 8, 2026 · 1 fileLow 46channeld: initialize tx_sigs_allowed on startup
peer->tx_sigs_allowed was only set in peer_reconnect() and when we
receive channel_ready, so on a fresh channeld start a stray
tx_signatures arriving before the peer's channel_ready made
handle_unexpected_tx_sigs() read an uninitialized bool. UBSan flags
this as a load of an invalid bool value, and in normal builds the
"warn and disconnect" branch was effectively taken at random.
Default it to false: we only allow an unexpected tx_signatures when
reconnecting.
Changelog-None
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 would read an uninitialized value. In practice this usually caused a random, harmless disconnection, but under undefined-behavior detection it was flagged as a serious bug. The fix simply sets the value to false at startup.
5685c9a3 · Sep 8, 2026 · 1 fileInformational 15ci: fix the coverage nightly's profile handling
Three things stand between the restored scripts and a nightly that
finishes:
pyln-testing sets CLN_TEST_NAME for every test, so the profiles land in
$CLN_COVERAGE_DIR/<test-name>/ and never directly in $CLN_COVERAGE_DIR.
The coverage-raw/*.profraw upload glob therefore matches nothing, under
if-no-files-found: error. A local three-test run produced 515 profiles,
all of them in subdirectories. Both jobs now hand the directory to
collect-coverage.sh, which walks it and drops what crashed tests left
half-written; that also retires the flattening cp, which could collide
on <pid>-<signature>.profraw between matrix cells.
The build uses the runner's default clang while the report job installed
LLVM 18 and symlinked llvm-profdata to it. There are no compatibility
guarantees for the raw profile format across LLVM releases, so the two
have to come from the same one.
Codecov cannot read a .profdata; it gets the lcov export instead.
Changelog-None
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HGKo3ccLpkH2xFeEXUzEBK
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-compatible lcov report instead of an unreadable .profdata file. There is no security issue here—just build-script maintenance.
ddbd2963 · Sep 3, 2026 · 50 filesLow 37schemas: make required fields match the code
Fields added to `required` (source where unconditionally added):
- askrene-create-layer/layers[]. & askrene-listlayers/layers[]:
`biases`, `node_biases` - plugins/askrene/layer.c:1512,1519
- bkpr-channelsapy/channels[]: `fees_in_msat` - plugins/bkpr/channelsapy.c:292
- bkpr-report: `format` (request) - plugins/bkpr/bookkeeper.c:520;
`format-hint` - plugins/bkpr/report.c:499
- datastore & deldatastore: `generation`, `hex` - lightningd/datastore.c:19,20
- decode/offer_recurrence[]: `compulsory_field` - plugins/offers.c:880
- delpay/payments[]: `groupid` - lightningd/pay.c:144
- feerates/onchain_fee_estimates: `unilateral_close_nonanchor_satoshis`
- lightningd/chaintopology.c:788
- fundchannel_start: `channel_type` - lightningd/opening_control.c:321
- help: `format-hint` - lightningd/jsonrpc.c:496
- hook/onion_message_recv & _secret: `unknown_fields`,
`reply_blindedpath.{first_path_key,hops}` - lightningd/onion_message.c:30,31,66
- listchannels/channels[]: `htlc_maximum_msat` - plugins/topology.c:263
- listclosedchannels/closedchannels[]: `channel_type`
- lightningd/closed_channel.c:43
- listconfigs: `configs` - lightningd/configs.c:275
- listpays/pays[]: `amount_sent_msat` - plugins/xpay/listpays.c:183
- listpeerchannels/channels[]: `channel_type` - lightningd/peer_control.c:959,
lightningd/dual_open_control.c:128, lightningd/opening_control.c:48
- listpeers/peers[]: `features` - lightningd/peer_control.c:2619
- multifundchannel: `failed` - plugins/spender/multifundchannel.c:501
- notification/coin_movement: `extra_tags` - lightningd/coin_mvts.c:169
- offer: `force_paths` - lightningd/offer.c:24
- openchannel_init & openchannel_bump: `requires_confirmed_inputs`
- lightningd/dual_open_control.c:3478
- parsefeerate: `perkw` - lightningd/chaintopology.c:823
- pay: `destination` - plugins/xpay/xpay.c:473, plugins/libplugin-pay.c:2144
- reckless (request): `target/subcommand` - plugins/recklessrpc.c:280
- renepay & renepaystatus/paystatus[]: `groupid`, `destination`
- plugins/renepay/json.c:269,278,279
- sendonion: `groupid` - lightningd/pay.c:144; pending branch `message` - :299
- sendpay & waitsendpay: `groupid` - lightningd/pay.c:144
- splice_signed: `outnum` - lightningd/channel_control.c:548
- splicein & spliceout: `psbt`, `txid` - plugins/spender/splice.c:1763,1764
Fields removed from `required` (conditional in code):
- bkpr-editdescriptionbypaymentid/items[]: `description`
- plugins/bkpr/chain_event.c:33-34, plugins/bkpr/channel_event.c:53-54
- createinvoice & sendinvoice: `description` - lightningd/invoice.c:64-65
- hook/invoice_payment: `result` - lightningd/invoice.c:237 (optional);
`failure_message` only used when `result` is absent, now required there
via if/then/else
- invoicerequest (request): `description` - plugins/offers_offer.c:693 (p_opt)
- splice_signed (request): `channel_id` - lightningd/channel_control.c:2511
(p_opt)
Note: bkpr-editdescriptionbyoutpoint keeps `description` required: the
SQL refetch filters credit_msat > 0 (recorder.c:376-382) and the desc was
just stored keyed by outpoint (bookkeeper.c:853).
Adjust plugins and tests to the now-required fields:
- lsps-plugin: peer.features is non-optional (listpeers)
- wss-proxy-plugin: listconfigs' configs object is non-optional
- cln-rpc/src/test.rs
Changelog-None
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 practice it mostly removes 'optional' markers from fields that were already unconditionally emitted, and makes a few truly conditional fields optional. It also changes one plugin hook response schema so that a plugin can reject a payment by returning only a custom failure_message, without a result field. The changes are broad but are described by the project as a schema consistency fix, not a security fix. There is no direct evidence in the commit of an exploitable vulnerability.
a34b9758 · Sep 2, 2026 · 6 filesInformational 15doc: document error 313 on every command which can return it
FUND_CANNOT_AFFORD_WITH_EMERGENCY is raised in exactly two places,
`fundpsbt` and `utxopsbt` (wallet/reservation.c), when the node has an
anchor channel and the transaction would not leave `min-emergency-msat`
behind. Note that this does not require `opening_anchor_channel`: any
existing anchor channel is enough.
Every other command which can return it does so by forwarding one of
those two errors verbatim, but only `withdraw`, `fundchannel` and
`multifundchannel` documented it. Add it to the rest:
- `fundpsbt` and `utxopsbt`, which raise it directly;
- `txprepare` and `multiwithdraw`, which call them;
- `upgradewallet`, which calls `utxopsbt` via txprepare_continue() and
had no `errors` section at all, so document -1 and 301 there too.
Changelog-None
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 and was already documented for some commands; this change makes the documentation complete and consistent. No code behavior changes.
8e495707 · Sep 2, 2026 · 1 fileLow 25tools/build-release.sh: name the checksum file when verifying the signature
The --verify path called `gpg --verify ../SHA256SUMS-$VERSION.asc` and
let gpg work out the rest. For a proper detached signature it does find
the sibling file, so this happened to work, but an inline signed .asc
would verify its own embedded payload and exit 0 without ever looking at
the checksums we just compared. Since the exit status is what decides
whether we print "Verified Successfully!", that is not a distinction we
want to leave to gpg.
Changelog-None: docs and release tooling only, nothing user-facing.
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-signed message containing its own text, GPG would still report success without ever checking the actual checksum file. The fix explicitly names the checksum file so GPG verifies the signature against the intended manifest. This is a hardening change in internal release tooling, not a fix for an active vulnerability in the Lightning node software users run.
2dee8699 · Sep 2, 2026 · 2 filesLow 42doc: pass the manifest explicitly to gpg --verify
We told people to drop SHA256SUMS and SHA256SUMS.asc into the same
directory and run `gpg --verify SHA256SUMS.asc`. That relies on gpg
guessing what to check, and the guess only happens for a real detached
signature. If the .asc turns out to be an inline signed message, gpg
verifies the payload embedded in the .asc itself, never touches
SHA256SUMS, and exits 0. It does warn on stderr, but that is easy to
scroll past and worthless to anything checking the exit code.
Spell out both filenames instead, and explain why. Also drop the
"gpg: assuming signed data in 'SHA256SUMS'" line from the sample
output, since gpg has nothing left to assume once we name the file.
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 the .asc file is not a proper detached signature over the manifest, because gpg may verify only a message embedded inside the .asc file and never check SHA256SUMS. The change prevents a subtle but real verification bypass in the release process, though it is a documentation-only fix and does not change any code or tooling.
c1551c55 · Aug 24, 2026 · 1 fileLow 25Cargo.lock: update dependencies
```
cargo update
Updating crates.io index
Locking 87 packages to latest Rust 1.85.0 compatible versions
Updating aho-corasick v1.1.4 -> v1.1.5
Updating android_system_properties v0.1.5 -> v0.1.6
Updating anyhow v1.0.103 -> v1.0.104
Updating async-trait v0.1.89 -> v0.1.92
Updating bitcoin v0.32.101 -> v0.32.102
Updating bitcoin-consensus-encoding v1.0.0 -> v1.2.0
Updating bitcoin-internals v0.5.0 -> v0.6.0
Updating bitflags v2.13.0 -> v2.13.1
Updating cc v1.2.67 -> v1.4.4
Updating crc32fast v1.5.0 -> v1.5.1
Updating data-encoding v2.11.0 -> v2.11.1
Updating displaydoc v0.2.6 -> v0.2.7
Updating dnssec-prover v0.6.8 -> v0.6.9
Updating either v1.16.0 -> v1.18.0
Updating fastrand v2.4.1 -> v2.5.0
Updating find-msvc-tools v0.1.9 -> v0.1.11
Updating futures v0.3.32 -> v0.3.34
Updating futures-channel v0.3.32 -> v0.3.34
Updating futures-core v0.3.32 -> v0.3.34
Updating futures-executor v0.3.32 -> v0.3.34
Updating futures-io v0.3.32 -> v0.3.34
Updating futures-macro v0.3.32 -> v0.3.34
Updating futures-sink v0.3.32 -> v0.3.34
Updating futures-task v0.3.32 -> v0.3.34
Updating futures-util v0.3.32 -> v0.3.34
Updating h2 v0.4.15 -> v0.4.18
Updating hex-conservative v0.3.2 -> v1.2.0
Updating http v1.4.2 -> v1.5.0
Updating http-body v1.0.1 -> v1.1.0
Updating http-body-util v0.1.3 -> v0.1.5
Updating hybrid-array v0.4.13 -> v0.4.14
Updating hyper v1.10.1 -> v1.11.0
Updating ipnet v2.12.0 -> v2.12.1
Updating jiff v0.2.32 -> v0.2.35
Adding jiff-core v0.1.0
Updating jiff-static v0.2.32 -> v0.2.35
Updating js-sys v0.3.103 -> v0.3.104
Updating libc v0.2.186 -> v0.2.189
Updating lightning v0.1.11 -> v0.1.12
Updating lightning-types v0.2.1 -> v0.2.12
Updating litemap v0.8.2 -> v0.8.3
Updating log v0.4.33 -> v0.4.34
Updating mio v1.2.1 -> v1.2.2
Updating num-integer v0.1.46 -> v0.1.47
Updating portable-atomic v1.13.1 -> v1.15.0
Updating potential_utf v0.1.5 -> v0.1.6
Updating proc-macro2 v1.0.106 -> v1.0.107
Updating pulldown-cmark-to-cmark v22.0.0 -> v22.0.1
Updating quote v1.0.46 -> v1.0.47
Updating regex v1.13.0 -> v1.13.1
Updating regex-automata v0.4.15 -> v0.4.18
Updating rustls v0.23.41 -> v0.23.43
Updating rustls-pki-types v1.15.0 -> v1.15.1
Updating rustls-webpki v0.103.13 -> v0.103.15
Updating serde v1.0.228 -> v1.0.229
Updating serde_core v1.0.228 -> v1.0.229
Updating serde_derive v1.0.228 -> v1.0.229
Updating serde_json v1.0.150 -> v1.0.151
Updating serde_qs v1.1.2 -> v1.1.3
Updating simd-adler32 v0.3.9 -> v0.3.10
Updating simd_cesu8 v1.1.1 -> v1.2.0
Updating socket2 v0.6.4 -> v0.6.5
Removing syn v2.0.118
Adding syn v2.0.119
Adding syn v3.0.4
Updating thiserror v2.0.18 -> v2.0.20
Updating thiserror-impl v2.0.18 -> v2.0.20
Updating tinystr v0.8.3 -> v0.8.4
Updating tokio v1.52.3 -> v1.53.1
Updating tokio-macros v2.7.0 -> v2.7.2
Updating tokio-stream v0.1.18 -> v0.1.19
Updating tokio-util v0.7.18 -> v0.7.19
Updating wasm-bindgen v0.2.126 -> v0.2.127
Updating wasm-bindgen-futures v0.4.76 -> v0.4.77
Updating wasm-bindgen-macro v0.2.126 -> v0.2.127
Updating wasm-bindgen-macro-support v0.2.126 -> v0.2.127
Updating wasm-bindgen-shared v0.2.126 -> v0.2.127
Updating web-sys v0.3.103 -> v0.3.104
Updating webpki-root-certs v1.0.8 -> v1.0.9
Updating webpki-roots v1.0.8 -> v1.0.9
Updating writeable v0.6.3 -> v0.6.4
Updating zerocopy v0.8.54 -> v0.8.56
Updating zerocopy-derive v0.8.54 -> v0.8.56
Updating zerotrie v0.2.4 -> v0.2.5
Updating zerovec v0.11.6 -> v0.11.8
Updating zerovec-derive v0.11.3 -> v0.11.6
Updating zlib-rs v0.6.6 -> v0.6.7
Updating zmij v1.0.22 -> v1.0.23
```
Changelog-None
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 it to a known vulnerability. Dependency updates can fix hidden security bugs, but this change alone does not prove any specific flaw exists or is being patched.
83f92e4b · Aug 20, 2026 · 2 filesHigh 80common: bound JSON nesting depth when parsing
json_next() and the JSMN result validator each recurse once per level of
nesting, so a sufficiently deeply nested (but otherwise valid) JSON document
could exhaust the C stack. Bound the nesting depth in json_parse_input(),
before either recursive walk runs, and reject anything deeper. The depth
check is itself iterative, so it cannot overflow.
Changelog-Fixed: JSON-RPC: reject excessively-nested JSON rather than risk a stack overflow.
(cherry picked from commit b940aa32b7b385b4139bbc9251b1cca044c496cc)
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 for each nesting level, so such input could crash the process by exhausting the C call stack. The patch adds an iterative depth check (maximum 256 levels) before any recursive walk, rejecting over-nested input safely.
34883ff7 · Aug 18, 2026 · 2 filesModerate 60wallet: exclude immature coinbase outputs from fee rescue selection
wallet_utxo_boost() selects wallet-funded inputs for anchor and HTLC fee
rescue transactions, but unlike ordinary coin selection it never applied
the coinbase-maturity check. An immature coinbase could therefore be the
sole rescue input, producing a consensus-invalid transaction that Bitcoin
Core rejects as a premature coinbase spend.
Apply the same utxo_is_immature() filter used by deep_enough()/ordinary
selection. Since both call sites pass the live blockheight and rebuild on
reorg/RBF, maturity is revalidated at construction and after reorgs.
This makes test_anchorspend_ignores_immature_coinbase pass, so its xfail
marker is dropped.
Changelog-Fixed: Wallet: anchor and HTLC fee rescue no longer select immature coinbase outputs, which produced a transaction bitcoind rejects
(cherry picked from commit 5e79baacc1c900c29acfae852f6233095872e309)
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 network, potentially leaving a channel unable to quickly bump fees during congestion. The patch adds the same maturity check already used for normal spending.
ba08356f · Aug 17, 2026 · 4 filesHigh 78dualopend: bound the feerates a peer opens at
The previous commits bounded the feerates arriving on every path except
this one. `accepter_start()` takes both `funding_feerate_perkw` and
`feerate_per_kw_commitment` straight off the wire from `open_channel2`
with no bound in either direction, and `dualopend_wire.csv` had no
min_feerate/max_feerate on `dualopend_init` at all -- so it is not that
the check was forgotten at the call site, it is that the bounds were
never plumbed to the daemon.
The `openchannel2` hook only *reports* `feerate_our_max`/`feerate_our_min`
to plugins. With no plugin hooked nothing enforces them, so a peer could
name any feerate and we would sign for it and store it. This is the
`open_channel2` plant named in the advisory, and the missing lower bound
is where the stored `feerate == 0` comes from.
Plumb the bounds into dualopend_init and dualopend_reinit -- reinit too,
since rbf_remote_start runs after a reconnect -- and apply them where the
values are parsed. The two feerates get different floors:
- The commitment feerate is held to feerate_min, as openingd holds
open_channel's: too low and the commitment we are signing cannot be
relayed at the point we need it.
- The funding feerate is held only to FEERATE_FLOOR. A slow funding tx
is the opener's problem and RBF is the remedy, so our policy minimum
would refuse perfectly good opens; but 0 is not a feerate, and it is
exactly the value that leaves no valid next RBF step.
The RBF path needs the upper bound separately: check_funding_feerate()
only enforces the 25/24 step *upwards*, so without this a peer can walk
an accepted open's feerate up without limit, one RBF at a time.
rbf_local_start() is left alone deliberately: that feerate comes from our
own openchannel_bump, which lightningd already holds to our_feerate_max.
As with channeld and openingd, ignore_fee_limits relaxes the policy
bounds but never FEERATE_CEILING.
Changelog-Fixed: dualopend: a peer opening a channel with `--experimental-dual-fund` can no longer name an arbitrary funding or commitment feerate; both are now bounded as other remote-proposed feerates are.
(cherry picked from commit 4e653ad602adbb6afe7f727e029723c6f902171e)
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 fee of zero, an impossibly high fee, or a commitment transaction fee so low it would never confirm. Core Lightning would sign and store these values anyway. The fix adds minimum and maximum fee checks, similar to those already present for other channel-opening paths.
65bdbc47 · Aug 17, 2026 · 2 filesHigh 72tests: regression coverage for out-of-range feerates
Three tests, one per way an absurd feerate used to get in or blow up.
test_feerate_ceiling drives the fee source: bcli trims anything wider
than a u32 of perkb to exactly 0xFFFFFFFF, which is also the value whose
+3 wrapped in the perkb->perkw conversion, so a fee source producing an
absurdly *high* feerate used to arrive as 0perkw and get quietly raised
to the floor. It fails without both the widened conversion and the
ceiling.
test_splice_stored_feerate_repaired_on_upgrade plants the poisoned value
on an inflight and then rewinds the db version so the clamping migrations
run over it, which is the upgrade an already-attacked node goes through.
Parametrized over the overflow value in both the form lightningd itself
would have stored it (db_bind_int makes it negative) and the form you get
writing it by hand, plus the zero case and a merely-large one. Asserts
both that the row is repaired and that listpeerchannels -- which used to
abort right here -- agrees.
test_splice_feerate_too_high covers the accepter bound, which did not
previously exist: force_feerate gets us past our own check on what we
will pay, leaving the peer's bound as the thing under test. The RPC
blocks because the splice_ack never comes, hence the thread.
Changelog-None
(cherry picked from commit a609189feeaad80680c35791abad7e1fea66974d)
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 32-bit integer overflow), causing transactions to be mined very slowly or not at all. Another bug let an attacker plant an out-of-range feerate in the database, which then crashed the node every time it started because a plugin called listpeerchannels before the RPC was available. A third bug allowed a peer to propose a splice with an absurdly high feerate that the accepting node did not previously reject. The commit only contains tests; the actual fixes are implied to exist in the code the tests exercise.
d67c4936 · Aug 17, 2026 · 7 filesModerate 64lightningd: don't assert on funding feerates read from the db
The 25/24 RBF escalation from BOLT #2 is computed on a u32 in three
places, and two of them assert that the result came out larger than the
input. It doesn't, for anything above UINT_MAX/25: the multiplication
wraps and the assert fires. That value comes out of
channel_funding_inflights, which is to say out of whatever fee estimator
(ours or a peer's) produced it, so it is not an invariant we were ever in
a position to state.
The worse of the two is in json_add_channel. listpeerchannels is
read-only introspection that plugins call at startup, so one bad row
turns into a crash-loop with no RPC left to repair it with.
check_funding_feerate() in dualopend already had the right shape for
this, so hoist it into bitcoin/feerate.c as next_funding_feerate() and
use it at all three sites rather than keeping three copies of the
calculation. It also rejects a last feerate of 0, which is the other end
of the same problem: assert(last_feerate > 0) sits immediately above the
overflow one.
That makes next_feerate a field we can fail to produce, so the schema no
longer requires it: a last feerate of 0, or one below 24 where rounding
down lands back on itself, admits no valid next feerate, and there is no
honest value to print for one. The bindings already modelled it that
way (Option<String> in cln-rpc, optional in the proto), so the required
list was the outlier.
The preceding commits bound every path a feerate arrives on, and the
migration repaired what was already stored, so the invariant does now
hold. This is the belt to their braces: a future unbounded write path
should not be able to turn straight back into a crash-loop, and finding
out about it in listpeerchannels is finding out too late. Since the
stored value is in range, the output is unchanged in every reachable
case. openchannel_bump fails the command rather than the daemon.
Changelog-Fixed: lightningd: `listpeerchannels` no longer aborts when a channel has an out-of-range funding feerate stored for an in-progress open.
Changelog-Changed: JSON-RPC: `listpeerchannels`.`next_feerate` is now optional: it is omitted for an in-progress open whose stored feerate admits no valid next feerate.
(cherry picked from commit 84443b55fc4a5cc2d6e3a557f2c58dca60f8f264)
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 internal sanity check (an 'assert') that treated bad stored data as an impossible condition. The fix replaces that hard crash with a safe failure: it either skips the optional 'next fee rate' field in the output, or returns an error for the specific command. This prevents a single bad database row from making the whole node crash repeatedly at startup.
f057c692 · Aug 17, 2026 · 1 fileModerate 53wallet: clamp absurd inflight funding feerates on upgrade
The bounds in the previous commits only apply to feerates arriving from
now on. Nodes that already recorded an absurd `funding_feerate` for an
inflight splice or dual-fund RBF are stuck: the BOLT #2 rule that the
next RBF pays 25/24 times the last feerate is computed on a u32, so
anything above UINT_MAX/25 overflows and trips the
assert(next_feerate > last_feerate) in listpeerchannels. Plugins call
listpeerchannels at startup, so such a node crash-loops with no way out
but to rewrite the stored value.
Clamp it on upgrade. Note we write the feerate with db_bind_int(), so a
u32 above INT_MAX reads back negative; those are exactly the values that
overflow, hence the second clause.
Rewriting is safe: this feerate only sanity checks the fee the funding
transaction already pays and tells the user what the next RBF has to
beat. It never feeds anything we have signed, and lowering it only
relaxes the check.
Changelog-Fixed: lightningd: nodes that stored an out-of-range feerate for an in-progress splice no longer crash-loop on `listpeerchannels`; the stored feerate is clamped on upgrade.
(cherry picked from commit 0393174cb312079da1e0d272640cac145ccdf4c7)
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 later code check would overflow or fail an assertion when listing peer channels. Since plugins call that list at startup, the node would keep crashing. The fix adds a database upgrade step that clamps those bad stored values to safe limits when the node starts up after updating.
96f026ec · Aug 13, 2026 · 2 filesHigh 72lightningd: check value overflow for forward amounts
Blinded paths encrypted_recipient_data payment_relay fee_proportional_millionths
is a 32 bit unsigned integer. We convert to 64 bits before doing arithmetic
operations to avoid integer overflow.
**BROKEN** lightningd: FATAL SIGNAL 8 (version v26.06-197-g8c42be3-modded)
**BROKEN** lightningd: backtrace: common/daemon.c:46 (send_backtrace) 0x556ac0a6be39
**BROKEN** lightningd: backtrace: common/daemon.c:83 (crashdump) 0x556ac0a6be76
**BROKEN** lightningd: backtrace: ./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0 ((null)) 0x7f9c98a31def
**BROKEN** lightningd: backtrace: common/onion_decode.c:61 (ceil_div) 0x556ac0a7835d
**BROKEN** lightningd: backtrace: common/onion_decode.c:122 (handle_blinded_forward) 0x556ac0a784c4
**BROKEN** lightningd: backtrace: common/onion_decode.c:355 (onion_decode) 0x556ac0a78c39
**BROKEN** lightningd: backtrace: lightningd/peer_htlcs.c:1548 (peer_accepted_htlc) 0x556ac0a087fa
**BROKEN** lightningd: backtrace: lightningd/peer_htlcs.c:2648 (peer_got_revoke) 0x556ac0a09e25
**BROKEN** lightningd: backtrace: lightningd/channel_control.c:1624 (channel_msg) 0x556ac09c3e11
**BROKEN** lightningd: backtrace: lightningd/subd.c:562 (sd_msg_read) 0x556ac0a16e2e
**BROKEN** lightningd: backtrace: ccan/ccan/io/io.c:60 (next_plan) 0x556ac0aa8fc1
**BROKEN** lightningd: backtrace: ccan/ccan/io/io.c:422 (do_plan) 0x556ac0aa944c
**BROKEN** lightningd: backtrace: ccan/ccan/io/io.c:439 (io_ready) 0x556ac0aa9505
**BROKEN** lightningd: backtrace: ccan/ccan/io/poll.c:471 (io_loop) 0x556ac0aaaea3
**BROKEN** lightningd: backtrace: lightningd/io_loop_with_timers.c:22 (io_loop_with_timers) 0x556ac09dea99
**BROKEN** lightningd: backtrace: lightningd/lightningd.c:1518 (main) 0x556ac09e43f7
**BROKEN** lightningd: backtrace: ../sysdeps/nptl/libc_start_call_main.h:58 (__libc_start_call_main) 0x7f9c98a1bca7
**BROKEN** lightningd: backtrace: ../csu/libc-start.c:360 (__libc_start_main_impl) 0x7f9c98a1bd64
**BROKEN** lightningd: backtrace: (null):0 ((null)) 0x556ac09b3120
**BROKEN** lightningd: backtrace: (null):0 ((null)) 0xffffffffffffffff
Changelog-Fixed: lightningd: guard for arithmetic operation overflow on onion message request for forward a payment through a blinded path
Reported-by: Vincenzo Palazzo (Bitcoin Security Council finding 2026-08-11)
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
This commit fixes a crash bug in Core Lightning's payment forwarding code. When processing a hidden (blinded) payment route, the node reads a fee rate from encrypted data. That fee rate is a 32-bit unsigned integer. The old code added it to 1,000,000 using 32-bit arithmetic, so a maliciously large fee rate could wrap around to a tiny value, causing a division-by-zero or other bad arithmetic that crashed the lightningd daemon with a fatal signal. The fix forces the addition to be done in 64-bit arithmetic, preventing the wraparound. The commit also adds tests showing how a crafted blinded path can trigger the issue.
38fa7e2a · Aug 13, 2026 · 8 filesModerate 62lightningd: don't return io logs from getlog
The io level of the log book holds the raw JSON-RPC and plugin traffic,
which can contain secrets such as runes, and getlog returns the whole
log book to its caller. Refuse level=io there: io logging remains
available in the log file, via --log-level=io.
Changelog-Changed: JSON-RPC: `getlog` no longer accepts `level=io`; io logs are only available in the log file (`--log-level=io`).
(cherry picked from commit e05c572fa3a921f85899bdf61bad68557386c824)
This commit fixes a security issue in Core Lightning's `getlog` JSON-RPC command. Previously, `getlog` could return 'io' level logs, which contain raw JSON-RPC and plugin traffic including secrets like authentication runes. Now `getlog` refuses to return io logs, keeping them only in local log files for users who explicitly enable them. This prevents a caller with RPC access from extracting sensitive secrets through the log command.
6556f16d · Aug 12, 2026 · 1 fileHigh 76lightningd: don't allocate huge log entries on the stack
log_to_files() sized a stack VLA by the log string's length. Callers
can log attacker-controlled strings of arbitrary size - e.g. clnrest
logging unauthenticated request parameters on rune failure - so a
single ~10MB HTTP request overflowed the stack and crashed lightningd
(SIGSEGV).
Use a fixed 1kB stack buffer for normal entries and a heap allocation
for oversized ones.
Changelog-Fixed: lightningd: logging a very large message no longer crashes the node (stack overflow).
Reported-by: Vincenzo Palazzo (Bitcoin Security Council finding 2026-08-10)
(cherry picked from commit cc90f6b63da7a1ea9ea0b8276a96980dd2ed7496)
This fix prevents a crash in Core Lightning's logging code. Previously, when the program wrote a log message, it reserved space on the stack based on the message's length. Because some logged text comes from outside sources (for example, unauthenticated web requests to the clnrest plugin), an attacker could send a very large request and cause the program to overflow its stack, crashing the node. The patch now uses a small fixed stack buffer for ordinary messages and switches to a heap allocation only when a message is unusually large.
f8ca3f4c · Aug 7, 2026 · 1 fileLow 32db: tidy db_col_psbt NULL handling
Return early for a NULL column like the sibling db_col_* helpers, and
only parse and set the version when there is actual data to work with.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Changelog-None
(cherry picked from commit d6f8cc32eddb5f9aaba4c0561f94944b550cb61f)
This commit fixes a helper function that reads PSBT data from the database. Previously, when the database column was NULL, the code would still try to parse it and unconditionally set the PSBT version, which could lead to a crash or undefined behavior. Now it returns NULL early for NULL columns, matching the behavior of similar helper functions, and only sets the version when parsing actually succeeded.
28c7ab93 · Aug 7, 2026 · 1 fileModerate 57wallet: bound-check shachain_known pos on load
Keep the loaded pos within the known[] array like the other defensive
checks in the channel loader, so a malformed row fails loudly instead of
indexing out of range.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Changelog-Fixed: wallet: an out-of-range shachain index in the database is now rejected at load instead of read out of bounds.
(cherry picked from commit fdd7b11e9f38eb2d3fa5515c00e64f0ad17d63fc)
This update fixes a bug in Core Lightning's wallet code where it reads a 'position' value from its database and uses it directly as an array index without first checking whether it is valid. If the database contained an out-of-range value, the program could read or write memory outside the intended array, which can cause crashes or unpredictable behavior. The fix adds a simple bounds check and makes the program stop with a clear error if the value is invalid.
4e7fa317 · Aug 6, 2026 · 17 filesHigh 72channeld: split the feerate we'll pay from the one we'll accept
The previous commit clamped our own fee source on the way in. This is
the counterpart for the other side of the channel: our peer's estimator
can be just as broken as ours, and we are the only one in a position to
notice before their money is gone.
`splice_accepter` only rejected a remote `funding_feerate_perkw` below
feerate_min; there was no upper bound at all. The downstream safeguard
in check_balances only inspects the accepter's own fee contribution, and
since accepter_relative is 0 our weight is nil, so that check never
fires. A peer whose estimator has gone haywire can therefore drive a
splice at an arbitrary feerate and we will cheerfully sign it, even
though the fee comes out of their channel balance. Refusing costs us
nothing and saves them from committing their funds to a transaction they
did not mean to pay for.
Reject anything above feerate_max, and apply the same bound in
handle_splice_init so that we extend the same courtesy in reverse: if
our own estimator is the broken one, we catch it before we ask a peer to
sign for it. handle_splice_init honours `splice_force_feerate` there,
as check_balances already does: that flag is the user saying they meant
it, and a policy limit should not override it.
feerate_max also needs a bound of its own, since it was derived purely
from the estimates times config.max_fee_multiplier. But a single bound
cannot serve both directions, because feerate_max gates what we accept
in `update_fee` *and* what we propose ourselves. Set for the accept
side it would have us paying absurd fees; set for the propose side it
would pin our commitment feerate below what a congested chain demands,
which is precisely when it has to confirm. So there are now two:
- FEERATE_CEILING (1000000 perkw, 4000 sat/vB) is the most we let a
peer drive us to. Their estimator being broken is not by itself
worth dropping a channel over, so this only has to exclude the
absurd.
- MAX_OUR_FEERATE_PER_KW (100000 perkw, 400 sat/vB) is the most we will
pay: roughly 0.011 BTC for a bare anchor commitment. Declining to
propose a feerate costs us nothing, so we can afford to be strict.
our_feerate_max() applies it wherever the money is ours:
default_feerate, splice_feerate, opening_feerate and dual-fund RBF.
Note this leaves the paths where we cannot decline -- mutual close,
penalty and onchain resolution -- bounded only by the ceiling, which is
the right answer for a feerate that has a deadline attached.
channeld needs both, so channeld_init and channeld_feerates carry
our_feerate_max alongside feerate_max, and check_balances holds whichever
side is ours to the stricter one. The multiplier is settable via
--dev-max-fee-multiplier, so widen to u64 before multiplying.
Finally, remove the UINT_MAX sentinels. feerate_max returned UINT_MAX
when there were no estimates at all, and lightningd overwrote the bound
with 0xFFFFFFFF when fee limits were ignored. Both are the bound a
peer's proposal is measured against, and we store what we accept -- a
u32 that large overflows the 25/24 RBF calculation downstream. The
unknown path now falls back to FEERATE_CEILING, exactly as feerate_min
falls back to FEERATE_FLOOR, and ignore_fee_limits travels to channeld
and openingd as an explicit flag which relaxes the policy bounds but
never the ceiling. That last part makes a documented promise false, so
the three places which say ignore-fee-limits means "any fee they want"
now say what it actually means.
Changelog-Fixed: channeld: a peer can no longer initiate a splice at an arbitrarily high feerate; it is now bounded like other remote-proposed feerates.
Changelog-Changed: lightningd: we no longer propose a feerate above 100000perkw (400 sat/vB) of our own accord, for channel opens, splices, commitment updates and dual-fund RBFs.
Changelog-Changed: lightningd: `--ignore-fee-limits` and `setchannel`'s `ignorefeelimits` still drop our policy bounds, but no longer accept a feerate above 1000000perkw (4000 sat/vB).
Changelog-Changed: JSON-RPC: `feerates` reports `max_acceptable` as the feerate ceiling rather than 4294967295 when no fee estimates are available.
(cherry picked from commit 4a10d71822c277e381bf289202f494e64110b522)
This commit fixes a bug in Core Lightning where a channel peer could trick or accidentally push the node into signing a Bitcoin transaction with an absurdly high transaction fee during a 'splice' operation. Before the fix, there was no upper limit on the fee rate a peer could propose for a splice, and an internal balance check did not catch it because the accepting side contributed no funds. The patch adds two separate fee ceilings: a sanity ceiling on what any peer can propose, and a stricter self-imposed limit on fees the node itself will pay for its own transactions. It also removes unsafe 'no limit' sentinel values that could overflow later calculations.
1818553e · Aug 4, 2026 · 3 filesInformational 16add a test for downgrading askrene datastore
Also trigger a db upgrade in the v26.09 so that impressions can be
removed by the downgrade tool.
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
This commit adds a regression test for Core Lightning's database downgrade path. It ensures that when a user downgrades from an upcoming v26.09 release to an older version (v26.06), the new 'impressions' data added by the askrene routing subsystem is cleanly removed while other askrene data survives. The code change itself is purely a test and a marker comment in the migration list; it does not fix an active security vulnerability.
4d926285 · Aug 4, 2026 · 1 fileInformational 23downgrade: we need to remove "impressions" from askrene datastore when downgrading to v26.06.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is a database downgrade helper fix, not a live network vulnerability. Core Lightning's downgrade tool previously failed to strip out new 'channel impression' records when rolling a database back to version v26.06. The patch teaches the tool to remove those records during downgrade. If left unfixed, a downgrade could leave newer data in an older database format, which might cause errors or prevent the node from starting after rollback. There is no attacker-controlled path in normal operation.
42995326 · Aug 4, 2026 · 1 fileLow 31downgrade tool: fix invalid memory bug
Fix a typo in the downgrade tool that produced an OOM error.
Changelog-None
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
This commit fixes a typo in a database downgrade helper tool. The bug caused the tool to pass a negative number (turned into a huge positive size) when copying data, which led to an out-of-memory (OOM) error. The fix swaps two variable names so the tool copies the already-processed chunk of data instead of the remaining chunk. It is a reliability bug in an offline maintenance tool, not a network-exploitable vulnerability.
8c42be35 · Aug 3, 2026 · 1 fileInformational 12tests: add regression test for hsmtool commands with passphrase
Why it was queuedThis commit only adds and updates a regression test in the project's test suite. It checks that the hsmtool utility correctly handles both empty and non-empty passphrases when working with BIP39 mnemonic-based wallet secrets. There is no change to the actual hsmtool or wallet code, so it does not introduce or fix a live security vulnerability on its own.