Live › vulnerability › CVE-2026-114118
Go to dashboardVyper 0.3.4 through 0.5.0b1 computes the remaining blueprint size in create_from_blueprint with unchecked uint256 subtraction, so a large code_offset wraps to a small positive value. An attacker who controls code_offset can make a factory deploy contracts with no runtime code, which can trap ETH and tokens sent to them.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 21:57 UTC. All times on this page are UTC.
Teams that compile contracts with Vyper 0.3.4 through 0.5.0b1 and use blueprints with create_from_blueprint in a factory where the caller can influence code_offset. Contracts compiled with other Vyper versions, or factories that do not accept a caller-supplied offset, are less exposed. unknown for whether any specific production contract is deployed this way.
No product ranges from the sources yet.
vyper --version or the pinned version in the lockfile or build config, and see whether it falls in 0.3.4 through 0.5.0b1.create_from_blueprint and check whether code_offset can come from user input or an untrusted caller.code_offset in factory contracts so it is always below the blueprint code size.Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
Vyper 0.3.4 through 0.5.0b1 computes the remaining blueprint size in create_from_blueprint by uint256 subtraction without first checking that code_offset is below the blueprint's code size, so a huge offset wraps to a small positive value. An attacker controlling code_offset can make a factory deploy contracts with no runtime code, potentially trapping ETH and tokens.
This page as .md · .json · in your agent: get_signal("CVE-2026-114118")
NVD data is provided by NIST and is public domain · EPSS scores by FIRST, used with attribution. Posts quoted belong to their authors.