CVE-2026-114118 in Vyper
Summary
by MITRE • 10/22/2026
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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/22/2026
The vulnerability identified in Vyper versions 0.3.4 through 0.5.0b1 represents a critical integer underflow issue within the create_from_blueprint function, which is responsible for deploying new contract instances based on existing blueprints. This flaw stems from a lack of boundary validation when calculating the size of the runtime code to be deployed. Specifically, the implementation performs an unsigned 256-bit subtraction to determine the remaining blueprint size by subtracting the provided code_offset from the total blueprint code size. However, it fails to verify that the code_offset is strictly less than or equal to the actual length of the bytecode stored in the blueprint prior to executing this arithmetic operation.
In Solidity and Vyper smart contract development, unsigned integer types such as uint256 wrap around upon underflow rather than throwing an error by default unless protected by explicit checks. When an attacker controls the code_offset parameter passed into create_from_blueprint, they can supply a value significantly larger than the blueprint's actual bytecode size. Because no pre-condition check exists to ensure that code_offset is within valid bounds, the subtraction operation results in a massive underflow. This mathematical error causes the calculated remaining size to wrap around and become a small positive integer rather than triggering an exception or reverting the transaction as intended by secure coding practices.
The operational impact of this vulnerability is severe, primarily affecting factory contracts that rely on blueprints for immutable code deployment patterns. By exploiting the underflow, an attacker can force the EVM to deploy a contract with effectively no runtime bytecode. In Ethereum Virtual Machine semantics, if the deployed code size is zero or contains only initialization logic without any subsequent execution code, the resulting contract instance becomes inert regarding external interactions but still holds value. Consequently, this allows attackers to trap ETH and ERC-20 tokens within these newly created contracts. Since there is no executable code to handle withdrawal requests or transfer functions, the assets become permanently inaccessible, leading to significant financial loss for users who interact with the compromised factory contract under the assumption that it operates correctly.
From a classification perspective, this vulnerability aligns closely with CWE-190 Integer Overflow or Wraparound and CWE-682 Incorrect Calculation. It also maps to MITRE ATT&CK techniques related to exploitation of software vulnerabilities in decentralized finance contexts, specifically leveraging logic errors to facilitate asset theft or denial of service through fund trapping. The root cause is a failure to implement proper input validation for critical parameters that influence memory allocation and code execution boundaries within the deployment process.
To mitigate this vulnerability, developers must enforce strict boundary checks before performing any arithmetic operations on sizes derived from external inputs. In Vyper contracts utilizing blueprints, it is essential to add an explicit assertion or require statement ensuring that code_offset does not exceed the length of the blueprint's bytecode array prior to subtraction. For example, adding a check such as assert code_offset <= len(blueprint_code) would prevent the underflow condition by reverting the transaction if invalid offsets are provided. Furthermore, upgrading to Vyper versions beyond 0.5.0b1 where this issue has been addressed is recommended for existing deployments that cannot be easily patched due to immutability constraints of deployed factories. Auditors and developers should prioritize reviewing all create_from_blueprint implementations in legacy codebases to ensure that size calculations are protected against wraparound attacks, thereby preserving the integrity of asset custody mechanisms within decentralized applications.