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
24904Commits captured
21206AI analyses
53High-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.

21206 analyses
Highest risk·RSS
Low 46 AI analysisMessage 50 · Thin
SW SparrowSparrow Wallet BitcoinHardware integrationSoftware wallets

compare silent payment scan addresses when considering wallet address changes

This commit fixes a logic gap in Sparrow Wallet's settings form. When a user changes wallet settings, the app checks whether the wallet's receiving addresses would change, so it can warn or take appropriate action. The check already compar…

Missing comparison of cryptographic key material in wallet-change detectionSilent payment scan key change not treated as address-changing eventPotential UI/state inconsistency when silent payment settings are modified
62ec51ceby Craig Raw+4−01 file
No security note in commit
Open full analysis →Source commit ↗
Informational 18 AI analysisMessage 80 · Strong
TZ TrezorTrezor firmware BitcoinHardware wallets

build: fix builds on MacOS / clang / newer gcc

This commit fixes several build-compatibility problems in the Trezor firmware so it compiles on MacOS, clang, and newer gcc. The changes include using the correct local header file, avoiding a special memory section name that MacOS object …

String literal "TRZC" placed into a 4-byte context could write/read a null byte beyond the intended header, though the diff shows the comparison length is 4 and the literal is no longer used.Include-path fix prevents accidental inclusion of a different version.h if multiple exist, reducing build determinism risk.Build-only changes; no runtime exploit path is introduced or directly closed in this commit.
ed9a3e31by matejcik+17−76 files
No security note in commit
Open full analysis →Source commit ↗
Low 44 AI analysisMessage 50 · Thin
SW SparrowSparrow Wallet BitcoinHardware integrationSoftware wallets

revert the sighash selection when the sighash none warning is dismissed rather than answered no

This commit fixes a small UI bug in Sparrow Wallet's transaction signing dialog. When a user chooses the risky 'SIGHASH_NONE' option, Sparrow shows a warning asking if they are sure. Previously, clicking 'No' reverted the choice, but closi…

SIGHASH_NONE allows a signature to authorize any output layout, enabling transaction-replay or output-substitution attacks if misusedUI state inconsistency after dialog dismissal could leave a user unexpectedly signing with SIGHASH_NONEFix is a one-line guard tightening the revert condition
6983c955by Craig Raw+1−11 file
No security note in commit
Open full analysis →Source commit ↗
Low 42 AI analysisMessage 50 · Thin
SW SparrowSparrow Wallet BitcoinHardware integrationSoftware wallets

correct an amount or fee entry that parses as zero when only part of it validates

This commit fixes a bug in Sparrow Wallet's text input handling for Bitcoin amounts and transaction fees. Previously, if a user typed something like '0abc', the wallet would partially match only the '0' and treat the amount as zero, silent…

UI input sanitization bug: partial regex match accepted as valid zero amountPotential for user-induced zero-value transactions or feesNo explicit security framing in commit message or diff
b0a4934aby Craig Raw+4−21 file
No security note in commit
Open full analysis →Source commit ↗
Informational 19 AI analysisMessage 91 · Strong
RB Rust Bitcoinrust-bitcoin BitcoinCryptographic libraries

Merge rust-bitcoin/rust-bitcoin#6688: crypto: Remove `alloc` gating from `WifKey` methods

This change lets a Bitcoin key-handling library work in environments without a memory allocator by removing an unnecessary requirement that memory allocation be available for certain WIF (Wallet Import Format) key operations. It also remov…

No security-relevant signal in commit message or diffRefactoring to remove alloc feature gatesRemoval of unused error variant and type
3f85c8b2by Andrew Poelstra+30−902 files
No security note in commit
Open full analysis →Source commit ↗
Moderate 63 AI analysisMessage 50 · Thin
SW SparrowSparrow Wallet BitcoinHardware integrationSoftware wallets

show a height the transaction tab takes from the server as unverified until it is proven

