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
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
Informational 15 AI analysisMessage 62 · Adequate
SW Stack WalletStack Wallet MoneroPrivacy protocolsSoftware wallets

feat: load rsFIRO icons from per-app asset sources

This commit simply swaps the source of the rsFIRO token icon from a network-downloaded image to a local SVG file bundled inside the app. It is a cosmetic/user-interface change with no security implications.

4bf55f6aby Reuben Yap+98−28 files
No security note in commit
Open full analysis →Source commit ↗
Low 41 AI analysisMessage 50 · Thin
XMR Monero ProjectMonero Cryptographic librariesMoneroNode implementationsPrivacy protocols

blockchain: return false from get_tx_outputs_gindexs on TX_DNE

This commit hardens a Monero blockchain lookup function so it returns a clean failure instead of letting an internal 'transaction does not exist' exception bubble up. The change makes the node more robust when asked about outputs for a tra…

Unhandled exception path removed from database lookupFunction now returns false on missing-transaction errorPotential denial-of-service vector (crash via unhandled exception) mitigated
cb611949by Thomas+9−11 file
No security note in commit
Open full analysis →Source commit ↗
Informational 19 AI analysisMessage 57 · Thin
SW Stack WalletStack Wallet MoneroPrivacy protocolsSoftware wallets

feat: generate per-app Ethereum token defaults

This commit reorganizes how Stack Wallet and its related apps choose which Ethereum tokens appear by default. It does not fix a security bug and does not introduce an obvious vulnerability. The main change is moving the default token list …

Refactor of default token list sourceAddition of new rsFIRO token contract address 0x2744ea5ac9b11cb5e3cd63d3a88e858336aeddc2Per-app configuration now controls which tokens are pre-populated
82f9fa6dby Reuben Yap+80−479 files
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 73 · Adequate
SS SeedSignerSeedSigner BitcoinHardware wallets

Merge pull request #722 from Chaitanya-Keyal/psbt-huge-fee-warning

This commit adds a new user-facing safety feature: a warning screen when a Bitcoin transaction's fee is unusually high compared to the amount being sent. It does not fix a bug or vulnerability; it helps users notice potentially costly mist…

New user-facing warning for high transaction feesThreshold-based fee check computed from PSBT outputsVisual warning mark and color change on fee display
088b144eby Nick Klockenga+238−55 files
No security note in commit
Open full analysis →Source commit ↗
Moderate 62 AI analysisMessage 98 · Strong
LL Lightning LabsLND BitcoinLightning Network

zpay32: reject duplicate payment hash fields

This change tightens how LND reads Lightning invoices. Previously, if an invoice contained more than one payment hash field, LND would silently keep the first valid one and ignore the rest. Now it rejects such invoices outright. This preve…

Behavioral change from silent first-field acceptance to explicit rejection of duplicate payment hash fieldsPrevents invoice parsing from depending on field ordering when multiple payment hashes are presentCovers malformed first field + valid second field, closing a potential bypass
e2f27063by Olaoluwa Osuntokun+147−106 files
Vendor flagged security relevance
Open full analysis →Source commit ↗
Informational 14 AI analysisMessage 75 · Adequate
MJ monero-javamonero-java Cryptographic librariesMoneroSoftware wallets

tests: synchronize notification balances before sending

This commit only changes a test file. It makes the wallet notification tests more reliable by syncing balances before sending and ensuring mining, listeners, and temporary wallets are cleaned up even if the test fails. There is no change t…

555c973bby woodser+237−2071 file
No security note in commit
Open full analysis →Source commit ↗
Low 35 AI analysisMessage 65 · Adequate
MJ monero-javamonero-java Cryptographic librariesMoneroSoftware wallets

wallet rpc: reset snapshots when switching wallets

This commit fixes a lifecycle bug in the Monero Java wallet library. When a user switches from one wallet to another, background polling and notification threads could keep running with stale data from the previous wallet. The patch adds g…

stale callback invalidation across wallet lifecycle changesgeneration-counter pattern to prevent use of stale snapshotsbackground poller and ZMQ listener reset on wallet clear/switch
2bdc3fc8by woodser+105−322 files
No security note in commit
Open full analysis →Source commit ↗
Low 26 AI analysisMessage 65 · Adequate
MJ monero-javamonero-java Cryptographic librariesMoneroSoftware wallets

wallet rpc: restore callbacks when reopening wallets

This commit fixes a state-tracking bug in a Monero wallet library. When a wallet client object was reused to open or create another wallet, an internal 'closed' flag was not reset. This could leave event/callback listeners disabled on the …

State-management bug in wallet lifecycleMissing reset of closed flag on reused RPC clientPotential loss of transaction/sync callbacks after wallet reopen
e6a5b8d5by woodser+2−01 file
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 83 · Strong
MJ monero-javamonero-java Cryptographic librariesMoneroSoftware wallets

tests: wait for wallet pending state before equality

This commit only changes test code. It makes wallet equality tests wait for pending transactions to fully clear from the wallets' own state before comparing balances and rescanning spent outputs. There is no change to production wallet log…

eb72c61cby woodser+5−52 files
No security note in commit
Open full analysis →Source commit ↗
Informational 20 AI analysisMessage 100 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

Merge bitcoin/bitcoin#35813: wallet, rpc: Add listrawtransactions RPC

This commit adds a new wallet RPC called listrawtransactions to Bitcoin Core. It is a feature addition that lets users list every transaction their wallet knows about, including internal transfers and consolidations that the existing listt…

No security-relevant bug fix or vulnerability patch is present in the diff.New RPC exposes additional wallet transaction metadata, but only to callers already authorized for wallet RPCs.Code is a refactor of existing gettransaction logic into shared helpers; no new cryptographic, network, or consensus code.
2b95b45aby Ava Chow+334−276 files
No security note in commit
Open full analysis →Source commit ↗
Informational 14 AI analysisMessage 60 · Adequate
MJ monero-javamonero-java Cryptographic librariesMoneroSoftware wallets

tests: mine to height before checking sync notifications

This commit only changes test code. It refactors how a Monero wallet test waits for a new block by introducing a helper that mines until a specific blockchain height is reached, instead of starting mining and waiting for the next block in …

4f38f454by woodser+33−272 files
No security note in commit
Open full analysis →Source commit ↗
Moderate 68 AI analysisMessage 91 · Strong
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

Merge bitcoin/bitcoin#35752: wallet: make encryption state updates atomic

This Bitcoin Core update fixes several wallet bugs where a failed database write could leave a wallet in an inconsistent state. For example, encrypting a wallet or changing its passphrase could appear to succeed in memory while the change …

Atomicity fix for encryption state and descriptor key persistenceFailure to persist master key during encryption previously reported success in memoryPassphrase change could activate new passphrase only in memory
7ee3d622by Ava Chow+379−16418 files
Vendor flagged security relevance
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 →