A significant code generation bug has been discovered in Solidity, the primary programming language for writing smart contracts on the Ethereum blockchain. The vulnerability, which affects memory-based byte arrays, causes the delete operator to overwrite significantly more memory than intended. While the bug has been rated with a low-to-medium severity level and currently shows no evidence of exploitation in deployed smart contracts, it highlights subtle memory management pitfalls in low-level EVM compilation paths.
The issue was formally brought to light on August 14, 2026, when developer Shaheen Fazim identified the unexpected behavior in the Solidity code generator. Fazim promptly reported the flaw through the Ethereum Foundation’s official bug bounty program, providing a reproducible test case that allowed core developers to trace the defect back to its roots in the compiler’s architecture.
Understanding the Memory Corruption Defect
To grasp the nature of the bug, developers must understand how Solidity manages memory allocations. Most data types in Ethereum Virtual Machine (EVM) memory occupy clean, full 32-byte words. Dynamic byte arrays (bytes) and strings, however, are exceptions to this rule. A memory byte array consists of a 32-byte length header followed immediately by packed byte data, packed back-to-back without internal gaps.
Solidity allocates memory sequentially by shifting the free memory pointer forward. When a developer applies the delete operator to a specific element within a memory byte array—such as writing delete b[i]—the developer reasonably expects the operation to behave identically to assigning zero to that specific index (b[i] = 0).
Under the hood, however, the default evmasm compilation pipeline diverged significantly in how it handled these two operations. While regular index assignment correctly utilized a single-byte store (mstore8), the code path generated for the delete instruction erroneously issued a full 32-byte zero write starting directly at the target element’s memory address.
Because this write begins at the index location rather than aligning with a 32-byte word boundary, it does not confine itself to the intended element. Instead, it overwrites up to 31 subsequent bytes. Depending on where the deleted element sits, this stray memory wipe either corrupts the remaining elements within the same array or spills past the array’s boundaries entirely, destroying data belonging to whatever variable or structure happens to be allocated next in memory. Notably, the array’s length field, which resides preceding the data, remains untouched, meaning the contract continues to read the corrupted data structure blindly during subsequent operations like hashing or ABI encoding.
Scope and Affected Versions
The scope of this compiler defect is broad in terms of historical versions but narrow in terms of actual execution pathways. The affected code path within the Solidity compiler actually predates the very first publicly released version of the language. Consequently, all compiler versions up to and including version 0.8.36 are vulnerable. The bug was successfully patched and resolved in Solidity 0.8.37.
Several key conditions must align for a smart contract to be vulnerable. First, the contract must be compiled using the default evmasm pipeline. Contracts compiled using the modern IR (Intermediate Representation) pipeline are completely unaffected, as the IR backend routes delete operations through the same secure code path as standard assignments. Second, the defect is strictly limited to byte arrays (bytes) or string data types residing in memory. Byte arrays stored in persistent blockchain storage (storage) utilize an entirely independent code path and remain safe. Similarly, calldata parameters and fixed-size byte arrays like bytes1[] or primitive bytesNN types are unaffected because their elements occupy full, uncompressed words or behave as value copies rather than direct memory references.
The bug is also agnostic toward the Solidity optimizer; enabling or disabling the optimizer does not prevent the compiler from emitting the faulty instructions.
Analysis of Real-World Risk and Severity Assessment
To evaluate the real-world danger posed by this vulnerability, security analysts scanned the Sourcify database, a massive repository containing approximately 870,000 verified smart contract compilations. The search specifically hunted for source code patterns that could trigger the memory-wiping defect.
The scan revealed that the vulnerable pattern appeared in only 17 distinct compilations across the entire dataset, involving just two unique functions. Further inspection by the Solidity team determined that neither of those functions was actually vulnerable in practice. In one instance, the corrupted bytes inside the array were discarded immediately afterward, while in the other, the memory region immediately following the array remained completely unallocated at the time of execution, causing the stray write to land harmlessly in unused space.
Furthermore, a comprehensive review of public blockchain data yielded no known instances of deployed smart contracts suffering from malicious exploitation or accidental funds loss due to this bug. Because the defect manifests as silent data corruption rather than a visible runtime revert or compilation error, it could theoretically be difficult to debug in custom testing suites. However, standard unit tests checking array transformations under the evmasm pipeline would typically expose the unexpected state changes.
Technical Illustration of Memory Overwrite
To demonstrate how the bug manifests, consider a simplified contract structure where multiple variables are declared sequentially, forcing the EVM to place them adjacently in memory.
contract C
struct S uint256 x;
function clearElement() public pure returns (bytes memory)
bytes memory d = hex"0102030405";
delete d[0];
return d;
function clearLastElement() public pure returns (uint256)
bytes memory b = new bytes(32);
S memory s = S(type(uint256).max);
delete b[31];
return s.x;
When compiled under the vulnerable evmasm pipeline, executing clearElement does not merely clear the first byte, leaving hex"0002030405". Instead, the 32-byte zero write sweeps across the entire five-byte array and its internal padding, returning hex"0000000000".
In the second function, clearLastElement, deleting the final element of a 32-byte unpadded array causes the 32-byte zero write to bleed directly into the memory allocated for the adjacent structure s. Because Solidity integers store their most significant bytes first, the overwrite wipes out the upper 31 bytes of type(uint256).max, leaving only the lowest byte intact and causing the function to erroneously return 255 instead of the maximum possible integer value. Replacing the delete statements with explicit zero assignments (d[0] = 0 and b[31] = 0) avoids this behavior entirely across all tested versions.
The Fix and Recommended Actions
With the release of Solidity 0.8.37, the core development team resolved the discrepancy by updating the delete code path to consult element widths precisely the way assignment operations do. When clearing an element inside a packed memory byte array, the compiler now correctly emits a single-byte store (mstore8) rather than a full-word memory write, ensuring absolute semantic parity between delete b[i] and b[i] = 0.
Developers maintaining codebases on older versions of Solidity are strongly advised to audit their smart contracts for instances where the delete keyword is applied to individual indices of memory-based bytes or string variables. Upgrading the compiler toolchain to version 0.8.37 or later, or switching compilation configurations to the IR pipeline where applicable, completely eliminates the underlying vulnerability.
The Solidity team expressed gratitude to security researcher Shaheen Fazim for discovering the bug, validating the code path, and submitting the report through the Ethereum Foundation bug bounty ecosystem, allowing the issue to be addressed proactively before causing disruption in the broader decentralized finance ecosystem.
