A significant memory corruption vulnerability has been discovered within the Solidity code generator, impacting all historical versions of the programming language up to and including version 0.8.36. Disclosed publicly following a bug report submitted through the Ethereum Foundation’s bug bounty program, the defect involves how the compiler handles the delete operator when it is applied to specific elements of dynamic byte arrays residing in memory. Under certain conditions, the generated machine code inadvertently overwrites adjacent memory spaces, posing potential integrity risks for smart contracts executing on the Ethereum Virtual Machine.
The issue was formally brought to light on August 14, 2026, by researcher Shaheen Fazim. According to the analysis provided by the Solidity core development team, the vulnerability is strictly confined to the default evmasm compilation pipeline. Contracts compiled using the modern IR (Intermediate Representation) pipeline remain completely safe from the defect. Furthermore, the presence or absence of the Solidity optimizer does not influence whether the bug is triggered, as the underlying semantic flaw exists fundamentally within the code generation phase itself.
Understanding the Vulnerability Mechanics
To comprehend the scope of the vulnerability, developers must examine how dynamic memory arrays, specifically bytes and string types, are structured under the hood in Solidity. Unlike standard value types or arrays of fixed widths—such as bytes1[]—which allocate a full 32-byte word for every individual element, packed byte arrays store their elements consecutively back-to-back immediately following a 32-byte length header.
When a developer wishes to clear an individual element within a standard array, they might choose to write an explicit assignment, such as b[i] = 0, or utilize the language’s built-in delete operator, writing delete b[i]. Under normal operating conditions, both operations are expected to yield identical results: clearing precisely one byte of data at the specified index.
However, the legacy evmasm code generator routes these two instructions down entirely separate implementation paths. While an explicit assignment correctly issues a single-byte store operation (mstore8), the delete pathway erroneously emits a full 32-byte zero write starting directly at the index of the targeted element. Because the write operation initiates at the specific byte location rather than conforming to a 32-byte word boundary, it spills far beyond its intended target.
This results in a dual-faceted corruption pattern. First, the write clears up to 31 subsequent bytes located further down the same array. Second, if the deleted element resides near the trailing end of the array, the overflow write punches straight past the array’s boundaries and corrupts whatever data happens to be allocated immediately afterward in memory.
Scope of Impact and Affected Configurations
The vulnerability affects a broad historical range of the Solidity ecosystem, with the flawed code path dating back prior to the very first official release of the language. All compiler versions up to and including 0.8.36 are susceptible, while the bug has been fully patched in version 0.8.37.
To determine whether a specific smart contract is vulnerable, developers must verify that multiple distinct conditions are met simultaneously. Crucially, the contract must be compiled using the default evmasm pipeline rather than the IR pipeline. The source code must invoke the delete operator specifically on an element of a memory-bound bytes or string type.
It is important to clarify that whole-array deletions, such as calling delete b on an entire array, utilize an entirely separate and correct code path and are therefore unaffected. Similarly, byte arrays residing in blockchain storage (storage) are completely immune, as are calldata arrays, which do not permit the delete operation. Furthermore, arrays whose elements occupy distinct 32-byte memory words—such as bytes1[] memory—do not experience this issue because their elements are not tightly packed.
String values, while not supporting direct index deletion natively, can easily encounter the bug if the string is explicitly cast to a byte array, such as executing delete bytes(s)[i]. Because the cast creates a direct reference to the existing memory space rather than a copy, the subsequent deletion modifies the underlying string data in place and triggers the identical memory overflow.
Technical Nuances of Memory Layout and Overwrites
Memory allocation in Solidity operates by sequentially advancing a free memory pointer, ensuring that consecutive allocations sit flush against one another. Depending on how an array is instantiated, it may include internal padding. Arrays created via standard constructors like new bytes(n) or populated from hardcoded literals generally include up to 31 bytes of trailing zero padding to ensure that subsequent allocations align neatly on 32-byte word boundaries.
Conversely, certain modern constructs—including bytes.concat, string.concat, and the family of abi.encode functions—produce unpadded arrays. In these unpadded instances, the data ends precisely where the next memory allocation begins, leaving zero buffer space to absorb an errant write.
When a padded array experiences a delete operation on one of its elements, the trailing padding absorbs part of the 32-byte zero-write. Consequently, only deletions performed on the final 31 elements of an array can potentially reach past the allocation boundary. The exact number of vulnerable elements depends entirely on the array’s length. For instance, arrays whose lengths are clean multiples of 32 possess zero padding, meaning any deletion among their final 31 elements will inevitably overflow into subsequent memory.
When an overflow breaches the boundary of the array, it impacts whatever variable or data structure was allocated next. Because Solidity handles variable alignment by placing left-aligned types like bytesN at the start of a word and right-aligned types like integers, addresses, and pointers at the end of a word, the nature of the corruption varies. For right-aligned variables such as large integers, a 32-byte zero write can obliterate the most significant bytes, drastically altering numerical values while leaving lower bytes intact.
Practical Demonstration and Observed Behavior
To illustrate the concrete impact of the bug, consider a smart contract containing a tightly packed memory array alongside an adjacent data structure. In a controlled test environment using vulnerable compiler settings, invoking a function that deletes an element near the beginning of a short array clears not only that single element but inadvertently wipes out all subsequent elements within the same structure.
Similarly, when a deletion is executed on the final element of a 32-byte padded array sitting adjacent to a maximum-value 256-bit unsigned integer (uint256), the 31-byte overflow zeroes out the most significant bytes of that integer. Rather than evaluating to its true maximum limit, the corrupted variable silently collapses to a value of 255. Because the compiler issues no runtime reverts or compilation warnings, these silent modifications can easily bypass standard test suites unless developers explicitly validate internal memory states following array manipulation operations.
Severity Assessment and Ecosystem Prevalence
The Solidity development team has classified this vulnerability with a low-to-medium internal severity rating. The primary factor mitigating widespread real-world exploitation is that the bug manifests as a silent data corruption rather than an immediate transaction failure or unauthorized access vector, requiring highly specific structural conditions to alter contract logic maliciously.
To gauge potential real-world exposure, the development team conducted an automated scan of the Sourcify verified compilation database, analyzing roughly 870,000 verified smart contract compilations for the exact source pattern capable of triggering the defect. The search identified the vulnerable pattern in a mere 17 compilations, encompassing only two distinct functions across the entire dataset. Further security analysis revealed that neither of those two functions was actually exploitable in practice; in one instance, the corrupted bytes were subsequently discarded or overwritten, while in the other, the memory following the array remained entirely unused at the time of execution. No deployed production contracts are currently known to have suffered malicious exploitation as a result of this vulnerability.
Remediation and Recommended Actions
The discovery of this long-standing defect prompted an immediate release of Solidity version 0.8.37, which implements the definitive fix. The core patch corrects the delete code generation pathway, forcing the compiler to correctly consult the element’s actual width and emit the proper single-byte store (mstore8) instruction rather than a full-word write. Consequently, delete b[i] and b[i] = 0 now execute with identical semantics across both the evmasm and IR compilation pipelines.
Developers maintaining existing smart contracts built on versions 0.8.36 and earlier are strongly urged to review their codebase for memory-based byte and string array manipulations. The most robust remediation strategy is to upgrade the project’s compiler version to Solidity 0.8.37 or later. Alternatively, developers unable to upgrade immediately can audit their code to ensure that the delete operator is never invoked on individual elements of memory-resident bytes or string arrays, substituting explicit single-byte assignments or utilizing the IR pipeline where feasible.
The Solidity core team expressed their gratitude to security researcher Shaheen Fazim for responsibly identifying the bug through the Ethereum Foundation’s bug bounty program and supplying a functional reproduction case that enabled a swift and accurate resolution.
