CVE-2023-41052Medium· 5.3▾ Sunlitincorrect order of evaluation of side effects for some builtins
▾ Sunlit zone — Low / medium · no exploitation signal
impact 29.2 · likelihood 0.1 · 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
0.5%
Last analysed / modified upstream
The order of evaluation of the arguments of the builtin functions uint256_addmod, uint256_mulmod, ecadd and ecmul does not follow source order.
• For uint256_addmod(a,b,c) and uint256_mulmod(a,b,c), the order is c,a,b.
• For ecadd(a,b) and ecmul(a,b), the order is b,a.
Note that this behaviour is problematic when the evaluation of one of the arguments produces side effects that other arguments depend on.
https://github.com/vyperlang/vyper/pull/3583
When using builtins from the list above, make sure that the arguments of the expression do not produce side effects or, if one does, that no other argument is dependent on those side effects.
vyper < 0.3.10Upgrade to a patched release:
vyper 0.3.10Connected by shared product, vendor, weakness, or advisory.
CVE-2020-37288Medium· 3.7Vyper: Return inside for loop more than 1 level deep
CVE-2020-37286Medium· 6.5Vyper 0.1.0b4 before 0.3.0 Memory Corruption via Nested Internal Function Calls
CVE-2020-37287Medium· 5.9Vyper before 0.2.6 Call Stack Corruption via Complex Type Function Arguments
GHSA-vg88-3v92-rjx2MediumVyper: Return inside for loop more than 1 level deep
GHSA-2r3x-4mrv-mcxfMediumVyper: Memory corruption using function calls within tuples / nested calls
GHSA-4v7v-gqf9-ww2gMediumVyper: Call stack corruption when passing complex type containing non-base type members as argument