Core Lightning

This commit fixes a reliability bug in Core Lightning's `fetchinvoice` command. When a peer was disconnected, the node still kept that peer in its internal network map, so it sometimes tried to send an invoice request through a peer that was no longer reachable. The fix removes disconnected peers' channels from the map and also avoids using disabled channels for onion messages. This is a bug fix rather than a security vulnerability: the worst outcome was a failed invoice fetch, not loss of funds or remote code execution.

This commit fixes three places in the 'reckless' plugin-installer tool where a file path was stored as a Path object instead of as a plain string. The fix converts the path to a string before assigning it. This is a type-correctness bug that could cause crashes or unexpected behavior when the value is later used as a string, but it is not a direct security vulnerability and there is no evidence it is exploitable for code execution or privilege escalation.

This commit simply enlarges two memory buffers used to capture text output from a plugin installation helper. It is a routine capacity tweak, not a security fix. There is no indication of a vulnerability, crash, or attack path.

This commit fixes a bug in Core Lightning's 'reckless' plugin installer tool. The bug was that very verbose dependency-resolution output from the 'uv' Python package manager was being dumped all at once as JSON to the reckless-rpc plugin, potentially overloading it. The fix both removes the verbose '-v' flag from uv and adds a rate-limiting helper that prints large JSON output in small chunks with tiny delays. It is a reliability/DoS-style bug fix, not a code-execution vulnerability.

This commit fixes a low-level programming bug in four source files. The standard C library functions used to check whether a character is a digit or whitespace (like isdigit and isspace) can misbehave or crash when given a character whose numeric value is negative on systems where the char type is signed. The patch replaces those direct calls with safer project-specific wrappers that cast the value to an unsigned type first. This is a defensive hardening change rather than a fix for a known exploitable vulnerability.

This commit adds a new test-only check that makes Core Lightning's Python test harness validate plugin hook and notification JSON messages against published schemas. It is a testing/quality improvement, not a fix for an exploitable vulnerability in production code. The only runtime behavior change is writing plugin I/O to a directory during tests and then validating it during teardown.

This is a small compatibility fix in the Python plugin client for Core Lightning. It helps older plugin code automatically produce the newer notification format, reducing the chance that a plugin sends a malformed or unexpected message. There is no direct security vulnerability being patched here; it is a robustness improvement.

This change adds a safety valve in Core Lightning's connection handler: if the internal message queue to the gossip subsystem grows beyond 500,000 messages, incoming gossip messages are silently dropped instead of being queued indefinitely. The commit message frames this as a cleanup now that an earlier gossip bug is fixed, but the patch itself is a hardening measure against memory exhaustion from a backed-up queue.

This commit updates the Python plugin client library (pyln-client) so it understands both old and new styles of plugin notification messages from the lightningd daemon. It adds backward/forward compatibility shims so plugins written for either format still receive their expected 'payload' and 'origin' fields. The changes are in the client library and its tests; there is no direct fix for an exploitable vulnerability.

This commit is a code-generator fix that renames some automatically generated Rust type names from 'ConnectDirection' and 'ConnectAddressType' to 'PeerConnectDirection' and 'PeerConnectAddressType'. It only affects the names used in the cln-rpc Rust library and the tool that generates it. There is no change to how Core Lightning handles network connections, payments, or user funds, and no security fix or vulnerability is visible in the diff.

This commit adds a hidden developer-only command-line option called --dev-save-plugin-io. When a developer turns it on, Core Lightning writes copies of plugin hook and notification messages to files in a specified directory. It is a diagnostic/logging feature, not a change to normal node behavior, and it is not enabled by default.

This commit changes how plugin notifications are formatted so they match a newer convention used by the rest of the software. It wraps the notification payload inside an extra object named after the notification method, while still accepting the old format for backward compatibility. There is no direct security fix here; it is a compatibility and cleanup change that may reduce confusion or interoperability bugs down the road.

This commit adds a new automated test to the Core Lightning project. It checks that the 'pay' command correctly sends three types of plugin notifications (channel hint updates, payment success, and payment failure). There is no change to production code, no bug fix, and no security-related content.

This commit is a cleanup of how Core Lightning reports channel-state change notifications. Previously, when a channel did not yet have a short channel ID, the notification would include a literal null value; for brand-new channels it could also report an 'unknown' old state. The change makes these fields optional so they are simply left out instead of being sent as null/unknown. It is a deprecation/API-consistency patch, not a fix for an exploitable vulnerability.

This commit changes how Core Lightning forwards notifications between plugins. Previously, plugin notifications wrapped their data in a 'payload' sub-object. Now the data is placed directly in 'params', matching how native notifications work. This is a deliberate API cleanup with a deprecation period, not a security fix. It could break older plugins that still expect the old 'payload' wrapping, but there is no direct evidence of a vulnerability being patched.

This commit is a documentation and generated-code update. It adds 'websocket' as a valid address type in the JSON schema, gRPC proto, and Rust bindings for the 'connect' notification. There is no code behavior change and no security issue.

This commit fixes a notification formatting inconsistency in Core Lightning's plugin system. Plugin-generated notifications (channel_hint_update, pay_failure, pay_success) now wrap their data inside an object named after the notification, matching how core notifications already work. The old unwrapped format is kept as a deprecated option for backward compatibility. This is primarily an API consistency and compatibility fix, not a security vulnerability fix.

This is a routine build/maintenance patch. It re-adds a Makefile target used by developers to bump version numbers across several files, and changes the sed command to be compatible with Ubuntu (GNU sed). There is no change to the lightning node's runtime code, no user-facing behavior change, and no security relevance.

This commit only updates documentation examples and the test script that auto-generates them. It adds a new example for the fetchbip353 command, refreshes feature-bit strings and plugin lists in RPC schema examples, and fixes a couple of autogeneration script entries. There are no code changes that affect how Core Lightning processes payments, peers, or configuration, so there is no security impact.

This is a one-line testing infrastructure change. It adds a 'reckless' binary to a list of programs that should be skipped when running tests under the Valgrind memory-checking tool. The change prevents test timeouts caused by Valgrind slowing down a Python-based helper called reckless. There is no security vulnerability or user-facing bug fix here.

This is a one-line change to a test file only. It fixes an occasional test failure (a 'flake') by adding a larger safety margin for a timing-related value in a Lightning payment route. There is no change to production code, no security fix, and no vulnerability.

This commit adds a developer-only tuning knob called dev_maxparts to the xpay plugin in Core Lightning. It lets advanced users limit how many simultaneous payment routes the plugin tries at once. The change is defensive: it caps resource usage and prevents unbounded route exploration, but it is not described by the project as fixing a known security bug.

This commit adds a small internal helper function called remove_flows to the askrene routing-refinement plugin. It simply trims the lowest-value payment routes from a list to keep the number of candidate routes manageable. There is no indication this change fixes a security bug or introduces a vulnerability.

This commit adds a new optional parameter called maxparts to the getroutes RPC in Core Lightning's askrene routing plugin. It lets callers limit how many separate payment routes the solver returns. There is no indication this fixes a security bug; it appears to be a normal feature addition.

This commit updates a bundled helper library (CCAN) used by Core Lightning, mainly adding a new function that can unescape JSON strings of a known length rather than relying on null-terminated strings. The change also hardens the unescape logic so malformed escape sequences (for example, a backslash at the very end of the string) are rejected instead of reading past the end of the buffer. There is no direct evidence in the commit that this fixes an exploitable vulnerability in Core Lightning itself, but it is a defensive improvement that removes a potential out-of-bounds read and adds safer memory handling.