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

lnrpc: add include_log field to GetDebugInfoRequest

LLf0e22873 View source ↗
Public commit record

What the developer wrote

Authored by saubyk

73/100 · Adequate
lnrpc: add include_log field to GetDebugInfoRequest

Add an `include_log` bool field to GetDebugInfoRequest proto message.
When set to true, the server will include the log file content in the
response in addition to the configuration map.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit adds a new optional flag called include_log to the GetDebugInfo API request in LND. When set to true, the server will return the contents of its log file along with the existing configuration map. The change is purely a protobuf/API schema update; the actual server-side logic that reads and returns the log file is not visible in this diff. Because log files can contain sensitive information (connection details, errors, paths, or in rare cases accidentally logged secrets), adding an easy way to retrieve them over the API could increase the impact of any future RPC authentication weakness or misconfiguration. However, the commit itself does not introduce a vulnerability, and the default behavior remains unchanged (logs are not returned unless explicitly requested).

Recommended action

Review the corresponding server-side handler change (not included in this diff) to ensure that: (1) GetDebugInfo remains behind strong RPC authentication and authorization, (2) log file reading is bounded to prevent excessive memory use or denial of service, (3) log paths cannot be influenced by the request, and (4) no secrets are written to logs. Operators should treat GetDebugInfo responses as sensitive and avoid exposing the RPC interface to untrusted networks.

Security signals we found

01

New optional API flag that can cause the server to return log file contents

02

Log files may contain operational or sensitive node information

03

Default behavior is unchanged; explicit opt-in required

04

No server-side implementation visible in this commit; security impact depends on handler changes not shown

Risk score

Why this scored 27/100

Our methodology →
Potential impact 5/30
Exploitability 5/25
Stealth signal 5/15
Affected reach 5/15
Confidence 5/10
Evidence quality 2/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 ↗