LND

This update fixes a bug in how LND handles old-style punishment transactions when a channel partner tries to cheat. Previously, tiny (dust) HTLCs were left as blank placeholder entries in the punishment data, which could cause the node to crash or behave incorrectly when trying to claim funds back. The fix removes those blank entries and adds safety checks further down the line.

This change tightens how LND reads Lightning invoices (BOLT 11). Previously, if an invoice contained more than one payment hash field, LND would silently keep the first one and ignore the rest. Now it rejects the invoice entirely. The release notes frame this as an interoperability improvement rather than a security fix, but the behavior removes a potential source of confusion or invoice manipulation where a second, different payment hash could be present but ignored.

This change tightens how LND reads Lightning invoices. Previously, if an invoice contained more than one payment hash field, LND would silently keep the first valid one and ignore the rest. Now it rejects such invoices outright. This prevents an attacker from potentially tricking a wallet into interpreting a different payment hash than intended, which could lead to payments being sent to the wrong destination or failing in unexpected ways. The fix is being backported to two release branches.

This commit updates the Go programming language version used to build LND from 1.25.13/1.26.6 to 1.26.8 (language version) and 1.27.1 (toolchain). It also regenerates many automatically generated RPC files and adjusts linter settings. The main security angle is that newer Go releases typically fix bugs and security vulnerabilities in the Go runtime and standard library, so staying current is good defensive hygiene. However, the commit itself does not describe any specific vulnerability being fixed, and the code changes are mostly version bumps and generated file updates rather than targeted security patches.

This commit is a routine build-maintenance change. It updates the project's Go linter configuration to a newer version and fixes the resulting style warnings: a WebSocket header spelling and several documentation comments that didn't start with the correct symbol names. There is no functional code change that affects security.

This commit is a housekeeping change that regenerates automatically generated RPC binding files using a newer Go compiler version. The only differences are in code comments (doc-comment formatting), not in actual program logic or API behavior. There is no security impact.

This commit is a routine maintenance update that changes which version of the Go programming language is used to build the lnd project. It does not change any application logic, fix a bug, or address a security vulnerability. The project is simply moving its build tooling to a newer Go release and keeping the minimum required Go version current.

This commit adds a new optional wallet feature to LND that lets users lock UTXOs until the transaction spending them reaches a chosen confirmation depth, instead of relying on a wall-clock timeout. It is a feature addition with safety checks (required custom lock ID, capability checks, rollback on partial failure) and is not a fix for a known exploit. The main risk is that a bug in the new reorg-aware lease logic could keep coins locked longer than intended or, in a worst case, allow double-spending of locked UTXOs, but the diff itself does not show such a vulnerability.

This commit is a large internal code reorganization for the LND Lightning node. It moves channel state storage logic from the `channeldb` package into a new `chanstate` package, while keeping the same database keys, serialization formats, and public behavior. There is no new feature or obvious security fix in the visible diff; it is primarily a refactoring to separate concerns.

This change fixes a data-handling bug in LND's channel-opening code. When opening a Lightning channel using an optional 'auxiliary funding controller' (used for custom channel types such as Taproot Assets), the funding manager was previously passing an incomplete channel state object that lacked the negotiated local and remote channel settings. The patch adds a new method that builds a complete view including both sides' agreed configuration, and updates the funding manager to use it. There is no direct evidence this is exploitable as a security vulnerability; it appears to be a correctness fix that could prevent misbehavior or failures in custom channel flows.

This commit only adds a new integration test for an existing feature called confirmation-controlled leases. It does not change production code, so it cannot introduce a security vulnerability or fix one directly. The test exercises how long a wallet lease stays locked under various conditions (time passing, blockchain reorganization, node restart, and multiple confirmations).

This update fixes two security-related bugs in LND's REST WebSocket proxy. First, a specially crafted WebSocket protocol header could crash the proxy (a panic). Second, the proxy previously had no limit on how large an incoming WebSocket message it would accept, which could let an attacker exhaust server memory. The patch caps incoming message sizes and correctly parses the protocol header as a comma-separated list.

This commit adds release notes for two fixes in LND's REST WebSocket proxy: one that could crash the proxy with a malformed header, and another that limits how large incoming WebSocket messages can be. The actual code changes happened in a different pull request; this commit only documents them.

This commit adds release notes for two fixes in LND's REST WebSocket proxy. One fix prevents a server crash (panic) triggered by a malformed WebSocket protocol header. The other fix limits how large incoming WebSocket messages can be, rejecting oversized frames early. Both are defensive hardening changes, but the commit itself only documents them; the actual code changes are in a different pull request.

