By Evan Lee Salim 
Developers working with Ethereum’s Solidity smart contract language are being urged to update their compiler versions following the disclosure of a long-standing memory corruption vulnerability. The bug, which impacts code generated through the traditional evmasm pipeline, causes the delete operator to misbehave when applied to individual elements of memory-based bytes or string arrays. Instead of clearing a single byte as intended, the generated bytecode issues a full 32-byte zero write, inadvertently wiping out adjacent data structures in memory.
The vulnerability was discovered and reported on August 14, 2026, by researcher Shaheen Fazim through the official Ethereum Foundation bug bounty program. According to the core Solidity development team, the affected code path predates the very first official release of the language. Consequently, all versions of Solidity up to and including version 0.8.36 are vulnerable. The issue has been formally addressed and patched in Solidity version 0.8.37.
Understanding the Vulnerability and Code Generation Flaw
To understand how the bug manifests, developers must look closely at how Solidity manages dynamic memory allocation. Most data types in Ethereum Virtual Machine (EVM) memory occupy a full 32-byte word. Dynamic byte arrays (bytes) and strings represent a notable exception to this rule. In memory, a byte array consists of an initial 32-byte length field followed sequentially by the raw data elements, packed tightly back to back without internal gaps.
Solidity allocates memory dynamically by advancing a free memory pointer, meaning that consecutive declarations sit flush against one another. Normally, because byte array elements are single bytes, storing a value to memory is handled via a single-byte store operation (mstore8) when the compiler knows the exact width of the element. However, an inconsistency in the code generator’s internal logic treated the delete path differently than standard assignments.
While an explicit assignment such as b[i] = 0 correctly invokes the single-byte store and alters only the targeted index, using the delete operator on the same element (delete b[i]) triggers a full-word 32-byte zero write. Because this write initiates at the specific index of the array element rather than aligning with a standard 32-byte memory boundary, it spills forward, overwriting subsequent bytes.
The implications of this behavior depend heavily on where the deleted element resides within the array and whether the array itself is padded. The evmasm pipeline handles memory padding differently depending on how the array was initialized. Arrays created using new bytes(n) or literal values typically include up to 31 zero bytes of padding at the end to ensure the next memory allocation begins cleanly on a word boundary. Conversely, unpadded arrays—such as those generated by functions like bytes.concat, string.concat, and various abi.encode variants—end precisely where the next memory allocation starts, leaving no buffer whatsoever.
When a developer applies delete to an element inside a padded array, the corruption is often absorbed partially by the trailing padding bytes, provided the deletion does not occur near the tail end of the array. But when elements near the end of a padded array—or any element within an unpadded array—are targeted, the 32-byte zero write breaches the boundary of the array entirely. It spills directly into whatever variable, structure, or pointer happens to be allocated next in memory.
Scope of Impact and Sourcify Database Analysis
The Solidity team evaluated the real-world risk of the vulnerability by conducting a comprehensive scan of the Sourcify database, which contains roughly 870,000 verified smart contract compilations. The objective was to search for source code patterns that explicitly invoke the vulnerable delete pattern on memory byte arrays.
The scan revealed that the problematic pattern appeared in a mere 17 total compilations across the entire dataset, encompassing only two distinct functions. Furthermore, a deeper severity assessment concluded that neither of those functions was actively compromised in a dangerous manner. In both instances, the corrupted bytes within the array were either immediately discarded or deleted anyway, while writes extending past the arrays landed either in safely isolated memory lengths or unallocated space. Consequently, the core team assigned the vulnerability a severity rating of low-to-medium, noting that no deployed smart contracts are currently known to have suffered malicious exploitation from the bug.
Despite the low frequency in verified public sources, developers are cautioned that the bug can be difficult to diagnose during standard testing phases. The compiler emits no warning flags when processing the vulnerable code, and the EVM does not trigger a runtime revert. Instead, contracts execute successfully while silently returning corrupted or altered data, making the defect insidious for applications that rely heavily on string manipulation or binary data parsing in memory.
The vulnerability is strictly isolated to the default evmasm code generation pipeline. The modern IR (Intermediate Representation) compilation pipeline, which utilizes a different internal architecture for handling memory operations, remains entirely unaffected. Furthermore, enabling or disabling the Solidity optimizer has no bearing on whether the bug manifests, as the faulty semantics are baked directly into the base instructions emitted by the code generator.
Technical Demonstration and Contract Behavior
The mechanics of the bug can be clearly observed in controlled contract environments where memory layout is predictable. Consider a contract featuring structures or arrays declared consecutively. If a developer allocates a small byte array, deletes an element near the beginning, and returns the array, the corruption remains internal.
In a demonstration function clearing an element in a short byte array, the 32-byte zero write clears out multiple adjacent bytes that were never intended to be touched. More critically, when the delete operation targets the final elements of an unpadded array or an array placed directly adjacent to a complex data structure—such as a uint256 integer—the trailing bytes of the zero write overwrite the most significant bytes of the neighboring variable. This can drastically alter numeric values, transforming maximum integer boundaries into fractional or trivial numbers without triggering any exception.
Developers who utilize string data types must also remain vigilant. While direct index deletion like delete s[i] is not permitted by the compiler for standard memory strings, strings can be explicitly type-cast into byte arrays using bytes(s). Executing delete bytes(s)[i] routes the operation through the same vulnerable code path, modifying the underlying string memory in place and introducing identical corruption risks.
Recommended Actions and The Fix
The permanent resolution for this vulnerability is implemented in Solidity version 0.8.37. The fix updates the compiler’s code generation logic so that the delete path properly queries the element width, ensuring it emits the precise single-byte store (mstore8) rather than a full-word instruction. As a result, delete b[i] and b[i] = 0 now produce identical, correct byte-level behavior across both compilation pipelines.
Smart contract developers and project maintainers are strongly advised to upgrade their toolchains to Solidity 0.8.37 or later. Projects that cannot immediately upgrade should audit their codebases to verify whether delete operations are ever performed on individual elements of memory-based bytes or string arrays. If such patterns exist, developers should refactor their logic to use explicit assignments or alternative clearing mechanisms until an upgrade can be safely completed.
The discovery underscores the ongoing importance of rigorous code auditing and the value of community-driven security research facilitated through programs like the Ethereum Foundation bug bounty initiative.
Asep Darmawan 
Raul Delapena Setiawan 
rifanmuazin