CommitWatch RSS
AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Low 46 Bitcoin

build: bump otel sdk past vulnerable version

LL9978f4d3 View source ↗
Public commit record

What the developer wrote

Authored by ziggie

85/100 · Strong
build: bump otel sdk past vulnerable version

Bump the root and standalone kvdb module OTel dependencies to v1.40.0,
which is the first release containing the fix for GO-2026-4394. This
also raises golang.org/x/sys to v0.40.0 through the updated module graph.

Keep the root and nested kvdb module metadata aligned so both normal and
kvdb_etcd builds resolve the fixed SDK version.
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context✓ Names security-relevant behavior explicitly
The short version

What changed, and why it matters

This commit updates the OpenTelemetry (OTel) software library used by the Lightning Network Daemon (LND) from a version with a known security flaw to a fixed version. It is a dependency-only change affecting build files, not LND's own code. The commit message explicitly says it fixes GO-2026-4394, a published vulnerability database entry, but the exact attack details are not shown in the diff itself.

Recommended action

Verify that downstream builds and the kvdb_etcd build tag now resolve go.opentelemetry.io/otel/sdk to v1.40.0 or later (for example with `go mod graph | grep otel/sdk`). Review the GO-2026-4394 advisory to confirm whether LND's use of OTel/telemetry exporters exposes the vulnerable code path, and consider backporting this dependency bump to supported release branches.

Security signals we found

01

Dependency bump explicitly described as fixing a known vulnerability (GO-2026-4394)

02

OpenTelemetry SDK updated across both root and kvdb nested modules to keep versions aligned

03

No application code changes; risk depends entirely on whether the vulnerable OTel code path is reachable in LND builds

04

golang.org/x/sys minor version bump is a routine transitive update, not independently flagged

Risk score

Why this scored 46/100

Our methodology →
Potential impact 12/30
Exploitability 8/25
Stealth signal 6/15
Affected reach 10/15
Confidence 7/10
Evidence quality 3/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.

More from LND

Related watches

Moderate 62 AI analysisMessage 58 · Thin
LL Lightning LabsLND BitcoinLightning Network

Merge pull request #11212 from ziggie1984/disable-legacy-channels

This change stops LND from opening new Lightning channels using the old 'legacy' commitment format. The legacy format makes it harder to recover funds if something goes wrong, because the money owed to you is tied to a secret key that chan…

Prevents opening new channels with the legacy commitment type, whose tweaked to_remote output complicates data-loss recoveryCloses a negotiation path where an empty channel_type TLV bypassed feature checks and forced a legacy channelAdds explicit RPC and wire rejection with a dedicated error code
112cb5f3by ziggieXXX+265−4716 files
Vendor flagged security relevance
Open full analysis →Source commit ↗
Moderate 56 AI analysisMessage 73 · Adequate
LL Lightning LabsLND BitcoinLightning Network

Merge pull request #11223 from gijswijs/legacy-dust-retribution-fix

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
500ca51fby ziggieXXX+168−146 files
No security note in commit
Open full analysis →Source commit ↗
Moderate 62 AI analysisMessage 73 · Adequate
LL Lightning LabsLND BitcoinLightning Network

Merge pull request #11190 from Roasbeef/zpay32-reject-duplicate-payment-hashes

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
86306f89by Yong+147−106 files
No security note in commit
Open full analysis →Source commit ↗