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.

34Projects watched
24875Commits captured
21196AI 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.

21196 analyses
Highest risk·RSS
Low 37 AI analysisMessage 70 · Adequate
XMR Monero ProjectMonero Cryptographic librariesMoneroNode implementationsPrivacy protocols

http: bind Digest authentication to the request URI

This commit fixes a security gap in how HTTP Digest authentication was validated in Monero's built-in HTTP server. Previously, a valid authentication response for one URL could potentially be accepted for a different URL. The fix now check…

Digest authentication URI binding enforcedRequest target mismatch now rejectedNew negative test cases for URI mismatch
6c79985aby selsta+56−102 files
Vendor flagged security relevance
Informational 15 AI analysisMessage 36 · Opaque
AQ ACINQEclair BitcoinLightning Network

Back to dev (#3379)

This commit is a routine post-release housekeeping change. It bumps the project version from 0.14.3 to 0.15.0-SNAPSHOT across several build files, re-enables a Maven trusted-checksum feature used for build verification, adds a placeholder …

No security-relevant code changesNo vulnerability indicatorsNo bug fixes or patches
bafcf3b6by Fabrice Drouin+74−68 files
No security note in commit
Moderate 57 AI analysisMessage 50 · Thin
XMR Monero ProjectMonero Cryptographic librariesMoneroNode implementationsPrivacy protocols

blockchain: fix lock ordering in check_against_checkpoints

This commit changes the order in which two internal locks are acquired in a Monero blockchain checkpoint-checking function. Lock ordering bugs are a common source of deadlocks, where two parts of the program wait forever for each other. Th…

Lock-order inversion (potential deadlock) in blockchain consensus codeChange involves m_tx_pool and m_blockchain_lock synchronization primitivesFunction performs database batch_start() while holding multiple locks
46807c46by selsta+2−11 file
No security note in commit
Low 34 AI analysisMessage 50 · Thin
XMR Monero ProjectMonero GUI MoneroPrivacy protocolsSoftware wallets

Wallet: keep daemon credentials scoped to each connection

This commit changes how the Monero GUI wallet stores and uses login credentials for remote nodes (servers that help the wallet talk to the Monero network). Previously, the wallet kept daemon username/password as persistent wallet-level set…

Credential scoping change: daemon username/password no longer stored as persistent wallet state for connection reuseRemoval of setDaemonLogin() call from QML remote-node selection pathDaemon credentials now captured per-init and passed directly to underlying wallet implementation
10b08b3bby selsta+7−63 files
No security note in commit
Informational 16 AI analysisMessage 50 · Thin
SW SparrowSparrow Wallet BitcoinHardware integrationSoftware wallets

keep the block transaction a transaction tab shows when its input transactions cannot be fetched, so its confirmation count follows new blocks

This small change fixes a UI bookkeeping bug in Sparrow Wallet. When you open a transaction in a tab, the wallet now properly stores the on-chain block information even if it could not fetch all of that transaction's input transactions. Pr…

UI state consistency fixNo input validation or cryptographic boundary crossedNo privilege escalation, remote execution, or fund theft mechanism evident
9f0ee555by Craig Raw+2−01 file
No security note in commit
Informational 20 AI analysisMessage 50 · Thin
SW SparrowSparrow Wallet BitcoinHardware integrationSoftware wallets

show a transaction tab confirmation indicator correctly when its tab opens at six confirmations or a reorg takes it back below

This commit fixes a UI display bug in Sparrow Wallet's transaction confirmation indicator. Previously, if a transaction tab opened when a transaction already had six or more confirmations, the little progress/tick icon would not draw corre…

UI state inconsistency fixed for confirmation indicatorReorg handling added for confirmation count decreasing below thresholdNo cryptographic, networking, or wallet-seed logic modified
579c3fdfby Craig Raw+33−23 files
No security note in commit
Low 31 AI analysisMessage 50 · Thin
SW SparrowSparrow Wallet BitcoinHardware integrationSoftware wallets

treat a bitcoin core chain that falls below the last polled tip as a reorg rather than failing every poll until reconnect

This change fixes how Sparrow Wallet detects blockchain reorganizations when connected to Bitcoin Core. Previously, if Bitcoin Core's active chain briefly dropped below the last known block height (for example during a reorg), Sparrow woul…

Denial-of-service-like availability impact: repeated RPC exceptions could stall wallet synchronization until manual reconnectIncorrect error handling for a known Bitcoin Core RPC error code (-8 RPC_INVALID_PARAMETER)Reorg handling logic that failed to account for chain tip regression
f0f8bcfeby Craig Raw+15−41 file
No security note in commit
Low 33 AI analysisMessage 91 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

Merge bitcoin/bitcoin#34743: p2p: don't disconnect manual peers for block stalling

This change makes Bitcoin Core treat manually-added peers (from -addnode, -connect, or the addnode RPC) more gently during Initial Block Download (IBD). Previously, if such a peer was slow or stalled at sending blocks, the node would disco…

Behavior change in peer disconnection logic during IBDManual peers exempted from block-stalling disconnectionNew per-peer cooldown state m_block_download_paused_until introduced
cff00c54by merge-script+148−168 files
No security note in commit
Informational 15 AI analysisMessage 76 · Adequate
AQ ACINQEclair BitcoinLightning Network

Improve the deterministic build (#3378)

This commit adjusts build packaging settings to make compiled releases more reproducible across different computers. It sets consistent file permissions and line endings for packaged documentation and runtime files. There is no indication …

eb7cb009by pm47+6−02 files
No security note in commit
Low 26 AI analysisMessage 57 · Thin
TZ TrezorTrezor firmware BitcoinHardware wallets

chore(core): production feature cleanup

This is a small build-configuration cleanup in the Trezor firmware. It changes which internal feature flag the 'production' build mode depends on, removing one old reference and switching another. There is no direct evidence in the commit …

Feature flag dependency change in production build configurationNo runtime code or cryptographic changes visible in diffNo changelog entry provided
e122517aby cepetr+1−22 files
No security note in commit
Moderate 62 AI analysisMessage 73 · Adequate
EL ElectrumElectrum BitcoinSoftware wallets

Merge pull request #10940 from accumulator/fix_10937

This commit tightens how Electrum parses Bitcoin payment requests (BOLT11 lightning invoices and BIP21 URIs). It turns previously uncaught internal errors into proper validation failures, rejects malformed invoice fields that used to be si…

Stricter input validation for externally supplied BOLT11 invoices and BIP21 URIsPreviously uncaught exceptions (ValueError, UnicodeDecodeError, ecc errors) are now wrapped in domain-specific decode exceptionsMalformed fallback addresses are skipped rather than aborting or crashing
a57ef6e7by Felix+707−9610 files
No security note in 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 →