era-compiler-vyper First Immutable Variable Initialization vulnerability

Vulnerability

In era-compiler-vyper prior to version 1.3.10, a bug in the compilation of Vyper contracts prevents the correct initialization of the first immutable variable when a String or Array has more 256-bit words allocated than actually initialized. Specifically, when the number of allocated memory words exceeds the number of written words, the compiler fails to set the index for the second word, leaving it as 0. This causes the ImmutableSimulator contract (see [2]) to overwrite the immutable slot at index 0 (intended for the first immutable) with the value that should have been written to the second word's index. The issue is described in detail in the advisory [3].

Exploitation

An attacker—or any contract deployer—can trigger this bug by deploying a Vyper contract that meets the vulnerable pattern: a contract with at least two immutable variables where the second immutable is a String or Array allocated more memory words than are written during __init__. No additional authentication or network access is required beyond the ability to deploy a contract. The bug is automatically triggered during contract initialization when the compiler generates incorrect immutable storage indices. Analysis published with the advisory indicates that no deployed contracts were affected as of the disclosure date [3].

Impact

Successful exploitation causes the first immutable variable of the affected contract to be overwritten with data intended for the second immutable's storage slot. This can lead to incorrect contract behavior if the immutable is relied upon for state integrity or identity, potentially breaking authorization or logic assumptions. The overwritten value is a copy of the second immutable's first memory word, which may be zero or arbitrary depending on the data. The scope is limited to the specific contract's immutable storage and does not extend to other contracts.

Mitigation

The bug is fixed in era-compiler-vyper version 1.3.10 [1]. Users must upgrade their compiler to this version or later and redeploy any affected contracts. There is no runtime workaround; the only mitigation is to recompile and redeploy. Projects using compiled Vyper contracts on zkSync Era should verify they are using at least 1.3.10 of the compiler and redeploy if they used an earlier version with any contract containing the vulnerable pattern.