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
24348Commits captured
20920AI analyses
58High-risk findings · 30d
Active security advisories
High

Core Lightning: disable experimental features immediately

Core Lightning is investigating a potential issue affecting experimental features that may impact user funds. The vendor urges every Core Lightning operator running experimental features to disable them immediately.

Affected: Core Lightning nodes with one or more experimental features enabled. The vendor has not yet identified the affected feature, versions, trigger, or whether exploitation or fund loss has occurred.

Action: Follow the vendor instruction and disable all experimental features immediately. Check lightningd configuration and startup arguments for experimental options, restart with them disabled, and do not re-enable them until Core Lightning publishes further guidance.

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.

20920 analyses
Highest risk·RSS
Informational 15 AI analysisMessage 28 · Opaque
CK CoinkiteCOLDCARD firmware BitcoinHardware wallets

Signed for q1 release.

This commit only updates a signed release manifest file (releases/signatures.txt). It refreshes SHA-256 checksums for several changelog/history files and adds two new Q1 firmware release files, then re-signs the file with a PGP signature. …

8b1d005bby Peter D. Gray+16−141 file
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 28 · Opaque
CK CoinkiteCOLDCARD firmware BitcoinHardware wallets

update block height

This commit simply updates a stored Bitcoin blockchain height number from 969,312 to 969,345, reflecting about five hours of new blocks. There is no code logic change, no user-facing behavior change, and no security relevance.

5fa4e6a6by Peter D. Gray+2−21 file
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 0 · Opaque
CK CoinkiteCOLDCARD firmware BitcoinHardware wallets

edits

This commit only reorganizes release notes. It moves the changelog entries for firmware versions 5.6.2/1.5.2Q and 5.6.3/1.5.3Q into the historic changelog files and resets the 'next' changelog to placeholder 'tbd' entries. No source code, …

08ae1a54by Peter D. Gray+142−824 files
No security note in commit
Open full analysis →Source commit ↗
Low 46 AI analysisMessage 35 · Opaque
BB BitBoxBitBox02 firmware BitcoinHardware wallets

Merge branch 'cedwies/zeroize'

This commit hardens how the BitBox02 firmware builds BIP39 recovery phrases so the memory buffer is pre-sized and never grows. The goal is to prevent leftover copies of sensitive mnemonic words from lingering in memory after a reallocation…

Use of zeroize crate to clear sensitive mnemonic data on dropPre-allocation of fixed-size buffer to avoid heap reallocationsReplacement of format! and join with manual byte writes into a single buffer
dfbb0e66by Cedric Wiese+49−72 files
No security note in commit
Open full analysis →Source commit ↗
Low 36 AI analysisMessage 73 · Adequate
LL Lightning LabsLND BitcoinLightning Network

Merge pull request #11277 from GeorgeTsagk/maxfeeratio-ceiling

This change loosens a safety cap on Bitcoin transaction fees for a specific LND wallet RPC. Previously, callers could not allow fees larger than the transaction's total output value. Now they can opt in to a ratio up to 5x the output value…

Relaxation of a fee-ratio safety bound from 1.0 to 5.0New audit log warning when caller opts into ratio > 1.0Hard ceiling at 5.0 to catch misconfiguration
69e35917by ziggieXXX+119−74 files
No security note in commit
Open full analysis →Source commit ↗
Low 35 AI analysisMessage 98 · Strong
SS SeedSignerSeedSigner BitcoinHardware wallets

Restore why change candidacy ignores cosigners

This commit only adds explanatory comments to a function that decides whether a Bitcoin transaction output should be treated as 'change' (money going back to the user's own wallet). The code itself is not changed. The new comments warn tha…

Comment-only change restoring a security rationale for ignoring cosigners in change candidacyDescribes a potential bypass where a malformed PSBT could cause an output to skip change-level scrutinyReferences prior behavior change in PR #1032 regarding fingerprint vs derivation-path cosigner resolution
f5cbc18aby kdmukai+10−11 file
No security note in commit
Open full analysis →Source commit ↗
Low 34 AI analysisMessage 58 · Thin
XMR Monero ProjectMonero Cryptographic librariesMoneroNode implementationsPrivacy protocols

Merge pull request #11366

This change fixes a binary search in the Monero wallet that previously could loop forever or behave incorrectly if something went wrong. The old code used an unbounded 'while (true)' loop and a midpoint calculation that could overflow. The…

Unbounded loop replaced with bounded iterationInteger overflow mitigation in midpoint calculationDefensive error handling added for search failure
c16cd3f7by tobtoht+4−21 file
No security note in commit
Open full analysis →Source commit ↗
Low 36 AI analysisMessage 71 · Adequate
XMR Monero ProjectMonero Cryptographic librariesMoneroNode implementationsPrivacy protocols

Merge pull request #11345

This change upgrades the Monero RPC server's HTTP Digest Authentication to support SHA-256 and adds a command-line flag to disable the older MD5 algorithm. MD5 is considered weak by modern security standards, so this gives node operators a…

Adds SHA-256 support to HTTP Digest Auth (RFC 7616)Adds --disable-md5 flag to allow operators to reject MD5MD5 remains enabled by default for backwards compatibility
ae8f728aby tobtoht+525−239 files
No security note in commit
Open full analysis →Source commit ↗
Low 46 AI analysisMessage 50 · Thin
XMR Monero ProjectMonero Cryptographic librariesMoneroNode implementationsPrivacy protocols

wallet2: sanitize untrusted daemon status in sweep unmixable

This commit changes how a Monero wallet handles error status codes returned by a remote daemon during a cleanup operation called 'sweep unmixable.' Previously, the wallet trusted the daemon's raw status response. Now it passes that status …

Untrusted daemon input used in error-handling decisionRPC response status sanitized before being passed to error macroPattern consistent with other wallet2 hardening against malicious remote nodes
ff1157b1by selsta+1−11 file
No security note in commit
Open full analysis →Source commit ↗
Low 36 AI analysisMessage 62 · Adequate
TZ TrezorTrezor firmware BitcoinHardware wallets

feat(ethereum): Unknown vaults fetch relevant token defintion from host

This commit changes how Trezor handles Ethereum 'vault' transactions (like deposits and withdrawals from yield-bearing token vaults). Previously, the device only supported a fixed list of known vaults and rejected or blindly signed unknown…

Removal of `_is_vault_tx_safe` strict signer/receiver/owner equality check for known vaultsIntroduction of host-fetched token and display definitions for unknown vaults (`request_definitions`, `find_display_format`)New parsing of external display format to extract `const_token_address` for asset token resolution
a130a694by PrisionMike+109−604 files
No security note in commit
Open full analysis →Source commit ↗
Informational 19 AI analysisMessage 78 · Adequate
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Revert "Pass entropy source when queueing monitor event"

This commit is a straightforward code cleanup: it removes an unused 'entropy source' argument that was previously passed around when creating monitor events. The project now generates those event IDs deterministically, so the randomness so…

No security-relevant behavioral change: only removes an unused parameterDeterministic monitor event IDs already in place before this revertNo mention of vulnerability, CVE, bug bounty, or security fix in commit message
8f793eb7by Valentine Wallace+83−1447 files
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 68 · Adequate
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Revert "ChainMonitor::_entropy_source -> ::entropy_source"

This commit simply renames a field inside the ChainMonitor struct from `entropy_source` back to `_entropy_source`. The leading underscore is a Rust convention meaning 'this field is intentionally unused.' The commit message explains the fi…

e0c0bcddby Valentine Wallace+12−121 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 →