CVE-2026-114114 in Vyper
Summary
by MITRE • 10/21/2026
Vyper 0.1.0b1 before 0.1.0b12, 0.1.0b14, and 0.4.1 through 0.5.0b1 mix character-based line offsets with Python's UTF-8 byte col_offset values in vyper/ast/parse.py, so multi-byte characters shift the source slices used to reconstruct later numeric literals. An attacker contributing source with non-ASCII identifiers that NFKC-normalize to ASCII, or an invisible byte-order mark, can silently substitute addresses, integers or other constants in compiled code.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/21/2026
The vulnerability identified involves a critical flaw in the Vyper compiler's abstract syntax tree parsing logic, specifically within the vyper/ast/parse.py module across versions 0.1.0b1 prior to 0.1.0b12, as well as version 0.1.0b14 and the range from 0.4.1 through 0.5.0b1. This issue stems from an inconsistency in how character offsets are handled during source code parsing. The parser incorrectly mixes character-based line offsets with Python's UTF-8 byte column offsets, which leads to miscalculated source slices when reconstructing numeric literals and other constants from the original source text.
In standard Unicode processing, a single visual character can occupy multiple bytes in UTF-8 encoding. When the compiler uses byte counts for some offset calculations but assumes character counts for others, it creates a desynchronization between where the parser believes a token begins or ends and its actual position in the raw byte stream. This discrepancy becomes particularly dangerous when source code contains non-ASCII characters that are visually indistinguishable from ASCII equivalents after NFKC normalization, such as full-width Latin letters or invisible control characters like zero-width spaces or byte-order marks.
An attacker can exploit this parsing inconsistency by injecting specific Unicode sequences into the smart contract source code. By using identifiers or literals containing these non-ASCII characters that normalize to standard ASCII values, the attacker causes the parser to misalign the extracted substrings used for constant reconstruction. Consequently, the compiled bytecode may contain different addresses, integers, or other critical constants than what was explicitly written in the source file. This silent substitution allows an adversary to alter the fundamental logic of a smart contract without triggering obvious syntax errors or warnings during compilation.
The operational impact of this vulnerability is severe within the context of blockchain and decentralized finance applications where Vyper contracts are deployed. Since smart contracts often handle financial assets, address routing, and access control based on hardcoded constants, any alteration to these values can lead to catastrophic failures. For instance, if an attacker manipulates a contract address or a threshold integer through this offset error, they could redirect funds to unauthorized wallets, bypass security checks, or trigger unintended execution paths that drain the protocol's liquidity. The silent nature of the attack makes it difficult for auditors and developers to detect via standard code review processes, as the source code appears syntactically correct and logically sound at a glance.
This flaw aligns with CWE-697, which describes incorrect comparison results due to type confusion or encoding issues, although in this specific case, it manifests more broadly as an integrity violation leading to unauthorized information modification via CWE-354. From the perspective of the MITRE ATT&CK framework for software supply chain attacks, this vulnerability facilitates code injection and tampering during the build phase, specifically under techniques related to compiler or interpreter exploitation where malicious actors manipulate source-to-binary translation processes to embed backdoors or alter logic without detection.
Mitigation strategies must focus on ensuring consistent offset handling throughout the parsing pipeline. Developers should enforce strict validation of input encodings and ensure that all column offsets are calculated using a uniform metric, preferably character-based indices for logical processing while correctly mapping them to byte positions only when necessary for low-level operations. Upgrading to patched versions of Vyper where this inconsistency has been resolved is the primary remediation step. Additionally, implementing rigorous static analysis tools that flag non-ASCII characters in critical sections of smart contract code can help prevent such manipulations from reaching production environments. Auditors should also be trained to look for subtle Unicode anomalies and verify that compiled bytecode matches source expectations through deterministic verification methods rather than relying solely on visual inspection of the source text.