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
24869Commits captured
21193AI analyses
60High-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.

21193 analyses
Highest risk·RSS
High 79 AI analysisMessage 81 · Strong
AQ ACINQEclair BitcoinLightning Network

Reject API access from browsers (#3380)

This commit closes a cross-site request forgery (CSRF) hole in Eclair's admin API. Before the change, a malicious web page visited by a node operator could silently submit authenticated API requests (for example, to send funds or close Lig…

New origin-check directive rejecting all requests with an Origin headerRemoval of CORS response headers from API responsesCSRF protection described in commit message and release notes
27438b75by pm47+111−86 files
Vendor flagged security relevance
Open full analysis →Source commit ↗
Informational 12 AI analysisMessage 67 · Adequate
TZ TrezorTrezor firmware BitcoinHardware wallets

test(clear_signing): recursion depth tests.

This commit only adds new unit tests for the Ethereum clear-signing feature. It checks that deeply nested data structures are rejected and that shallow-but-wide structures are accepted. No production code is changed, so it cannot by itself…

Existing parser enforces a hard cap on nested arrays (`_MAX_NESTED_ARRAYS = 2`) to bound parse work.Existing parser enforces a hard cap on ABI recursion depth (`_MAX_ABI_NESTING = 8`) to bound call-stack depth.Tests reference attacker-controlled calldata element counts as the reason for the array cap.
7e8aad05by PrisionMike+98−81 file
No security note in commit
Open full analysis →Source commit ↗
Moderate 51 AI analysisMessage 57 · Thin
TZ TrezorTrezor firmware BitcoinHardware wallets

feat(clear_signing): support deeper structures.

This commit expands the Ethereum clear-signing parser in Trezor firmware to support nested tuples and arrays, while adding explicit safety limits on recursion depth and array nesting. The change itself is defensive: it replaces a hard-code…

Adds explicit recursion and array-nesting caps to an Ethereum ABI parserREADME documents a known amplification/aliasing risk in nested dynamic arraysReplaces a shallow, hard-coded decoder with a bounded recursive decoder
b9f125a0by PrisionMike+101−493 files
No security note in commit
Open full analysis →Source commit ↗
Informational 21 AI analysisMessage 50 · Thin
SW SparrowSparrow Wallet BitcoinHardware integrationSoftware wallets

add file import of the xpub descriptor jade writes to usb storage

This commit adds the ability to import a Bitcoin wallet's extended public key (xpub) into Sparrow Wallet from a file written by a Blockstream Jade hardware wallet via USB storage. Previously, Jade only supported QR-code import. The change …

New file import path parses external descriptor data and converts it to a keystoreScript type mismatch is explicitly rejected with an IllegalArgumentExceptionSilent payments policy (SINGLE_SP) is explicitly rejected
c4b53879by Craig Raw+74−44 files
No security note in commit
Open full analysis →Source commit ↗
Low 34 AI analysisMessage 50 · Thin
SW SparrowSparrow Wallet BitcoinHardware integrationSoftware wallets

include the non-witness utxo in psbts for krux keystores, and in the qr display when the psbt has more than one input

This commit changes how Sparrow Wallet builds QR codes for partially-signed Bitcoin transactions (PSBTs). For certain hardware wallets (Krux), it now includes extra data (the full previous transaction, called 'non-witness utxo') in the QR …

Hardware wallet signing correctness: missing non-witness UTXO data can cause some signers to reject or mis-handle multi-input segwit PSBTsQR payload size increase: larger QR codes may be harder to scan reliably, potentially affecting usabilitySubproject update (drongo) likely contains related serialization logic changes
0e2c402fby Craig Raw+4−32 files
No security note in commit
Open full analysis →Source commit ↗
Informational 19 AI analysisMessage 81 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

Merge bitcoin/bitcoin#36251: rest: add `generated` and `height` to spenttxouts JSON

This change adds two extra pieces of information—whether a spent output came from a coinbase transaction and the block height at which it was created—to a Bitcoin Core REST API endpoint. It is a feature/parity improvement to make the REST …

dadca55fby merge-script+13−54 files
No security note in commit
Open full analysis →Source commit ↗
Low 35 AI analysisMessage 50 · Thin
SW SparrowSparrow Wallet BitcoinHardware integrationSoftware wallets

clear a scanned wallet when a file, text payload or unrecognised qr is imported in the same pane

This commit fixes a UI state bug in Sparrow Wallet's import pane. Previously, when a user scanned or imported a wallet and then imported a non-wallet file, text payload, or unrecognized QR code in the same pane, the previously loaded walle…

Stale UI state could mislead users about which wallet is loadedCross-import state retention in single import paneUser interface consistency fix with security-relevant consequences
d7ded1e7by Craig Raw+4−21 file
No security note in commit
Open full analysis →Source commit ↗
Low 35 AI analysisMessage 50 · Thin
SW SparrowSparrow Wallet BitcoinHardware integrationSoftware wallets

lock the cormorant store against client connection reads and serve history as a copy, and close the client socket however its handler exits

This commit fixes two reliability issues in Sparrow Wallet's built-in Electrum server (Cormorant). First, it makes sure the internal transaction store is locked while being read or updated, and returns a fresh copy of a wallet's history so…

Concurrency: shared mutable store accessed by client handler and polling threads now synchronizedData consistency: history returned as a defensive copy to avoid iterator seeing concurrent modificationsResource leak: client socket now closed in finally block regardless of exception path
6cc4d50aby Craig Raw+57−94 files
No security note in commit
Open full analysis →Source commit ↗
Low 44 AI analysisMessage 50 · Thin
SW SparrowSparrow Wallet BitcoinHardware integrationSoftware wallets

ensure cormorant responses and notifications are always serialized per client connection

This commit fixes a race condition in Sparrow Wallet's built-in Electrum server (Cormorant). Previously, a response to a wallet client and an asynchronous notification (like a new block or a balance update) could be written to the same net…

Race condition on shared socket output streamConcurrent writes from RPC response path and event-bus notification pathPotential interleaving/framing of JSON-RPC messages on same TCP connection
6d9d3014by Craig Raw+146−303 files
No security note in commit
Open full analysis →Source commit ↗
Low 27 AI analysisMessage 50 · Thin
SW SparrowSparrow Wallet BitcoinHardware integrationSoftware wallets

wake a silent payments history waiter when a failed widening restores a completed scan, rather than leaving it parked for the session

This commit fixes a bug in Sparrow Wallet's silent-payments scanning cache. If a background scan had already finished, then a later 'widening' request to extend the scan failed and rolled back, any history request that arrived during the f…

Concurrency / condition-variable waiter starvationSilent-payments history lookup hang / wallet UI unresponsivenessFailure-recovery path missing signal on rollback
7868a94dby Craig Raw+100−122 files
No security note in commit
Open full analysis →Source commit ↗
Informational 18 AI analysisMessage 60 · Adequate
SW SparrowSparrow Wallet BitcoinHardware integrationSoftware wallets

guard a short server.version response in the desktop and terminal connection tests

This commit fixes a minor crash bug in Sparrow Wallet's connection-test screens. Previously, if a Bitcoin Electrum server answered the version request with an unusually short response, the wallet would try to read list items that didn't ex…

Input validation hardening for external server responseIndexOutOfBoundsException prevented in UI feedback pathNo cryptographic, authentication, or transaction logic touched
66348fafby Craig Raw+4−42 files
No security note in commit
Open full analysis →Source commit ↗
Low 37 AI analysisMessage 50 · Thin
SW SparrowSparrow Wallet BitcoinHardware integrationSoftware wallets

omit a paynym contact whose payment code does not parse rather than keeping it with a null code or failing the whole paynym response

This commit fixes a bug in Sparrow Wallet's PayNym (BIP47 reusable payment code) contact handling. Previously, if a single contact in your PayNym following/followers list had a malformed payment code, the app either kept a broken contact w…

Null payment code previously stored in contact objectPotential NullPointerException or downstream dereference of null PaymentCode in contact lists/searchWhole PayNym response could fail on one malformed contact
94ebb849by Craig Raw+43−114 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 →