CVE-2023-37902

Vyper 0.4.0b1 through 0.5.0b1 miscompiles unfoldable constants and omitted default arguments from imported modules, because parse_Name resolves their names in the using function's scope rather than at declaration. When a contract's parameter, local, or loop variable shares such a name, attacker-influenced input can replace the intended value, including out-of-range values for narrow types such as uint8, corrupting validation or accounting logic.

In Vyper 0.3.4 through 0.5.0b1, create_from_blueprint computes the remaining blueprint size via uint256 subtraction without checking that code_offset is below the code size. A huge offset can wrap to a small positive value.

Vyper 0.3.8 through 0.5.0b1 contains an optimizer miscompilation where (msg.value | K) or (len(msg.data) | K) with nonzero K compiles to constant 1 in a ternary branch under -O gas or -O codesize. Affected contracts use the wrong value without warning.

Vyper 0.1.0b1 before 0.1.0b17 and 0.4.1 through 0.5.0b1 builds its source-line table with str.splitlines(), which treats characters like form feed and U+2028 as line breaks ignored by the Python parser, causing numeric literals to be classified from shifted source text.

Vyper 0.3.8 through 0.5.0b1 contains a compiler miscompilation vulnerability in parse_IfExp that reads nested arrays with narrower inner bounds using the wider result type's memory layout. When a ternary selects the narrower array, inner arrays after the first are read at wrong offsets, causing contracts to silently store corrupted values or revert.

Vyper 0.1.0b1 before 0.1.0b12, 0.1.0b14, and 0.4.1 through 0.5.0b1 mix character-based line offsets with Python's UTF-8 byte col_offset values in vyper/ast/parse.py, so multi-byte characters shift source slices used to reconstruct later numeric literals.

Vyper from 0.1.0b4 before 0.3.0 contains a memory corruption vulnerability caused by an incorrect stack tip pointer when internal function calls are performed inside arrays. Contracts placing internal calls in nested array elements, external call arguments, struct literals, or raw_log topics can have memory corrupted, producing incorrect contract behavior.

Vyper before 0.2.9 deploys forwarder proxies through the built-in create_forwarder_to function that report a fixed 4096-byte RETURNDATASIZE rather than the actual return data size. Calls through these proxies can yield corrupted data when a function returns more than 4096 bytes without return data sanitation, and fail strict return-size checks such as SafeERC20.safeTransfer.

Vyper from 0.2.13 before 0.2.15 allocates storage slots for @nonreentrant reentrancy locks at the same locations as contract storage variables. When a function using @nonreentrant is called, setting the lock overwrites the overlapping storage variable, corrupting contract state and breaking the contract's intended logic.

Vyper before 0.3.1 lacks a uint8 type, allowing interface return values declared as uint8, such as ERC20.decimals(), to be stored in uint256 variables without bounds checking. Malicious contracts can return values greater than 255 to manipulate or bypass contract logic that relies on these values.