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
24267Commits captured
20890AI 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.

20890 analyses
Highest risk·RSS
Moderate 69 AI analysisMessage 66 · Adequate
XMR Monero ProjectMonero Cryptographic librariesMoneroNode implementationsPrivacy protocols

Merge pull request #11333

This Monero update hardens how public keys and transaction pubkeys are handled. It moves a low-level 'torsion clearing' routine into the core crypto library, adds checks that wallet/destination addresses are valid points on the main subgro…

Adds main-subgroup membership validation for public address keys (spend/view)Normalizes transaction public keys before use in payment-ID decryption and tx proofsMoves torsion-clearing primitive into core crypto layer to ensure consistent behavior
6f4b99abby tobtoht+178−15016 files
No security note in commit
Open full analysis →Source commit ↗
Moderate 63 AI analysisMessage 58 · Thin
XMR Monero ProjectMonero Cryptographic librariesMoneroNode implementationsPrivacy protocols

Merge pull request #11268

This Monero update fixes a networking bug where the server could accidentally block all of its worker threads while waiting for slow clients to accept data. If all workers became stuck this way, the node could stop processing any network t…

Removal of blocking condition-variable wait in network send pathFail-fast on send-queue overflow instead of parking worker threadsHTTP handler now propagates send failures and enters error state
dba16f07by tobtoht+205−3025 files
No security note in commit
Open full analysis →Source commit ↗
Moderate 59 AI analysisMessage 58 · Thin
XMR Monero ProjectMonero Cryptographic librariesMoneroNode implementationsPrivacy protocols

Merge pull request #11260

This Monero wallet patch adds stronger safety checks when a wallet prepares, signs, or loads multi-step transactions (unsigned transactions, multisig transactions, and cold-device transactions). It verifies that money going into the transa…

Adds duplicate-input detection across transaction setsAdds destination address type consistency checksAdds uint64 overflow guard for summed input amounts
66dd773eby tobtoht+265−454 files
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 #11144

This Monero update makes the network layer clean up leftover block download records when a peer connection fails or is rejected. Previously, rejected or disconnected peers could leave stale block spans in a queue, which might cause the nod…

Denial-of-service resistance: stale block spans from malicious or faulty peers could prevent a node from obtaining valid blocksState cleanup on peer disconnection/rejectionNo authentication or memory-safety bug evident in diff
ddfa2279by tobtoht+2−01 file
No security note in commit
Open full analysis →Source commit ↗
Low 46 AI analysisMessage 58 · Thin
XMR Monero ProjectMonero Cryptographic librariesMoneroNode implementationsPrivacy protocols

Merge pull request #11362

This small patch fixes a bug in the Monero wallet where, if an output had already been scanned once, the wallet would return early without clearing an error flag. In rare cases this could leave a stale 'error' state attached to a transacti…

Stale error-state propagation in wallet scanning logicMissing reset of tx_scan_info.error on cached/short-circuit code pathPotential for incorrect received-payment or scan-failure reporting
30860a26by tobtoht+3−01 file
No security note in commit
Open full analysis →Source commit ↗
Informational 16 AI analysisMessage 50 · Thin
SW SparrowSparrow Wallet BitcoinHardware integrationSoftware wallets

declare the regtest coin to trezor and bitbox02 devices on regtest, and allow bitbox02 message signing off mainnet

This commit updates a submodule called 'lark' inside the Sparrow Wallet project. The change appears to be about telling Trezor and BitBox02 hardware wallets how to handle Bitcoin's regtest network (a test-only network) and allowing message…

Submodule pointer update with no visible code diffCommit message references hardware wallet network/coin declaration changesCommit message references message signing behavior on non-mainnet networks
b2ed172fby Craig Raw+1−11 file
No security note in commit
Open full analysis →Source commit ↗
Low 43 AI analysisMessage 50 · Thin
SW SparrowSparrow Wallet BitcoinHardware integrationSoftware wallets

