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 →
23Projects watched
16881Commits captured
16824AI analyses
83High-risk findings · 30d
The watch feed

Changes worth understanding

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

16824 analyses
Highest risk·RSS
Low 30 AI analysisMessage 68 · Adequate
BB BitBoxBitBox02 firmware BitcoinHardware wallets

api: disable BitBoxSync by default

This commit turns off a feature called BitBoxSync by default. Unless a developer explicitly enables it during build, any request to use BitBoxSync will now receive a standard 'disabled' error. The change is framed as temporary while API ch…

Feature-gates an API that was previously reachable by defaultReturns Error::Disabled for requests to the gated APICommit message describes the change as temporary pending API changes
93d36fc8by benma's agent+7−02 files
No security note in commit
Open full analysis →Source commit ↗
Low 42 AI analysisMessage 70 · Adequate
BB BitBoxBitBox02 firmware BitcoinHardware wallets

rust: bound executor queue

This commit replaces an unbounded task queue inside the BitBox02 firmware's Rust executor with a fixed 16-slot ring buffer. It also adds a hard limit of 16 active tasks and protects queue access with critical sections so interrupt-driven c…

Replaced unbounded queue with fixed-capacity ring buffer to prevent memory exhaustionRemoved allocation from scheduling/wake path, including interrupt contextAdded critical-section synchronization between wakers and main-loop executor
b99e200aby benma's agent+186−285 files
No security note in commit
Open full analysis →Source commit ↗
Informational 17 AI analysisMessage 83 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

fuzz: allow empty-channel force close with in-flight payments

This commit changes a fuzz-testing harness, not the production Lightning node code. It loosens a test rule so the fuzzer can simulate force-closing a channel that has no pending payments of its own, even if other channels in the test still…

Fuzz harness behavior change onlyNo modifications to production consensus, cryptography, or networking codeNo privilege boundary crossed
dbb12502by Joost Jager+32−71 file
No security note in commit
Open full analysis →Source commit ↗
Informational 12 AI analysisMessage 78 · Adequate
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

fuzz: require expected payment failures

This commit is a fuzz-test hardening change, not a fix for a live security bug. It makes an internal test harness stricter about when a simulated Lightning payment is allowed to fail, so the fuzzer can catch unexpected failure paths. It do…

Fuzz-test harness hardening onlyNo production code paths changedNo real-fund handling modified
090181b1by Joost Jager+179−81 file
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 78 · Adequate
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

fuzz: derive routes from payment paths

This commit is a refactoring of internal fuzz-test code only. It changes how fake Lightning payment routes are built in a test harness so that route construction uses a single shared helper instead of hand-written route structures. There i…

5b8a8bf7by Joost Jager+96−1111 file
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 78 · Adequate
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

fuzz: centralize payment send tracking

This is a small internal cleanup in a fuzz-testing file. It renames a helper function and routes a few bookkeeping calls through a single new helper. There is no change to production code, no change to user-facing behavior, and no security…

671ccb0dby Joost Jager+31−431 file
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 78 · Adequate
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

fuzz: track payment send resolutions

This commit changes an internal fuzz-testing harness in the rust-lightning project. It tightens how the test tracker records and resolves simulated Lightning payments, and adds assertions so the test harness panics if it sees unexpected pa…

New assertions in test-only code (panic on untracked payment)Stricter state-machine tracking in fuzz harnessNo changes to cryptographic, networking, or consensus code
fed08b48by Joost Jager+60−371 file
No security note in commit
Open full analysis →Source commit ↗
Informational 13 AI analysisMessage 78 · Adequate
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

fuzz: prepare payment failure tracking

This commit only changes internal fuzz-testing code in rust-lightning. It adds plumbing to track the minimum final CLTV expiry for simulated payments and threads a PaymentTracker through more test helpers. The commit message explicitly say…

e704b74eby Joost Jager+71−101 file
No security note in commit
Open full analysis →Source commit ↗
Informational 13 AI analysisMessage 78 · Adequate
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

fuzz: retain channel ids in payment paths

This commit changes internal fuzz-testing code only. It adds extra bookkeeping so that simulated payment paths remember both a short channel ID and a channel ID. The commit message explicitly says the new fields are not used yet and that t…

No security-relevant code change in production pathsChange is confined to fuzz test harnessCommit message describes change as preparatory and explicitly notes new fields are not interpreted yet
a01754d7by Joost Jager+51−181 file
No security note in commit
Open full analysis →Source commit ↗
Low 25 AI analysisMessage 76 · Adequate
AQ ACINQEclair BitcoinLightning Network

Reject `start_batch` with size <= 1 (#3333)

This commit tightens validation of a Lightning network peer message called start_batch. Previously, the software only rejected batch sizes larger than 20. Now it also rejects batch sizes of 0 or 1, which the protocol specification says mus…

Protocol compliance fix for BOLT 2 start_batch validationAdds lower-bound validation that was previously missingPrevents acceptance of degenerate batch sizes (0, 1)
e4e1a19dby Bastien Teinturier+25−32 files
No security note in commit
Open full analysis →Source commit ↗
Moderate 60 AI analysisMessage 88 · Strong
AQ ACINQEclair BitcoinLightning Network

Don't store duplicate settlement messages (#3336)

This patch fixes a bug in Eclair's Lightning payment channel code. If a buggy peer (or internal message queue bug) sent the same HTLC settlement message twice, Eclair would store the duplicate in its list of pending remote changes. Later, …

Avoids unilateral channel force-close due to duplicate settlement messagesPrevents duplicate remote proposal accumulation in commitment changesMaintains relay of first valid settlement to downstream HTLC origin
3eebbe96by Bastien Teinturier+51−02 files
Vendor flagged security relevance
Open full analysis →Source commit ↗
Informational 19 AI analysisMessage 77 · Adequate
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

util: LineReader - Don't include newline and acknowledge single-char \r

This is a small code cleanup in Bitcoin Core's line-reading utility. It changes how the reader strips newline characters from input lines. The old code tried to remove both '\n' and '\r' from the end of a line after the fact; the new code …

Input parsing boundary changeLine termination handling changeNo explicit security claim in commit message
e8eaa80cby Hodlinator+4−31 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 →