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
16803Commits captured
4412AI analyses
46High-risk findings · 30d
The watch feed

Changes worth understanding

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

4412 analyses
Highest risk·RSS
Low 39 AI analysisMessage 73 · Adequate
BB BitBoxBitBox02 firmware BitcoinHardware wallets

rust: initialize C output buffers

This commit fixes a class of low-level memory-safety bugs where Rust code was given buffers containing uninitialized bytes. Rust's rules require every byte of a slice to be initialized, even if the function will overwrite them. Passing uni…

Undefined behavior at C/Rust FFI due to uninitialized buffers being treated as Rust slicesPotential optimizer-dependent behavior from violating Rust slice initialization rulesHardening of cryptographic output paths (SHA-256, HMAC-SHA256, HMAC-SHA512)
511018eaby benma's agent+52−2713 files
Vendor flagged security relevance
Critical 91 AI analysisMessage 0 · Opaque
CK CoinkiteCOLDCARD firmware BitcoinHardware wallets

fixes rng

This commit fixes a critical random-number bug in COLDCARD hardware wallets. The device was accidentally using a weak, software-based fallback random generator instead of its secure hardware one when creating Bitcoin seed phrases. Because …

Weak/fallback PRNG silently linked in place of hardware RNGSeed phrase entropy reduction allowing private-key recoveryBuild-system override of upstream rng.o with empty object
ca724637by Peter D. Gray+60−711 files
Vendor flagged security relevance
Informational 15 AI analysisMessage 78 · Adequate
RB Rust Bitcoinrust-bitcoin BitcoinCryptographic libraries

hashes: add sha256::Midstate::SHA256_IV constant

This commit is a routine internal refactoring in the rust-bitcoin SHA-256 hashing code. It exposes the SHA-256 initial value (IV) as a public constant and renames an internal helper function so it can start from any midstate rather than al…

dc21841bby Andrew Poelstra+39−143 files
No security note in commit
Informational 15 AI analysisMessage 50 · Thin
RB Rust Bitcoinrust-bitcoin BitcoinCryptographic libraries

hashes: add several methods to sha256::Midstate for computing them in const contexts

This commit adds new helper methods to the SHA-256 'Midstate' type in the rust-bitcoin hashes library. These helpers let callers compute SHA-256 intermediate states inside 'const' contexts (compile-time constants). It is a routine feature …

7d8f06d2by Andrew Poelstra+80−72 files
No security note in commit
Informational 15 AI analysisMessage 73 · Adequate
EP Elements Projectlibwally-core BitcoinCryptographic librariesSoftware wallets

crypto: add ec_public_key_compress to produce a compressed pubkey

This commit adds a new public-key compression function to a cryptographic library and updates the existing decompression function so both can accept already-compressed or already-uncompressed keys as input. It also adds tests and language …

03351cc9by Jon Griffiths+92−1610 files
No security note in commit
Informational 12 AI analysisMessage 55 · Thin
EP Elements Projectlibwally-core BitcoinCryptographic librariesSoftware wallets

tests: add tests for parsing invalid der sigs

This commit only adds new test cases to check that the library correctly rejects malformed cryptographic signatures. It does not change any production code, so by itself it cannot introduce or fix a security vulnerability. It may be relate…

DER signature parsing validation is being exercisedTest vectors include R/S overflow and zero R/S casesNo functional code change in this commit
824e8a33by Jon Griffiths+11−01 file
No security note in commit
Moderate 62 AI analysisMessage 85 · Strong
EP Elements Projectlibwally-core BitcoinCryptographic librariesSoftware wallets

sign: disallow overlong der encodings and zero r or s values

This commit tightens signature validation in a cryptographic library. It now rejects malformed DER-encoded signatures that are longer than allowed, or where one of the signature numbers (R or S) is zero. Previously, the underlying secp256k…

Cryptographic input validation hardeningRejection of overlong DER-encoded ECDSA signaturesRejection of zero R or S signature components
e7894ee6by Jon Griffiths+6−11 file
Vendor flagged security relevance
Moderate 54 AI analysisMessage 73 · Adequate
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Retransmit splice_locked for 0-conf channels missing tx_signatures

This commit fixes a bug in the Lightning Dev Kit where, after a disconnection, a node could fail to retransmit a 'splice_locked' message to a peer that was still waiting for transaction signatures. Without this retransmission, the two peer…

Protocol state desynchronization between channel peers after reconnectionMissing retransmission of splice_locked for 0-conf splice channelsPotential channel unusability or stuck splice negotiation
5434015bby Wilmer Paulino+266−12 files
No security note in commit
High 74 AI analysisMessage 78 · Adequate
BB BitBoxBitBox02 firmware BitcoinHardware wallets

eth: limit EIP-712 recursion depth

This commit adds a hard limit on how deeply nested Ethereum typed-message (EIP-712) structures can be when the BitBox02 hardware wallet signs them. Without the limit, an attacker could craft a message type that refers to itself over and ov…

Adds explicit recursion-depth cap to attacker-controlled input parsingPre-validates schema roots before host callbacks or user confirmationProtects against stack exhaustion / denial-of-service from deeply nested EIP-712 types
4ccadcc0by benma's agent+196−451 file
No security note in commit
Informational 15 AI analysisMessage 62 · Adequate
TZ TrezorTrezor firmware BitcoinHardware wallets

chore(core): add trailing colon for Bolt/Caesar EIP-7702 info items

This is a cosmetic user-interface change for the Trezor hardware wallet. It adds a trailing colon to labels shown when a user is reviewing Ethereum EIP-7702 authorization or revoke actions. There is no security impact: no code logic, crypt…

243a9d21by Roman Zeyde+218−2003 files
No security note in commit
Moderate 52 AI analysisMessage 93 · Strong
EL ElectrumElectrum BitcoinSoftware wallets

lnwallet: don't blacklist htlc failures without channel update

This change fixes how Electrum's Lightning wallet reacts when a payment route fails but the failing node no longer provides a channel update message, as now allowed by the Lightning protocol spec. Previously, Electrum would permanently bla…

Denial-of-service via over-blacklisting: prior behavior could cause legitimate channels to be blacklisted, degrading payment success and potentially isolating the wallet from usable routes.Spec compliance fix: aligns Electrum with updated Lightning BOLT protocol behavior.No cryptographic bypass or funds theft signal: the change is about routing policy, not key leakage or transaction authorization.
a865e336by f321x+48−142 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