Developers working within the Ethereum ecosystem have been urged to update their compiler toolchains following the disclosure of a long-standing memory corruption vulnerability in the Solidity programming language. The bug, which impacts how the compiler handles the deletion of individual elements within in-memory byte arrays and strings, remained hidden within the core codebase for years before being brought to light through the Ethereum Foundation\u2019s official bug bounty program. <\/p>\n
Discovered and reported by researcher Shaheen Fazim on August 14, 2026, the defect stems from a discrepancy in the code generation stage under the default evmasm compilation pipeline. When developers apply the standard delete<\/code> operator to a specific index of a bytes<\/code> or string<\/code> array located in memory, the generated bytecode erroneously issues a full 32-byte zero write starting precisely at that target element. This unexpected behavior vastly oversteps the intended scope of clearing a single byte, overwriting up to 31 subsequent bytes either further down within the same array or spilling over entirely into whatever data structure happens to be allocated immediately following it in memory.<\/p>\n
The core issue poses a unique challenge because it breaks a fundamental expectation of the language: that applying delete<\/code> to an array element should be functionally identical to manually assigning the zero value to that same index. However, testing has confirmed that equivalent direct assignments, such as writing b[i] = 0<\/code>, remain entirely unaffected and correctly modify only a single byte. <\/p>\n
Scope of the Vulnerability and Affected Versions<\/h3>\n
According to the technical assessment conducted by the Solidity development team, the vulnerability is classified as having a low-to-medium severity rating on their internal scale. The flawed code path is deeply embedded in the history of the compiler, having predated the very first official public release of Solidity. Consequently, every single version of the compiler up to and including version 0.8.36 is susceptible to the bug. <\/p>\n
Fortunately, the issue is strictly isolated to the default evmasm compilation pipeline. Projects utilizing the modern IR (Intermediate Representation) pipeline are completely unaffected. Furthermore, the presence or absence of the Solidity optimizer does not influence whether the bug manifests, as the compiler’s code generator emits the faulty instruction sequence regardless of optimization settings. <\/p>\n
The bug specifically targets dynamic byte arrays and strings resident in memory. Byte arrays stored in contract storage utilize an entirely separate, secure code path and are immune to this behavior. Similarly, fixed-size byte arrays like bytes1[]<\/code> that allocate a full word per element are unaffected, as are calldata arrays, to which the delete<\/code> operator cannot be applied in the first place. Strings, while utilizing a variable-length UTF-8 encoding that prevents direct index access, can be explicitly typecast to bytes<\/code>\u2014for instance, delete bytes(s)[i]<\/code>\u2014which subsequently triggers the exact same memory corruption sequence.<\/p>\n
Technical Mechanics and Memory Layout<\/h3>\n
To understand how the vulnerability manifests during contract execution, one must examine how Solidity manages memory allocation. Unlike most data types in Solidity memory, which occupy a standardized full 32-byte word, dynamic bytes<\/code> and string<\/code> arrays store their data back-to-back immediately following a 32-byte length field, without intervening padding gaps. <\/p>\n
Solidity allocates memory sequentially by advancing a global free memory pointer. As a result, consecutive allocations sit flush against one another. To maintain word alignment for subsequent operations, the compiler traditionally appends up to 31 zero bytes of padding to the end of certain memory allocations, creating what the development team defines as "padded" arrays. However, certain modern operations\u2014including bytes.concat<\/code>, string.concat<\/code>, and the entire suite of abi.encode*<\/code> functions\u2014generate "unpadded" arrays where the data ends precisely where the next memory allocation begins.<\/p>\n
When a standard assignment like b[i] = 0<\/code> is executed on a byte array, the compiler correctly references the element’s width and executes a single-byte store instruction (mstore8<\/code>). In contrast, the delete b[i]<\/code> execution path within the evmasm pipeline historically bypassed this check, incorrectly executing a full 32-byte word write (mstore<\/code>) beginning at the index of the deleted element. <\/p>\n<\/figure>\n
Because this 32-byte write initiates at the specific byte index rather than at an aligned 32-byte boundary, it radiates forward through memory. If the deletion occurs inside the array, it wipes out up to 31 subsequent elements, replacing them with zeros while leaving the array’s recorded length field intact. This means functions that subsequently read the array\u2014such as hashing algorithms via keccak256<\/code>, ABI encoding routines, or external function returns\u2014will unknowingly process corrupted data.<\/p>\n
When the deletion targets one of the final elements of an array, the write can easily breach the boundaries of the array’s memory allocation. For padded arrays, the trailing padding absorbs part of the zero-write, limiting the spillover depending on the array’s total length. However, for unpadded arrays or arrays with lengths that are exact multiples of 32, deleting any of the last 31 elements causes the zero-write to land directly at the beginning of the subsequent memory allocation.<\/p>\n
Depending on the memory layout of adjacent variables, this overflow can corrupt complex data structures, structs, or variables declared immediately after the array. For instance, left-aligned values will have their most significant bytes zeroed out, while right-aligned values such as integers or addresses may experience partial or total truncation depending on the size of the write and the width of the data type.<\/p>\n
Real-World Risk and Ecosystem Impact<\/h3>\n
Despite the severity of potential memory corruption, extensive analysis suggests that the real-world risk to deployed decentralized applications is remarkably low. Following the bug disclosure, the Solidity team collaborated with verification platforms to scan the comprehensive Sourcify database, which indexes roughly 870,000 verified smart contract compilations. <\/p>\n
The automated scan specifically searched for source patterns capable of triggering the vulnerability. Out of nearly a million verified compilations, the triggering pattern was discovered in a mere 17 compilations, encompassing only two distinct functions. Furthermore, a deeper manual inspection of those specific functions revealed that neither was actively vulnerable in practice. In one instance, the corrupted bytes within the array were subsequently overwritten or discarded anyway, while in the other, no active memory allocations existed beyond the array when the delete operation executed. <\/p>\n
Extensive historical audits and the absence of prior reports suggest that the bug went completely unnoticed throughout the entire history of the language, largely because it manifests as silent data corruption or unexpected return values rather than explicit transaction reverts. <\/p>\n
Resolution and Recommended Actions<\/h3>\n
The Solidity core team has officially released version 0.8.37 to address and permanently resolve the vulnerability. The fix modifies the compiler’s delete code path to properly reference element widths, ensuring that clearing an element in a packed byte array correctly emits a single-byte store instruction rather than a full-word write. Consequently, delete b[i]<\/code> and b[i] = 0<\/code> now execute with identical semantics across both compilation pipelines.<\/p>\n
Developers maintaining active codebases utilizing Solidity versions 0.8.36 and earlier are strongly advised to upgrade their compiler toolchain to version 0.8.37 or later. Projects that rely heavily on in-memory byte manipulation, custom string encoding routines, or low-level memory operations should review their test suites and verify that deletion operations on byte array elements behave as intended.<\/p>\n","protected":false},"excerpt":{"rendered":"
Developers working within the Ethereum ecosystem have been urged to update their compiler toolchains following the disclosure of a long-standing memory corruption vulnerability in the Solidity programming language. The bug, which impacts how the compiler handles the deletion of individual elements within in-memory byte arrays and strings, remained hidden within the core codebase for years<\/p>\n","protected":false},"author":6,"featured_media":865,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[366],"tags":[1014,952,401,951,406,1013,201,953,949,407,950,5,400,402,948],"class_list":["post-866","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-smart-contract-auditing","tag-affecting","tag-array","tag-auditing","tag-byte","tag-code","tag-corruption","tag-critical","tag-deletions","tag-discovered","tag-generator","tag-memory","tag-security","tag-smart-contracts","tag-solidity","tag-vulnerability"],"_links":{"self":[{"href":"https:\/\/wyominginvest.com\/index.php?rest_route=\/wp\/v2\/posts\/866","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/wyominginvest.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/wyominginvest.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/wyominginvest.com\/index.php?rest_route=\/wp\/v2\/users\/6"}],"replies":[{"embeddable":true,"href":"https:\/\/wyominginvest.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=866"}],"version-history":[{"count":0,"href":"https:\/\/wyominginvest.com\/index.php?rest_route=\/wp\/v2\/posts\/866\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/wyominginvest.com\/index.php?rest_route=\/wp\/v2\/media\/865"}],"wp:attachment":[{"href":"https:\/\/wyominginvest.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=866"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/wyominginvest.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=866"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/wyominginvest.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=866"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
![\"Memory](\"https:\/\/soliditylang.org\/assets\/logo-og-image.png\")
<\/figure>\n