CVE-2026-114117 in Vyper
Summary
by MITRE • 10/22/2026
Vyper 0.3.8 through 0.5.0b1 contains an optimizer miscompilation in which (msg.value | K) or (len(msg.data) | K), where K is any nonzero integer literal, is compiled to the constant 1 when used as a ternary expression branch under -O gas (the default) or -O codesize. Affected contracts use the wrong value in storage writes, arithmetic, indexes, return values, or events without warning or revert, which can record deposits incorrectly and lock funds.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/22/2026
The vulnerability identified in Vyper compiler versions 0.3.8 through 0.5.0b1 represents a critical optimizer miscompilation that fundamentally alters the logical evaluation of specific bitwise operations when used within ternary expressions under default optimization settings. The core technical flaw lies in how the compiler handles expressions involving the bitwise OR operator combined with integer literals, specifically patterns such as (msg.value | K) or (len(msg.data) | K), where K is any nonzero integer literal. Under the -O gas and -O codesize optimization flags, which are enabled by default, the optimizer incorrectly simplifies these complex conditional branches to a constant value of 1. This miscompilation occurs because the compiler erroneously assumes that the bitwise OR operation with a non-zero constant will always result in a truthy value, thereby bypassing the necessary evaluation of the actual operand values during compilation.
This logical error has severe operational implications for smart contracts deployed on Ethereum and other EVM-compatible blockchains. Since Vyper compiles directly to bytecode without intermediate checks or runtime validation for this specific optimization path, the resulting contract behaves unpredictably compared to its source code intent. Contracts relying on these expressions for conditional logic will execute with incorrect values in critical operations including storage writes, arithmetic calculations, array indexing, return value assignments, and event emission parameters. The absence of any warning during compilation means developers remain unaware that their contracts are operating under flawed assumptions until after deployment, leaving the system vulnerable to exploitation without prior indication from the toolchain itself.
The most significant impact of this vulnerability is the potential for incorrect recording of deposits and subsequent fund locking. When a contract uses such an expression to determine how much value has been sent or which user account should be credited, the constant 1 result causes all transactions to be processed as if they met a specific condition regardless of their actual parameters. This can lead to situations where funds are deposited into incorrect accounts, balances are miscalculated due to faulty arithmetic derived from these expressions, or users are unable to withdraw their assets because the contract logic no longer recognizes valid withdrawal conditions. In severe cases, this miscompilation can render entire contracts unusable for their intended financial purposes, effectively locking user funds indefinitely if no manual intervention or upgrade mechanism is available.
From a classification perspective, this issue aligns with CWE-691 which denotes use of unintentional address space mapping and more specifically relates to logic errors in conditional compilation that lead to incorrect program behavior. In the context of the MITRE ATT&CK framework for software vulnerabilities, this falls under techniques related to compiler optimization flaws that can be exploited by attackers who understand the specific bytecode generation patterns. While not a direct injection or buffer overflow, it represents a sophisticated attack vector where an adversary could exploit contracts known to use these Vyper versions and specific coding patterns to manipulate state variables or drain funds based on the predictable incorrect behavior of the optimizer.
Mitigation strategies require immediate action for any projects using affected Vyper versions. The primary recommendation is to upgrade the compiler to version 0.5.1 or later, where this miscompilation has been resolved in subsequent releases. For contracts already deployed with vulnerable code, there is no patch available at the bytecode level; therefore, developers must migrate funds to new contracts compiled with a fixed version of Vyper and deprecate the old addresses. To prevent recurrence, development teams should implement rigorous testing protocols that include verifying generated bytecode against expected logical outcomes for all conditional branches involving bitwise operations on external inputs like msg.value or msg.data length. Additionally, enabling stricter linting rules and conducting manual code reviews focused on optimizer-dependent logic can help identify similar patterns before deployment.