Vyper CVE-2026-114118

Exploitation requires a factory contract compiled with vulnerable Vyper (0.3.4 through 0.5.0b1) that uses create_from_blueprint AND passes an attacker-influenceable code_offset argument without bounds validation; the attacker must be able to supply a code_offset larger than the blueprint's code size so the uint256 subtraction wraps. Limiting factors: this is not exploitable against arbitrary contracts - only factories that both use this specific builtin and expose code_offset to callers are affected (reflected by CVSS AT:P). Although PR:N means no authentication is needed to call the factory on-chain, the non-default requirement of attacker-controlled offset materially narrows the real-world attack surface, and impact is confined to trapping assets in the newly-deployed codeless contract rather than compromising the factory or its state.

This is a moderate, conditional risk rather than a drop-everything priority. The input CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:L) yields 6.3 (Medium): network-reachable and unauthenticated - consistent with any EVM caller invoking a contract - but it carries AT:P, meaning a specific attack requirement must hold, and impact is limited to low integrity and low availability with no confidentiality loss. There is no EPSS score, no CISA KEV listing, and no public POC provided, so all three exploitation-likelihood signals are either absent or negative; this points to a latent correctness bug, not evidence of active or imminent mass exploitation. The real-world risk is gated by the AT:P condition: exploitation only matters for factory contracts that (a) were compiled with vulnerable Vyper 0.3.4-0.5.0b1 and (b) expose code_offset to attacker control in create_from_blueprint. Note a tag/impact conflict: the input Tags include 'Information Disclosure', which contradicts the CVSS vector's VC:N (no confidentiality impact) - the actual effect is fund-trapping (integrity/availability), so the tag appears mislabeled. Bottom line: prioritize for teams that build or depend on Vyper blueprint factories, but it is not a widespread, high-urgency item absent those conditions.

A DeFi protocol deploys a factory contract (compiled with a vulnerable Vyper version) that lets callers specify a code_offset when deploying child contracts via create_from_blueprint. An attacker calls the factory with an enormous code_offset; the unsigned subtraction wraps to a small positive 'remaining size', so the factory deploys a child contract with no runtime code, causing any ETH or tokens routed to that child to become permanently trapped. No public exploit code was identified at time of analysis.