This patch fixes a bug in LND's cooperative channel-closing logic where extra 'auxiliary' outputs (used by custom/taproot channel types) were not counted when the initial closing fee was first estimated. If the fee was too low, the resulting close transaction could be rejected by the Bitcoin network's mempool. The fix adds a new 'shape' query so the closer knows the size of these extra outputs up front, includes them in the fee calculation, and then verifies that the final outputs match the declared shape before signing.

This change fixes a bug in LND's wallet RPC code that handles locking multiple bitcoin inputs at once. Previously, if locking one input failed after earlier inputs were already locked, the rollback tried to unlock the earlier inputs using LND's internal lock ID instead of the caller's actual lock ID. That meant the earlier locks might not get released, leaving funds stuck or unavailable. The patch makes the rollback use the real lock ID recorded for each acquired lease, and also rolls back on metadata lookup failures, not just lease failures.

This commit adds a new optional wallet feature that lets LND lock a coin (UTXO) until the transaction spending it reaches a chosen number of confirmations. It is purely additive: it defines a new interface, routes calls through wallet adapter wrappers, and keeps the old zero-confirmation lease path unchanged. There is no bug fix, no reported vulnerability, and no evidence this change itself introduces a security issue.

This commit fixes a bug in how LND's WebSocket proxy handled a special browser header called Sec-Websocket-Protocol. Previously, a client could send just the protocol name without a required separator, causing the server to crash with a panic. The crash was only contained by accident, not by design. The fix also prevents a trick where a client could make one protocol entry steal a value from another entry in the same list. The patch adds tests to confirm the correct behavior.

This commit is a routine maintenance update that changes the version numbers of the Go programming language used to build LND from 1.25.11 to 1.25.13 (and the build toolchain from 1.26.4 to 1.26.6). It only edits configuration files, Dockerfiles, documentation, and module files. There is no code change, no bug fix, and no security patch visible in the diff.

This commit adds a new, clearly marked experimental RPC and command-line option called XCreateAccount that lets an LND user create a separate, named pocket of on-chain funds within the same wallet. It is not a security patch and does not fix a vulnerability. The main risk is user error: money sent to one of these accounts cannot be found again with only the wallet seed, so the user must separately save extra recovery details. The feature is gated behind an explicit 'I know what I am doing' flag on release builds to reduce accidental misuse.

This commit adds a new 'outbound' remote-signer mode to LND. In the existing 'inbound' mode, the watch-only node connects to the signer; in the new 'outbound' mode, the signer node connects out to the watch-only node. The change introduces a dedicated gRPC listener, a new macaroon permission ('remotesigner:generate'), and configuration validation. It is a large feature addition rather than a clear-cut vulnerability fix, but it touches authentication, network exposure, and wallet startup logic, so it has security relevance.

This commit fixes two separate boundary-case bugs in the Lightning Network Daemon (LND). First, it prevents a peer from getting stuck when a channel-funding message arrives after its wallet reservation has already been cleaned up: the code now sends a completion signal instead of leaving the caller waiting forever. Second, it corrects how zero-block gossip range queries are handled so that empty queries keep their starting block height and so that a densely populated first block no longer triggers an invalid zero-block reply before the real reply.

This commit fixes a small but real bug in LND's channel-funding code. When a funding request referred to a reservation that no longer existed, the code sent an error message but forgot to send the matching 'completion' signal. A caller waiting on both channels could hang or misbehave. The fix adds the missing completion signal and includes a regression test. There is no claim in the commit that this is a security issue, but incomplete error handling in wallet code can sometimes be abused to cause denial of service.

This update fixes two related problems in LND's cooperative channel-closing code. First, it eliminates a data race where the same state machine was being advanced by two different internal goroutines at once, which could cause crashes or inconsistent close negotiations. Second, it now always checks that the other party's payout address is well-formed and safe to pay, instead of only checking when an upfront shutdown address was already on file. Previously, a malformed or malicious address could slip through in some cases.

This change fixes a bookkeeping bug in how LND records the other party's preferred closing address during a channel close. Previously, a late or unexpected Shutdown message could overwrite the correct address with one from a message that was rejected. The fix only saves the address when the message is actually accepted. The bug currently has no downstream effect because the recorded value is not used until after negotiation finishes, but it makes the close record more accurate.