_abi_decode input not validated in complex expressions in Vyper

Vulnerability

Overview

The _abi_decode() function in Vyper, a Pythonic smart contract language for the EVM, fails to validate input when it is nested within an expression [1]. The root cause is that _abi_decode() tags its output with encoding=Encoding.ABI, but validation (bounds checking) only occurs when that output is passed to make_setter (e.g., during assignment or return). When _abi_decode() is used inside another expression, such as convert(), the validation is bypassed [4].

Exploitation

An attacker can exploit this by crafting input that exceeds the expected type bounds. For example, a contract that decodes a uint256 as a uint8 using _abi_decode() inside a convert() call will not trigger bounds checking, allowing the attacker to supply a value like 256 and have it returned as 256 instead of being truncated or rejected [4]. No special privileges are required; the attacker only needs to call the affected function with maliciously crafted calldata.

Impact

Successful exploitation leads to incorrect decoding results, which can corrupt contract state or logic. This could enable attacks such as integer overflows, unauthorized access, or financial loss, depending on how the decoded value is used.

Mitigation

As of the publication date, no fix has been released. The Vyper team expects a fix in version 0.3.10 and has provided a pull request (#3626) that addresses the issue by calling make_setter within _abi_decode() to enforce validation [4]. Users are advised to review the PR and consider avoiding nested _abi_decode() usage until the patch is available.