discard a wallet discovery result where the words or passphrase were edited while it ran

This commit fixes a timing issue in Sparrow Wallet's wallet-import screen. If a user changed their seed words or passphrase while a background 'discover wallet' scan was still running, the app could previously show results from the old (or…

stale-result race conditionuser input mutation during async operationUI state desynchronization
f81f6790by Craig Raw+6−11 file
No security note in commit
Open full analysis →Source commit ↗
Low 29 AI analysisMessage 50 · Thin
SW SparrowSparrow Wallet BitcoinHardware integrationSoftware wallets

take the bwt shutdown handle once across overlapping shutdowns, and do nothing in a shutdown that finds it taken

This commit fixes a race condition in how Sparrow Wallet shuts down its bundled Bitcoin Wallet Tracker (bwt) daemon. Previously, if two shutdown attempts overlapped, the same internal 'handle' could be used twice or cleared while still in …

Race condition in shutdown pathPotential double-use of native daemon handleSynchronization added around shared mutable pointer
a32e8653by Craig Raw+13−51 file
No security note in commit
Open full analysis →Source commit ↗
Low 42 AI analysisMessage 50 · Thin
SW SparrowSparrow Wallet BitcoinHardware integrationSoftware wallets

always rebuild the send transaction when a human readable name is pasted over the pay to address

This commit fixes a bug in Sparrow Wallet's 'Send' screen. Previously, if you pasted a human-readable payment name (like a DNS payment alias) over an already-filled recipient address, the wallet sometimes kept the old transaction details i…

UI state desynchronization between displayed recipient and constructed transactionEarly return bypassing transaction rebuild after recipient field changeHuman-readable name resolution race/caching could leave stale recipient in unsigned transaction
25db034cby Craig Raw+17−201 file
No security note in commit
Open full analysis →Source commit ↗
Low 32 AI analysisMessage 50 · Thin
SW SparrowSparrow Wallet BitcoinHardware integrationSoftware wallets

clear the max selection and revalidate the amount when a payment uri sets the send amount

This commit fixes a UI bug in Sparrow Wallet's send screen. When a user clicked a Bitcoin payment link (a 'payment URI') that included a specific amount, the wallet could leave the 'send maximum' option turned on. That combination could le…

Transaction amount/UI-state inconsistency in a Bitcoin walletPayment URI (BIP21) handling bypassing existing send-max reset logicPotential for user-confirmed transaction with unintended total amount
4c085e00by Craig Raw+14−81 file
No security note in commit
Open full analysis →Source commit ↗
Moderate 58 AI analysisMessage 50 · Thin
SW SparrowSparrow Wallet BitcoinHardware integrationSoftware wallets

leave the wallet file encryption unchanged in a queued update where the storage key has changed since it was queued

This commit fixes a bug in Sparrow Wallet where a background save of a wallet file could use the wrong encryption password. If a user added or removed a wallet password while another save was still waiting in a queue, the queued save could…

Race condition between asynchronous wallet persistence and password changePotential unintended decryption of wallet file after password is addedPotential unintended encryption with stale password after password is removed
8b440c44by Craig Raw+71−53 files
No security note in commit
Open full analysis →Source commit ↗
Low 33 AI analysisMessage 50 · Thin
SW SparrowSparrow Wallet BitcoinHardware integrationSoftware wallets

cormorant: replace a transaction entry moved within its block, hold entries sharing a block position, and stop relisting unconfirmed entries as updates

This commit fixes bookkeeping bugs in how Sparrow Wallet tracks Bitcoin transactions when they move around in a block or sit unconfirmed. Before the fix, the wallet could report the same transaction as a new 'update' every time it was poll…

Incorrect state tracking after blockchain reorganizationDuplicate/missing transaction entries due to comparator/Set semanticsUnconfirmed transactions repeatedly reported as updates
a185c91dby Craig Raw+82−73 files
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 →