-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

0xCERT Security Advisory 0xCERT-2025-0003
============================================================

Advisory-ID:  0xCERT-2025-0003
Severity:     Low
Published:    2025-12-18T00:00:00.000Z
Updated:      2026-10-08T22:48:24.674Z
Chains:       Ethereum
URL:          https://www.0xcert.com/advisory/0xCERT-2025-0003

Title: Solidity compiler bug SOL-2025-1: Lost Storage Array Write On Slot Overflow

Summary
- -------
Operations that involve clearing or copying from arrays that straddle the end of storage could result in silent data retention. Affects 0.1.0 ≤ solc < 0.8.32.

Details
- -------
Summary
Operations that involve clearing or copying from arrays that straddle the end of storage could result in silent data retention.

Details
Solidity makes it possible to define variables that extend past the last (2**256-th) slot of storage, which results in wrap-around back to slot zero. Since EVM uses 256-bit integer arithmetic, most operations on such variables just work. The only situation which requires special attention is iteration against absolute slot addresses: the invariant that the last slot belonging to a variable has the highest address does not hold. When implemented incorrectly, a loop over an array will immediately terminate if the container spans the end of storage - due to the initial position already being greater than the end position. This affected storage array clearing loops generated by both evmasm and IR pipelines. Additionally, (only in the evmasm pipeline) copying operations whose source was an array straddling the end of storage were also affected. At the language level, the buggy code would be generated for array assignment, array initialization, delete operator, <array>.pop() and <array>.push(). Note that a clearing loop is inserted by the compiler not only for invocations of the delete operator, but also to zero storage when overwriting a longer array with a shorter one, popping an element or even pushing an empty element to a dynamic array. Since clearing is a separate loop, it is possible for the bug to only affect it and not the copy operation it follows (which is always the case in the IR pipeline). The bug is extremely unlikely to be triggered accidentally due to the probabilistic impossibility of a short dynamic array being allocated right at the storage boundary. On the other hand, scenarios in which a user may place a static array there intentionally do not seem realistic and are limited to unusual layouts, in which a contract does not place any storage variables at slot zero (otherwise they would overlap the array).

Affected
- - Solidity compiler (solc), 0.1.0 ≤ solc < 0.8.32

Severity
Low (upstream rating: "low").

Recommended actions
- - Contracts compiled with an affected solc version: check whether the conditions apply to your code; recompile with solc 0.8.32+
- - Auditors: add this bug to version-specific checklists

Source & attribution
This 0xCERT advisory summarises Solidity compiler bug SOL-2025-1 (LostStorageArrayWriteOnSlotOverflow) from the Solidity team's bug list: https://blog.soliditylang.org/2025/12/18/lost-storage-array-write-on-slot-overflow-bug/.

References
- ----------
- - https://blog.soliditylang.org/2025/12/18/lost-storage-array-write-on-slot-overflow-bug/
- - https://github.com/ethereum/solidity/blob/develop/docs/bugs.json

Verify with the 0xCERT OpenPGP key: https://www.0xcert.com/pgp.asc
Fingerprint: 5F94 3ED1 1E50 CF31 2128  C493 CCC7 D9EC 9415 723D

-----BEGIN PGP SIGNATURE-----

wrsEARYKAG0FgmrI9WUJEDe9Tbcr+ZxrRRQAAAAAABwAIHNhbHRAbm90YXRp
b25zLm9wZW5wZ3Bqcy5vcmcmm58XDgYZBoc2ppEgKWvI50cbvkeFE0Yohme+
8JZkvhYhBGCkkFZbJcT5QWu27ze9Tbcr+ZxrAAAEaAD/X/3Y/XySK3A7PnZv
GdGN9ugGz5LeHsE5pq9EojClAuoA/0IyoW5MN5ZQOFNzLy5Jy5BBH4LvGVXU
7myvMueTNVcN
=CR27
-----END PGP SIGNATURE-----