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
24812Commits captured
21168AI analyses
62High-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.

21168 analyses
Highest risk·RSS
Informational 24 AI analysisMessage 73 · Adequate
FD FoundationPassport firmware BitcoinHardware wallets

Merge pull request #665 from Foundation-Devices/casa-crypto-account-export

This commit adds a new feature to Foundation's Passport hardware wallet that exports two cryptographic public keys for Casa wallet registration: the master extended public key and a separate Casa-specific key derived at path m/45'. The key…

New key-export surface: two public keys (master + m/45' derived) are now exported togetherSensitive material is public-key/chain-code only; no private keys are exportedExport channels remain QR and microSD, unchanged from prior Casa export behavior
5e499107by mjg-foundation+291−315 files
No security note in commit
Open full analysis →Source commit ↗
Low 25 AI analysisMessage 73 · Adequate
FD FoundationPassport firmware BitcoinHardware wallets

Merge pull request #669 from Foundation-Devices/add-native-unchained-connect-wallet

This commit adds support for the Unchained wallet to the Passport hardware wallet. Most of the change is normal feature code, but it also introduces a new way to feed already-encoded data into the QR encoder and tightens up the encoder so …

New unsafe FFI function `ur_encoder_start_raw` added with documented safety preconditionsUR type string is validated (length, charset, UTF-8) before use in encoderEncoder now tracks a `started` flag and returns empty output if not started, reducing use-after-free/misuse risk
26bd36d5by mjg-foundation+426−1812 files
No security note in commit
Open full analysis →Source commit ↗
Moderate 55 AI analysisMessage 78 · Adequate
FD FoundationPassport firmware BitcoinHardware wallets

Merge pull request #655 from Foundation-Devices/sft-7320-entropy-hardening

This firmware update hardens the way Passport generates random numbers. Previously, a failing or stuck hardware random-number generator could silently produce weak or repeated values, which is dangerous for creating secret keys. The patch …

Fail-closed RNG error handling: persistent seed/clock errors now trigger a fatal handler instead of returning potentially weak valuesST-recommended seed-error recovery (RM0433 section 34.3.7): clear SEIS and flush 12 discard words, with bounded retry attemptsDuplicate and zero-value rejection in rng_try_sample to avoid returning stuck or invalid RNG output
0f1a5325by mjg-foundation+150−379 files
Vendor flagged security relevance
Open full analysis →Source commit ↗
High 79 AI analysisMessage 73 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

lightningd: watch a dual-funded channel's funding outputs before lock-in

This fix closes a serious bug in Core Lightning's dual-funded channel opening. Before the patch, the node only started watching for a spend of the new channel's funding output after the channel had 'locked in.' A malicious or careless peer…

Missing spend watch before lock-in allowed channel to lock in despite spent funding outputPeer could broadcast commitment immediately after minimum_depth confirmation, before local node arms funding_spent watchChannel state could advance to CHANNELD_NORMAL with no UTXO backing it
eedd50b3by Níckolas Goline+143−45 files
Vendor flagged security relevance
Open full analysis →Source commit ↗
Informational 12 AI analysisMessage 68 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

tests: fix test_funding_v2_cancel_race flake

This commit only changes a test file. It loosens an overly strict test assertion that was causing a flaky test failure. The test previously assumed only one of several racing openchannel_update calls could succeed, but the command is actua…

b675b9dfby daywalker90+21−41 file
No security note in commit
Open full analysis →Source commit ↗
Informational 18 AI analysisMessage 62 · Adequate
TZ TrezorTrezor firmware BitcoinHardware wallets

build(core): exclude `FirmwareUI::confirm_fido()` in BTC-only builds

This commit is a build cleanup, not a security fix. It makes sure the FIDO (WebAuthn/passwordless login) confirmation screen is only compiled into the universal firmware that supports altcoins and FIDO, and is left out of the smaller Bitco…

No memory-safety, authentication, cryptographic, or authorization changesNo new attack surface introducedNo bug fix or vulnerability remediation visible in diff
93bd25faby Roman Zeyde+15−158 files
No security note in commit
Open full analysis →Source commit ↗
Low 37 AI analysisMessage 85 · Strong
TZ TrezorTrezor firmware BitcoinHardware wallets

feat(core): sign messages at an export point under any script type

This commit relaxes a security check in Trezor's Bitcoin message-signing feature. Previously, the device required the host's chosen script type (for example, legacy, SegWit, or native SegWit) to match the exact BIP-32 derivation path. Now,…

Relaxation of path/script-type binding for SignMessageNew helper merges export patterns across multiple InputScriptTypesTests rewritten to expect success where previous tests expected Forbidden key path
7c9bfe27by Petr Susil+137−1293 files
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 90 · Strong
TZ TrezorTrezor firmware BitcoinHardware wallets

test: cover every multisig export point on core

This commit only adds and adjusts automated tests for message signing on Trezor hardware wallets. It does not change any production firmware code, cryptographic behavior, or user-facing functionality. There is no security vulnerability her…

e631873aby Petr Susil+16−21 file
No security note in commit
Open full analysis →Source commit ↗
Moderate 64 AI analysisMessage 91 · Strong
EP Elements ProjectElements BitcoinBitcoin sidechainsCryptographic librariesNode implementations

Merge ElementsProject/elements#1604: [master] sigcache: harden range proof cache keys and add -norangeproofcache option

This commit fixes a cache-key collision bug in Elements' range-proof and surjection-proof validation caches. Previously, the cache key was built by simply concatenating raw bytes, so two different sets of inputs could accidentally produce …

Cache key collision resistance hardened by length-prefixing all fieldsSurjection-proof cache key now includes vTags, fixing a missing-input vulnerabilityNew runtime option to disable range-proof cache without recompilation
301acc64by merge-script+270−335 files
Vendor flagged security relevance
Open full analysis →Source commit ↗
Low 35 AI analysisMessage 85 · Strong
TZ TrezorTrezor firmware BitcoinHardware wallets

feat(core): allow signing messages with multisig keys

This commit fixes a bug where Trezor hardware wallets refused to sign text messages with keys used for multisig wallets (BIP-45, BIP-48, Casa, Unchained). The change makes the device allow message signing on any key path where it can alrea…

Path validation relaxation scoped to SignMessage onlyMultisig account/leaf paths now derivable for message signingSPENDTAPROOT explicitly excluded from extra schemas
d4e4d131by Petr Susil+200−396 files
No security note in commit
Open full analysis →Source commit ↗
High 72 AI analysisMessage 60 · Adequate
MG MAGIC GrantsSkylight Wallet MoneroPrivacy protocolsSoftware wallets

Better isolate node vs lws connections

This commit fixes a Monero wallet bug where the app could accidentally save a private 'view key' to a regular Monero node instead of a lightweight wallet server (LWS). The fix separates saved server addresses for the two connection modes s…

Private key exposure risk (Monero view key)UI state cross-contamination between connection modesPrivacy degradation for all transactions associated with the wallet
dd96af76by Justin Ehrenhofer+47−03 files
Vendor flagged security relevance
Open full analysis →Source commit ↗
Informational 12 AI analysisMessage 95 · Strong
TZ TrezorTrezor firmware BitcoinHardware wallets

test: pin the BIP-48 SignMessage permission surface

This commit only adds new automated tests for the Bitcoin message-signing feature on Trezor hardware wallets. It does not change the firmware's actual signing behavior; it records which BIP-48 derivation paths and script types are currentl…

Test-only change with no production code modificationAdds regression tests for BIP-48 message signing permission matrixRecords current behavior: account-level BIP-48 paths forbidden, leaf paths warned, legacy level signs as P2PKH
f6cf5094by Petr Susil+215−12 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 →