First high-severity Solidity compiler bug since 2016 discovered by Hexens, affecting all Solidity smart contracts with potential storage corruption.
Tech & Launches ·
Security firm Hexens disclosed a high-severity vulnerability in the Solidity compiler itself, marking the first such bug of that severity level since 2016. The issue, termed TSTORE Poison, stems from a cache key collision in the via-ir code generator that causes the compiler to emit incorrect storage opcodes when handling variable deletion. Affected versions span solc 0.8.28 through 0.8.33, and the defect went undetected for 18 months despite shipping in every release during that window. Hexens published a detailed technical analysis of the root cause and trigger conditions.
The flaw creates a dangerous mismatch: the compiler may instruct transient storage deletions to write to persistent storage instead, or vice versa, depending on function selector ordering. Neither direction is safe. The vulnerability produces no compiler warnings and generates bytecode that passes standard test suites, making silent detection nearly impossible without explicit auditing. Potential impacts range from fund drainage and ownership theft to access control bypasses and the permanent retention of token approvals.
The Solidity team released version 0.8.34 as a fix, requiring affected projects to upgrade the compiler, recompile their contracts, and redeploy. The exact number of deployed smart contracts exposed to storage corruption remains unquantified, though Hexens indicated plans to scan chains for ecosystem-wide impact assessment. The vulnerability highlights how compiler-level defects can propagate silently across the ecosystem without triggering detectable errors.