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 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…
New validation gate added to Invoice.Encode() to reject malformed invoices before serializationReader rejects unknown even invoice TLV types and unknown even feature bitsReader enforces chain compatibility against activeChain
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…
Principle of least privilege: write token moved out of the model-bearing jobUntrusted input (model-generated comment) sanitized before privileged API useExternal action pinned to immutable commit SHA instead of mutable tag
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 featur…
New RPC endpoint gated by onchain:write macaroon permissionPackage size bounded to 25 transactions to limit deserialization workFee-rate ceiling passed through to backend; explicit 0 disables limit
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 reques…
New input validation functions added for protocol messagesValidation now runs before encoding, preventing malformed outbound messagesOverflow guard added for amount*quantity calculation
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 i…
Large dependency upgrade touching core Bitcoin primitives (wire, txscript, chainhash, btcutil, psbt, address)Migration to new v2 module layout with API changes in address handlingPins new upstream releases (btcd 0.26.0, btcwallet 0.17.0, neutrino 0.18.0, lightning-onion 1.4.0) that may include undisclosed fixes
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 safel…
Unconditional type assertion panic in DNS fallback pathMissing bounds check on LookupHost result before array indexingMissing network deadline on manually dialed DNS TCP connection
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 i…
Removal of a dependency-level vulnerability workaroundReference to historical advisory GHSA-25xm-hr59-7c27 in deleted commentNo code changes; only go.mod cleanup
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. T…
Removal of a dependency override that was a security mitigation for CVE-2021-29482Commit explicitly references the original GHSA advisory (GHSA-25xm-hr59-7c27)No actual downgrade or re-introduction of the vulnerable module is visible in the diff
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 tes…
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 (Op…
Dependency bump explicitly motivated by a known vulnerability identifier (GO-2026-4394)No source code changes in LND itself; only module metadata updatedVendor describes the root build as already unaffected, limiting direct security impact on LND
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. H…
Removal of deprecated network protocol (Tor v2) reduces attack surface and prevents futile/unsafe dials to unreachable services.Input validation added at operator boundaries (ParseAddressString, parseAddr) to reject v2 .onion addresses with a clear error.On-disk legacy key fallback now validates decrypted key type and rejects non-v3 (RSA1024) keys before passing them to Tor.
This commit fixes a bug in LND's remote-signing setup where zero-value previous transaction outputs were wrongly ignored when preparing a PSBT for a remote signer. The most concrete affected use case is BIP-322 message attestation, where t…
Functional denial-of-service in remote-signer BIP-322 workflows due to PSBT rejectionIncorrect zero-value UTXO validation caused legitimate outputs to be droppedFix removes Value check while preserving non-empty PkScript sanity check
This commit only adds new unit tests for an existing helper function in LND's RPC wallet code. It does not change any production logic, so it cannot introduce a security vulnerability or directly fix one in the code being committed. The te…
This commit removes old, unused code paths for sending Lightning payments through the main RPC server. These RPCs (SendPayment, SendPaymentSync, SendToRoute, SendToRouteSync) were already deleted from the service definition in a prior chan…
Removal of deprecated RPC handlers and macaroon permissionsDeletion of dead payment-dispatch helper codeNo new input parsing, network exposure, or privilege changes introduced
This commit removes three old, deprecated payment RPC methods (SendPayment, SendToRoute, and TrackPayment) from the LND Lightning node's router service. These methods were already replaced by newer V2 versions and were only thin wrappers a…
Removal of deprecated RPC surface reduces attack surfaceMacaroon permission entries for removed methods are deletedNo new code paths or logic added
This change closes a denial-of-service weakness in LND's onion-message forwarding. Previously, an attacker could create unlimited free peer identities and burn through the global byte-budget reserved for onion messages, starving real peers…
Adds a Sybil-resistance gate requiring funded, non-pending channels for onion message ingressChannel gate runs before per-peer and global rate limiters, preventing no-channel peers from consuming any token budgetIntroduces atomic shadow counter for O(1) hot-path checks on every incoming onion packet
This commit only updates test data in a JSON file used for automated tests of Lightning's new taproot channel features. It adds secret nonce values and corrects public nonce values so the test vectors match the expected commitment transact…
No production code modifiedTest-only JSON fixture updateNonce values are part of test vectors, not live secrets
This change adds a hidden switch that lets developers plug in a custom random source when creating MuSig2 signing nonces, mainly so tests can produce exactly the same signatures every time. In normal operation the switch is left empty, so …
New optional custom random source for MuSig2 nonce generationDefault call sites explicitly pass empty option, preserving CSPRNG behaviorCode comments state the option is intended only for reproducible test vectors
This commit only adds new test code and a JSON file of expected test outputs for Taproot Lightning channels. It does not change any production logic, network behavior, or wallet handling. There is no security issue in the commit itself.
This commit only adds a new test to the project's test suite. It does not change any production code, user-facing behavior, or network protocol. The new test cryptographically checks that example transactions in the project's test data car…
Adds independent cryptographic signature verification for test vectorsUses txscript.NewEngine with StandardVerifyFlags to mirror on-chain validationVerifies both the commitment transaction and each HTLC resolution transaction
Merge pull request #11024 from ziggie1984/invoices-update-validation
invoices: refine update handling
58/100 · ThinMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Links an issue, advisory, or supporting reference! No meaningful explanatory body
Why it was queued
boot or update pathmerge-commit duplicate discount
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
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
Security candidateci: split issue dedupe into find and post jobsby Olaoluwa Osuntokun · d1ea8687 · Jul 8, 2026 · 1 fileMessage 80 · StrongTriage 8Details
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
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
Security candidatefunding: use channel state open channelby ziggie · 03daaad4 · Jul 7, 2026 · 2 filesMessage 68 · AdequateTriage 18Details
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
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.
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
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
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
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 · AdequateTriage 18Details
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
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 · AdequateTriage 18Details
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
Security candidatelnwallet/rpcwallet: add unit tests for WitnessUtxo population helperby Olaoluwa Osuntokun · 6bb2c6f5 · May 19, 2026 · 1 fileMessage 83 · StrongInformational 15Details
Commit message · Olaoluwa Osuntokun
lnwallet/rpcwallet: add unit tests for WitnessUtxo population helper
Cover the four resolution branches plus the BIP-322 regression case:
- wallet-owns-it: FetchOutpointInfo returns a Utxo, helper writes the matching WitnessUtxo into the PSBT input. - external-fallback: wallet returns ErrNotMine, helper writes the WitnessUtxo from the sign descriptor's PrevOutputFetcher. - zero-value-fallback: same as above with the fetched entry's Value set to zero. This is the BIP-322 to_spend shape (input 0 of every BIP-322 to_sign references a virtual prev whose Value is mandated to be zero); the helper must populate the WitnessUtxo rather than silently skip it. - no-fallback: wallet returns ErrNotMine and no PrevOutputFetcher is provided; the helper leaves the input bare and the warning log fires (asserted only by absence of a populated WitnessUtxo). - empty-pk_script-fallback: the fetcher returns a non-nil entry with an empty PkScript; the helper rejects it as unusable (the PSBT WitnessUtxo serializer requires a non-empty script) and leaves the input bare.
The signed input (signDesc.InputIndex) is intentionally left untouched by the helper — that input is the one the caller's main path will populate later — and the tests cross-check that invariant on the wallet-owns-it case.
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
signing boundarysigning or wallet path
AI analysis · Informational 15/100
This commit only adds new unit tests for an existing helper function in LND's RPC wallet code. It does not change any production logic, so it cannot introduce a security vulnerability or directly fix one in the code being committed. The tests document and verify how the helper populates PSBT witness UTXO data, including a regression test for BIP-322 zero-value outputs.