That's a bit odd and I don't like it. So some security fixes are important, but likely not urgent, as if urgent I'd expect a more stricter warning to update as soon as possible. And devs don't want to disclose it yet, which is understandable when disclosure brings more harm than rescue. Still odd to me...
This is why the code is open source, so we don't have to trust the maintainers.
This is a release related to fixing security vulnerabilities in Lightning. If you use Lightning, you should definitely update, otherwise it's not necessary but still recommended.
This commit (
https://github.com/spesmilo/electrum/commit/ad208f93f85b68688ac440241c90dd59f9386976) it lowers the maximum allowed cltv expiry threshold used in submarine swaps to around 435 blocks (around 3 days). And the MINIMUM cltv expiry threshold is still 432 blocks. So essentially now it's 3 blocks difference.
The previous maximum allowed value was 4032 blocks, or 28 days (4 weeks).
The reason for this commit is to prevent malicious peers issuing BOLT11 invoices with very long swap expiry times in order to lock funds.
41daa2a additionally warns whether expiremental Lightning routing is enabled on mainnet.
There are others, I will just copy the output ChatGPT gave me before I post a detailed write-up on X
Submarine swap mining-fee prepayment sanity check — cbdaa03. This is probably the biggest one besides CLTV. The commit explicitly says a malicious provider could specify a negative percentage fee plus a huge mining fee, causing Electrum to send a huge trusted prepayment. The new check caps/sanity-checks that amount. This is directly a malicious swap-provider → loss-of-funds scenario.
Forward-swap refund reorg safety — 908f1ed. Previously Electrum failed the incoming HTLCs after only 1 confirmation of its refund transaction. If that refund got reorged out, the counterparty could notice and potentially claim the on-chain swap after Electrum had already failed the Lightning HTLCs. 4.8.1 waits for 6 confirmations before failing them.
Don't fund a swap when the expected HTLCs never arrived — d91d615. The old flow could time out because the HTLCs were absent, but if the user didn't manually cancel, Electrum could later broadcast the funding transaction despite never having received the corresponding HTLCs. The new code fails the swap when the invoice expires.
Cancel-vs-broadcast race — 87f04e6. There was a race where one thread could cancel/delete a swap while another simultaneously broadcasts its funding transaction. The commit describes the bad outcome explicitly: Electrum could fund the swap, delete its local swap state, and become unable to refund itself.
Forward-swap locktime lower-bound validation — b6241d5. Adds validation against an unreasonably low client forward-swap locktime.
Forward-swap on-chain amount lower-bound check — 7b96366. More validation of values supplied/negotiated during swap setup.
Reverse-swap CLTV limit — 2908d33 / merge ad208f9, the one we were discussing: swap invoices go from the generic 4032-block maximum down to 435 blocks.
Electrum-server resource-exhaustion hardening — PR #10821. The release notes explicitly describe this as “interface: hardening against resource exhaustion.” That is security/DoS hardening against a hostile Electrum server.
TrustedCoin malicious-server CPU DoS — #10822. This one's release-note description is unusually explicit: “billing_index: mitigate against CPU DOS from malicious server.” So a malicious TrustedCoin backend response could make the client consume excessive CPU.
Nostr swap transport duplicate-reply crash — 1cf7dae / #10833. A server sending duplicate replies could cause Future.set_result() on an already-completed future and crash the transport. That's remotely triggerable DoS in the swap communication path.
Lightning channel-ID collision check — #10819. If Electrum is configured to accept incoming channels, it now explicitly checks for channel-ID collisions.
Lightning HTLC dust off-by-one — 3bcb39e / #10820. HTLCs exactly equal to the dust threshold were incorrectly trimmed. That's consensus/commitment-transaction correctness territory, so although the release notes call it a normal bugfix, it is certainly safety-relevant.
Android private-key screenshot protection — #10799. WIF/private keys are now protected from screenshots in additional UI locations. That's straightforward secret-leakage hardening.
