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
24880Commits captured
21196AI analyses
59High-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.

21196 analyses
Highest risk·RSS
Low 33 AI analysisMessage 91 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

Merge bitcoin/bitcoin#36218: build: avoid `pipe2` on Darwin (for now)

This is a build-system fix for Bitcoin Core on macOS. Apple's upcoming developer tools report that a function called `pipe2` is available, but older macOS versions do not actually provide it at runtime, which would cause Bitcoin Core to cr…

No security-relevant code change: only build-system feature detection logicNo memory safety, cryptography, network, or consensus code touchedCrash-on-launch on older macOS is a denial-of-service-like symptom, but caused by toolchain/SDK availability mismatch, not by an attacker
51b540c5by merge-script+3−11 file
No security note in commit
Open full analysis →Source commit ↗
Low 46 AI analysisMessage 58 · Thin
EL ElectrumElectrum BitcoinSoftware wallets

Merge pull request #10945 from accumulator/stale_utxo_data_fixes

This commit fixes cases where Electrum's wallet cache could hold onto outdated information about coins and transactions after blockchain reorganizations or mempool changes. For example, if a transaction was previously thought to be mined b…

stale cached state after reorg/mempool evictionincorrect confirmation metadata displayed to userscache invalidation added at multiple state transitions
e20b24c0by Felix+132−239 files
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 60 · Adequate
EL ElectrumElectrum BitcoinSoftware wallets

transaction: add set_mined_info setter to TxInput

This commit is a simple code cleanup: it replaces two repeated lines that set a transaction input's block height and position with a single helper method called set_mined_info. There is no change in behavior, no bug fix, and no security re…

61f71acbby f321x+7−73 files
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 60 · Adequate
EL ElectrumElectrum BitcoinSoftware wallets

qt/util: consolidate short_id check pattern

This is a small internal code cleanup in the Electrum Bitcoin wallet. It moves the logic that builds a compact transaction identifier (like '123x4') into one shared helper method, and removes a duplicate helper class. There is no user-faci…

2af9e26aby f321x+7−133 files
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 91 · Strong
RB Rust Bitcoinrust-bitcoin BitcoinCryptographic libraries

Merge rust-bitcoin/rust-bitcoin#6845: ci: install rbmt from crates.io in replay job

This is a routine CI maintenance fix. It changes how an internal developer tool (cargo-rbmt) is installed during an automated fuzzing replay job, switching from a pinned git revision to a version number read from the project's Cargo.toml. …

2f3cf11bby Andrew Poelstra+3−51 file
No security note in commit
Open full analysis →Source commit ↗
Moderate 58 AI analysisMessage 62 · Adequate
TZ TrezorTrezor firmware BitcoinHardware wallets

feat(clear_signing): tuple supports abi values instead of parsers directly

This commit refactors how Trezor firmware parses Ethereum 'clear signing' data so that tuple/struct fields can themselves contain nested tuples or arrays, instead of only simple leaf values. The change removes a previous restriction and up…

Parser now supports nested tuples and arrays, reducing risk of mis-parsing valid ABI payloads that were previously unsupportedOld empty-tuple guard comment that cited prevention of unbounded parse loop was removed; rejection still occurs via other pathsTuple field size calculation changed from fixed word stride to sum of field head sizes, fixing incorrect offsets for nested static structs
8760d111by PrisionMike+112−654 files
No security note in commit
Open full analysis →Source commit ↗
Low 42 AI analysisMessage 50 · Thin
SW SparrowSparrow Wallet BitcoinHardware integrationSoftware wallets

size an unresolved silent payment output as the p2tr output it becomes when deriving the fee

This commit fixes how Sparrow Wallet calculates transaction size and fees for silent-payment transactions before they are fully signed. Previously, the wallet treated an unresolved silent-payment output as if it took up no space, which mad…

Silent payment output script not yet resolved at fee-estimation timeFee-rate display and high-fee warning used under-sized transactionPotential for user to broadcast a transaction with a higher effective fee rate than shown
3dc99b6bby Craig Raw+27−74 files
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 60 · Adequate
TZ TrezorTrezor firmware BitcoinHardware wallets

tests(clear_signing): unit tests for .from_proto()

This commit only adds new unit tests for an existing Ethereum clear-signing decoder. It does not change any production firmware code, so it cannot introduce a security vulnerability or fix one directly. The tests document how the decoder c…

2aec9696by PrisionMike+301−11 file
No security note in commit
Open full analysis →Source commit ↗
Informational 12 AI analysisMessage 0 · Opaque
MG MAGIC GrantsSkylight Wallet MoneroPrivacy protocolsSoftware wallets

Cleanup

This commit is a routine code cleanup. It removes several unused or dead utility files, widgets, and tests, and moves one small status icon definition into the screen that uses it. There is no change to how the app handles money, keys, net…

5e55b6a3by Keeqler+3−66611 files
No security note in commit
Open full analysis →Source commit ↗
Informational 19 AI analysisMessage 50 · Thin
SW SparrowSparrow Wallet BitcoinHardware integrationSoftware wallets

recognise a silent payments descriptor when matching label origins and reading a descriptor pdf

This commit adds support for a newer Bitcoin address format called 'silent payments' when Sparrow Wallet reads wallet labels from files or PDFs. Before this change, the wallet could fail to recognize silent-payment descriptors, so labels t…

Silent payment descriptor parsing now recognized in PDF import pathOrigin matching extended to include silent payment scan addressesNew test cases assert label import/round-trip for silent payment wallets
10b001e8by Craig Raw+87−44 files
No security note in commit
Open full analysis →Source commit ↗
Moderate 59 AI analysisMessage 50 · Thin
SW SparrowSparrow Wallet BitcoinHardware integrationSoftware wallets

fetch all nodes on a silent payments refresh when a reorg has invalidated any of them

This commit fixes a bug in Sparrow Wallet's handling of silent payments after a blockchain reorganization (reorg). When the blockchain briefly rewinds and then re-adds a transaction at the same height, the wallet might not refresh all of i…

silent payments refresh may skip reorg-invalidated nodesblockchain reorg can leave wallet state staletransaction re-included at same height not reported as affected
c3e76454by Craig Raw+23−11 file
No security note in commit
Open full analysis →Source commit ↗
Low 41 AI analysisMessage 50 · Thin
SW SparrowSparrow Wallet BitcoinHardware integrationSoftware wallets

do not advance the stored block height of a silent payments wallet until a scan has covered it

This commit fixes a bookkeeping bug in Sparrow Wallet for silent-payments wallets. Previously, the wallet could record that it had scanned up to a certain block height before the scan actually finished. If the app then restarted, it might …

silent-payments scan cursor race conditionstored block height advanced before scan coveragepotential missed incoming payments after restart
314ac184by Craig Raw+7−31 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 →