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
17865Commits captured
17284AI analyses
99High-risk findings · 30d
The watch feed

Changes worth understanding

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

17284 analyses
Highest risk·RSS
Informational 15 AI analysisMessage 47 · Thin
LL Lightning LabsLND BitcoinLightning Network

docs: update release notes

This commit only edits the release notes document. It describes a previously merged code change that tightens validation of time-lock settings for Lightning payments, but the commit itself contains no code changes and therefore does not al…

Release notes mention a prior change that validates final-hop HTLC CLTV expiry and caps per-channel TimeLockDelta at 2016No code, build, configuration, or cryptographic changes are present in this commit
bffae65aby ziggie+11−01 file
No security note in commit
Open full analysis →Source commit ↗
Moderate 59 AI analysisMessage 73 · Adequate
LL Lightning LabsLND BitcoinLightning Network

contractcourt: align final htlc handling in contest resolver

This change fixes a mismatch between how Lightning Network payment checks are done while a payment is still flowing through the network versus when the channel is forced on-chain. Previously, the on-chain resolver could settle an exit-hop …

On-chain resolver now rejects final-hop HTLCs with mismatched amount or expiry, preventing settlement of non-conforming HTLCs that previously could be settled with only a preimageAligns on-chain and off-chain final-hop handling, reducing a class of inconsistency bugsCustom HTLC amount validation remains delegated to auxiliary channel logic, preserving existing extension behavior
03ca45a2by ziggie+207−86 files
No security note in commit
Open full analysis →Source commit ↗
Low 44 AI analysisMessage 68 · Adequate
LL Lightning LabsLND BitcoinLightning Network

config: check cltv expiry policy range

This commit adds validation checks to make sure a Lightning node's configured CLTV expiry limits and advertised channel policies stay within the same supported range. Previously, a node operator could configure settings that were internall…

Input validation added for configuration and RPC policy parametersPrevents advertised forwarding CLTV delta from exceeding node acceptance limitPrevents local max-cltv-expiry from being set below default time lock delta or above protocol maximum
b8e861feby ziggie+123−83 files
No security note in commit
Open full analysis →Source commit ↗
Informational 19 AI analysisMessage 59 · Thin
EL ElectrumElectrum BitcoinSoftware wallets

trezor: support Safe 7

This commit adds support for the new Trezor Safe 7 hardware wallet to Electrum. It introduces a pairing step where the user enters a 6-digit code shown on their device to establish an encrypted, authenticated connection. The change is a fe…

New pairing flow introduces user-supplied code transmitted to hardware deviceCross-thread cancellation disabled for THP models, which may affect responsiveness but is documented as a trezorlib limitationPairing state assertions added before accessing device features
1547c5b4by Roman Zeyde+133−193 files
No security note in commit
Open full analysis →Source commit ↗
Low 30 AI analysisMessage 97 · Strong
TZ TrezorTrezor firmware BitcoinHardware wallets

fix(core): fix `AVOID_RESTARTING_FOR` handling in THP

This commit fixes a bug in the Trezor hardware wallet's new THP (Trezor Host Protocol) message handling. Previously, the code ignored a special signal that tells the device not to restart the current flow when certain harmless messages (li…

Workflow interruption / denial-of-service: recovery flow could be aborted by a benign GetFeatures messageProtocol state-handling inconsistency between v1 and THPReturn-value propagation fix for AVOID_RESTARTING_FOR sentinel logic
7b570c25by Roman Zeyde+5−92 files
No security note in commit
Open full analysis →Source commit ↗
Informational 11 AI analysisMessage 72 · Adequate
TZ TrezorTrezor firmware BitcoinHardware wallets

test(core): make sure recovery flow is not restarted on `GetFeatures`

This commit only adds a new automated test. It checks that asking a Trezor device for its features during a recovery process does not accidentally restart the recovery flow. No actual device code is changed, so this is a test-only addition…

Test-only commit with no firmware code changesNew regression test for recovery flow restart behavior on GetFeaturesReferences AVOID_RESTARTING_FOR behavior in comment
587e791aby Roman Zeyde+113−02 files
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 87 · Strong
TZ TrezorTrezor firmware BitcoinHardware wallets

test(core): use capability name when skipping a test

This is a tiny test-only change that makes a skip message more readable. Instead of printing a numeric capability index, it now prints the capability's human-readable name. It does not touch any wallet firmware, cryptography, or device beh…

3b8714a5by Roman Zeyde+1−11 file
No security note in commit
Open full analysis →Source commit ↗
Informational 20 AI analysisMessage 77 · Adequate
TZ TrezorTrezor firmware BitcoinHardware wallets

fix(solana): show the program id for unknown programs in the tx details view instead of a generic "Unsupported program" label.

This change improves the Trezor hardware wallet's Solana transaction confirmation screen. When a transaction contains an unknown program (smart contract), the device now shows the actual program ID instead of a generic 'Unsupported program…

UI/UX hardening: improved transparency for unknown Solana programs during transaction signingNo cryptographic, memory, or parsing changes observedNo privilege escalation, buffer handling, or authorization logic modified
7ea33494by Sammy Harris+96−244 files
No security note in commit
Open full analysis →Source commit ↗
Moderate 64 AI analysisMessage 73 · Adequate
LL Lightning LabsLND BitcoinLightning Network

htlcswitch+invoices: align final-hop CLTV handling

This commit tightens the checks that Lightning nodes perform when they are the final recipient of a payment. It makes sure the payment's time-lock expiry is not unreasonably far in the future, matching the same limit already used when forw…

Adds explicit upper-bound validation for final-hop CLTV expiryAdds explicit upper-bound validation for forwarding CLTV deltaFixes underflow-prone subtraction in CheckHtlcForward by checking incomingTimeout < outgoingTimeout before computing delta
c5992d38by ziggie+444−208 files
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 95 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

test: add interface_gui.py to test bitcoin-gui startup via RPC

This commit adds a new automated test that starts the Bitcoin GUI in a headless mode and checks it can be shut down by a remote command. It also makes a small code change so the GUI does not try to load custom fonts when running in the min…

aa01721cby Ryan Ofsky+79−88 files
No security note in commit
Open full analysis →Source commit ↗
Moderate 64 AI analysisMessage 73 · Adequate
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Ignore stale splice initial commitment_signed

This patch fixes a bug in the Lightning Dev Kit where a delayed message from a peer could accidentally force-close a live payment channel. During a failed 'splice' (a way to resize a channel), the peer might already have sent a signature f…

Force-closure of a live Lightning channel due to stale signature validationRace condition between splice cancellation and in-flight commitment_signedIncorrect signature validation against post-abort channel state
b3e2dc8dby Wilmer Paulino+81−02 files
Vendor flagged security relevance
Open full analysis →Source commit ↗
Low 27 AI analysisMessage 83 · Strong
BC Bitcoin Corelibsecp256k1 BitcoinCryptographic libraries

field: correct fe_equal's b magnitude bound

This commit fixes an off-by-one error in the documented and runtime-checked input limit for a low-level math helper called secp256k1_fe_equal. The function compares two finite-field values for equality. It first negates one input (which te…

Off-by-one in cryptographic field-element magnitude boundInternal invariant violation in secp256k1_fe_equalAddition-after-negation magnitude accounting error
994b3501by Lőrinc+15−23 files
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 →