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 →
34Projects watched
24970Commits captured
21232AI analyses
48High-risk findings · 30d
Active security advisories
Critical

Core Lightning v26.06.9: urgent loss-of-funds security update

Core Lightning says v26.06.9 fixes a newly reported vulnerability that can lead to loss of funds. The release also contains security fixes in channel reestablishment, splicing, HTLC shutdown handling, onion and on-chain handling, gossip range queries, runes, configuration, and several remote-crash and hardening fixes.

Affected: Every Core Lightning node running v26.06.8 or earlier is affected, according to the vendor. Technical tests for the security fixes are temporarily withheld to slow exploit development while operators upgrade.

Action: Upgrade to Core Lightning v26.06.9 immediately. Download the release from https://github.com/ElementsProject/lightning/releases/tag/v26.06.9, verify the appropriate signed SHA256 manifest and checksums for your architecture, install it, restart lightningd, and confirm the running version.

Read source ↗
Critical

Liquid Network: ~4,000 BTC withdrawn in critical peg incident

Liquid confirms that purported white-hat actors withdrew roughly 4,000 BTC (about $320 million) from its federation wallet through the SideSwap PAK. Liquid says the PAK and other federation keys were not compromised. The actors have not yet returned the funds. Independent public analysis points to a newly introduced range-proof cache-key flaw, but Liquid has not yet published its root-cause report.

Affected: The L-BTC peg and Liquid federation reserves are affected. Bridge nodes are disabled, the sidechain is paused, and exchanges have suspended L-BTC deposits and withdrawals. Liquid says other issued assets, including USDT, DePix, and RWAs, are unaffected; Bitcoin's base layer is not affected.

Action: Do not initiate Liquid peg-ins, peg-outs, swaps, or L-BTC exchange deposits or withdrawals while the network is paused. Follow official Liquid and Blockstream updates, and treat L-BTC peg exposure as impaired until reserves are restored and a verified fix and incident report are published.

Read source ↗
Critical

BTCPay Server: actively exploited LND credential theft

BTCPay confirms that an unauthenticated remote attacker could obtain LND .macaroon credentials, take control of affected LND nodes, and move funds. The vendor reports confirmed exploitation and stolen funds.

Affected: BTCPay Server versions before 2.4.2, including 2.4.2 release candidates, when used with LND. BTCPay says other Lightning implementations are not exposed to this specific credential risk.

Action: Update to BTCPay Server 2.4.2 and LND 0.21.1 immediately, review node activity, and rotate credentials. If you cannot update now, take the affected server offline.

Read source ↗
The watch feed

Changes worth understanding

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

21232 analyses
Highest risk·RSS
High 74 AI analysisMessage 85 · Strong
EP Elements ProjectElements BitcoinBitcoin sidechainsCryptographic librariesNode implementations

blindpsbt: require both range bounds to match claim in VerifyBlindValueProof

This commit fixes a bug in how Elements verifies confidential transaction value proofs. Previously, the software only checked the lower bound of a mathematical range proof against the amount shown in a transaction. That meant a proof could…

Understated output values in PSET blind value proofsIncomplete range-proof bound verificationConfidential transaction amount mismatch risk
34be37f3by Byron Hambly+5−11 file
Vendor flagged security relevance
Open full analysis →Source commit ↗
Low 48 AI analysisMessage 73 · Adequate
EP Elements ProjectElements BitcoinBitcoin sidechainsCryptographic librariesNode implementations

validation: always validate and retain dynafed header block_height

This patch fixes a bug in the Elements blockchain where dynamic-federation (dynafed) block headers could contain an incorrect block height and still be accepted, and where stored header records could be rebuilt with a different hash than t…

Header hash mismatch between accepted and reconstructed dynafed headers when legacy option disabledMissing height validation for dynafed headers when -con_blockheightinheader option is offPotential for accepting dynafed headers with incorrect block_height
c7ec63c5by Byron Hambly+12−32 files
No security note in commit
Open full analysis →Source commit ↗
Moderate 60 AI analysisMessage 78 · Adequate
EP Elements ProjectElements BitcoinBitcoin sidechainsCryptographic librariesNode implementations

dynafed: require at least four-fifths approval for parameter transition

This commit fixes a voting threshold bug in Elements' dynamic federation (dynafed) feature. The code was supposed to require at least 80% (four-fifths) of recent blocks to approve a change to federation parameters, but due to integer divis…

Consensus threshold under-approximation due to integer floor divisionPotential for dynafed parameter transition with less than intended 80% block approvalOverflow-safe ceiling formula used as remediation
bdedb12eby Byron Hambly+5−21 file
Vendor flagged security relevance
Open full analysis →Source commit ↗
Moderate 63 AI analysisMessage 73 · Adequate
EP Elements ProjectElements BitcoinBitcoin sidechainsCryptographic librariesNode implementations

headerssync: retain Elements identity and proof fields

This commit fixes a bug in how Elements nodes temporarily store block headers during initial sync. The node was stripping out Elements-specific fields (block height, proof, dynamic federation parameters, and signblock witness) when compres…