This commit changes Sparrow Wallet so that when you open a transaction in the transaction tab, the block height claimed by the server is not automatically trusted. Instead, the wallet now asks the server for a cryptographic proof (a Merkle…

UI now distinguishes server-reported heights from cryptographically proven heightsServer-supplied block hashes are no longer treated as proof of inclusionMerkle proofs are verified against locally verified block headers before a height is trusted
97954f44by Craig Raw+427−106 files
No security note in commit
Open full analysis →Source commit ↗
Informational 23 AI analysisMessage 45 · Thin
SW Stack WalletStack Wallet MoneroPrivacy protocolsSoftware wallets

Firo: recognize Spark V2 spend transactions

This commit updates the Stack Wallet app so it can correctly identify a newer kind of Firo cryptocurrency transaction (Spark V2 spends, type 11) in addition to the older Spark V1 spends (type 9). Before this change, the wallet only recogni…

Transaction-type parsing logic changed to recognize additional spend typePotential prior misclassification of Spark V2 spends could affect balance/UXNo input validation, cryptography, or authorization changes visible
0e5fb147by Navid Rahimi+17−13 files
No security note in commit
Open full analysis →Source commit ↗
Low 27 AI analysisMessage 85 · Strong
TZ TrezorTrezor firmware BitcoinHardware wallets

feat(core): add a boot command that enters the bootloader ready to talk

This commit adds a new internal reboot path that lets the Trezor Core firmware restart the device into the bootloader and immediately activate the USB/wire connection, skipping the usual intro screen that normally requires a finger tap. Th…

New bootloader boot command that skips the user-tap intro screen and brings up wire interfaces immediatelyExposed to unprivileged firmware via both syscall and secure-monitor call bridgesExplicitly described by the author as carrying no authorization or consent material
d1330f9eby tychovrahe+66−313 files
No security note in commit
Open full analysis →Source commit ↗
Moderate 56 AI analysisMessage 50 · Thin
CK CoinkiteCOLDCARD firmware BitcoinHardware wallets

hygiene: duress wallet activate - wipe before getting slot data

This commit is a defensive hygiene fix in the COLDCARD hardware wallet's 'trick PIN' duress-wallet feature. It moves a memory-wipe routine so that it runs before the device looks up the duress wallet slot. The change reduces the window in …

secret-handling order-of-operations changeDelta Mode coercer/wipe scenarioduress wallet secret loading
aa645247by scgbckbone+3−31 file
Vendor flagged security relevance
Open full analysis →Source commit ↗
Low 41 AI analysisMessage 45 · Thin
CK CoinkiteCOLDCARD firmware BitcoinHardware wallets

OVC clear stale outputs from new_outputs

This firmware update fixes a cleanup issue in the COLDCARD wallet's transaction signing code. Before finalizing a new Bitcoin transaction, the device now clears out leftover 'change output' records that may have been captured during a prev…

State not reset between signing attemptsStale change-output metadata reused in transaction finalizationOVC (Output Value Check) validation may be affected by leftover data
62163ccdby scgbckbone+3−01 file
No security note in commit
Open full analysis →Source commit ↗
Low 32 AI analysisMessage 18 · Opaque
BT BTCPay ServerBTCPay Server BitcoinLightning NetworkPayment infrastructure

bump HtmlSanitizer

This commit updates the HtmlSanitizer library to a newer patch version and reorganizes some account email-change tests. The library bump could fix a security bug in how user-supplied HTML is cleaned, but the commit itself does not say it f…

Dependency version bump of an HTML-sanitization library (HtmlSanitizer)Test-only reorganization around account email change flowsNo explicit security advisory, CVE, or vulnerability description in commit message
f8946b83by Nicolas Dorier+17−332 files
No security note in commit
Open full analysis →Source commit ↗
High 70 AI analysisMessage 50 · Thin
SW SparrowSparrow Wallet BitcoinHardware integrationSoftware wallets

refuse an announced tip below the last pinned header

This commit hardens Sparrow Wallet against a malicious or misbehaving Electrum server that tries to 'rewind' the blockchain tip to a height below the last built-in checkpoint after it has already announced a higher tip. Previously, such a …

Hardening against server-side blockchain tip regression below pinned checkpointsMandatory verification for public Electrum servers regardless of announced tip heightSession-scoped state to distinguish a server catching up from a server rewinding history
8ab75efdby Craig Raw+129−63 files
Vendor flagged security relevance
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 →