A critical code generation defect has been uncovered in Solidity, the primary programming language for writing smart contracts on the Ethereum blockchain. The vulnerability, which affects the default code generation pipeline, causes the deletion of a single element within a memory-based byte array to inadvertently overwrite up to 32 bytes of memory. This unexpected behavior can corrupt adjacent data structures within smart contracts, leading to silent calculation errors, unexpected outputs, or compromised application logic. Fortunately, a patch has been swiftly deployed by the Solidity development team, and developers are being urged to upgrade their compiler versions to mitigate potential risks.
The security issue was officially brought to light on August 14, 2026, when developer Shaheen Fazim reported the bug through the Ethereum Foundation’s bug bounty program. Fazim provided a precise reproduction case that demonstrated how the code generator handles memory allocations. When the delete operator is applied to an element of a bytes array located in memory, the underlying compiler logic incorrectly generates a 32-byte zero write starting precisely at the targeted element. Rather than clearing a single byte, the operation cascades forward, wiping out up to 31 subsequent bytes. These overwritten bytes can either reside further down the same array or spill over into whatever data structure happens to be allocated immediately after it in memory.
Interestingly, the equivalent manual assignment operation, such as setting b[i] = 0, remains completely unaffected by the defect. It correctly targets and clears exactly one byte without impacting neighboring memory spaces. The discrepancy arises because the compiler’s internal delete path and assignment path diverge in how they issue memory stores for packed byte arrays.
Following the initial disclosure, the Solidity team assigned the vulnerability a severity rating of low to medium on their internal scale. Several mitigating factors contribute to this assessment. First, the bug is strictly isolated to the default evmasm compilation pipeline. Contracts compiled using the modern IR (Intermediate Representation) pipeline are entirely unaffected. Furthermore, the activation of the Solidity optimizer is not required to trigger the bug, meaning that unoptimized builds are just as vulnerable as optimized ones.
An extensive historical analysis conducted by the core development team revealed that the affected code path actually predates the very first official release version of Solidity. Consequently, all versions of the compiler up to and including version 0.8.36 are susceptible to the bug. To gauge the real-world impact of the vulnerability, the team scanned the Sourcify database, which contains approximately 870,000 verified smart contract compilations. They searched specifically for the exact source pattern capable of triggering the issue.
The results of the scan showed that the vulnerable pattern appeared in a mere 17 compilations across the entire dataset. These compilations encompassed only two distinct functions, and a deeper forensic analysis confirmed that neither of the deployed functions was actually compromised in a harmful way. In one instance, the corrupted bytes within the array were subsequently discarded or overwritten anyway, while the overflow into adjacent memory landed in unused space. At the time of the disclosure, no deployed smart contracts in the wild were known to have suffered malicious exploitation or unintended failures as a result of the bug.
To determine whether a specific smart contract is vulnerable, developers must verify several intersecting conditions. A contract is only exposed if it meets a precise set of criteria related to its compilation settings, source code structure, and memory layout. Specifically, the contract must be compiled using the default evmasm pipeline with any version up to 0.8.36. It must also utilize memory-based dynamic byte arrays or string conversions and actively invoke the delete operator on specific elements within those arrays.
The Solidity team has emphasized that if a smart contract never applies the delete operator to an element of a bytes or string value residing in memory, it is completely immune to the defect. Moreover, neither the optimizer settings nor the target EVM version can prevent or alter how the bug manifests. The defect is structurally embedded in the code emitted during the codegen phase, and the optimizer blindly preserves those faulty operational semantics.
To fully understand the mechanics of the bug, it is helpful to look closely at how Solidity manages memory allocation. Most data types in Solidity memory consume a full 32-byte word. Dynamic byte arrays (bytes) and string types are the notable exceptions. A memory byte array consists of an initial 32-byte length field immediately followed by the raw data bytes packed tightly back-to-back without internal padding.
Solidity allocates memory sequentially by advancing a global free memory pointer, ensuring that consecutive allocations sit flush against one another. To maintain word alignment for subsequent operations, the compiler often appends up to 31 bytes of zero padding at the end of an allocation. However, certain modern constructs—such as arrays generated via bytes.concat, string.concat, and various abi.encode functions—produce unpadded allocations where the data ends precisely where the next memory allocation begins.
When developers apply delete to an array element, the compiler attempts to assign the default zero value of that type. In a standard assignment like b[i] = 0, the compiler uses an mstore8 instruction when it knows the element width is a single byte. However, the legacy evmasm code generation path for the delete operation mistakenly bypassed this element-width check, treating the targeted index as a full-word operation and issuing a 32-byte zero write (mstore).
Because this write initiates at the specific index of the array element rather than aligning with a 32-byte word boundary, it spills forward. If the deletion occurs near the end of a padded array, the overflow is partially absorbed by the padding. If the array has no padding—such as those produced by unpadded concatenation functions—or if the deletion targets one of the final 31 elements of a padded array, the 32-byte zero write breaches the boundaries of the array and overwrites whatever data structure occupies the subsequent memory slot.
Consider a scenario where a smart contract declares a dynamic bytes array alongside a complex struct or integer variable in memory. If an element near the tail end of the array is deleted, the cascading zero write will overwrite the leading bytes of the neighboring variable. For right-aligned types like uint256 integers, the most significant bytes are wiped out, drastically altering the numeric value stored in memory without triggering any runtime errors or compiler warnings.
The Solidity core team addressed this vulnerability directly in version 0.8.37. The fix modifies the code generator’s delete path so that it correctly consults the element width, ensuring it emits a single-byte store (mstore8) for packed byte arrays just as it does for standard assignments. As a result, both delete b[i] and b[i] = 0 now execute identically across all compilation pipelines.
Developers maintaining existing codebases using vulnerable compiler versions are strongly encouraged to upgrade to Solidity 0.8.37 or later. For projects unable to upgrade immediately, developers should audit their codebases to identify and replace any instances where the delete operator is applied to individual elements of memory-based bytes or string arrays, substituting them with explicit zero assignments or alternative data manipulation techniques.
The discovery and resolution of this issue highlight the ongoing effectiveness of the Ethereum Foundation’s bug bounty program and the vigilance of the broader developer community in maintaining the security and integrity of core blockchain tooling.
