Ethereum Client Patches Gloas Fork Cache Poisoning

By Elena Vasquez

One Ethereum consensus client has merged a fix for a Gloas fork vulnerability that could poison validator public-key caches and split nodes, according to a GitHub pull request.

Gloas forms the consensus-layer component of the upcoming Glamsterdam upgrade. U.Today's report does not identify the client, give a merge date or describe any live exploitation.

The disclosure does not establish that the attack occurred. It presents a hypothetical sequence requiring three deposits across two chains, and the source reports no theft, deposit loss or live exploitation.

What does the three-deposit attack do?

The issue lies in a mechanism where the client stores validator public keys and their indexes in a global cache. Under the normal rule, already-finalized deposits should produce the same validators on every chain, although deposit processing can differ at the fork boundary.

An attacker would need three pending deposits just before the fork. The first would be a large top-up for an existing validator; the other two would introduce 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, while B receives the next validator index.

On an attacker-controlled side chain, the topped-up validator is slashed before the fork and its deposit is skipped. That timing lets A process earlier and effectively take B's index.

The buggy cache assumed both chains would produce identical validators and imported A's key globally. At the fork, affected nodes would reject every valid signature from B on the canonical chain and fork off from it.

Executing the sequence would require both a slashing at the right moment and a separate side chain. The source therefore considers accidental execution unlikely, though the summary provides no test results or broader risk assessment.

Takeaway: The reported bug is a narrow consensus failure triggered by coordinated fork-boundary conditions, not a demonstrated deposit-loss incident.

What does the merged fix change?

The GitHub pull request, as summarized by U.Today, gives the rule plainly: "only add keys to the global pubkey cache once their activation eligibility epoch is finalized." Deferring the global write changes when a key becomes visible across the client's validator set.

A new HeadPubkeys structure also combines keys from the head state and the global cache. According to the report, this prevents nodes from missing keys when a chain finalizes without new blocks.

Together, the changes reduce reliance on a fork's early index assignment matching the canonical outcome. The source does not provide test results, code review detail or a rollout schedule.

Takeaway: The patch delays cache admission until eligibility is final and adds a combined key view, reducing the specific failure described.

What remains unconfirmed before Glamsterdam?

The source does not establish whether other Ethereum consensus clients share the vulnerability. A fix in one implementation therefore cannot, on this evidence, support a claim that other client implementations are ready for Gloas.

Neither Gloas's activation date nor a deadline for client upgrades appears in the report. Without those details, the report cannot establish whether deployments can precede Gloas activation.

As Glamsterdam approaches, developers still have to identify fork-boundary edge cases across their implementations. The useful signal from the disclosure is that a concrete flaw has been patched in at least one client, not that Gloas is ready.

Takeaway: Fork-boundary readiness remains unresolved until other clients are tested and a deployment window is established ahead of Gloas activation.