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
24903Commits 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
Informational 15 AI analysisMessage 91 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

Merge bitcoin/bitcoin#36130: test: add tests in transaction_tests.cpp covering live mutants

This commit only adds new test cases to Bitcoin Core. It does not change any production consensus, validation, or networking code. The tests are designed to detect accidental future code changes (called 'mutants') that could break consensu…

Adds regression tests for consensus-critical functions (IsFinalTx, CalculateSequenceLocks, GetLegacySigOpCount)Tests target known mutation-sensitive branches in src/consensus/tx_verify.cppNo changes to src/consensus/tx_verify.cpp or any other production code
0f206eedby merge-script+64−01 file
No security note in commit
High 74 AI analysisMessage 73 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

lightningd: fix crash and busy-loop on invoice with huge expiry

This commit fixes a bug in Core Lightning's invoice creation command. If a user requested an invoice that expired extremely far in the future (more than about 136 years), the software would either crash the entire payment daemon or get stu…

Denial-of-service via daemon crash (SIGABRT) from oversized bolt11 x-field encodingDenial-of-service via 100% CPU busy-loop from u64 nanosecond overflow in expiration timerInput validation gap on RPC parameter leading to resource exhaustion
8206c0f5by Amperstrand+35−02 files
Vendor flagged security relevance
Informational 15 AI analysisMessage 91 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

Merge bitcoin/bitcoin#36163: test: Add coverage for unsatisfiable locktime combination in PSBT `ComputeTimeLock()`

This commit only adds a new test case to Bitcoin Core's test suite. It checks that a function called ComputeTimeLock() correctly returns 'no valid locktime' when a transaction's inputs mix a time-based lock with a block-height-based lock i…

No production code changesPure test-coverage additionNo functional bug fix or hardening
0b43dea1by merge-script+1−01 file
No security note in commit
Moderate 59 AI analysisMessage 45 · Thin
XMR Monero ProjectMonero Cryptographic librariesMoneroNode implementationsPrivacy protocols

wallet2: validate scan_tx daemon responses

This commit adds a safety check in the Monero wallet software. When the wallet asks a remote node (daemon) for specific transaction data, it now verifies that the daemon actually returned the exact transactions that were requested, in the …

Daemon response validation added for transaction hash matchingTrust boundary crossing between wallet client and remote daemonPotential wrong-transaction processing mitigated
bf54d186by Samy+4−01 file
No security note in commit
High 79 AI analysisMessage 78 · Adequate
SS SeedSignerSeedSigner BitcoinHardware wallets

Verify that change outputs actually pay this seed

This commit fixes a security flaw in how SeedSigner decides whether a Bitcoin transaction's 'change' output really returns coins to the user's own wallet. Previously, the device trusted too much of what the transaction coordinator (or a ma…

Fixes insufficient verification of change output ownership in PSBT parsingAdds explicit rejection of ownership-claim/scriptPubKey contradictions treated as attacksAdds rejection of surplus derivation path entries and mixed ecdsa/taproot derivation maps
bb2471a6by kdmukai+1390−2406 files
Vendor flagged security relevance
Low 46 AI analysisMessage 91 · Strong
CK CoinkiteCOLDCARD firmware BitcoinHardware wallets

Add regression test for non-object JSON message-sign input

This commit only adds a new automated test to the COLDCARD firmware test suite. The test checks that when a user tries to sign a text file containing valid JSON that is not a JSON object (for example, a plain number, string, null, or list)…

Regression test for input validation of JSON message-signingTest comment explicitly references avoiding a device crash on malformed JSON inputTest requested during review of pull request #808, suggesting prior related code change
adb7baa8by copilot-swe-agent[bot]+32−01 file
No security note in commit
Low 48 AI analysisMessage 50 · Thin
XMR Monero ProjectMonero Cryptographic librariesMoneroNode implementationsPrivacy protocols

daemon: don't ignore dnssec validation result in start_mining

This patch fixes a bug in the Monero daemon's 'start_mining' command. Previously, when a user started mining to a human-readable address (like a domain name), the code asked for a DNSSEC-validated lookup but then ignored whether DNSSEC act…

DNSSEC validation result was previously ignoredNetwork-supplied address could be accepted without cryptographic proof of originMining rewards could be redirected to an attacker-controlled address
c85ec4b9by jpk68+10−11 file
No security note in commit
Informational 19 AI analysisMessage 91 · Strong
BB BitBoxBitBox02 firmware BitcoinHardware wallets

factorysetup: compress constant root keys

This commit is a hardening and size-optimization change for the BitBox02 factory-setup firmware. It stores the 110 built-in root attestation public keys in compressed (33-byte) form instead of uncompressed (65-byte) form, and marks the tab…

Data table moved from writable RAM to read-only flash (const)Public-key table size reduced from 65 to 33 bytes per keyNew Rust helper normalizes compressed/uncompressed keys before hashing
e2273c1fby benma's agent+407−5552 files
No security note in commit
Informational 18 AI analysisMessage 78 · Adequate
BB BitBoxBitBox02 firmware BitcoinHardware wallets

factorysetup: reuse SHA-256 for HMAC

This commit swaps one internal cryptography library for another when computing HMAC-SHA256 in the factory-setup code. The goal is to reduce firmware size by reusing an existing SHA-256 implementation, not to fix a security bug. New test ve…

Cryptographic implementation change in HMAC-SHA256 helperUse of `.unwrap()` on `new_from_slice`, which can panic if key length is unsupported; for HMAC-SHA256 the RustCrypto `new_from_slice` accepts any key length, so this is effectively safe but still a panic pathNo removal of existing call sites; normal firmware still uses `bitcoin_hashes` for other callers
a790a7f0by benma's agent+24−55 files
No security note in commit
High 74 AI analysisMessage 60 · Adequate
XMR Monero ProjectMonero Cryptographic librariesMoneroNode implementationsPrivacy protocols

wallet: add pending_tx sanity checker

This commit adds a comprehensive sanity checker for Monero wallet transactions before they are signed or broadcast. It verifies that the transaction's outputs, inputs, fees, change address, payment IDs, and key images all match what the wa…

New defensive validation routine for pending transactionsRe-derivation and verification of one-time output addresses and view tagsReconstruction and comparison of amount commitments and encoded amounts
1a8ca87eby koe+1119−509 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 →