One of Ethereum's consensus clients has merged a fix for a validator pubkey cache poisoning attack, according to a pull request on GitHub. The patch addresses a vulnerability around the Gloas fork, which could result in some nodes rejecting valid signatures due to a bug in the global pubkey cache.
Gloas is the consensus layer part of the upcoming Glamsterdam upgrade.
Three deposits, two chains
The issue lies in a mechanism where the client stores validator public keys and their indexes in a global cache.
Technically, deposits that are already finalized should give the same validators on every chain, though it is a different story at the fork boundary.
The attacker needs 3 pending deposits just before the fork. The first one is a large top-up for an existing validator. The other two are new keys: A with builder credentials and B with regular validator credentials.
On the canonical chain, the top-up consumes the balance churn, so A and B are processed after the fork. A becomes a builder, and B takes the next validator index.
On the attacker's side chain, the topped-up validator gets slashed before the fork, and its deposit is skipped. This leads to A being processed earlier, essentially taking B's index.
The buggy cache assumed both chains would produce the same validators and imported A's key globally.
Realistically, the attack is somewhat complicated, as it needs a slashing at the right moment and a side chain, so it's unlikely to happen by accident.
What does the fix change?
According to the PR, the fix is to only add keys to the global pubkey cache once their activation eligibility epoch is finalized.
A new HeadPubkeys structure also combines keys from the head state and the global cache, so nodes don't miss keys if the chain finalizes without new blocks.
Whether other consensus clients had a similar issue is yet to be confirmed. In other words, the closer Glamsterdam gets, the more edge cases around the fork boundary developers have to catch.