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.
Message quality measures whether a commit identifies its scope, purpose, rationale, testing, and supporting references. It does not change the security-severity score.
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 …
nil-pointer dereference risk in breach retribution pathlegacy revocation log handling inconsistency with modern formatdefensive hardening added for trimmed/dust HTLCs
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 rele…
Behavior change from 'use first duplicate field' to 'reject duplicate fields'New error type ErrDuplicatePaymentHash returned on duplicate payment hash fieldsMalformed/unsupported-length duplicate payment hash now treated as duplicate and rejected
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 preve…
Behavioral change from silent first-field acceptance to explicit rejection of duplicate payment hash fieldsPrevents invoice parsing from depending on field ordering when multiple payment hashes are presentCovers malformed first field + valid second field, closing a potential bypass
This change fixes how LND answers network 'ping' messages from other Lightning nodes. Previously, LND would sometimes silently ignore valid pings to limit reply traffic, which violates the Lightning protocol (BOLT 1) and could make a peer …
Protocol compliance fix: BOLT 1 requires a Pong for every valid PingRemoved silent suppression of Pong replies that could cause peer timeout/misbehaviorUnified rate limiting now accounts for amplification bandwidth, not just ping count
This change fixes a bug in LND's handling of AMP (Atomic Multi-Path) payments. Previously, if one partial payment set failed to reconstruct its secret preimage, the entire invoice was canceled, including unrelated partial payment sets from…
Denial-of-service against reusable static AMP invoices by causing unrelated accepted HTLC sets to be canceledIncorrect invoice state transition from set-local failure to global invoice cancellationAvailability impact on multi-payer AMP invoice scenarios
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 …
Go version bump may indirectly address unlisted runtime/standard-library security fixesLarge regenerated protobuf files suggest dependency/toolchain refresh rather than logic changeLinter configuration expanded to suppress new checks, consistent with a toolchain upgrade
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…
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 behav…
This commit is a routine build-and-test maintenance patch to make the LND codebase compile and pass tests with the upcoming Go 1.27 release. It upgrades the project's custom linter tool, refreshes many indirect tool dependencies, adjusts o…
No production code changesNo vulnerability fix or CVE reference presentDependency-only refresh in tools module (development tooling)
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 i…
This commit fixes a bug in LND's invoice handling for reusable AMP (Atomic Multi-Path) invoices. Previously, if one payment set failed to reconstruct its preimage, the entire invoice was canceled, even though other valid payment sets on th…
Denial-of-service-like availability impact: a malicious or buggy payer could cause a whole reusable AMP invoice to be canceled, blocking legitimate concurrent payersSet-local failure incorrectly escalated to invoice-global cancellationRegression test added for concurrent-set survival after reconstruction failure
This commit adds the missing cryptographic signature layer for BOLT 12 offers in LND. It builds a Merkle tree from the message fields, signs that tree with a BIP-340 Schnorr signature, and now rejects invoice requests and invoices whose si…
Adds BIP-340 Schnorr signature verification for BOLT 12 invoice_request and invoice messagesMerkle tree commits to canonical re-encoded TLV records; non-minimal feature/amount encodings now rejected to preserve byte-exactnessSignature TLV type 240 and reserved range 240-1000 excluded from the signed Merkle root
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 chec…
New RPC fields release_after_spend_confs and confirmed_spend_height added to LeaseOutput and FundPsbtCustom lock ID enforced as required for confirmation-controlled FundPsbt leases; all-zero and reserved internal IDs rejectedCapability check (ResolveOutputLeaser) prevents silent downgrade to time-only lease when confirmation control is requested
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, …
Large refactoring with no change to cryptographic or consensus-critical logicCodec serialization moved verbatim to new package; wire format unchangedDatabase bucket keys and TLV record types preserved
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 previous…
Data-correctness fix in funding handshake: negotiated channel configs now exposed to auxiliary funding controllerAuxiliary funding controller receives incomplete channel state before patch, complete state after patchNo explicit security claim, CVE, or advisory referenced in commit or supplied materials
This change makes LND's BOLT 12 invoice and invoice-request reader actually check that the digital signature is valid, instead of only checking that a signature field exists. Before, an attacker could craft or modify a BOLT 12 message and …
Missing cryptographic verification on parsed BOLT 12 messages replaced with BIP-340 Schnorr signature verificationReader accepted any 64-byte placeholder signature before the patchNew negative tests verify rejection of wrong-signer and tampered Merkle-root fields
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 lon…
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 m…
panic fix in request header parsingunbounded incoming WebSocket message read now cappedincorrect header value assignment possible before fix
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…
Denial-of-service vector: malformed Sec-Websocket-Protocol header could panic the REST WebSocket proxyInput validation improvement: header now parsed as comma-separated sub-protocol listResource-exhaustion mitigation: incoming WebSocket message size now bounded by MaxWsMsgSize
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, reje…
Denial-of-service vector: malformed Sec-Websocket-Protocol header caused a panic in the REST WebSocket proxyInput validation improvement: WebSocket sub-protocol header now parsed as a comma-separated listResource exhaustion mitigation: incoming WebSocket message size now bounded by MaxWsMsgSize with early rejection
Merge pull request #11223 from gijswijs/legacy-dust-retribution-fix
lnwallet+contractcourt: skip trimmed HTLCs in legacy breach retribution
73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body✓ Links an issue, advisory, or supporting reference
Why it was queued
signing or wallet pathmerge-commit duplicate discountsecond-pass: security-sensitive path
AI analysis · Moderate 56/100
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.
Merge pull request #11190 from Roasbeef/zpay32-reject-duplicate-payment-hashes
zpay32: reject duplicate payment hash fields
73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body✓ Links an issue, advisory, or supporting reference
Why it was queued
parser or protocol pathmerge-commit duplicate discountsecond-pass: security-sensitive path
AI analysis · Moderate 62/100
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.
In this commit, we reject BOLT 11 invoices that contain more than one payment hash (`p`) field. `zpay32.Decode` previously kept the first supported payment hash and ignored later fields, so the interpreted payment hash depended on field order.
The decoder now tracks whether a `p` field has appeared separately from whether its contents parsed successfully, and any later `p` field returns `ErrDuplicatePaymentHash`. This covers identical hashes, distinct hashes, and a malformed first field followed by a valid one. The change is deliberately stricter than the current BOLT 11 text, which tells a reader to use the first `p` field; it is motivated by lightning/bolts#1357, and will be backported to the v0.20.5 and v0.21.4 releases.
We also replace the stale comment above parse32Bytes, which quoted the old BOLT 11 rule that a reader must skip over 32-byte fields with an unsupported length. The current reader requirements say the opposite: a reader must fail the payment if a fixed-length field (p, h, s, n) does not have the correct length. The new comment states that reporting the field as absent is a known divergence, and explains why the end result for the payment hash is the same either way.
In the tests, we cover identical and distinct duplicate hashes, a malformed first field followed by a valid one, and the signed vectors. A valid variant of the flipped vector keeps the wrong-length h and n fields, so the coverage that such fields are skipped survives. The duplicate vector in the decode table pins ErrDuplicatePaymentHash through a new wantErr field rather than asserting any decode error.
98/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference
Why it was queued
parser or protocol pathsecond-pass: security-sensitive path
AI analysis · Moderate 62/100
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.
Merge pull request #11132 from yyforyongyu/task-11129-pong
peer: answer every valid ping
58/100 · ThinMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Links an issue, advisory, or supporting reference! No meaningful explanatory body
This change fixes how LND answers network 'ping' messages from other Lightning nodes. Previously, LND would sometimes silently ignore valid pings to limit reply traffic, which violates the Lightning protocol (BOLT 1) and could make a peer think the connection is dead. Now LND replies to every valid ping, while still disconnecting peers that flood too many pings. The cost of a reply is counted against a single flood budget based on how large the reply would be.
Merge pull request #11146 from bitromortac/2604-bolt12-1g
bolt12: add string-codec wrappers and fuzz harnesses
83/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference
Why it was queued
fuzzing or regression evidencemerge-commit duplicate discount
Merge pull request #11206 from ziggie1984/fix-invoice-rapid-timeout
invoices: bound rapid migration test workload
83/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference
Merge pull request #11198 from gijswijs/amp-setlocal-reconstruction-fix
invoices: cancel only the failing AMP set on reconstruction failure
73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body✓ Links an issue, advisory, or supporting reference
Why it was queued
boot or update pathmerge-commit duplicate discount
AI analysis · Moderate 60/100
This change fixes a bug in LND's handling of AMP (Atomic Multi-Path) payments. Previously, if one partial payment set failed to reconstruct its secret preimage, the entire invoice was canceled, including unrelated partial payment sets from other payers. Now only the failing set is canceled, and the invoice stays open so other valid sets can still complete and settle. This is a correctness/availability fix for reusable AMP invoices.
Run the SQLite and Postgres property checks as isolated subtests, close each database after its check, and migrate a bounded batch of randomized invoices per Rapid iteration. This preserves multi-invoice transaction coverage while preventing the accidental 100-by-100 workload from exhausting the Postgres fixture under the race detector.
78/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
Merge pull request #11200 from ziggie1984/build-go-1.27.1
build: bump Go language to 1.26.8 and toolchain to 1.27.1
73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body✓ Links an issue, advisory, or supporting reference
Why it was queued
signing or wallet pathparser or protocol pathmerge-commit duplicate discountsecond-pass: unusually broad changesecond-pass: security-sensitive path
AI analysis · Low 29/100
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.
Lower-prioritydocs: add release notes for 0.20.5 and 0.21.4by Gijs van Dam · 7b65e329 · Sep 18, 2026 · 2 filesMessage 57 · ThinTriage 0Details
Commit message · Gijs van Dam
docs: add release notes for 0.20.5 and 0.21.4
57/100 · ThinMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope! No meaningful explanatory body
The linter configuration uses default: all, so upgrading golangci-lint also enables checks introduced after v2.4. Adopt canonicalheader, clickhouselint, godoclint, iotamixing, and unqueryvet because they add focused HTTP, documentation, const-block, and SQL safeguards.
Fix the canonical WebSocket protocol header spelling required by the expanded canonicalheader implementation. Update twelve existing doc comments to begin with their declared symbol names as required by godoclint.
Keep modernize disabled for now because its findings require broader code changes that should be reviewed separately against the Go 1.26 support baseline.
92/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context✓ Explains rationale or failure mode
Why it was queued
signing or wallet pathparser or protocol pathsecond-pass: security-sensitive path
AI analysis · Informational 15/100
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.
AI review queuedlnrpc: regenerate protos with Go 1.27by ziggie · dd523108 · Sep 18, 2026 · 26 filesMessage 68 · AdequateInformational 15Details
Commit message · ziggie
lnrpc: regenerate protos with Go 1.27
The protobuf generator uses Go's formatting packages and is now compiled inside the Go 1.27.1 Docker image. This changes generated doc-comment formatting and causes rpc-check to report stale checked-in bindings.
Regenerate the RPC bindings with the newly pinned image. The resulting changes affect comments only; protobuf schemas and generated API code stay unchanged.
68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
signing or wallet pathsecond-pass: unusually broad changesecond-pass: security-sensitive path
AI analysis · Informational 15/100
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.
Upgrade the custom golangci-lint from v2.4.0 to v2.13.2 because the older version reports false type-checking errors for generic mutex code when it runs with Go 1.27. Refresh the tools module dependencies, account for the renamed exhaustruct_v5 linter, and disable the deprecated gomodguard while leaving gomodguard_v2 active.
Apply Go 1.27's gofmt output to the PSBT test's composite-literal return.
Lower the consecutive-SCID zlib test boundary from 30,794 to 30,792. Go 1.27 changed compress/flate output, making 30,793 SCIDs exceed the 65,535-byte Lightning message limit while 30,792 still fit.
100/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification
Why it was queued
signing boundarysigning or wallet path
AI analysis · Informational 20/100
This commit is a routine build-and-test maintenance patch to make the LND codebase compile and pass tests with the upcoming Go 1.27 release. It upgrades the project's custom linter tool, refreshes many indirect tool dependencies, adjusts one test's formatting, and lowers a test constant that checks how many compressed channel IDs fit in a Lightning message. There is no direct security fix here; it is a compatibility and test-hygiene change.
AI review queuedbuild: bump Go language and toolchain versionsby ziggie · b1f9ca66 · Sep 17, 2026 · 30 filesMessage 80 · StrongInformational 15Details
Commit message · ziggie
build: bump Go language and toolchain versions
Keep lnd compatible with the previous stable Go release by updating the language version in every tracked go.mod file to Go 1.26.8.
Move build and release tooling to Go 1.27.1, including CI, Docker images, the Makefile, protobuf generation, the linter configuration, and mobile build documentation. Update the installation documentation and official Linux archive checksums for Go 1.26.8 as well.
80/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context
Why it was queued
second-pass: unusually broad change
AI analysis · Informational 15/100
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.
Security candidateinvoices: cancel only the failing AMP set on reconstruction failureby Gijs van Dam · d74ab6fa · Sep 16, 2026 · 2 filesMessage 83 · StrongModerate 60Details
Commit message · Gijs van Dam
invoices: cancel only the failing AMP set on reconstruction failure
When an AMP set completes but fails preimage reconstruction, updateMpp issued a CancelInvoiceUpdate that canceled the greater invoice. For reusable static AMP invoices this is too broad: the failure is a set-local condition, since only the HTLCs of the failing set can never settle. Other sets accepted on the same invoice are unaffected by the failure and should remain payable.
Issue a CancelHTLCsUpdate scoped to the failing set instead, keeping the invoice open. Adds a regression test verifying that a concurrently accepted set on the same invoice survives a failing set and can still settle.
83/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
Why it was queued
fuzzing or regression evidenceboot or update path
AI analysis · Moderate 60/100
This commit fixes a bug in LND's invoice handling for reusable AMP (Atomic Multi-Path) invoices. Previously, if one payment set failed to reconstruct its preimage, the entire invoice was canceled, even though other valid payment sets on the same invoice were unaffected. Now, only the failing set is canceled, and the invoice stays open so other payers can still complete their payments. This is a correctness and availability fix for a specific Lightning Network payment feature.
docs+routerrpc: document that interceptor outgoing amount is untrusted
The `outgoing_amount_msat` field of `ForwardHtlcInterceptRequest` is the sender's `amt_to_forward` value copied straight out of the onion payload. The incoming link does not validate it, and the switch only compares it against the real incoming amount and the outgoing forwarding policy in `CheckHtlcForward` when the HTLC is resumed. When the interceptor answers with SETTLE that check never runs, so an interceptor that credits the outgoing amount can be made to release a preimage for far more than the incoming HTLC is actually worth.
The field comments did not say any of this, and the naming makes the outgoing amount look like "the" amount. Spell out that only `incoming_amount_msat` reflects what the peer committed to, and that the `in_amount_msat` override on RESUME_MODIFIED replaces the value used by the policy check without changing what is actually received.
Generated files are updated by hand to match the proto comments since only comments changed.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
In this commit, we add the public PR to the 0.20.5 and 0.21.4 release notes.
The note calls out that incoming-link replays are reconciled after the interceptor resumes a forward, so operators know the duplicate interception behavior is fixed.
80/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context
Merge pull request #11061 from bitromortac/2604-bolt12-1f
bolt12: add Merkle tree and BIP-340 message signatures
73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body✓ Links an issue, advisory, or supporting reference
Why it was queued
signing boundarysigning or wallet pathparser or protocol pathmerge-commit duplicate discount
AI analysis · Low 34/100
This commit adds the missing cryptographic signature layer for BOLT 12 offers in LND. It builds a Merkle tree from the message fields, signs that tree with a BIP-340 Schnorr signature, and now rejects invoice requests and invoices whose signatures do not verify. It also tightens decoding so non-minimal encodings of feature bits and amounts are rejected, preventing a message from being accepted in one form but re-encoded into a different byte form that would break the signature.
