Critical Memory Corruption Bug Discovered in Solidity Code Generator Affecting Versions up to 0.8.37

A significant vulnerability has been uncovered within the Solidity code generator, affecting all versions of the prominent Ethereum smart contract programming language up to and including version 0.8.36. The flaw, which deals with memory management and byte array operations, causes unintended data corruption by improperly clearing 32 full bytes of memory instead of a single target byte when utilizing the delete operator on specific elements of in-memory bytes arrays.

Discovered on August 14, 2026, by researcher Shaheen Fazim through the Ethereum Foundation’s bug bounty program, the defect resides within the older, default evmasm compilation pipeline. While the vulnerability carries profound implications for smart contract integrity under specific conditions, developers have been reassured that a fix is already live in Solidity 0.8.37, and a comprehensive database scan indicates that no deployed production contracts are known to be actively compromised.

Understanding the Vulnerability

To comprehend the nature of the bug, one must examine how Solidity handles data structures in memory. Unlike most values in Ethereum Virtual Machine (EVM) memory that cleanly occupy full 32-byte words, packed byte arrays—namely bytes and string types—are structured differently. They consist of a 32-byte length descriptor followed immediately by raw data packed back-to-back without internal gaps.

Normally, when a developer wishes to clear a specific element within a byte array, they can either assign a zero value via b[i] = 0 or apply the native delete keyword via delete b[i]. While both programming constructs are logically intended to perform the exact same operation, they take fundamentally different paths in the compiler’s evmasm code generator.

The standard assignment path correctly utilizes a single-byte store operation (mstore8), ensuring that only the designated byte index is overwritten with zeros. However, the legacy delete code path inadvertently invokes a full 32-byte memory write. Because this write operation initiates at the target element’s exact memory offset rather than aligning with a standard 32-byte word boundary, it stretches far beyond the intended index. Consequently, it wipes out up to 31 subsequent bytes either further down within the same array or spilled over into whatever memory space happens to be allocated immediately afterward.

Crucially, the array’s internal length field remains untouched by this stray write. Because the length parameter does not change, subsequent operations—such as computing cryptographic hashes via keccak256, performing ABI encoding routines, or returning data to external callers—will unwittingly process the silently corrupted data.

Scope and Affected Pipeline Characteristics

The Solidity development team has assigned this vulnerability a severity rating of low-to-medium on their internal scale. Several precise conditions must align for a smart contract to be vulnerable. First, the contract must be compiled using the default evmasm pipeline. The modern IR (Intermediate Representation) pipeline is completely unaffected by the defect, as it handles the delete instruction through the correct single-byte storage route. Additionally, the use of the Solidity optimizer does not trigger, mitigate, or alter the bug; the fault lies fundamentally in the raw code emission stage.

Furthermore, the vulnerability is strictly confined to memory allocations. Byte arrays stored in persistent blockchain storage utilize an entirely separate, unaffected code path, and the delete operator cannot be applied to calldata arrays at all. Arrays whose elements occupy full, uncompressed words—such as bytes1[] memory—remain completely safe because they do not utilize packed data storage.

Only dynamic bytes arrays and UTF-8 string memory values (when explicitly cast to bytes via bytes(s)[i]) are susceptible. Standard fixed-size byte arrays like bytes32 are similarly immune because index access on those types returns an isolated copy of the byte rather than a mutable reference to the underlying memory location.

Technical Mechanics of Memory Overwriting

The extent of the damage caused by the delete instruction depends heavily on the array’s structural layout and its placement within memory. Solidity manages memory by continuously advancing a free memory pointer, meaning consecutive variable declarations sit flush against one another.

When dealing with padded arrays—such as those created via new bytes(n) or literal definitions—the compiler appends up to 31 zero bytes of padding at the end of the array to ensure subsequent memory allocations cleanly start on a fresh 32-byte word boundary. When a developer applies delete to an element near the beginning or middle of a padded array, the 32-byte zero write swallows up to 31 subsequent elements internally. If the delete operation targets one of the final elements near the end of the array, the overflow write can breach the array boundary entirely and spill over into whatever variable was allocated directly after it.

The situation is even more pronounced with unpadded arrays. Pipelines generated by operations like bytes.concat, string.concat, and the various abi.encode functions do not include trailing padding. Consequently, for unpadded arrays, deleting any of the final 31 elements will invariably corrupt the subsequent memory allocation, regardless of the array’s overall length. For small unpadded arrays comprising 31 bytes or fewer, this includes every single index, right down to the very first element.

Empirical Impact and Assessment

To measure the real-world exposure of this long-standing defect—which predates the very first official release of Solidity—developers conducted an extensive security scan. Researchers analyzed the Sourcify database, encompassing approximately 870,000 verified smart contract compilations, searching specifically for the problematic source code pattern.

The scan revealed that the vulnerable pattern appeared in a mere 17 total compilations, accounting for only two distinct functions across the entire dataset. Further analysis of those specific functions confirmed that neither was actually vulnerable in practice. In both instances, the bytes cleared within the array were either immediately discarded or written over anyway, while the overflow memory corruption landed either in safely bounded array lengths or in entirely unallocated memory spaces.

Despite these reassuring findings, diagnosing the bug in custom codebases can be challenging. The compiler emits no warnings during compilation, and affected contracts do not trigger EVM reverts at runtime. Instead, the defect manifests silently as incorrect mathematical computations, corrupted string data, or altered state logic, making thorough unit testing and compiler version auditing vital for development teams.

Remediation and Recommended Actions

The discovery prompted the immediate release of Solidity version 0.8.37. The core patch rectifies the underlying discrepancy in the compiler backend by forcing the delete instruction path to consult the element’s actual width. By routing delete b[i] through the same single-byte store mechanism (mstore8) already utilized by standard array assignments, the fix ensures absolute behavioral consistency between both pipelines.

Smart contract developers utilizing legacy versions up to 0.8.36 are strongly encouraged to upgrade their compiler toolchains to version 0.8.37 or later. Projects relying on the default evmasm compilation pipeline should audit their codebase for any instances where the delete operator is applied to indexed elements of in-memory bytes or string arrays, substituting them with explicit zero-assignments or migrating compilation workflows to the IR pipeline where appropriate.

The Ethereum Foundation and the Solidity core team expressed their gratitude to security researcher Shaheen Fazim for responsibly disclosing the vulnerability through the official bug bounty program and providing a clear, reproducible test case.