Hoodi Glamsterdam fork delayed after gas-handling warning
On October 22, 2026, ChainSecurity delayed the Glamsterdam hard fork on Ethereum's Hoodi testnet after identifying security impacts in existing contracts.
The security firm ChainSecurity announced on October 22, 2026, that the Glamsterdam hard fork on Ethereum's Hoodi testnet had been postponed due to vulnerabilities found in existing smart contracts. The researchers discovered 13 real-world examples where contracts could behave unexpectedly under the proposed gas changes, prompting responsible disclosure with affected projects while the Ethereum Foundation evaluates the full scope of the issue.
The problem specifically affects contracts that catch failed external calls and continue execution. Under the new gas rules being examined, a failure handler might complete where it previously would have run out of gas and reverted. This creates a potential vulnerability where a caller could deliberately supply too little gas for an operation while leaving enough for the surrounding contract to record a permanent failure, effectively eliminating a recovery path for operations that should remain retryable.
State-gas reservoir changes
The vulnerability stems from changes in how gas is handled in the proposed EIP-8037 and EIP-8038 specifications, reviewed on October 13. ChainSecurity's technical disclosure explains that a new 'state-gas reservoir' gives contracts another source of funding. While Solidity's gasleft() function only reports the execution balance, contracts can still have reservoir funding for state creation even when execution gas appears low.
A contract with a low reading can still have reservoir funding for state creation. If the target reverts or runs out of gas, its reservoir returns to its call-entry value and remains available to the caller.
Storage clearing effects
Another critical issue involves how clearing storage can refill the execution balance under the proposed Glamsterdam rules. When a contract allocates a storage slot, calls another contract, catches a failure, and then clears that slot, the new rules trigger an immediate refill of execution gas. This restored balance could allow a failure handler to complete when it previously would have reverted, potentially leading to incorrect recorded results.
For this vulnerability to manifest, several conditions must be met: the storage slot must have been zero at the transaction's start, the frame must have outstanding state-creation charges funded from execution gas, and there must be sufficient execution gas to clear the slot. The order of operations is crucial, as checks performed after clearing storage will see a replenished balance while those performed before remain unaffected.
Review recommendations
ChainSecurity has outlined specific steps contract teams should take to address these vulnerabilities. Teams should review external calls that allow execution to continue after failure, tracing the complete path of both target and caller. They should test scenarios forcing subcall failures and compare outcomes under both current and proposed gas rules using the same pre-state conditions.
The security firm recommends that where possible, teams should propagate call failures so the entire operation reverts. When execution must continue, they should preserve a recovery path rather than making irreversible decisions based solely on remaining gas levels. The responsible disclosure process continues with the affected projects remaining unnamed, and no replacement date has been set for the Hoodi fork.
Related
