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.

24Projects watched
18178Commits captured
17450AI analyses
103High-risk findings · 30d
The watch feed

Changes worth understanding

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

17450 analyses
Highest risk·RSS
Informational 11 AI analysisMessage 65 · Adequate
EL ElectrumElectrum BitcoinSoftware wallets

lnworker: export_channel_backup: document design in more detail

This commit only adds explanatory comments to existing code. It does not change any behavior. The new comments describe how encrypted lightning channel backups work in Electrum and note that the wallet's public key (xpub) is somewhat sensi…

Documentation-only changeMentions sensitivity of xpub + encrypted channel backupAdds TODO about hardened-path derived secret for future improvement
6f31136eby SomberNight+11−31 file
No security note in commit
Informational 22 AI analysisMessage 99 · Strong
TZ TrezorTrezor firmware BitcoinHardware wallets

fix(core/caesar): allow GC previous allocations at `confirm_payment_request()`

This commit fixes an out-of-memory (OOM) crash during Ethereum payment-request signing on the Trezor Safe 3 (T2B1). The fix wraps UI layout construction in a temporary async task so the device's garbage collector can reclaim memory sooner.…

Out-of-memory (OOM) crash on a hardware wallet during transaction signingFix enables earlier garbage collection of UI allocationsCrash reproducible by an existing device test for Ethereum payment requests
c5d7697fby Roman Zeyde+37−331 file
No security note in commit
Moderate 62 AI analysisMessage 73 · Adequate
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Fix string slicing in TXT record validation

This commit fixes a crash bug in how rust-lightning checks DNS text records embedded in private onion messages. The old code used string slicing that could panic if a TXT record contained multi-byte characters and the prefix length landed …

panic due to non-character-boundary string slicingdenial-of-service vector via crafted onion message TXT recordBIP 353 DNSSEC resolution input validation
ae852b58by Matt Corallo+2−11 file
Vendor flagged security relevance
Moderate 61 AI analysisMessage 78 · Adequate
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Get real rand in `possiblyrandom` on supported platforms w/o feat

This commit fixes a bug in a small helper crate called `possiblyrandom` used by the Lightning Dev Kit. The crate was supposed to return real random bytes on normal operating systems, but due to a Cargo.toml misconfiguration it was silently…

Cryptographic randomness source silently disabled, producing all-zero outputConditional compilation mismatch between Cargo.toml target cfg and source feature cfgSecurity-relevant helper crate (`possiblyrandom`) used by Lightning Dev Kit
b7c9935bby Matt Corallo+9−61 file
Vendor flagged security relevance
Moderate 52 AI analysisMessage 68 · Adequate
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Truncate logged peer message strings

This commit fixes a minor denial-of-service issue where a malicious peer could send very long text strings inside Lightning network messages (errors, warnings, transaction aborts). Those strings were written to log files without any length…

Counterparty-controlled strings logged without length limitsInconsistent sanitization across logging sites for untrusted peer dataPotential log-file bloat / disk-filling from malicious peer messages
e2f611e9by Elias Rohrer+97−123 files
Vendor flagged security relevance
High 76 AI analysisMessage 80 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Reject pre-epoch `LSPSDateTime` at parse time

This commit fixes a remote denial-of-service bug in rust-lightning's LSPS (Lightning Service Provider Specification) code. An attacker could send a specially crafted date string from before 1970 (like "1900-01-01T00:00:00Z") in certain pee…

Remote-triggerable panic (DoS) via peer-controlled inputInteger conversion panic: i64 negative timestamp coerced to u64 with .expect()Input validation bypass: serde transparent deserialization skipped custom parser
837763a6by Elias Rohrer+29−31 file
Vendor flagged security relevance
Low 47 AI analysisMessage 68 · Adequate
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Return optional recovered BOLT11 payee keys

This commit changes how a Bitcoin Lightning invoice library exposes the payee's public key. Previously, a function called recover_payee_pub_key always returned a public key, even when mathematically recovering it from the invoice signature…

API semantics changed from non-optional to optional return for a cryptographic recovery operationPrevious behavior could silently return an explicitly included key instead of a recovered keyNew behavior surfaces recovery failure rather than masking it
851d03f3by Elias Rohrer+23−131 file
No security note in commit
Moderate 63 AI analysisMessage 73 · Adequate
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Use BOLT11 invoice payee keys for payment params

This commit fixes a bug in how Lightning payment parameters are built from BOLT11 invoices. Previously, the code always tried to recover the payee's public key from the invoice signature, even when the invoice already explicitly included t…

BOLT11 invoice payee public key derivation changed from signature recovery to explicit key preferencePaymentParameters::from_bolt11_invoice now uses get_payee_pub_key instead of recover_payee_pub_keyTest cases demonstrate handling of invoices with valid included payee key but invalid recovery ID
06393ebaby Elias Rohrer+105−93 files
No security note in commit
Moderate 51 AI analysisMessage 45 · Thin
RB Rust Bitcoinrust-bitcoin BitcoinCryptographic libraries

fee_rate: fix mul_by_weight to use ceil not floor

This commit fixes a rounding bug in a Bitcoin fee calculation. The code previously rounded the fee rate down to the nearest whole number before multiplying by transaction weight, which could cause the calculated fee to be slightly too low.…

Rounding direction changed from floor to ceil in fee computationPotential for computed fee to be slightly below required amount before fixTransaction fee insufficiency can lead to network rejection or delayed confirmation
8c7584caby Muhammad+1−11 file
No security note in commit
Informational 12 AI analysisMessage 55 · Thin
RB Rust Bitcoinrust-bitcoin BitcoinCryptographic libraries

fee_rate: add test for mul_by_weight rounding

This commit only adds a new unit test that checks how a fee rate multiplied by a transaction weight rounds up. It does not change any production code, so it cannot introduce or fix a security vulnerability by itself. It may be related to a…

517705a0by Muhammad+8−01 file
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