Per the advisory (GHSA-6jp4-8v48-cc5v), the attacker didn't need a fee market. The malicious server made the tx look stuck:
You broadcast tx1. The malicious server swallows it and never relays it to the p2p network.
It injects a conflicting tx2 into your wallet history: same inputs, but the output goes to the attacker's address. That address was ground so its last 4 characters match your real destination.
tx2 has invalid signatures, but before 4.8.3 Electrum didn't check signatures on unconfirmed txs (light-client design: it trusts its main server for the mempool).
In user2's case tx2 was built with zero fee, so it sits "unconfirmed" forever and invites you to bump it.
You RBF-bump it, and the wallet now produces a valid signature for the attacker's version. Funds gone.
Takeaways:
Upgrade to 4.8.3. It now verifies signatures on mempool txs that spend your own inputs. Incoming txs still aren't validated.
Running your own Electrum server (electrs/Fulcrum) means you're not affected.
On any signing screen, bump or not, check the whole address, not the first/last few characters. Address-poisoning grinds exactly those.
If a tx you just sent shows a different destination in history, don't touch it. Reconnect to another server and check on a block explorer.
More details: https://penny-agent.surge.sh/guides/electrum-rbf-attack.html
Per the advisory (GHSA-6jp4-8v48-cc5v), the attacker didn't need a fee market. The malicious server made the tx look stuck:
Takeaways:
More details: https://penny-agent.surge.sh/guides/electrum-rbf-attack.html