Trocher

**Name of the Vulnerable Software and Affected Versions** zkvyper versions 1.3.12 through 1.5.3 **Description** The issue arises from the compilation of LLL IR to a loop with a late exit condition, potentially leading to a loss of funds or unwanted behavior if the loop body contains specific conditions. However, common use cases like iterating over an array are not affected. No contracts were reportedly affected by this issue. **Recommendations** For versions 1.3.12 through 1.5.3, upgrade and redeploy affected contracts to avoid the issue. At the moment, there is no information about other versions that may require different actions.

**Name of the Vulnerable Software and Affected Versions** Vyper versions 0.3.8 through 0.4.0b1 **Description** The issue arises when looping over a `range` of the form `range(start, start + N)`, where `start` is a signed integer and can be negative. This causes the execution to always revert due to an incorrect assertion inserted by the code generation of the `range` statement. The problem occurs because `start` is interpreted as an unsigned integer for comparison, and if it is negative, its 255th bit is set to `1`, making it a very large unsigned integer and causing the assertion to fail. Any contract with a `range(start, start + N)` where `start` is a signed integer and can be negative is affected. **Recommendations** For versions 0.3.8 through 0.4.0b1, update to version 0.4.0b1 or later, which fixes the issue by disallowing the problematic form of `range()`. As a temporary workaround, consider avoiding the use of `range(start, start + N)` with negative `start` values in affected contracts until the issue is resolved.

**Name of the Vulnerable Software and Affected Versions** Vyper versions prior to 0.4.0 **Description** The issue arises when using the built-in `extract32(b, start)` function in Vyper, a pythonic Smart Contract Language for the Ethereum virtual machine. If the `start` index provided has a side effect that updates `b`, the byte array, it could lead to reading and returning dirty memory. **Recommendations** For versions prior to 0.4.0, update to version 0.4.0 or later to resolve the issue. As a temporary workaround, consider avoiding the use of the `extract32(b, start)` function when the `start` index has a side effect that updates `b`. Restrict access to the `extract32` function to minimize the risk of exploitation.

**Name of the Vulnerable Software and Affected Versions** Vyper versions prior to 0.3.10 **Description** The ` abi decode()` function in Vyper does not validate input when it is nested in an expression, allowing for bounds checking to be bypassed and resulting in incorrect results. This can be triggered by constructing specific examples where the output of ` abi decode` is not internally passed to input validating routines. **Recommendations** For versions prior to 0.3.10, update to version 0.3.10 to resolve the issue. As a temporary workaround, consider avoiding the use of ` abi decode()` in nested expressions until the patch is applied. Restrict access to the ` abi decode()` function to minimize the risk of exploitation.

**Name of the Vulnerable Software and Affected Versions** Vyper versions 0.2.9 through 0.3.9 **Description** The issue concerns locks of the type `@nonreentrant("")` or `@nonreentrant('')` that do not produce reentrancy checks at runtime. This can be mitigated by ensuring the lock name is a non-empty string. **Recommendations** For versions 0.2.9 through 0.3.9, ensure the lock name is a non-empty string as a workaround until the issue is resolved by updating to version 0.3.10 or later. For version 0.3.10 and later, no additional action is required as the issue is fixed in this version.

**Name of the Vulnerable Software and Affected Versions** Vyper versions 0.3.9 and prior **Description** The memory used by the builtins `raw call`, `create from blueprint`, and `create copy of` can be corrupted under certain conditions, leading to incorrect `calldata` in the sub-context or deploying incorrect bytecode. Each builtin has specific conditions that must be fulfilled for the corruption to happen, including the use of complex expressions that result in writing to memory. As of the time of publication, no patched version exists, and the issue is still being investigated. There might be other cases where the corruption might happen. When the builtin is being called from an `internal` function, the issue is not present if the function calling it wrote to memory before calling it. **Recommendations** For Vyper versions 0.3.9 and prior, as a temporary workaround, consider caching complex expressions in memory prior to the call to the builtin. For example, in the case of `create from blueprint`, cache the `salt` value in memory before passing it to the builtin. At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Vyper (affected versions not specified) **Description** The Vyper compiler evaluates arguments from right to left instead of left to right for certain expressions, including `unsafe add, unsafe sub, unsafe mul, unsafe div, pow mod256, |, &, ^ (bitwise operators), bitwise or (deprecated), bitwise and (deprecated), bitwise xor (deprecated), raw call, <, >, <=, >=, ==, !=, in, not in (when lhs and rhs are enums)`. This behavior becomes a problem when the evaluation of one argument produces side effects that other arguments depend on. Expressions that can produce side effects include state modifying external calls, state modifying internal calls, `raw call`, `pop()` when used on a Dynamic Array stored in the storage, `create minimal proxy to`, `create copy of`, and `create from blueprint`. **Recommendations** As a temporary workaround, consider ensuring 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. At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Vyper (affected versions not specified) **Description** The order of evaluation of the arguments of the builtin functions `uint256 addmod`, `uint256 mulmod`, `ecadd`, and `ecmul` does not follow source order. This behavior is problematic when the evaluation of one of the arguments produces side effects that other arguments depend on. 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`. **Recommendations** As a temporary workaround, consider ensuring 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 when using builtins from the list above. At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Vyper versions prior to 0.3.8 **Description** In contracts with more than one regular nonpayable function, it is possible to send funds to the default function, even if the default function is marked `nonpayable`. This issue was fixed by the removal of the global `calldatasize` check. **Recommendations** For versions prior to 0.3.8, upgrade to version 0.3.8. For users unable to upgrade, avoid use of nonpayable default functions.

**Name of the Vulnerable Software and Affected Versions** Vyper versions prior to 0.3.8 **Description** The issue occurs during codegen when the length word of a dynarray is written before the data. This can result in out-of-bounds array access when the dynarray is on both the lhs and rhs of an assignment, potentially causing data corruption across call frames. The expected behavior is to revert due to out-of-bounds array access. **Recommendations** For versions prior to 0.3.8, update to version 0.3.8 to resolve the issue. As a temporary workaround, consider avoiding assignments where a dynarray is on both the lhs and rhs to minimize the risk of exploitation. Restrict the use of dynarrays in critical functions until the issue is resolved.

**Name of the Vulnerable Software and Affected Versions** Vyper versions prior to 0.3.8 **Description** The issue is due to a missing overflow check for loop variables in Vyper, a Pythonic smart contract language for the Ethereum virtual machine. By assigning the iterator of a loop to a variable, it is possible to overflow the type of the latter. This issue seems to happen only in loops of type `for i in range(a, a + N)`, as the compiler can raise a `TypeMismatch` when trying to overflow the variable in loops of type `for i in range(start, stop)` and `for i in range(stop)`. **Recommendations** For versions prior to 0.3.8, update to version 0.3.8 to resolve the issue. As a temporary workaround, consider avoiding the use of loops of type `for i in range(a, a + N)` where the iterator is assigned to a variable, to minimize the risk of exploitation. Restrict access to vulnerable smart contracts to prevent potential overflows until the issue is resolved.

**Name of the Vulnerable Software and Affected Versions** Vyper versions prior to 0.3.8 **Description** The storage allocator in Vyper does not guard against allocation overflows, allowing an attacker to overwrite the `owner` variable. This issue can be exploited by calling a contract with specific calldata, enabling the attacker to modify the owner variable. The issue was fixed in version 0.3.8. **Recommendations** For versions prior to 0.3.8, update to version 0.3.8 to resolve the issue. As a temporary workaround, consider restricting access to the `foo` function until the update is applied. Avoid using the `buffer` variable in the affected contract until the issue is resolved.