Live › vulnerability › CVE-2020-37289
Go to dashboardVyper before 0.3.1 has no uint8 type, so interface functions declared to return uint8, such as ERC20.decimals(), are stored in uint256 without bounds checking. A malicious contract can return values above 255 and so manipulate or bypass logic that trusts those values.
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 Vyper contracts older than 0.3.1 and that call external contracts through interfaces declaring uint8 returns. Exposure depends on whether the contract trusts a value an untrusted contract can return. Projects on 0.3.1 or later, or with no external uint8 calls, can skip it.
No product ranges from the sources yet.
vyper --version in each project that compiles Vyper contracts and check whether it is below 0.3.1.uint8 return values and that read from external or untrusted contracts.0.3.1 or later and recompile.Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
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.
This page as .md · .json · in your agent: get_signal("CVE-2020-37289")
NVD data is provided by NIST and is public domain · EPSS scores by FIRST, used with attribution. Posts quoted belong to their authors.