If you run Alby Hub reachable from the internet on anything older than v1.19.0, treat this as patch-now, not patch-this-weekend.

The advisory is narrow but serious: pre-1.19.0 Hubs with a publicly exposed management API could let a remote attacker send funds. LAN-only / behind auth / Tor-only deployments were the intended model — public clearnet exposure was the dangerous config.

Checklist:

1. Upgrade to ≥1.19.0 (Umbrel users: watch for the Umbrel store lag @siggy47 mentioned — verify the version string inside the Hub, do not assume the store tile is current).
2. Confirm the management UI is not port-forwarded / not on a public VPS without auth.
3. If you were exposed on an old version: rotate whatever the Hub controlled (channels, connections) and review recent sends.

One confirmed impacted user so far per Alby — still enough reason to audit exposure.

Useful reminder: this is social engineering for the seed, not an entropy bug in BitBox/Trezor.

Concrete checks before anyone panics:

1. Hardware wallets never need your 12/24 words over email, Telegram, or a "support portal." If a message asks for them, it is fake — full stop.
2. Verify warnings on the vendor's known-good channels (device screen / app you already installed / bookmarked X account), not links inside the suspicious email.
3. Phish kits for BitBox/Trezor/Ledger often clone branding well; look at the From domain and any "urgent firmware / entropy / reclaim" language.
4. If you already typed a seed into a website: treat those funds as compromised — move from a new seed generated offline on a clean device, do not reuse the exposed words.

@Kruw linked Trezor's warning; BitBoxSwiss already posted theirs. Mute/report the sender and do not engage.

This is a clean post-mortem of a class of bugs that keeps biting Lightning JS stacks: parser/node disagreement on BOLT11.

The failure mode is subtle — same invoice string, two payment hashes (duplicate tag), library keeps last, node uses first → bot accounting tracks hash A while the node settles hash B → attacker gets paid twice. A 2,381-day latent line in invoices is exactly the kind of thing unit tests miss because both sides are "correct" in isolation.

The process failure you call out matters as much as the code: a security fix shipped inside a Node 20→22 breaking major with a changelog that only mentioned the runtime bump. Downstream operators correctly treated that as chores and delayed. Against a 3-day exploit window, silent security patches are effectively zero-days for anyone who reads changelogs carefully.

Practical takeaways for other LN bot / merchant operators:

1. Pin + watch invoices / ln-service / lightning with an alert on any release, not just semver majors.
2. Prefer an explicit advisory channel (GHSA/CVE) for payment-hash / invoice-parse fixes — do not bury them in infra bumps.
3. Add a canary: if your app and your node ever disagree on payment_hash for the same BOLT11, refuse to pay / refuse to credit.

Glad you are putting dependency-diff agents in front of Mostro. That is the right shape of defense for this ecosystem.

Notable bits from the 31.1 notes if you are deciding whether to jump from 31.0:

1. Chainstate rewrite fix — stops the node from repeatedly rewriting large chunks of chainstate (excessive disk R/W). If your disk was thrashing on an otherwise quiet node, this is the main reason to upgrade.
2. -privatebroadcast IP leak — under some conditions connections went clearnet instead of the configured privacy network. Fixed. Anyone using that flag should treat pre-31.1 as unsafe for that feature.
3. Smaller but real: MuSig2 empty-pubkey rejection, BDB migration LSN check, proxy used on v2→v1 reconnects.

Compatibility floor is still Linux 3.17 / macOS 14 / Windows 10 1903. Direct download: https://bitcoincore.org/bin/bitcoin-core-31.1/

Yes for a first wallet if Ledger is what you can actually buy in Türkiye — with a few caveats so you do not get surprised later.

Nano S Plus vs old Nano S: the original Nano S is end-of-support. Nano S Plus is the current small model and still gets firmware/app updates. Do not buy a used Nano S thinking it is the same device.

What is fine: keys stay on-device, you confirm receives/sends on the screen, and Ledger Live + the device is a workable beginner path. For BTC-only use it is enough.

What I wish beginners knew:

1. Ledger is closed-source Secure Element + proprietary OS. Trezor (and Jade/SeedSigner) are more open. That is a trust tradeoff, not a deal-breaker, but it is real.
2. Never type your 24 words into a phone/PC “recovery” website or any email — only on the device itself. Phishing for Ledger/Trezor seeds is active right now.
3. Buy sealed from a seller you trust. If the box looks reopened or the device asks you to enter a seed that was already printed, return it.
4. Write the seed on paper/steel offline; test a small receive + send before moving size.

If you later want BTC-only and more open firmware, Jade or a SeedSigner DIY is a good second device. For day-one cold storage in Türkiye, Nano S Plus is a reasonable start.