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 48 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.
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.
3588f826 · Aug 17, 2026 · 1 fileTriage 0lightningd: prefer latest blocks when querying historic blocks.
Worst case, we can get flooded with 10,000 scids, and we work through
them one at a time. In practice, there are more channels in more
recent blocks, so we should bias towards those. The iteration is not
free, but compared to all those getutxo calls with each block, it's
invisible.
```
$ ./devtools/dump-gossipstore gossip_store-2026-08-17 | grep -v ' t=0 ' | sed -n 's/.*channel_announcement(\([0-9]*\)x.*).*/\1/p' | stats --histogram
962804************************************************************************
|********************************************************
|**********************************
|***************
|**********
|**********
|********
|*******
|********
|***
|*
|*
|***
515419
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(cherry picked from commit cf06f3d3a206df0d36ae240535af9c4582e73fc8)
3589fd7c · Aug 17, 2026 · 1 fileTriage 0gossipd: don't bother looking up ancient blocks.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
(cherry picked from commit 511106d1cb0102e437c53650ce01823950c81a49)
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.
3bc430de · Aug 14, 2026 · 3 filesTriage 0doc: fix and extend `htlc_accepted` documentation for `resolve`
The documentation around the resolve response was outdated. CLN does
check the preimage and fails the HTLC incase of a mismatch.
Changelog-None
93f84627 · Aug 14, 2026 · 1 fileTriage 0openchannel: remove dead code.
This triggered a false positive use-after-free issue from Red Team.
In fact, the children of new_node_copy are deliberately owned by clone already
(see f2468963488026b7a9fa2c08a60f391195745ae8) so this cleanup attempt
(which was wrong, since size_t is never "> -1") was unnecessary anyway.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
5110f7b1 · Aug 14, 2026 · 1 fileTriage 0bcli: require bitcoind >= 23.0, and remove unneeded bitcoind version gate for getblockfrompeer.
Minimum version for bitcoind in CI is 25.0, but elements is older.
Bump hard reject version to 23.0 (which elements will still pass, just).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
d24960af · Aug 13, 2026 · 1 fileTriage 0closingd: Add a sanity check for feerate
As a final check before sending any signed mutal close, we confirm the fee remains below our max fee to accept.
Changelog-None
(cherry picked from commit 0aae0d53da34779613f40ba74e70eca896c3a524)
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.
204d0727 · Aug 13, 2026 · 2 filesTriage 0pytest: onchain preimage beats an unfinished outgoing failure
A peer can fulfill one HTLC and fail another with the same payment hash,
stop before either removal is final, then claim both onchain: we must
fulfill both incoming HTLCs.
Changelog-None
(cherry picked from commit 2ee1b484f7798050ef4b7b2ba7899699f2aa1ddb)
0787deb9 · Aug 13, 2026 · 4 filesTriage 0lightningd: check rpc name collisions with builtin commands
We crashed if the name collision happened to be a builtin command.
```
lightningd: FATAL SIGNAL 11 (version v26.06-241-gb35b848-modded)
0x5573cd532b2c send_backtrace
common/daemon.c:38
0x5573cd532bb6 crashdump
common/daemon.c:83
0x7fe1fd4ccdef ???
./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0x5573cd4d51a4 plugin_rpcmethod_add
lightningd/plugin.c:1396
0x5573cd4d5268 plugin_rpcmethods_add
lightningd/plugin.c:1423
0x5573cd4d57ef plugin_parse_getmanifest_response
lightningd/plugin.c:1805
0x5573cd4d68db plugin_manifest_cb
lightningd/plugin.c:1827
0x5573cd4d2316 plugin_response_handle
lightningd/plugin.c:692
0x5573cd4d7443 plugin_read_json
lightningd/plugin.c:781
0x5573cd56fd01 next_plan
ccan/ccan/io/io.c:60
0x5573cd57018c do_plan
ccan/ccan/io/io.c:422
0x5573cd570245 io_ready
ccan/ccan/io/io.c:439
0x5573cd571be3 io_loop
ccan/ccan/io/poll.c:471
0x5573cd4a5a99 io_loop_with_timers
lightningd/io_loop_with_timers.c:22
0x5573cd4d61d1 plugins_init
lightningd/plugin.c:2063
0x5573cd4aad6c main
lightningd/lightningd.c:1269
0x7fe1fd4b6ca7 __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58
0x7fe1fd4b6d64 __libc_start_main_impl
../csu/libc-start.c:360
0x5573cd47a120 ???
_start+0x20:0
0xffffffffffffffff ???
???:0
```
Changelog-Fixed: lightningd: checks for rpc name collisions with builtin commands when registering plugin RPC methods
Reported-by: Vincenzo Palazzo (Bitcoin Security Council finding 2026-08-11)
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
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.
c2ba2358 · Aug 13, 2026 · 1 fileTriage 0offers: fix recurrence proportional amount
Reported-by: Vincenzo Palazzo (Bitcoin Security Council finding 2026-08-11)
Changelog-Fixed: offers: recurrence with proportional_amount now computes the correct invoice amount based on the time remaining
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
245f3540 · Aug 13, 2026 · 2 filesTriage 0askrene: properly handle invalid "inform" field
Changelog-Fixed: askrene: askrene-inform-channel properly handle invalid "inform" field
Reported-by: Vincenzo Palazzo (Bitcoin Security Council finding 2026-08-11)
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
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.
04b0729b · Aug 13, 2026 · 1 fileTriage 0tests: check getlog does not return io logs
The io level of the log book holds raw JSON-RPC and plugin traffic,
which can contain secrets such as runes. Marked xfail until the next
commit.
(cherry picked from commit 03be4d7764fd1316f8d335262a34d77ba57f023c)
344f4371 · Aug 12, 2026 · 1 fileTriage 0tests: add clnrest test for large request bodies
Changelog-None
(cherry picked from commit 23e98db66b6f8fd8538d78363d0be39429a6b2b8)
804b9df8 · Aug 12, 2026 · 4 filesHigh 74clnrest: restrict maximum size of request bodies to 2MiB
Changelog-Fixed: clnrest: an unauthenticated user could crash the node with a large request body; bodies are now capped at 2MiB.
(cherry picked from commit d5c2f6dbf1b7a54679b97d2a71015ad45443baf8)
This update fixes a bug in Core Lightning's built-in REST plugin (clnrest). Before the fix, anyone on the network could send a very large request to the REST API without logging in, causing the node to crash. The patch now refuses bodies larger than 2 MB and returns an error instead of trying to read unlimited data.
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.
9ffa5881 · Aug 11, 2026 · 2 filesTriage 0common: ignore DNS address descriptors which are not hostnames
fromwire_wireaddr() accepted any bytes at all as an ADDR_TYPE_DNS address,
so a node_announcement could put arbitrary content into log messages,
listnodes output and outgoing connect attempts. is_dnsaddr() already
encodes the rules; apply it, and ignore the descriptor when it fails, the
same way we already ignore a descriptor with a zero port.
Changelog-Changed: gossipd: DNS addresses in a node_announcement which are not valid hostnames are now ignored.
(cherry picked from commit 9574eaa55d46f791e9bdf1108219f760d412dc9e)