CVE-2023-32058High· 7.5▾ TwilightVyper vulnerable to integer overflow in loop
▾ Twilight zone — High severity, or a signal on a lesser flaw
impact 41.3 · likelihood 0.2 · exploitation 0
Need a working PoC? Pro members can cast a request and our team develops one — it lands right here.
Exploit-prediction probability, daily snapshots since Sep 12.
Disclosure to exploitation, from the record and what we observed since indexing it.
Disclosed via OSV
Last analysed / modified upstream
0.9%
Due to missing overflow check for loop variables, by assigning the iterator of a loop to a variable, it is possible to overflow the type of the latter.
In the following example, calling test returns 354, meaning that the variable a did store 354 a value out of bound for the type uint8.
@external
def test() -> uint16:
x:uint8 = 255
a:uint8 = 0
for i in range(x, x+100):
a = i
return convert(a,uint16)
The issue seems to happen only in loops of type for i in range(a, a + N) as in loops of type for i in range(start, stop) and for i in range(stop), the compiler is able to raise a TypeMismatch when trying to overflow the variable.
thanks to @trocher for reporting
patched in 3de1415ee77a9244eb04bdb695e249d3ec9ed868
vyper < 0.3.8Upgrade to a patched release:
vyper 0.3.8Connected by shared product, vendor, weakness, or advisory.
CVE-2024-24567Medium· 4.8Vyper's raw_call `value=` kwargs not disabled for static and delegate calls
CVE-2023-30629High· 7.5Incorrect success value returned in vyper
CVE-2025-21607LowVyper Does Not Check the Success of Certain Precompile Calls
CVE-2023-32059High· 7.5Vyper vulnerable to incorrect ordering of arguments for kwargs passed to internal calls
CVE-2023-30837High· 7.5vyper vulnerable to storage allocator overflow
CVE-2024-24560Low· 3.7Vyper's external calls can overflow return data to return input buffer