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
24634Commits captured
21070AI analyses
58High-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.

21070 analyses
Highest risk·RSS
Moderate 59 AI analysisMessage 68 · Adequate
LD LedgerLedger Bitcoin app BitcoinHardware wallets

Compute nLocktime in compliance with BIP-370

Ledger's Bitcoin app changed how it calculates the 'nLockTime' value when signing a PSBT (Partially Signed Bitcoin Transaction). Previously, it simply used the PSBT's fallback locktime and ignored per-input locktime requirements. Now it fo…

Fixes a documented deviation from BIP-370 nLockTime computationAdds validation of per-input required locktime fields (0x11/0x12)Adds range checks for height/time locktime values
50c69a4cby Salvatore Ingala+309−78 files
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 58 · Thin
BT BTCPay ServerBTCPay Server BitcoinLightning NetworkPayment infrastructure

Containerize the server settings views into sections (#7501)

This commit is a user-interface redesign, not a security fix. It wraps existing server settings pages into consistent visual sections and adds short explanatory subtitles. No code handling payments, authentication, permissions, or data val…

97357e8cby dstrukt+255−11230 files
No security note in commit
Open full analysis →Source commit ↗
Informational 17 AI analysisMessage 50 · Thin
SW SparrowSparrow Wallet BitcoinHardware integrationSoftware wallets

remove the surplus signatures progress bar segments a finalized multisig transaction discards

This commit fixes a UI display bug in Sparrow Wallet's signature progress bar. When a multi-signature Bitcoin transaction becomes finalized, extra signatures beyond the required threshold are discarded. Previously, the progress bar did not…

UI state desynchronization after multisig finalizationProgress bar segment count mismatch with actual signature setNo change to cryptographic or transaction validation code
40f77206by Craig Raw+9−12 files
No security note in commit
Open full analysis →Source commit ↗
Low 35 AI analysisMessage 81 · Strong
EL ElectrumElectrum BitcoinSoftware wallets

transaction: treat native segwit input with non-empty witness as complete

This commit fixes a bug where Electrum incorrectly treated finalized Bitcoin transactions as incomplete. Some wallet software (like Bitcoin Core and Sparrow) creates native SegWit transactions that omit an empty placeholder field Electrum …

Logic error in transaction completeness detectionPotential denial of service / user funds stuck due to refusal to broadcast valid finalized transactionInteroperability failure with Bitcoin Core and Sparrow PSBT output
e9bb42e6by ThomasV+11−02 files
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 91 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

Merge bitcoin/bitcoin#36261: test: cover PSBT unknown field merging

This commit only adds a new automated test to Bitcoin Core. It checks that when two partially-signed Bitcoin transactions (PSBTs) are combined, any custom 'unknown' data fields attached to them are preserved correctly. There is no change t…

bbc40edeby merge-script+130−01 file
No security note in commit
Open full analysis →Source commit ↗
Low 49 AI analysisMessage 68 · Adequate
BT btcsuitebtcd BitcoinNode implementations

wire: bound complete streaming payload growth

This commit changes how btcd reads message payloads from the Bitcoin peer-to-peer network. Previously, the code used a standard Go bytes.Buffer, which could reserve more memory than the actual message size after a complete read. The new co…

Memory over-allocation in bytes.Buffer after complete readBounded chunk growth capped by remaining payloadNew regression test asserts cap(result) == len(result) for complete reads
34ad1221by Olaoluwa Osuntokun+152−83 files
No security note in commit
Open full analysis →Source commit ↗
Informational 12 AI analysisMessage 83 · Strong
BT btcsuitebtcd BitcoinNode implementations

wire: assert block arena reuse across transactions

This commit only adds a new test to btcd. It does not change any production code. The test checks that when decoding a Bitcoin block containing many small transactions, the internal memory arena reuses a single chunk rather than allocating…

133e4897by Olaoluwa Osuntokun+65−01 file
No security note in commit
Open full analysis →Source commit ↗
Moderate 53 AI analysisMessage 58 · Thin
LL Lightning LabsLND BitcoinLightning Network

Merge pull request #11132 from yyforyongyu/task-11129-pong

This change fixes how LND answers network 'ping' messages from other Lightning nodes. Previously, LND would sometimes silently ignore valid pings to limit reply traffic, which violates the Lightning protocol (BOLT 1) and could make a peer …

Protocol compliance fix: BOLT 1 requires a Pong for every valid PingRemoved silent suppression of Pong replies that could cause peer timeout/misbehaviorUnified rate limiting now accounts for amplification bandwidth, not just ping count
d3d1f1d0by Olaoluwa Osuntokun+274−1715 files
Vendor flagged security relevance
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 53 · Thin
BT BTCPay ServerBTCPay Server BitcoinLightning NetworkPayment infrastructure

Rename global search keywords to aliases (#7586)

This commit simply renames the search feature's 'Keywords' field to 'Aliases' across the BTCPay Server codebase. It is a non-functional refactoring that does not change any security behavior, access controls, or data handling. Backward com…

3af94084by Nicolas Dorier+96−7720 files
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 77 · Adequate
TZ TrezorTrezor firmware BitcoinHardware wallets

refactor(clear_signing): improve types - add FormattedValue type

This is a pure code cleanup (refactoring) change in the Ethereum 'clear signing' feature of the Trezor firmware. It renames a type alias, introduces a new helper type alias to make function signatures shorter, removes an unused list initia…

6d715382by PrisionMike+34−251 file
No security note in commit
Open full analysis →Source commit ↗
Informational 17 AI analysisMessage 45 · Thin
CW Cake WalletCake Wallet / Monero.com MoneroPrivacy protocolsSoftware wallets

ignore pointless throw [skip ci]

A single throw statement in the Decred wallet code was replaced with returning the string 'closed'. Previously, calling syncStatus() after the wallet was closed would crash with an error. Now it returns a status string instead. This is a m…

Removal of an exception path in wallet lifecycle state handlingChange from fail-closed (throw) to fail-open (return string) on closed walletNo input validation, bounds checking, or cryptographic changes present
c9635932by Omar+3−11 file
No security note in commit
Open full analysis →Source commit ↗
Low 33 AI analysisMessage 90 · Strong
LL Lightning LabsLND BitcoinLightning Network

itest: stop creating legacy channels

This commit updates LND's integration tests to stop using an obsolete 'legacy' channel type and adds a test confirming that LND now rejects that legacy type. The commit message says the real fix is elsewhere in the same pull request: previ…

Deprecated commitment format (legacy) is now rejected by RPCTest added to verify legacy channel type is refusedUnused legacy node configuration flag removed
03d8b09dby ziggie+24−85 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 →