Header integrity loss in sync path: reconstructed header hash would not match received headerLoss of proof and signblock witness data needed for signed/dynafed validationPotential denial-of-service via sync failure or validation rejection of otherwise valid headers
fef1a30bby Byron Hambly+26−32 files
No security note in commit
Open full analysis →Source commit ↗
Moderate 62 AI analysisMessage 73 · Adequate
EP Elements ProjectElements BitcoinBitcoin sidechainsCryptographic librariesNode implementations

blindpsbt: refuse to blind a PSET output with no amount

This commit fixes a crash/undefined-behavior bug in the Elements wallet's confidential-transaction blinding code. When processing a specially crafted Partially Signed Elements Transaction (PSET), the software would blindly use an output am…

Undefined behavior from dereferencing a disengaged std::optionalMissing input validation on optional PSET fieldPotential denial-of-service/crash via crafted PSET
066ecf6eby Byron Hambly+8−01 file
Vendor flagged security relevance
Open full analysis →Source commit ↗
Moderate 62 AI analysisMessage 73 · Adequate
EP Elements ProjectElements BitcoinBitcoin sidechainsCryptographic librariesNode implementations

blindpsbt: reject off-curve blinding pubkey before ECDH

This commit fixes a crash bug in Elements' confidential-transaction blinding code for PSBTs (Partially Signed Bitcoin Transactions). A malformed, attacker-chosen 'blinding public key' that is not actually a valid point on the cryptographic…

Off-curve / invalid elliptic-curve public key reaches ECDHAssertion abort (DoS / process termination) via crafted inputMissing input validation in PSBT blinding path compared to non-PSBT path
f634a3a4by Byron Hambly+7−01 file
Vendor flagged security relevance
Open full analysis →Source commit ↗
High 74 AI analysisMessage 73 · Adequate
EP Elements ProjectElements BitcoinBitcoin sidechainsCryptographic librariesNode implementations

blindpsbt: return error instead of asserting on surjection proof failure

This commit fixes a denial-of-service bug in Elements' confidential asset handling. Previously, a malformed transaction file (PSET) could trigger a hard program crash (assert/abort) by feeding in mismatched cryptographic tags. The patch tu…

assert-to-error conversiondenial-of-service vector from untrusted PSET inputsurjection proof failure on attacker-chosen tags/generators
b0aba619by Byron Hambly+9−21 file
Vendor flagged security relevance
Open full analysis →Source commit ↗
Low 42 AI analysisMessage 79 · Adequate
TZ TrezorTrezor firmware BitcoinHardware wallets

fix(core/rust): adjust menu item limits to prevent overflow errors

This commit fixes a capacity mismatch in the Trezor hardware wallet's on-screen menus. A global limit allowed up to 6 menu entries, but the internal storage for two menu layouts only held 5. When a 6-item menu was built, the code would pan…

Bounded vector capacity mismatch with global menu item limitRuntime panic (unwrap!) on menu item overflowCompile-time const assertion added to prevent regression
c81e063eby Vojtěch Nevřela+17−33 files
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 35 · Opaque
BB BitBoxBitBox02 firmware BitcoinHardware wallets

Add testboard openocd config

This commit adds a configuration file for OpenOCD, a debugging tool used during hardware development and testing. It tells the debugger how to connect to an STM32U5 test board using a J-Link adapter. There is no change to firmware code, no…

c5984b41by Niklas Dusenlund+16−01 file
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 85 · Strong
TZ TrezorTrezor firmware BitcoinHardware wallets

feat(core): report `Ethereum_EIP7702` from `GetFeatures`

This commit simply advertises that Trezor Model T / Core devices support a new Ethereum feature called EIP-7702 when a host asks the device for its capabilities. It does not change how transactions are signed, authorized, or validated. The…

e4a7d054by Roman Zeyde+3−22 files
No security note in commit
Open full analysis →Source commit ↗
Informational 19 AI analysisMessage 78 · Adequate
RB Rust Bitcoinrust-bitcoin BitcoinCryptographic libraries

units: Replace NumOpError internals with MathErrorKind

This commit is a code-quality refactor inside the rust-bitcoin library's 'units' crate. It changes how arithmetic errors (overflow, divide-by-zero, remainder-by-zero) are described internally, making error messages more specific and preser…

Refactor of error representation only; no new arithmetic bounds checks introducedExisting checked_add/checked_sub/checked_mul/checked_div/checked_rem paths remain unchangedError-preservation change in AddAssign/SubAssign could be considered a minor bugfix for error reporting but does not alter overflow/division-by-zero protection
eb8cbe95by Mitchell Bagot+262−996 files
No security note in commit
Open full analysis →Source commit ↗
Informational 18 AI analysisMessage 70 · Adequate
CW Cake WalletCake Wallet / Monero.com MoneroPrivacy protocolsSoftware wallets

feat: add fallback locktime support in PSBT deserialization (#3583)

This commit adds one line to make sure a fallback locktime value is copied from a Bitcoin transaction into a PSBT (Partially Signed Bitcoin Transaction) data structure during parsing. A locktime is a standard Bitcoin field that controls wh…

Adds missing PSBT v2 global field mappingNo input validation or bounds checking addedNo vendor security language in commit title or message
df87bab8by Konstantin Ullrich+1−01 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 →