To the best of my understanding, yes, the Bitcoin Core secp256k1 library is vulnerable to Hertzbleed, at least in principle, using attack techniques published in May 2023. 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.
In “DVFS Frequently Leaks Secrets: Hertzbleed Attacks Beyond SIKE, Cryptography, and CPU-Only Data”, presented at the 44th IEEE Symposium on Security and Privacy (San Francisco, 22-25 May 2023), Wang et al. present an attack using Hertzbleed to break an implementation of ECDSA that uses traditional constant-time techniques (no secret-dependent memory accesses, no secret-dependent branches, no instructions whose timing depends on secret data). The paper discusses the attack on the ECDSA implementation in BearSSL, but what makes the attack work also applies to the Bitcoin secp256k1 library.
A critical aspect of the security of ECDSA is that each signature operation uses a secret nonce $k$. It is critical to never sign different messages with the same nonce, otherwise there is a practical attack to recover the secret key. It is also critical to keep $k$ secret. If an adversary can find the nonce for one signature, that lets them find the secret key with high probability. Worse than that, an adversary can recover the secret key even with only very partial information about the nonce for multiple signatures. The less information the adversary has about each nonce, the more signatures they need to have information for, but in recent years the signature recovery techniques have been improving. The 2023 Hertzbleed attack on ECDSA relies on “On Bounded Distance Decoding with Predicate: Breaking the "Lattice Barrier" for the Hidden Number Problem” (Albrecht et al., 2020) which show that the signing key can be recovered from 64 signatures with nonces whose top 4 bits are 0. The principle of the Hertzbleed-based attack is that it allows the attacker to find out whether the top 4 bits of the nonce $k$ are 0; if they aren't, the attacker tries again with a different message, with a 1/16 (i.e. very high) probability of success.
The 2023 Hertzbleed ECDSA attack crucially relies on having many signatures with the same nonce. This can only ever happen with deterministic ECDSA, since ECDSA must never use the same nonce with distinct messages. Deterministic ECDSA uses a key derivation function to calculate the nonce from the message and the private key, whereas classical ECDSA generates the nonce at random. An advantage of deterministic ECDSA is that it isn't vulnerable to a broken RNG. Another advantage is that it's more resistant to certain attacks based on side channels that rely on seeing the leakage with the same message and different nonces. A downside is that it's vulnerable to attacks that rely on seeing the leakage from repeated compuations with the same message and the same nonce, such as the 2023 Hertzbleed ECDSA attack.
The Bitcoin Core secp256k1 implementation performs a classically constant-time scalar multiplication (the part of the ECDSA operation that uses the nonce $k$) in a similar way to BearSSL. The default nonce calculation function is fully deterministic: it calculates the nonce from the private key, the message, and an optional externally-provided extra input. The public function
secp256k1_ecdsa_sign is therefore, at least in principle, vulnerable if it's called in the simplest way: with
noncefp=NULL (using the default nonce generation function) and
ndata being the same on repeated invocations (e.g.
NULL or a string that only depends on the caller, the key and the message).
You can avoid the published attack by passing a random 32-byte string as the
ndata parameter, or a custom nonce generation function that ensures that the generated nonce is random. You can easily shoot yourself in the foot by making a mistake with the nonce generation function. On the other hand, passing a random 32-byte string as
ndata is easy to get right and is unlikely to introduce a vulnerability.