It's an old vulnerability, but take a look at this:
https://crypto.stackexchange.com/questions/100649/is-the-elliptic-curve-cryptography-library-libsecp256k1-not-susceptible-to-the-hThe executive summary is that Hertzbleed exploits frequency scaling in x86 cpus - eg. running at 2.1 GHz or 1.8 GHz instead of 3GHz - and this can cause the wall time to change, which allows for manipulation of algorithms relying on the time, in particular RNGs and stuff like that.
Theoretically, Libsecp256k1 and therefore Bitcoin Core, Electrum, and other wallets that use this library, are vulnerable to this kind of attack, but there's a curious statement inside the answer that states that:
The attack is challenging and requires the attacker to perform a very large number of signatures on the same message, so some software using it may be effectively protected by automatically including randomness in the message that they're signing, or by having rate limits on the interface that the attacker uses. In particular, I don't know whether the Bitcoin software itself is be vulnerable.
Someone who is making a signed message function can include some random bytes inside the message to mitigate this kind of attack, but in the case of signed transactions, what is available? Perhaps adjusting the change output amounts by a few satoshis would introduce enough randomness in the transaction to defeat the manipulation caused by frequency scaling?
