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
lnwallet: fix limboMtx/intentMtx lock order inversion in PsbtFundingVerify
PsbtFundingVerify acquired intentMtx and then limboMtx, while handleFundingCancelRequest, which runs in the wallet's single requestHandler goroutine, acquires the two in the opposite order. With PSBT or batch funding both paths run concurrently, so the two goroutines can deadlock.
The consequences are severe and node wide: requestHandler is the only executor of every ChannelReservation method, and those methods are unconditional round trips with neither a timeout nor a quit escape. Once it is stuck, a peer disconnect parks funding.Manager's resMtx forever in CancelPeerReservations, and the next zombie sweeper tick kills reservationCoordinator on resMtx.RLock. From that moment the node can neither open nor accept channels, freshly confirmed channels are stuck in the channelReadySent opening state and are never added to the graph nor announced, and no log line is emitted about any of it. Only a restart recovers.
Look the channel reservation up, and release limboMtx, before acquiring intentMtx, and document the required order on the mutex declaration.
73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
signing boundarysigning or wallet path
AI analysis · Critical 85/100
This commit fixes a classic deadlock bug in LND's wallet code. Two different code paths were acquiring the same two locks in opposite orders, which could cause the wallet's single request handler goroutine to freeze permanently. Once frozen, the node could no longer open or accept any Lightning channels, and newly confirmed channels would get stuck without being announced to the network. Only restarting the node would recover. The fix reorders the lock acquisition so both paths use the same order, and documents the rule.
The bolt12 package can already encode and decode the TLV layer but has no way to carry an offer as a human-transportable string, which is the form the spec specifies for QR codes, URLs and email signatures. BOLT 12's envelope is subtractive relative to BIP-173: there is no BCH checksum, because the BIP-340 signature over the Merkle root already secures the payload, and a '+' continuation marker may split the string across lines. btcutil/bech32's public API always wraps the checksum, so the alphabet layer is duplicated here rather than reused. Enforce a whitelist of BOLT 12 prefixes (lno, lnr, lni) on both Encode and Decode.
85/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Names security-relevant behavior explicitly
Why it was queued
signing boundary
AI analysis · Informational 23/100
This commit adds a new encoder/decoder that turns BOLT 12 Lightning payment data (offers, invoice requests, invoices) into human-readable strings like 'lno1...' and back again. It is a feature addition, not a fix for a known vulnerability. The code includes careful input checks for length, character set, case rules, allowed prefixes, and line-continuation markers, plus extensive tests. There is no indication in the commit that this resolves a security incident or was reported by an outside researcher.
The invoice_request codec has round-trip coverage against locally- constructed messages only, so a canonical-encoding bug would go unnoticed until a real peer rejected a signature. Drive the decoder from the spec's signature-test invoice_request and assert that re-encoding is byte-identical to the wire bytes, because the signature commits to the Merkle root of that exact encoding.
95/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification✓ Names security-relevant behavior explicitly
Why it was queued
signing boundary
AI analysis · Informational 12/100
This commit only adds a new test. It does not change any production code. The test decodes a standard BOLT12 invoice request from the official specification's test vectors and checks that re-encoding it produces exactly the same bytes. This is a defensive quality-improvement change meant to catch canonical-encoding bugs before they reach real peers.
InvoiceError is the negative-reply counterpart to an invoice, sent over onion messages at namespace type 68 when the receiver rejects an invoice request or the sender rejects a returned invoice. All three fields are odd (informational): erroneous_field (TLV 1, the offending TLV type), suggested_value (TLV 3, a valid replacement), and error (TLV 5, a UTF-8 explanation). Unlike Offer/InvoiceRequest/Invoice this type has no bech32 form and no Merkle signature — it travels only inside onion message payloads.
73/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Names security-relevant behavior explicitly
Why it was queued
signing boundary
AI analysis · Informational 21/100
This commit adds support in LND for a new Lightning protocol message called InvoiceError. It is used to politely tell another node why their payment invoice or invoice request was rejected, sent privately through an onion-routed message. The change is mostly a feature addition with built-in validation to make sure the error message is well-formed before it is sent.
Implement the structural validators for the BOLT 12 invoice, adding ValidateInvoiceWrite, ValidateInvoiceRead, ValidateInvoiceExpiry, and ValidateInvoiceAgainstRequest.
The validators implement the spec writer and reader requirements in the order the spec lists them. The reader confirms the signature TLV is present but defers actual Schnorr verification until the merkle and signing primitives land, mirroring the ValidateInvoiceRequestRead precedent.
This commit adds validation checks for BOLT 12 invoices in the LND Lightning node software. It ensures invoices contain required fields (creation time, amount, payment hash, node ID, payment paths), match their originating invoice requests, and aren't expired or malformed before being encoded or accepted. The change is defensive: it rejects invalid invoices rather than letting them propagate, which helps prevent payment failures, confusion, or minor abuse. Signature verification is explicitly left for a future patch, so this is not a complete security fix on its own.
Add the BOLT 12 Invoice message: a struct mirroring the invoice_request fields (types 0-91) plus the invoice-specific fields (types 160-176) and the signature (type 240), together with its pure-TLV Encode/DecodeInvoice codec and the UsableFallbackAddresses accessor that applies the spec's MUST-ignore filter.
Additionally, add the NewInvoiceFromRequest constructor to build an Invoice from a corresponding request. This copies all non-signature fields from the request (including unknown signed-range TLVs via the decodedTLVs sidecar) and mirrors invreq_amount into invoice_amount.
73/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Names security-relevant behavior explicitly
Why it was queued
signing boundary
AI analysis · Informational 12/100
This commit adds new code to support BOLT 12 invoices in the LND Lightning node. It introduces a data structure, encoding/decoding logic, and helper functions to filter fallback addresses and blinded payment paths. There is no bug fix or security patch here; it is a feature addition implementing a protocol specification.
Security candidateci: split issue dedupe into find and post jobsby Olaoluwa Osuntokun · d1ea8687 · Jul 8, 2026 · 1 fileMessage 80 · StrongInformational 15Details
Commit message · Olaoluwa Osuntokun
ci: split issue dedupe into find and post jobs
In this commit, we give the issue dedupe workflow the same shape: one job finds the duplicate candidates, another posts the comment. The find job records the candidate issue numbers to a file, and the post job hands those numbers to comment-on-duplicates.sh, which already validates each number and renders the comment from a fixed template.
Keeping detection and posting apart mirrors how the script is already factored, so the post job ends up a thin wrapper over it. We also drop the unused id-token permission and turn off checkout credential persistence while we're in here.
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
defensive validationcredential or privilege statedocumentation-only discount
AI analysis · Informational 15/100
This commit is a hardening and refactoring change to a GitHub Actions workflow that detects duplicate issues. It splits the workflow into two jobs: one that only reads issue data and uses an AI model to find duplicates, and a second that only posts comments. The change reduces the privileges available to the AI step, pins the action to a specific version, disables credential persistence, and adds concurrency controls. There is no indication of a security vulnerability being fixed or introduced; it is a defensive improvement.
ci: split PR severity workflow into classify and apply jobs
In this commit, we separate the two concerns in the PR severity workflow: working out the severity, and applying it. The classify job inspects the PR and records its verdict (the severity level, whether to comment, and the comment body) to a few files. A second apply job reads those files and does the mechanical work of setting the label and posting the comment.
Pulling the classification apart from the application keeps each job doing one thing and makes the flow easier to follow. The apply job takes the severity the classifier picked and checks it against the known set before touching a label, and posts the comment from a file via --body-file so the body is handled as plain data. We also turn off checkout credential persistence, since neither job needs a git credential on disk.
85/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context
Why it was queued
credential or privilege state
AI analysis · Informational 15/100
This commit is a hardening and cleanup of a GitHub Actions workflow that automatically labels pull requests by severity. It does not change any LND node code, wallet logic, or network protocol. Instead, it splits the workflow into two jobs: a read-only 'classify' job that runs an AI model to decide the severity, and a separate 'apply' job that actually sets the label and posts the comment. The change reduces security risk by keeping write permissions out of the job that processes untrusted pull-request text, pins the external AI action to a fixed commit hash, disables unnecessary git credentials, and adds input sanitization for the model-generated comment. It is a defensive improvement, not a vulnerability fix.
Update the gateway-action pin and runtime_ref to the v0.5.0 release commits, and extend the shim for the new inline-command support: a pull_request_review_comment trigger plus comment_in_reply_to input so /gateway dismiss, promote, and explain work as replies on a finding's inline thread. Same fork-PR safety profile as issue_comment — comment events receive no secrets on fork PRs.
Runtime highlights in v0.5.0: /gateway promote (file a finding as an issue and dismiss it), batch dismiss, gateway-approved label with stale-approval retraction, and one review comment per run with a verdict-first body.
68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
access controldocumentation-only discount
AI analysis · Informational 21/100
This commit updates a GitHub Actions workflow for an optional code-review bot called 'gateway' from version 0.4.4 to 0.5.0. It adds support for replying to inline review comments (not just regular PR comments) and pins the new action and runtime to specific, immutable commit hashes. The change is administrative and does not touch LND's core Lightning node code, wallet logic, or network protocol handling.
Security candidatefunding: use channel state open channelby ziggie · 03daaad4 · Jul 7, 2026 · 2 filesMessage 68 · AdequateInformational 15Details
Commit message · ziggie
funding: use channel state open channel
Update the funding manager callback and helper signatures to depend on the chanstate OpenChannel type instead of the channeldb alias.
The funding manager already receives channel persistence through the chanstate Store interface, so this keeps its open-channel boundary aligned with the backend-independent package.
68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
signing boundary
AI analysis · Informational 15/100
This commit is a straightforward internal code cleanup in LND's channel-opening machinery. It swaps one internal type name (channeldb.OpenChannel) for another (chanstate.OpenChannel) across function signatures in the funding manager and its tests. There is no change to user-facing behavior, network protocol, cryptography, or data handling, and nothing in the commit suggests a security fix or vulnerability.
Copy all HTLC fields when cloning channel commitment state.
The old copy method only copied a subset of scalar fields and copied into nil slices for Signature and ExtraData. Allocate those slices and deep-copy custom record values so snapshots and channel copies retain complete HTLC metadata.
This commit fixes a bug in how the Lightning Network Daemon (LND) copies payment channel data. When the program made a copy of an HTLC (a pending payment in a Lightning channel), it failed to copy several important fields and did not properly duplicate variable-length data like signatures, extra data, and custom records. This could cause copies or snapshots of channel state to be incomplete or accidentally share mutable data. The fix deep-copies all relevant fields and adds a test to verify the copy is fully independent.
Security candidatelnwallet+walletrpc: add SubmitPackage for v3 CPFP package relayby Elle Mouton · f55c0565 · Jun 30, 2026 · 17 filesMessage 73 · AdequateLow 30Details
Commit message · Elle Mouton
lnwallet+walletrpc: add SubmitPackage for v3 CPFP package relay
Add SubmitPackage to the lnwallet.WalletController interface and a new WalletKit.SubmitPackage RPC, so a client of lnd can relay a package of related transactions (parents first, child last) through lnd's own chain connection. This lets a zero-fee v3/TRUC parent be accepted via its fee-paying CPFP child without the caller needing a separate connection to the chain backend.
BtcWallet.SubmitPackage forwards to the chain backend's submitpackage for bitcoind/btcd, and broadcasts each transaction individually for neutrino (no mempool; relies on the peer's 1p1c package relay). The WalletKit handler maps the proto request/response to the btcjson result and is gated by the onchain:write macaroon permission. Mock controllers and the no-chain backend gain trivial implementations.
73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
credential or privilege statesigning or wallet path
AI analysis · Low 30/100
This commit adds a new RPC called SubmitPackage to LND's WalletKit. It lets users submit a group of related Bitcoin transactions together so a zero-fee parent can be accepted because a later child transaction pays its fee. This is a feature addition, not a fix for a known vulnerability. The code is careful about limits and permissions, but it does expose a new on-chain write capability that could be misused if an attacker already has a valid macaroon.
bolt12: validate InvoiceRequest per BOLT 12 reader/writer requirements
ValidateInvoiceRequestRead and ValidateInvoiceRequestWrite enforce the structural BOLT 12 requirements an invoice request can be checked against on its own. The reader validates incoming requests. The writer catches out-of-range types in decoded-then-mutated requests before they leave the local boundary. Type 240 carries the signature and sits outside the allowed range by spec design. Both validators skip it during the range scan.
Two reader MUSTs are deferred. Schnorr signature verification against the merkle root keyed by invreq_payer_id lands with the Invoice message, where the merkle and signing primitives are shared. Offer cross-validation requires an Offer reference the structural validator does not carry, and lands in the bolt12handler layer where both the request and the stored Offer are in scope.
88/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Names security-relevant behavior explicitly
Why it was queued
signing boundarydefensive validation
AI analysis · Low 49/100
This commit adds validation checks for BOLT 12 invoice requests in the LND Lightning node. It ensures that invoice requests follow protocol rules when being created (written) and received (read), rejecting malformed or non-compliant requests before they are encoded or processed. The change is defensive: it prevents invalid invoice requests from leaving the node or being accepted from peers, which could otherwise lead to payment confusion, incorrect amounts, or protocol incompatibility. Signature verification and full offer cross-checking are intentionally left for future commits.
bolt12: add InvoiceRequest message struct and TLV codec
The InvoiceRequest is the BOLT 12 message that links a payer to an offer: it mirrors the offer's fields so the issuer can stay stateless, and adds the payer-specific fields and Schnorr signature that prove the request.
It implements lnwire.PureTLVMessage so it round-trips through the shared TLV codec.
78/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Names security-relevant behavior explicitly
Why it was queued
signing boundary
AI analysis · Informational 12/100
This commit adds a new data structure and serialization code for BOLT 12 invoice requests in the LND Lightning node. It is purely an implementation of a protocol message format and includes a round-trip test. There is no indication in the commit that it fixes a security bug or introduces a vulnerability.
github: bump gateway code-review to v0.4.4 (#10926)
Bump the gateway-action pin to v0.4.4 (abe7cf8) and the runtime_ref to gateway v0.4.4 (20675fc), and drop the hardcoded installation_id. As of v0.4.4 the runtime resolves the App installation covering this repo from app_id/private_key, so a static (and easily wrong-org) id is no longer needed.
81/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
Why it was queued
access controldocumentation-only discount
AI analysis · Informational 21/100
This commit updates a GitHub Actions workflow that runs an automated code-review bot called 'gateway'. It bumps the bot's version from v0.4.3 to v0.4.4 and removes a hardcoded numeric 'installation_id'. The new version figures out the correct installation ID automatically from the app's credentials. The change is a routine dependency/maintenance update for a CI/CD automation tool, not a fix for a known vulnerability in the LND software itself.
Security candidatemulti: upgrade to btcd v2 modulesby Oli · 8047149c · Jun 24, 2026 · 605 filesMessage 88 · StrongLow 32Details
Commit message · Oli
multi: upgrade to btcd v2 modules
Migrate all btcd dependencies to the new per-package v2 modules (wire/v2, txscript/v2, chaincfg/v2, chainhash/v2, btcutil/v2, psbt/v2, btcec/v2) introduced by btcd v0.26.0, and pin the tagged ecosystem versions: btcwallet v0.17.0, neutrino v0.18.0 and lightning-onion v1.4.0.
The bulk of the import rewrite was produced by the scripted diff from https://github.com/btcsuite/btcd/pull/2547 (followed by 'make rpc'). The address symbols that moved out of btcutil into the new address package are imported as btcaddr where a local "address" variable would otherwise shadow them. The go.mod/go.sum updates and the remaining manual compilation fixes are folded into this single commit so it builds on its own (the migration was previously split into a reproducible scripted-diff plus follow-ups, intended to be squashed on merge).
88/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Links an issue, advisory, or supporting reference
Why it was queued
signing boundaryaccess controlsigning or wallet pathboot or update pathparser or protocol path
AI analysis · Low 32/100
This is a large dependency upgrade for the LND Lightning node software. It moves LND from older btcd Bitcoin library packages to new 'v2' packages and updates related wallet and network libraries. The commit is almost entirely mechanical import-path changes and version bumps. It does not appear to fix a specific known security bug on its own, but it pulls in newer upstream versions that may contain security fixes. Because the change touches 605 files and many core Bitcoin-handling modules, any mistake in the migration could affect transaction parsing, address handling, or cryptographic operations, so it should be reviewed and tested carefully.
Security candidatediscovery: fix panic in DNS fallback SRV lookupby Erick Cestari · 2a3642c6 · Jun 23, 2026 · 2 filesMessage 85 · StrongLow 47Details
Commit message · Erick Cestari
discovery: fix panic in DNS fallback SRV lookup
The fallback SRV lookup type-asserted each DNS Answer record to *dns.SRV unconditionally. If the response contains a non-SRV record (e.g. an A or CNAME), the type assertion panics and crashes the daemon. Use the comma-ok form to skip non-SRV records instead.
Also guard against an empty LookupHost result for the shim, which would otherwise panic on an out-of-bounds index into addrs.
This is safe to discuss and fix in public. The bug is very unlikely to be exploitable: triggering it requires either a DNS seeder to serve a malformed response, or an on-path MITM injecting one (the fallback response is unauthenticated). A malicious seeder already has far more direct ways to disrupt a node, and a MITM attack is hard to mount, so the panic does not meaningfully widen the attack surface.
85/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Names security-relevant behavior explicitly
Why it was queued
explicit security language
AI analysis · Low 47/100
This commit fixes a bug in LND's DNS seed bootstrap code that could crash the node. The code assumed every record in a DNS response was an SRV record, so a non-SRV record (like a normal A or CNAME record) would cause a panic. The fix safely skips non-SRV records and also handles cases where the DNS lookup returns no addresses at all. The commit message says the bug is hard to exploit because it requires a malicious DNS server or a network attacker, and such attackers already have easier ways to disrupt a node.
Opt-in review bot invoked via /gateway review PR comments (maintainer-gated). Thin shim onto the public lightninglabs/gateway-action (SHA-pinned to v0.4.3); the review runtime stays private. Comment-commands only, so fork PRs never spawn failing runs.
* github: address review on gateway workflow
- Gate the job on a /gateway command in the comment body so unrelated PR comments don't spin up no-op runners. Use contains() (not startsWith) since the runtime accepts the command at column 0 of any line, incl. multi-line. - Pin runtime_ref to the gateway commit SHA so runtime upgrades require an lnd PR rather than a moved tag, matching the action SHA-pin.
76/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
Why it was queued
access controldocumentation-only discount
AI analysis · Informational 12/100
This commit adds a new optional GitHub Actions workflow that lets maintainers trigger an automated code-review bot by typing '/gateway review' on a pull request. It is purely an infrastructure/configuration change and does not alter any LND node code, cryptography, or network behavior. The workflow is comment-triggered only, uses pinned commit references, and minimizes token permissions, which are defensive design choices rather than fixes for any known vulnerability.
Security candidatekvdb: remove stale xz replaceby ziggie · 80f98a5e · Jun 9, 2026 · 1 fileMessage 73 · AdequateInformational 18Details
Commit message · ziggie
kvdb: remove stale xz replace
Remove the nested kvdb module's github.com/ulikunitz/xz replace directive.
The current kvdb module graph does not select github.com/ulikunitz/xz, so the historical vulnerability workaround is no longer needed in this nested go.mod.
73/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Names security-relevant behavior explicitly
Why it was queued
explicit security language
AI analysis · Informational 18/100
This commit removes a temporary security workaround in a Go module file. The workaround forced the use of a newer, fixed version of a compression library (xz) to avoid a known historical vulnerability. The commit message says the library is no longer used by this part of the project, so the workaround is no longer needed. By itself, removing the workaround does not introduce a vulnerability, but it means the project now relies on the normal dependency resolution to pick a safe version elsewhere.
Security candidatemod: remove stale xz replaceby ziggie · eeaa717e · Jun 9, 2026 · 1 fileMessage 88 · StrongInformational 12Details
Commit message · ziggie
mod: remove stale xz replace
The github.com/ulikunitz/xz replacement was added for CVE-2021-29482 when an older embedded-postgres dependency chain pulled in the affected module indirectly.
That module is no longer part of the selected dependency graph: go mod why reports that the main module does not need it, and go list -m reports it is not a known dependency. Keeping the replacement no longer affects builds.
88/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Links an issue, advisory, or supporting reference
Why it was queued
explicit security language
AI analysis · Informational 12/100
This commit removes an old workaround in LND's dependency file (go.mod) that pinned a safe version of the 'xz' compression library. The workaround was originally added because another dependency once pulled in a vulnerable version of xz. The commit message says that dependency is no longer in LND's build graph, so the pin no longer does anything. There is no code change that introduces a vulnerability; it is cleanup of a stale configuration line.
Security candidatelint: remove redundant loop var copies in test filesby Erick Cestari · aca27e27 · Jun 3, 2026 · 137 filesMessage 83 · StrongInformational 15Details
Commit message · Erick Cestari
lint: remove redundant loop var copies in test files
Since Go 1.22 loop variables are scoped per-iteration, so the `x := x` / `a, b := a, b` copies inside range/for loops are no longer needed. This removes the existing redundant copies in test files.
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
cryptography-sensitive pathsigning or wallet pathboot or update pathauthentication path
AI analysis · Informational 15/100
This commit is a cleanup-only change that removes unnecessary loop-variable copies in Go test files. Since Go 1.22, loop variables are already scoped per-iteration, so the old `x := x` workarounds are redundant. The change affects only test code, not the running LND node software, and does not alter any behavior or fix a security bug.
Security candidatemod: bump btcwallet to v0.16.18by yyforyongyu · 5b45ac81 · May 28, 2026 · 2 filesMessage 68 · AdequateInformational 15Details
Commit message · yyforyongyu
mod: bump btcwallet to v0.16.18
Replace the pseudo-version pin on commit 70a94ea39e9c with the freshly tagged v0.16.18, which points at the same commit. The change is purely a relabel -- no transitive impact -- but it lets downstream consumers (litd, tapd, etc.) drop their replace directives, since v0.16.18 now sorts above the previously-tagged v0.16.17 under Go's MVS.
68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
access control
AI analysis · Informational 15/100
This commit only changes a dependency version label in LND's package manifest. The underlying code (commit 70a94ea39e9c) stays exactly the same; the dependency is simply tagged as v0.16.18 instead of being referenced by a pseudo-version. There is no functional or security change visible in this commit.
Security candidatemod: bump kvdb to v1.5.1by yyforyongyu · 12686ac3 · May 28, 2026 · 2 filesMessage 66 · AdequateLow 32Details
Commit message · yyforyongyu
mod: bump kvdb to v1.5.1
Move from kvdb/v1.5.0 to the freshly tagged kvdb/v1.5.1, which points at current master HEAD. The new tag includes the kvdb submodule's grpc floor bump to v1.79.3 (173fd5147) and the otel SDK bump past the GO-2026-4394 vulnerability (9978f4d33).
The root lnd module already requires the newer grpc and otel versions, so this bump is effectively a relabel with no transitive impact on the root build. But it keeps downstream consumers that import lnd/kvdb directly from picking up v1.5.0 and pulling in the vulnerable otel SDK through kvdb's submodule go.mod.
66/100 · AdequateMessage clarity
✓ Subject identifies a change✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Names security-relevant behavior explicitly
Why it was queued
explicit security language
AI analysis · Low 32/100
This commit updates a dependency version in LND's build files. It bumps the internal 'kvdb' submodule from version 1.5.0 to 1.5.1 so that downstream projects importing kvdb directly do not pull in an older, vulnerable telemetry library (OpenTelemetry SDK). The commit message says the main LND module already uses the newer versions, so this change is mostly a relabel for consumers of the kvdb submodule and has no direct code change in LND itself.
Security candidatemulti: drop tor v2 onion production, keep wire codec faithfulby Erick Cestari · 2ae1db83 · May 22, 2026 · 31 filesMessage 88 · StrongLow 34Details
Commit message · Erick Cestari
multi: drop tor v2 onion production, keep wire codec faithful
Tor stopped serving v2 onion services in October 2021; lnd should not produce v2 addresses anymore, but it must still verify signatures on and re-broadcast peer NodeAnnouncement messages that carry v2 entries.
Stop accepting v2 as configuration input (lncfg), strip the legacy `--tor.v2` flag from the sample config, and remove the `tor.OnionHostToFakeIP` helper. Operator entry points (`--externalip`, `--listen`, `lncli connect`, `lncli wtclient towers add`) fail fast on a v2 `.onion` string, so upgrading nodes must remove any v2 entry from `lnd.conf` before lnd will start.
Filter persisted v2 state before use without rewriting on-disk records: the self-announcement builder strips any v2 entry inherited from the stored self-node; the watchtower client drops v2 entries from each persisted tower's address list (skipping the tower entirely if no non-v2 address remains); the autopilot connector, graph bootstrapper, and static-channel backup restore paths skip v2 entries before attempting outbound dials. Restrict the Tor controller's ADD_ONION path to v3 keys, including the encrypted on-disk legacy-key fallback.
For inbound announcements, keep the wire codec wire-faithful: `lnwire.WriteOnionAddr`, `graph/db.encodeOnionAddr`, and the matching decoders round-trip v2 bytes so `DataToSign` reproduces the bytes the remote peer signed, signature validation succeeds, and the announcement is persisted to the graph DB and re-broadcast across restarts byte-for- byte. RPC surfaces continue to expose the full address set so external tools can independently reproduce and verify the signed bytes.
Add a netann regression test that signs a [v3, v2, ipv4] announcement, round-trips it through Encode/Decode, verifies the signature, and confirms the resulting models.Node preserves the v2 entry. Add a graph bootstrapper test asserting v2 entries are skipped while v3 and plain TCP entries on the same node still surface as bootstrap candidates.
88/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Names security-relevant behavior explicitly
Why it was queued
signing boundaryfuzzing or regression evidence
AI analysis · Low 34/100
This commit removes support for obsolete Tor v2 onion addresses from the Lightning Network Daemon (lnd). Tor v2 services were shut down by the Tor network in October 2021, so lnd will no longer create, accept, or dial v2 onion addresses. However, it still keeps the ability to store and re-broadcast v2 addresses that appear in messages from other nodes, because doing otherwise would break signature verification on those older announcements. The change is a cleanup and hardening patch rather than a fix for an active security vulnerability.
Security candidatemulti: update neutrino dep to include chainimport and header state fixby Olaoluwa Osuntokun · 88fff36e · May 21, 2026 · 3 filesMessage 78 · AdequateInformational 12Details
Commit message · Olaoluwa Osuntokun
multi: update neutrino dep to include chainimport and header state fix
Update the neutrino dependency to a version that includes the chainimport package for fast initial header sync, and the ResetHeaderState fix that allows P2P sync to continue after import.
The updated neutrino dependency changes the ChainService.Start method signature to accept a context.Context parameter. Update all call sites to pass context.TODO() to maintain existing behavior.
78/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Names security-relevant behavior explicitly
Why it was queued
signing boundary
AI analysis · Informational 12/100
This commit simply updates a software library dependency (neutrino) used by the Lightning Network Daemon (LND). The new version is said to add a faster way to import blockchain headers and fix a bug that could stop peer-to-peer header syncing after an import. The actual code change shown is only a version bump in dependency files plus a tiny whitespace cleanup in a linter config. There is no direct evidence in the commit of a security vulnerability or attack.
