CVE-2026-114115 in Vyper
Summary
by MITRE • 10/22/2026
Vyper 0.3.8 through 0.5.0b1 contains a compiler miscompilation vulnerability in parse_IfExp that reads nested arrays with narrower inner bounds using the wider result type's memory layout. When a ternary selects the narrower array, inner arrays after the first are read at wrong offsets, causing contracts to silently store corrupted values or revert.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/22/2026
The vulnerability identified within Vyper compiler versions 0.3.8 through 0.5.0b1 represents a critical miscompilation flaw located in the parse_IfExp function responsible for handling ternary conditional expressions. This defect specifically manifests when processing nested array structures where the inner arrays possess narrower bounds compared to the result type used by the broader context of the expression. The core technical failure lies in how memory layout is calculated and applied during code generation. Instead of dynamically adjusting the memory offset based on which branch of the ternary operator is selected at runtime, the compiler incorrectly assumes a static memory layout corresponding to the wider or larger array structure for all branches. This architectural oversight means that when execution flows through the path selecting the narrower inner arrays, the generated bytecode attempts to access memory locations using offsets calculated for the larger data structures.
This misalignment in memory addressing leads directly to severe operational integrity issues within deployed smart contracts on Ethereum-compatible blockchains. Because Solidity and Vyper compilers translate high-level logic into EVM opcodes that manipulate stack and memory states precisely, an incorrect offset calculation results in reading from or writing to unintended memory slots. In practical terms, this causes the contract to silently store corrupted values in storage variables that are not logically associated with the current operation. These silent corruptions can gradually degrade the state of the application without triggering immediate revert conditions, making them particularly dangerous as they may go undetected until significant financial loss or governance manipulation occurs. Alternatively, if the out-of-bounds access violates memory safety checks enforced by certain execution environments or triggers specific opcode constraints, it results in an abrupt transaction failure and reverting of state changes, leading to denial of service for users attempting legitimate interactions with the contract.
From a classification perspective, this vulnerability aligns closely with CWE-682 Incorrect Calculation, as the root cause is a fundamental error in computing memory offsets based on data type sizes. It also relates to CWE-134 Use of Externally-Controlled Format String if one considers how dynamic array bounds might be influenced by external inputs, though the primary issue remains computational logic within the compiler itself. In terms of adversary behavior mapped to the MITRE ATT&CK framework for ICS or general software exploitation, this falls under techniques involving supply chain compromise or toolchain manipulation, specifically CWE-1068 Trust Boundary Violation if an attacker can influence which branch is taken to trigger specific corruption patterns. Attackers could potentially exploit this by crafting transactions that force the execution of ternary expressions with nested arrays, thereby inducing state corruption in vulnerable contracts without triggering standard validation errors until it is too late.
Mitigation strategies must focus on immediate remediation and long-term defensive coding practices. The primary solution is to upgrade the Vyper compiler to a version later than 0.5.0b1 where this specific miscompilation has been addressed by the development team. For projects unable to immediately update, developers should refactor smart contract logic to avoid complex nested array structures within ternary expressions or conditional statements that mix different array sizes. Implementing rigorous static analysis tools and formal verification methods can help detect such logical inconsistencies before deployment. Additionally, adopting a defense-in-depth approach with comprehensive unit testing that specifically targets edge cases involving variable-sized arrays in conditional branches is essential. Security audits should prioritize reviewing any code paths where memory layout assumptions are implicit rather than explicit to prevent similar miscompilation vulnerabilities from being introduced or exploited in the future.