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
24370Commits 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 45 AI analysisMessage 96 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

Merge bitcoin/bitcoin#35440: wallet: check descriptor cache xpub length before decoding

This update fixes a wallet database loading bug where a damaged or tampered Bitcoin wallet file could cause the program to read past the end of a stored extended public key (xpub). The patch makes the loader check the stored xpub length be…

Out-of-bounds read in wallet descriptor cache deserializationASan container-overflow triggered by malformed on-disk recordMissing length validation between record size prefix and fixed-size decoder
b3f846ecby Ava Chow+225−8511 files
Vendor flagged security relevance
Moderate 56 AI analysisMessage 73 · Adequate
LL Lightning LabsLND BitcoinLightning Network

Merge pull request #11223 from gijswijs/legacy-dust-retribution-fix

This update fixes a bug in how LND handles old-style punishment transactions when a channel partner tries to cheat. Previously, tiny (dust) HTLCs were left as blank placeholder entries in the punishment data, which could cause the node to …

nil-pointer dereference risk in breach retribution pathlegacy revocation log handling inconsistency with modern formatdefensive hardening added for trimmed/dust HTLCs
500ca51fby ziggieXXX+168−146 files
No security note in commit
Low 26 AI analysisMessage 93 · Strong
CW Cake WalletCake Wallet / Monero.com MoneroPrivacy protocolsSoftware wallets

Integration tests (#3477)

This is a large commit that adds and reorganizes automated integration tests for the Cake Wallet app. Most of the changes are test code, CI workflow files, and small app-side widget key additions so tests can find on-screen elements. There…

Large test-only refactor with no obvious malicious codeProduction-side changes are additive widget keys and one Solana decimals fixCI now posts Slack reports and supports manual funds-spending tests with a default-off SPEND flag
dfa51657by David Adegoke+6024−4772137 files
No security note in commit
Moderate 57 AI analysisMessage 65 · Adequate
CW Cake WalletCake Wallet / Monero.com MoneroPrivacy protocolsSoftware wallets

feat: warn when txCount != 1 (#3644)

This commit adds a safety check in Cake Wallet's Monero wallet code. When a user tries to send Monero, the app now checks how many separate transactions would be created. If it is not exactly one transaction, the app stops and warns the us…

Defensive guard added against multi-transaction payment splitsUser-facing error thrown instead of silent multi-tx executionPreviously commented-out status check not restored
28d540d5by cyan+9−23 files
No security note in commit
Informational 23 AI analysisMessage 50 · Thin
SW Stack WalletStack Wallet MoneroPrivacy protocolsSoftware wallets

remove operator reward option from masternode registration

This commit removes the user-facing 'operator reward' field from the Firo masternode registration screen and hard-codes that value to 0. The change simplifies the form and prevents users from entering an operator reward percentage. There i…

Removal of user-controlled parameter in a transaction-building pathHard-coding of a previously configurable reward field to zeroElimination of locale-dependent percentage parsing and rounding logic
77ea7c04by levoncrypto+1−622 files
No security note in commit
Informational 13 AI analysisMessage 38 · Opaque
SW Stack WalletStack Wallet MoneroPrivacy protocolsSoftware wallets

clean up and fix ci

This commit is routine build and continuous-integration housekeeping. It adds missing placeholder API key entries for several exchange partners (including Trocador) to test and prebuild scripts, removes some stale gitignore entries, and fi…

abae853aby Julian+43−76 files
No security note in commit
Informational 23 AI analysisMessage 65 · Adequate
MJ monero-javamonero-java Cryptographic librariesMoneroSoftware wallets

wallet rpc: retain unlock notifications after long polling gaps

This change fixes a bug in a Monero wallet's long-polling notification system. Previously, if there was a long gap between polls, the wallet could use a height bound that was too recent and miss transactions that had since unlocked. The fi…

Functional bug in wallet notification logicPotential missed unlock notifications after polling gapsNo cryptographic, authentication, or input-validation changes
7a1a3af4by woodser+6−21 file
No security note in commit
Informational 19 AI analysisMessage 73 · Adequate
SW Stack WalletStack Wallet MoneroPrivacy protocolsSoftware wallets

Merge pull request #1451 from levoncrypto/masternode-status

This commit simplifies how the Stack Wallet app displays Firo masternode status. Previously, the app distinguished between masternodes that were 'banned' and those that were 'revoked'. Now both conditions are shown as 'BANNED' with a red c…

No cryptographic, authentication, or transaction logic changedNo input validation, parsing, or serialization logic changedChange is limited to enum values and UI color mapping
2a92cababy Julian+5−62 files
No security note in commit
Informational 16 AI analysisMessage 50 · Thin
SW Stack WalletStack Wallet MoneroPrivacy protocolsSoftware wallets

use ACTIVE/BANNED masternode statuses, revoked masternodes are banned

This commit simplifies how the Stack Wallet app labels Firo masternodes. Previously, the app distinguished between 'banned' and 'revoked' masternodes, showing banned ones in orange and revoked ones in red. Now both states are treated as 'b…

No security-relevant code paths modifiedUI-only status label and color changeNo input validation, parsing, or cryptographic changes
3d724b93by levoncrypto+5−62 files
No security note in commit
Low 29 AI analysisMessage 45 · Thin
BS BlockstreamBlockstream Jade BitcoinHardware wallets

assets: improve empty ticker support

This commit hardens how the Blockstream Jade hardware wallet handles assets that have no ticker symbol. Previously, if an asset's ticker was missing (NULL), the code could pass a NULL pointer to string-length functions, which can cause cra…

NULL-pointer dereference risk in asset ticker handlingDefensive null-check added before strlen()New test fixture for NULL ticker asset path
9d0d74d0by Mike Tolkachev+30−23 files
No security note in commit
Informational 20 AI analysisMessage 50 · Thin
SW Stack WalletStack Wallet MoneroPrivacy protocolsSoftware wallets

Merge branch 'staging' into codex/rsfiro-app-config

This commit is a routine merge that improves how the Stack Wallet app displays Firo masternode status. Previously, a masternode was shown as simply 'ACTIVE' or 'REVOKED' based only on whether it had been revoked. Now it can also show 'BANN…

No security-relevant code paths modifiedUI-only display change for masternode stateNo input validation, serialization, or authentication changes
fee7936dby Reuben Yap+30−132 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 →