Continuous public-repository analysis

Open source.
Not open secrets.

We watch what security-critical projects change—then translate the code into clear, independent intelligence anyone can understand.

23Projects watched
16864Commits captured
12657AI analyses
75High-risk findings · 30d
The watch feed

Changes worth understanding

AI analysis is published as generated. Community notes appear after human validation.

12656 analyses
Highest risk·RSS
Low 25 AI analysisMessage 73 · Adequate
LL Lightning LabsLND BitcoinLightning Network

htlcswitch: classify a node-ID forward as a forward event

This commit fixes a bookkeeping bug in LND's HTLC event stream. When a payment is forwarded to a 'blinded' next hop identified only by a node public key (not a channel ID), and it fails before the switch picks an outgoing channel, the even…

Event misclassification in HTLC event stream (forward reported as receive)Blinded/node-ID forwarding path introduced prior to this fixFailure and resolution packets dropped next-hop metadata before fix
a4844ef5by bitromortac+149−04 files
No security note in commit
Informational 19 AI analysisMessage 73 · Adequate
LL Lightning LabsLND BitcoinLightning Network

htlcswitch+lnrpc: report node-ID next hop to the off-chain HTLC interceptor

This change improves how the Lightning Network Daemon (LND) reports forwarding details to external plugins that inspect HTLCs (payment packets). For a new type of blinded route where the next hop is identified by node ID rather than a spec…

Information-correctness fix for HTLC interceptor APIPrevents misclassification of node-ID forwards as exit hopsAdds explicit sentinel to disambiguate zero SCID semantics
32373b76by bitromortac+29−13 files
No security note in commit
Low 29 AI analysisMessage 68 · Adequate
LL Lightning LabsLND BitcoinLightning Network

htlcswitch/hop: decode next_node_id blinded hops

This commit adds support in LND for a different way of identifying the next hop in a private ('blinded') Lightning payment route. Previously LND expected the next hop to be identified by a channel ID; now it also accepts the next node's pu…

New validation enforces BOLT 4 mutual exclusivity of short_channel_id and next_node_id in blinded route dataPreviously ambiguous or unhandled next_node_id forwarding case now explicitly decodedNo memory-safety, cryptographic, or authorization changes observed
4fd4289aby bitromortac+471−86 files
No security note in commit
Informational 15 AI analysisMessage 28 · Opaque
RB Rust Bitcoinrust-bitcoin BitcoinCryptographic libraries

Update API files

This commit only updates generated text files that list the project's public API surface. The change shows that a Sum trait implementation for a numeric result type was broadened to accept more input types. No actual source code was modifi…

8356c542by Mitchell Bagot+24−243 files
No security note in commit
Informational 15 AI analysisMessage 78 · Adequate
RB Rust Bitcoinrust-bitcoin BitcoinCryptographic libraries

Add tests for NumOpResult sum

This commit only adds new unit tests for summing Amount and SignedAmount values into a NumOpResult. It does not change any production code, fix a bug, or alter behavior. There is no security issue here.

75a27efaby Mitchell Bagot+24−01 file
No security note in commit
Informational 15 AI analysisMessage 68 · Adequate
RB Rust Bitcoinrust-bitcoin BitcoinCryptographic libraries

Make Sum generic for Signed/Amount -> NumOpResult

This is a small Rust API ergonomics change. It makes the 'sum' operation more flexible so developers can add up plain Amount values directly into a result type, not just values that are already wrapped in that result type. There is no secu…

4d37029cby Mitchell Bagot+6−61 file
No security note in commit
Informational 12 AI analysisMessage 83 · Strong
EL ElectrumElectrum BitcoinSoftware wallets

test_lnwallet: add unittest for unchanged channel update from failed htlc

This commit only adds a new unit test to Electrum's Lightning wallet test suite. It checks that when a payment fails due to a temporary lack of liquidity (TEMPORARY_CHANNEL_FAILURE) and the accompanying channel policy update is identical t…

Lightning payment routing failure handling behavior is being testedTEMPORARY_CHANNEL_FAILURE no longer (or is confirmed not to) blacklist channels when the channel update is unchangedLiquidity hints are used as an alternative to blacklisting for retry amounts
1f5b9adbby f321x+61−21 file
No security note in commit
Informational 15 AI analysisMessage 73 · Adequate
EL ElectrumElectrum BitcoinSoftware wallets

lnwallet: rename flag in handle_error_code_from_failed_htlc

This commit only renames a local variable from 'update' to 'handled' in a Lightning Network payment-failure handler. It does not change any program logic, behavior, or security properties. The change is purely cosmetic/clarifying.

8e3aed1fby f321x+8−81 file
No security note in commit
Low 45 AI analysisMessage 73 · Adequate
EL ElectrumElectrum BitcoinSoftware wallets

lnwallet: don't blacklist chan on unchanged channel update

This commit fixes a bug in Electrum's Lightning payment routing. Previously, if a payment failed because a channel didn't have enough money (a temporary liquidity issue), Electrum would incorrectly 'blacklist' that channel for an hour, eve…

Denial-of-service-like self-harm: unnecessary channel blacklisting degrades user's own payment routing capabilityLightning Network routing logic changeBehavioral fix for TEMPORARY_CHANNEL_FAILURE handling
6a97e74cby f321x+6−11 file
No security note in commit
Moderate 61 AI analysisMessage 58 · Thin
FD FoundationPassport firmware BitcoinHardware wallets

Merge pull request #651 from Foundation-Devices/firmware-update-validation-hardening

This change tightens how Passport's bootloader validates a new firmware update. Previously, if the currently-running firmware failed validation, the bootloader would skip signature checks on the incoming update and jump straight to install…

Missing signature verification on firmware update path when current firmware is invalidControl-flow change that moves verify_signature() outside conditional branchBootloader trust-boundary issue: current-firmware state influenced validation of new firmware
2e96f0afby Jacksper13+30−261 file
Vendor flagged security relevance
Informational 21 AI analysisMessage 100 · Strong
EP Elements ProjectCore Lightning BitcoinLightning Network

pyln-testing: don't let wait_for_log match its own forwarded announcement

This commit fixes a bug in Core Lightning's Python testing toolkit. When tests used an 'inline plugin' and ran with detailed (DEBUG) logging, the test helper wait_for_log() would accidentally see its own 'Waiting for...' message in the nod…

Test-framework self-match bug caused real test race and assertion failureLog forwarding filter prevents internal machinery messages from polluting node logsNo privilege escalation, remote attack surface, or cryptographic weakness introduced
ae8dee8aby Ken Sedgwick+79−13 files
No security note in commit
01
Why commit watching?

Security should leave a paper trail.

A quiet fix may be responsible caution—or it may leave users unaware that their assets were ever at risk. CommitWatch preserves the evidence, adds context, and tracks whether vendors disclose, acknowledge, and learn.

Why we built this