A longstanding and subtle code-generation bug within the Solidity programming language has been identified and officially resolved. The vulnerability, which affects how memory-resident bytes and string arrays handle element-level deletions under the default compiler pipeline, remained hidden since before the release of the very first version of Solidity. Fortunately, comprehensive security assessments and automated scans of public databases indicate that the real-world exploitation risk remains exceptionally low, and no deployed smart contracts have been identified as impacted.
The issue was formally brought to light on August 14, 2026, when developer Shaheen Fazim submitted a bug report through the Ethereum Foundation’s official bug bounty program. The defect specifically impacts the default evmasm compilation pipeline, while the modern IR (Intermediate Representation) pipeline remains entirely unaffected. Furthermore, invoking or disabling the Solidity optimizer plays no role in triggering the behavior, as the root cause lies intrinsically within the foundational code emission stage of the compiler.
Understanding the Vulnerability Mechanics
To comprehend how the bug manifests, one must examine how Solidity structures data types in Ethereum Virtual Machine (EVM) memory. The vast majority of values in EVM memory consume full 32-byte words. Dynamic byte arrays (bytes) represent a notable exception, consisting of a 32-byte length header followed immediately by back-to-back packed data bytes without internal gaps.
Memory allocation in Solidity relies on advancing the free memory pointer. Each new allocation begins precisely where the preceding one concludes. Consequently, consecutive memory allocations sit flush against one another, meaning any write operation that accidentally spills past the allocated boundary of one structure overwrites whatever data resides immediately afterward in memory.
When developers apply the delete operator to an entire dynamic byte array, the compiler executes a dedicated, correct code path. Similarly, assigning a zero value directly to an individual array element via an explicit assignment statement—such as writing b[i] = 0—correctly issues a single-byte store (mstore8) operation that clears precisely one byte.
However, a distinct code path is invoked when applying the delete operator to a specific element within a memory byte array, such as delete b[i]. In the affected versions of the default evmasm pipeline, this specific operation erroneously emits a full 32-byte zero-write starting directly at the target element’s memory address rather than utilizing a single-byte clear. Because the write initiates at the element’s position rather than aligning with a standard 32-byte word boundary, it spills far forward, clearing up to 31 subsequent bytes.
This unintended behavior introduces two distinct types of data corruption: internal corruption within the array itself and external corruption leaking into adjacent memory allocations.
Internal and External Memory Corruption
When a developer executes an element deletion on a memory byte array, every subsequent element within the array—up to a maximum of 31 following bytes—is inadvertently wiped out and replaced with zeros. Unless the array happens to consist entirely of zero-value padding beyond the targeted index, this alters the array’s contents immediately upon execution. Because the array’s length header located prior to the data remains untouched, the structure preserves its original length value, causing downstream operations like hashing via keccak256, ABI encoding, or external function returns to process corrupted data.
The situation becomes even more precarious when the deletion targets elements situated near the very end of an array. Memory layouts in Solidity often incorporate padding to ensure subsequent allocations begin on clean word boundaries. Arrays created via standard constructors or literals typically feature up to 31 zero bytes of padding. However, unpadded arrays—such as those produced by functions like bytes.concat, string.concat, and various abi.encode variants—lack this protective padding entirely.
When a deletion reaches past the conclusion of a padded or unpadded array, the 32-byte zero write spills directly into whatever data structure was allocated next in memory. Depending on whether the adjacent memory holds left-aligned values like bytesN types or right-aligned values like integers, addresses, or memory pointers, the consequences vary. Right-aligned integers, for instance, have their leading bytes systematically zeroed out, radically altering numeric values without triggering any runtime exceptions, revert statements, or compiler warnings.
Scope, Version History, and Severity Assessment
The code path responsible for this flaw predates the inaugural public release of Solidity. Consequently, every compiler version up to and including version 0.8.36 is affected. The vulnerability was definitively patched with the release of Solidity 0.8.37, which alters the delete code path to properly consult the element width and consistently emit single-byte stores (mstore8) in parity with standard assignment operations.
To gauge the real-world impact of the vulnerability, security researchers conducted an automated scan of the Sourcify database, analyzing approximately 870,000 verified smart contract compilations for the specific source pattern capable of triggering the bug. The pattern surfaced in a mere 17 compilations, encompassing only two distinct functions. Further manual auditing revealed that neither function was actually vulnerable in practice; in one instance, the wiped bytes were entirely discarded or subsequently overwritten, while the second instance involved an array that never grew large enough to reach adjacent memory, or encountered empty memory space upon execution.
The Ethereum Foundation classifies this issue at a low-to-medium severity level on its internal scale. Because the bug manifests silently as unexpected data corruption rather than a dramatic execution revert or compilation failure, developers are advised to upgrade their toolchains to Solidity 0.8.37 or later immediately. Projects relying on affected versions that utilize memory byte array element deletions should review their test suites and memory management logic to ensure data integrity across all deployment pipelines.
