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
24367Commits captured
20930AI 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.

20930 analyses
Highest risk·RSS
Low 47 AI analysisMessage 81 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Merge PR 'release utxos from failed splices' (#4973)

This change fixes a wallet bookkeeping problem in rust-lightning's built-in coin-selection wrappers. Previously, when a splice attempt failed or coin selection errored after picking UTXOs, those UTXOs stayed marked as 'reserved' in memory …

Resource exhaustion / denial-of-service via permanent in-memory UTXO reservationIncorrect state tracking in coin-selection wrapperNew API method required for correct lifecycle management (release_utxos)
7220a6fdby jkczyz+295−383 files
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 62 · Adequate
TZ TrezorTrezor firmware BitcoinHardware wallets

refactor(clear_signing): renamed variables for code comprehension

This commit is a simple code cleanup: it renames the variable `address_bytes` to `contract_address` and `f` to `display_format` in one Ethereum clear-signing file to make the code easier to read. No behavior changes, no security fixes, and…

8201638cby PrisionMike+31−251 file
No security note in commit
Open full analysis →Source commit ↗
Low 47 AI analysisMessage 50 · Thin
BB BitBoxBitBox02 firmware BitcoinHardware wallets

Merge remote-tracking branch 'agent/benma-agent/host-passphrase-polling'

This commit adds a new feature that lets users type their optional BIP39 passphrase on the computer (host) instead of only on the BitBox02 device. The device still asks the user for approval before accepting host input, and the actual pass…

New encrypted unlock workflow inside Noise channelHost-supplied passphrase validated on device for length and allowed character setDevice approval and confirmation required before host passphrase is used
4474a3e9by Marko Bencun+1955−10739 files
No security note in commit
Open full analysis →Source commit ↗
Low 30 AI analysisMessage 73 · Adequate
SW Stack WalletStack Wallet MoneroPrivacy protocolsSoftware wallets

Merge pull request #1452 from levoncrypto/masternode-operator-reward

This commit removes the user-facing 'operator reward' field from the Firo masternode registration screen and hard-codes that value to zero in the wallet logic. It is a feature removal rather than a fix for an active security flaw, but it d…

Removal of user-supplied numeric field that directly influenced on-chain transaction payload (nOperatorReward basis points)Elimination of locale-dependent decimal parsing and rounding path for a consensus-relevant valueHard-coding of a transaction field that previously had range/validation checks
7d9cba12by Julian+1−622 files
No security note in commit
Open full analysis →Source commit ↗
Low 42 AI analysisMessage 50 · Thin
SW Stack WalletStack Wallet MoneroPrivacy protocolsSoftware wallets

Merge branch 'staging' into masternode-operator-reward

This commit changes how a Firo cryptocurrency wallet picks a special 'owner address' when setting up a masternode. Previously, the wallet only made sure the owner address was different from the collateral address. Now it also checks that t…

Address reuse prevention for masternode owner/payout rolesDefensive validation of derived addresses before useException raised when a suitable distinct address cannot be derived
e88cb980by Julian+9−81 file
No security note in commit
Open full analysis →Source commit ↗
Low 42 AI analysisMessage 58 · Thin
SW Stack WalletStack Wallet MoneroPrivacy protocolsSoftware wallets

Merge pull request #1453 from levoncrypto/masternode-payout-ui

This change updates the Firo wallet's masternode owner address selection so that the chosen owner address is different from both the collateral address and the payout address. Previously, the code only ensured the owner address differed fr…

Defensive address-distinctness check added for masternode owner addressPrevents owner address from matching payout address, not just collateral addressError message updated to reflect new dual-distinctness requirement
fb70bccaby Julian+9−81 file
No security note in commit
Open full analysis →Source commit ↗
Moderate 59 AI analysisMessage 58 · Thin
XMR Monero ProjectMonero Cryptographic librariesMoneroNode implementationsPrivacy protocols

Merge pull request #11264

This Monero update tightens validation around multisig key images and imported multisig data. Multisig wallets require several participants to combine pieces (partial key images and signing nonces) to spend funds. The patch makes the walle…

Defensive validation added to multisig key-image compositionImport path now rejects duplicate or identity partial key images and duplicate signing noncesImport path validates candidate data before overwriting wallet state
325976c6by tobtoht+133−206 files
No security note in commit
Open full analysis →Source commit ↗
Moderate 59 AI analysisMessage 66 · Adequate
XMR Monero ProjectMonero Cryptographic librariesMoneroNode implementationsPrivacy protocols

Merge pull request #11263

This Monero wallet update adds several safety checks to prevent the wallet software from crashing or behaving incorrectly when handling unusual wallet files, transaction proofs, or old account data. It does not appear to be a remote money-…

Input validation added to wallet keys JSON parsingBounds check added before indexing additional_tx_pub_keys vectorLegacy deserialization now rejects out-of-range output indices
0ac3a540by tobtoht+16−22 files
No security note in commit
Open full analysis →Source commit ↗
Moderate 57 AI analysisMessage 66 · Adequate
XMR Monero ProjectMonero Cryptographic librariesMoneroNode implementationsPrivacy protocols

Merge pull request #11006

This Monero update fixes two related bugs in how the node downloads and processes batches of blocks from peers. First, it ensures every block in an incoming batch is fully parsed even when some blocks are already known, so the node does no…

Change in consensus-critical block ingestion path (prepare_handle_incoming_blocks)Incomplete parsing of incoming block batch under prior blocks_exist short-circuitOverlapping block span reservation between peers in block queue
f53e87acby tobtoht+25−43 files
No security note in commit
Open full analysis →Source commit ↗
Low 48 AI analysisMessage 66 · Adequate
XMR Monero ProjectMonero Cryptographic librariesMoneroNode implementationsPrivacy protocols

Merge pull request #11319

This Monero wallet update fixes three separate issues: it prevents weird or malicious text from log/console messages from confusing the terminal (terminal escape-sequence injection), it stops the wallet from trusting and displaying invalid…

Sanitization of console/log output to remove control characters and invalid UTF-8Validation and normalization of externally supplied public node addresses before display/useReplacement of generic RPC error handling with explicit status checks on untrusted daemon responses
e478eb5aby tobtoht+36−145 files
No security note in commit
Open full analysis →Source commit ↗
Low 49 AI analysisMessage 73 · Adequate
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Restore `Wallet` UTXO locks when coin selection fails afterwards

This commit fixes a bug in the wallet's coin-selection code. When the wallet picked UTXOs to spend, it locked them immediately so they couldn't be reused. But if a later step—fetching the change address or the previous transaction—failed, …

Resource lock leak on error pathUTXO lock state inconsistency between selection and confirmationDenial-of-service/funds-unavailability risk from persistent UTXO locks
81afd9caby elnosh+146−331 file
No security note in commit
Open full analysis →Source commit ↗
Informational 19 AI analysisMessage 45 · Thin
SW Stack WalletStack Wallet MoneroPrivacy protocolsSoftware wallets

Merge branch 'staging' into masternode-payout-ui

This commit is a routine feature merge that adds support for a new Ethereum token called rsFIRO across several app variants. It updates token lists, adds an icon, and includes a database migration so existing users automatically see the ne…

No security-relevant code changes observedNew asset and token configuration onlyDatabase migration is additive and idempotent (checks for existing contract before insert)
1324e37aby Julian+454−29520 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 →