Vyper compiler CVE-2026-114663

Exploitation is NOT possible against a default/arbitrary Vyper contract. It requires ALL of: (1) the contract was compiled with Vyper 0.4.0b1 through 0.5.0b1; (2) the contract imports a module that exposes an unfoldable constant and/or a function with an omitted default argument; and (3) the contract declares a parameter, local, or loop variable whose name shadows that imported name, so parse_Name misresolves it to the using function's scope. Only when this exact name-collision pattern exists can attacker-influenced input replace the intended value (e.g. supplying an out-of-range value for a narrow type such as uint8). LIMITING FACTORS: the bug is confined to beta compiler releases, depends on a specific non-default source-code pattern that the contract author must have written, and manifests only on the shadowed variable's input path - contracts without the collision are unaffected regardless of compiler version.

This is a compiler-level miscompilation flaw (CWE-706, incorrectly resolved name) in Vyper 0.4.0b1 through 0.5.0b1, reported by VulnCheck with an advisory and GitHub Security Advisory (GHSA-2489-32vh-8rrc). The input provides only a CVSS 4.0 base vector (score 8.6: AV:L/AC:L/AT:N/PR:N/UI:N with VC:H/VI:H/VA:H), and crucially there is NO EPSS score, NO CISA KEV listing, and NO POC indicator supplied - so the headline 8.6 is a severity rating, not an exploitation-likelihood signal. Exploitation status: no public exploit identified at time of analysis. The practical risk is materially lower than the raw score suggests because the flaw is latent: it only manifests when a contract is compiled with one of these specific BETA compiler versions AND the contract's own source contains a name collision between a local/parameter/loop variable and an imported unfoldable constant or defaulted argument. That narrow precondition points to targeted, case-by-case exploitation (or, more likely, accidental correctness bugs) rather than mass exploitation. Note a signal conflict: the vendor CVSS 4.0 vector uses AV:L (local), yet the description's 'attacker-influenced input' against a deployed smart contract is normally reachable over the network via a transaction - verify intended attack surface with the vendor. Also note the 'Information Disclosure' tag does not match the description, which describes integrity/accounting corruption rather than disclosure.

A DeFi contract compiled with an affected Vyper beta imports a module constant (or relies on an omitted default argument) whose name coincides with a function parameter or loop variable in the contract. Because parse_Name resolves the name in the using function's scope, an attacker submits a transaction supplying that colliding input - e.g. an out-of-range value for a narrow uint8 - which silently replaces the intended constant/default and corrupts a validation check or accounting calculation. No public exploit code is known; exploitation requires the specific vulnerable code pattern to already exist in the deployed contract.