A high-severity bug in the Solidity compiler (versions 0.8.28–0.8.33) was reported by Hexens on 2026-02-11. When using the IR pipeline (--via-ir), contracts that delete both a transient and a persistent storage variable of the same type will have the compiler emit the wrong opcode (sstore instead of tstore, or vice versa) due to a naming collision in generated Yul helper functions. The root cause is that the helper function name is derived only from the type, not the storage location, so one implementation overwrites the other. This can cause unintended writes to persistent storage (e.g., zeroing out an owner variable) or failure to clear persistent state (e.g., approvals that cannot be revoked). Only three deployed contracts were found affected across all EVM chains. The bug is fixed in Solidity 0.8.34. As a workaround, directly assigning zero (e.g., _lock = 0) instead of using delete on transient variables avoids the issue.

11m read timeFrom soliditylang.org
Post cover image
Table of contents
Which Contracts Are Affected?The BugExamplesSeverity AssessmentReaction and PrecautionsTechnical DetailsAcknowledgements

Sort: