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 1 hour, 2 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.
498e5086 · Sep 17, 2026 · 1 fileInformational 15wallet: fixed timestamps for invented bookkeeper deposits
migrate_setup_coinmoves() stamped wallet deposits with wall-clock time
via coinmvt_current_time(), so a slow migration could place the deposit
after the channel journal entry in bkpr-listaccountevents, flaking
test_migration_no_bkpr.
Use base_timestamp + 1, like the channel moves, so the order is stable.
Changelog-None
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 channel records instead of using the real-time clock. There is no security issue here.
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.
273d7f02 · Aug 20, 2026 · 2 filesInformational 15common: minor typo fixes
Why it was queuedThis 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 security relevance.
c4fe4cba · Aug 19, 2026 · 2 filesInformational 20pyln-testing: truncate long testnames
Postgres truncates identifiers at 63 bytes. This can lead to
'DuplicateDatabase' errors for tests with long names, as the nonce and
the node_id may collapse. This commit truncates the testname in favor of
the node_id and the nonce, to avoid conflicting db names.
Changelog-None
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
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 to accidentally share the same database name and fail with a 'DuplicateDatabase' error. The patch makes sure the unique parts of the name (node ID and random nonce) are kept while the long human-readable test name is shortened instead. It is a reliability fix for the test suite, not a security vulnerability in the live lightning node software.
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.
4681177d · Aug 18, 2026 · 2 filesModerate 59askrene: fix crash loading node bias with description
load_node_bias() passed take(description) to two consecutive
set_node_bias() calls. The first call's tal_strdup() consumes the
take (tal_resize_ + tal_steal), so the second take() was on freed
memory and we aborted in to_tal_hdr() with "Not a valid header"
while loading the layer at startup. Since askrene is an important
plugin, lightningd shuts down and the node cannot restart at all.
The description is already a copy off tmpctx, so simply don't take()
it: set_node_bias() strdups it into the bias anyway.
With this, the test from the previous commit passes.
Fixes: #9433
Reported-by: endothermicdev
Changelog-Fixed: askrene: node failed to start (`exited before replying to init`) when a persistent layer contains a node bias with a description
Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
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 it a second time, causing an immediate crash during startup. The fix removes the incorrect 'take ownership' call so the description remains valid for both uses. There is no evidence this crash can be triggered remotely or used as an attack; it appears to be a reliability bug that only affects nodes that already have such saved data.
0f3f67a0 · Aug 18, 2026 · 1 fileInformational 12tests: restart the node which owns the layer in node bias test
test_node_bias_persistence() restarted l2, but the layer and its
node bias records live in l1's datastore. The assert compared
l1's in-memory layer against itself, so load_node_bias() was never
actually exercised and this test could not have caught the startup
crash in #9433.
Restarting l1 instead makes the test reload the layer from the
datastore at startup. This is the reproducer for #9433; it fails
until the next commit.
Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
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 startup crash reported elsewhere, but the crash fix is in a separate commit.
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.
c313eff5 · Aug 15, 2026 · 2 filesModerate 60askrene: exclude stubchannels from routing
My node has some recovered channels, which were causing a crash
in askrene, due to the fact that they have duplicate scids.
Easy fix is simply to skip recovered stubs when planning
routes.
Aug 15 16:34:14 citrine lightningd[1976574]: cln-askrene: ./plugins/askrene/child/additional_costs.h:26: additional_cost_htable_add: Assertion `!additional_c ost_htable_getmatch_(ht, k, h, v, &i)' failed.
Changelog-Fixed: Crash when trying to pay and you have recovered channel stubs in your peers list
This commit fixes a crash in Core Lightning's routing plugin (askrene) that occurred when a user had 'recovered channel stubs'—placeholder records left behind after restoring a node from a backup. These stubs all share the same placeholder channel ID (1x1x1), which caused an internal table that expects unique IDs to fail an assertion and crash the plugin. The fix makes askrene skip these stubs when planning routes. The crash is triggered by normal user actions (trying to pay with recovered stubs present), not by a remote attacker, and the plugin can be restarted.
f435096d · Aug 13, 2026 · 2 filesModerate 66lightningd: fix crash on invoice_payment_hook_done
```
Valgrind error file: valgrind-errors.3449770
==3449770== Invalid read of size 8
==3449770== at 0x1B4F4A: htlc_set_fail_ (htlc_set.c:77)
==3449770== by 0x1B59FB: invoice_payment_hooks_done (invoice.c:276)
==3449770== by 0x1EC5DF: hook_done (plugin_hook.c:243)
==3449770== by 0x1EC710: plugin_hook_call_next (plugin_hook.c:343)
==3449770== by 0x1EC90E: plugin_hook_callback (plugin_hook.c:299)
==3449770== by 0x1E6316: plugin_response_handle (plugin.c:692)
==3449770== by 0x1EB443: plugin_read_json (plugin.c:781)
==3449770== by 0x283D01: next_plan (io.c:60)
==3449770== by 0x28418C: do_plan (io.c:422)
==3449770== by 0x284245: io_ready (io.c:439)
==3449770== by 0x285BE3: io_loop (poll.c:471)
==3449770== by 0x1B9A99: io_loop_with_timers (io_loop_with_timers.c:22)
==3449770== Address 0x38 is not stack'd, malloc'd or (recently) free'd
==3449770==
{
<insert_a_suppression_name_here>
Memcheck:Addr8
fun:htlc_set_fail_
fun:invoice_payment_hooks_done
fun:hook_done
fun:plugin_hook_call_next
fun:plugin_hook_callback
fun:plugin_response_handle
fun:plugin_read_json
fun:next_plan
fun:do_plan
fun:io_ready
fun:io_loop
fun:io_loop_with_timers
}
```
Changelog-Fixed: lightningd: fix crash of lightningd on race condition between delinvoice and a returning invoice_payment hook for fallback onchain settlements
Reported-by: Vincenzo Palazzo (Bitcoin Security Council finding 2026-08-11)
Co-Authored-By: Grok 4.5
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
This commit fixes a crash in the Core Lightning node software. The crash happens when an invoice is deleted while a plugin's 'invoice_payment' hook is still processing a payment that came in through an on-chain fallback address. By the time the hook finishes, the internal data structure it expected to use (the HTLC set) had already been cleared, causing the node to read invalid memory and crash. The fix simply checks whether that data still exists before using it.
7a05b8fa · Aug 13, 2026 · 2 filesModerate 64tests: huge log entries don't crash lightningd
Drive log_to_files() directly with an entry far larger than any stack buffer,
using a plugin which emits one on demand.
Nothing bounds a log entry, so testing this through clnrest is the wrong shape:
requests are now capped at 2MiB before any parameter is parsed, so an oversized
request is rejected long before it can reach the logger, and a test written that
way passes whether or not the daemon is fixed. A plugin can hand us an entry of
any size, which is what we actually want to exercise.
(cherry picked from commit 50910c956694006b516b8bca1dbc214f79842772)
This commit adds a test for a previously fixed crash in Core Lightning's logging code. The bug was that log entries could be arbitrarily large, and the daemon used to allocate a stack buffer based on the entry's length, which could exhaust the stack and crash the process. The test uses a plugin to feed the logger an 8 MB entry and checks the node stays alive. The commit itself only adds the test and plugin; it does not contain the actual fix.
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.