CommitWatch RSS
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.

Explore the watch feed ↓See how scoring works →
24Projects watched
17782Commits captured
17251AI analyses
98High-risk findings · 30d
The watch feed

Changes worth understanding

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

17251 analyses
Highest risk·RSS
Informational 12 AI analysisMessage 73 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

common/close_tx: add `create_simple_close_tx()` for `option_simple_close`

This commit adds a new helper function that builds a specific kind of Bitcoin closing transaction used by the Core Lightning node software when two channel peers agree on a simpler cooperative close. It follows the BOLT 3 specification, se…

New feature code, not a patch of existing vulnerable codeFollows explicit BOLT 3 specification for option_simple_closeUses standard nSequence 0xFFFFFFFD RBF signalling
e362c3bbby Níckolas Goline+112−02 files
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 91 · Strong
EP Elements ProjectCore Lightning BitcoinLightning Network

tests: `add option_simple_close` integration tests

This commit only adds new automated tests for an upcoming Lightning protocol feature called option_simple_close. It does not change any production code. Most of the new tests are explicitly marked as expected to fail (xfail) because the fe…

7640ab6bby Níckolas Goline+243−01 file
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 50 · Thin
TZ TrezorTrezor firmware BitcoinHardware wallets

feat(clear_signing, ethereum) add new provider names.

This commit is a routine feature update for Trezor's Ethereum 'clear signing' feature. It adds human-readable names for more DeFi and staking providers (like Lido, Morpho, Kiln) and makes the address lookup aware of which blockchain networ…

230cfe37by PrisionMike+87−82 files
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 38 · Opaque
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

depends: Boost 1.91.0-1

This commit simply updates the Boost dependency used by Bitcoin Core's build system from version 1.90.0 to version 1.91.0-1, including the new download URL and cryptographic hash. There is no indication in the commit itself that this fixes…

fb1d152cby fanquake+2−21 file
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 45 · Thin
EL ElectrumElectrum BitcoinSoftware wallets

qml: add myself to About page

This commit simply adds a person's name to the About page in Electrum's QML (mobile-style) user interface. It is a routine contributor-credit update with no security relevance.

d24c91e8by f321x+1−11 file
No security note in commit
Open full analysis →Source commit ↗
Low 30 AI analysisMessage 95 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

ln: add awaiting_trampoline_forwards to accumulate inbound MPP

This commit adds a new internal bookkeeping map for a not-yet-enabled feature called trampoline routing. The commit itself is defensive: it documents that the new map is intentionally not saved to disk and warns that using it in production…

New non-persistent state map for pending trampoline MPP HTLCsCommit message explicitly warns of force-close risk if used in production before persistence/restart logic is addedTrampoline HTLCs are currently rejected earlier in the lifecycle, mitigating the documented risk
bfb4acb8by Carla Kirk-Cohen+63−01 file
Vendor flagged security relevance
Open full analysis →Source commit ↗
Moderate 60 AI analysisMessage 85 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

ln: use outer onion values for trampoline NextPacketDetails

This change fixes how trampoline-style Lightning payments decide how much money and when (time lock) to forward to the next hop. Previously the code used values from the inner trampoline onion, which could differ from what the forwarding n…

Amount/CLTV mismatch between outer and inner trampoline onionsRemoval of blinded-forward amount/cltv recalculation in favor of outer onion valuesTrampoline forwarding logic change in payment onion decoding
52f2394aby Carla Kirk-Cohen+6−151 file
Vendor flagged security relevance
Open full analysis →Source commit ↗
Low 29 AI analysisMessage 73 · Adequate
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

ln: store next trampoline amount and cltv in PendingHTLCRouting

This commit changes how Lightning trampoline payments are tracked internally. It stores the amount and expiry time that the next trampoline hop expects, so the node remembers them when forwarding a payment. The change looks like a correctn…

Previously computed next-hop amount/CLTV values were intentionally discarded, suggesting a latent routing-state gap.New fields are marked `required` in serialization, which can affect backward compatibility and persistence recovery.Trampoline forwarding involves fee and timelock checks; missing expected values could theoretically lead to incorrect forwarding decisions.
e14a28ddby Carla Kirk-Cohen+17−22 files
No security note in commit
Open full analysis →Source commit ↗
Moderate 59 AI analysisMessage 85 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

ln: use outer onion values in PendingHTLCInfo for trampoline

This commit fixes a bug in how trampoline routing nodes validate incoming Lightning payments. Previously, the node used values from the inner (trampoline) onion, which included the fee budget, to check whether it received the correct amoun…

Use of incorrect payment amount source for validation (inner vs outer onion)Potential fee-budget underpayment by upstream peerFix changes which amount value is stored in pending HTLC state for trampoline forwarding
c58d1d83by Carla Kirk-Cohen+5−51 file
Vendor flagged security relevance
Open full analysis →Source commit ↗
Low 25 AI analysisMessage 68 · Adequate
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

ln: store incoming mpp data in PendingHTLCRouting

This commit is a small code change that stores extra multi-path payment (MPP) information when a trampoline forward is received. It appears to be a preparatory step for validating incoming payment parts before forwarding them onward. There…

Adds MPP data plumbing for trampoline forwardsNo validation logic is visible in this commitNo mention of security, CVE, bug, or vulnerability in commit message
a1260ed1by Carla Kirk-Cohen+12−52 files
No security note in commit
Open full analysis →Source commit ↗
Moderate 59 AI analysisMessage 85 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

ln: use total_msat to calculate the amount for our next trampoline

This commit fixes a bug in how the Lightning Dev Kit calculates the amount to forward when acting as a trampoline node for blinded multi-path payments. Previously, the code used the amount from a single incoming payment packet, which could…

Logic error in payment amount validation for blinded trampoline forwardsMulti-path payment (MPP) aggregation not accounted for in forward amount calculationPotential incorrect HTLC rejection or under-forwarding for trampoline payments
3e162db9by Carla Kirk-Cohen+5−11 file
No security note in commit
Open full analysis →Source commit ↗
Informational 23 AI analysisMessage 85 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

ln: remove incoming trampoline secret from HTLCSource

This commit removes a redundant 32-byte shared secret field from an internal data structure used when forwarding trampoline payments in the Lightning Dev Kit. The developers realized the secret was already stored inside each previous hop's…

Removes redundant secret field from in-memory/persisted stateChanges TLV serialization layout for HTLCSource::TrampolineForwardBreaking persistence change acknowledged by commit author
816b866dby Carla Kirk-Cohen+10−221 file
No security note in commit
Open full analysis →Source 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 →