Vyper CVE-2026-114114

Exploitation requires the victim to compile attacker-supplied Vyper source that contains either (a) a non-ASCII identifier that NFKC-normalizes to an ASCII name or (b) an invisible byte-order mark, triggering the character-vs-byte col_offset mismatch in vyper/ast/parse.py that shifts the slices used to reconstruct later numeric literals. Affected: Vyper 0.1.0b1 through 0.1.0b11, 0.1.0b14, and 0.4.1 through 0.5.0b1. Limiting factors that reduce real-world risk: the attacker must get malicious source into the victim's build pipeline (e.g. a merged pull request or a trusted package) and the victim must actually compile it, so code that is authored in-house or reviewed byte-for-byte is unaffected; there is no remote network service to attack and no impact on already-compiled trusted contracts.

This is a genuine code-integrity flaw rather than a hyped high-CVSS item, but its real-world priority is conditional on workflow. The vendor-supplied CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:P, VC:N/VI:H/VA:N) scores 6.0 (Medium) and correctly captures the shape of the risk: no confidentiality or availability impact, but HIGH integrity impact because attacker-controlled source can silently alter the constants emitted into compiled bytecode. The AT:P (attack requirements present - the attacker must craft characters that NFKC-normalize to ASCII or insert a BOM) and user-interaction requirement (the victim must compile the untrusted source) are real brakes on mass or automated exploitation. There is NO EPSS score, NO CISA KEV listing, and NO public exploit in the provided data, so there is no evidence of active or widespread exploitation - this reads as a targeted supply-chain/source-review integrity threat, not an internet-facing mass-exploitation bug. The priority is HIGH specifically for teams that compile Vyper source received from multiple or untrusted contributors (e.g. open-source DeFi projects, audited smart-contract repos), because a silently substituted address could redirect on-chain funds; it is LOW for developers compiling only their own trusted code. One signal to verify: PR:N implies the attacker needs no privileges, which fits a pull-request/contribution threat model, but the attack still depends entirely on the victim trusting and compiling foreign source.

An attacker submits a pull request (or publishes a package) containing Vyper source where a non-ASCII identifier NFKC-normalizes to an ASCII name, or an invisible byte-order mark is embedded. Because parse.py mixes character-based line offsets with Python's byte col_offset values, the multi-byte character shifts the source slices used to rebuild later numeric literals, so the code that a human reviewer reads differs from the constants actually compiled - e.g. a benign-looking address is silently replaced by the attacker's address. No public exploit is identified at time of analysis, so this would require the attacker to independently develop the crafted-source technique.