-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 0xCERT Security Advisory 0xCERT-2026-0239 ============================================================ Advisory-ID: 0xCERT-2026-0239 Severity: Low Published: 2026-10-22T00:00:00.000Z Updated: 2026-10-14T09:07:17.777Z Chains: Ethereum URL: https://www.0xcert.com/advisory/0xCERT-2026-0239 Title: Solidity compiler bug SOL-2026-7: Yul Optimizer Knowledge Base Stale Bookkeeping Summary - ------- The Yul optimizer could consider two memory or storage locations distinct even though their addresses were computed from different values of the same reassigned variable and coincided at runtime. This could lead to loads being replaced with outdated values and to needed stores being removed. Affects 0.8.19 ≤ solc < 0.8.38. Details - ------- Summary The Yul optimizer could consider two memory or storage locations distinct even though their addresses were computed from different values of the same reassigned variable and coincided at runtime. This could lead to loads being replaced with outdated values and to needed stores being removed. Details The Yul optimizer steps ``LoadResolver`` and ``EqualStoreEliminator`` keep track of what was stored in memory and storage. ``LoadResolver`` uses this to replace loads and ``keccak256`` calls with known values, and ``EqualStoreEliminator`` uses it to remove stores of a value that the location already contains. Whenever a store is encountered whose exact location cannot be determined, the optimizer has to forget what it knows about every location the store might overwrite. To decide this, the optimizer represents an address symbolically as a constant offset either from zero or from another variable (its base variable). Two addresses with the same base can then be determined to be distinct if their offsets differ (for storage) or are at least 32 bytes apart (for memory). These representations were cached per variable. The base variable, however, may be reassigned afterwards. The optimizer did not always notice and then compared an address computed from the old value of the base with an address computed from the new value as if both used the same base. As a result, it could consider two locations distinct even though they coincided at runtime, keeping a stale entry for a location that had just been overwritten. A subsequent load from that location could then be replaced with an outdated value, a subsequent store of that value to the location could be removed, and ``keccak256`` over the location could be replaced with the hash of an outdated value. Whether the bug is triggered depends on the structure of the intermediate code these optimizer steps receive. It is therefore sensitive to the optimizer sequence and to the surrounding code, and the two locations additionally have to coincide at runtime. In optimized IR code generation, any code may be affected, including code without inline assembly. In optimized evmasm code generation, only inline assembly that does not refer to any Solidity variables or functions and compiler-generated Yul utility functions could be affected. Unoptimized code is unaffected. Affected - - Solidity compiler (solc), 0.8.19 ≤ solc < 0.8.38 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.38+ - - Auditors: add this bug to version-specific checklists Source & attribution This 0xCERT advisory summarises Solidity compiler bug SOL-2026-7 (YulOptimizerKnowledgeBaseStaleBookkeeping) from the Solidity team's bug list: https://blog.soliditylang.org/2026/10/22/yul-optimizer-knowledge-base-stale-bookkeeping-bug/. References - ---------- - - https://blog.soliditylang.org/2026/10/22/yul-optimizer-knowledge-base-stale-bookkeeping-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----- wrsEARYKAG0FgmrQE+0JEDe9Tbcr+ZxrRRQAAAAAABwAIHNhbHRAbm90YXRp b25zLm9wZW5wZ3Bqcy5vcmcEp4iRPjR6EhfBzMbKW/kNxpw9UorjaDTi4eTM XLUEjxYhBGCkkFZbJcT5QWu27ze9Tbcr+ZxrAAAHxAEA2R8pvz7Qlqnlv4nx r8SM9ywN0AEO1ugquGmAqC/W1e0A/3gqcTMa63kZ5Jq2qlUHYX1hUvLQMsv8 eHpzzmuM9OoK =3QUt -----END PGP SIGNATURE-----