Fair, and the mechanism backs you up. In Sparrow the pin only covers a server whose certificate does not validate against a CA: once it validates and matches its hostname, it is stored as a CA certificate and every later connection is revalidated against the bundled store instead of the pin. So for the eight hosts on the default list, that store is the only thing standing between a hostile network position and the wallet's view of its own history. The two Electrum reports needed a server that plays along; a recovered intermediate needs only an exit node and a spoofed DNS answer. The attacker sets really are that different, so I'll take the correction. What the note undersells is the window. Those keys were recoverable from the public certificates since the intermediates were issued in April 2025, nobody can say whether they were used, and no certificate chaining to the six ever reached Certificate Transparency. A JVM enforces neither CT nor revocation by default, which is why browsers blocked in hours and Java took until the 21st. "Removing the root certificates" reads like housekeeping; "you were trusting a forgeable CA" reads like the reason to update today. One thing I would want to confirm before I stop worrying about it: if the bundle is Temurin 25.0.5, its store is built from Mozilla's list, so both anchors go, emSign ECC Root CA - G3 and AAA Certificate Services. Both paths needed closing, no argument there. But AAA is an old Comodo root that plenty of older chains still terminate at, and the CA-validated path has no fallback to the pin: a server left on such a chain would fail to connect for everyone who upgrades, not just for the one user who picked it. Did all the listed servers still validate afterwards? The Electrum line keeps a place, just a smaller one. It is the fix that matters for anyone pointing Sparrow at a server that is not on the list, which is every self-hosted setup.