Trocher

**Nome do software vulnerável e versões afetadas** zkvyper, versões 1.3.12 a 1.5.3 **Descrição** O problema decorre da compilação de LLL IR em um loop com uma condição de saída tardia, o que pode levar à perda de fundos ou a comportamentos indesejados caso o corpo do loop contenha condições específicas. No entanto, casos de uso comuns, como a iteração sobre uma matriz, não são afetados. Não há relatos de contratos afetados por este problema. **Recomendações** Para as versões 1.3.12 a 1.5.3, atualize e reimplante os contratos afetados para evitar o problema. No momento, não há informações sobre outras versões que possam exigir ações diferentes.

**Nome do software vulnerável e versões afetadas** Versões do Vyper 0.3.8 a 0.4.0b1 **Descrição** O problema ocorre ao iterar sobre um `range` da forma `range(start, start + N)`, onde `start` é um inteiro com sinal e pode ser negativo. Isso faz com que a execução sempre retorne devido a uma asserção incorreta inserida pela geração de código da instrução `range`. O problema ocorre porque `start` é interpretado como um inteiro sem sinal para comparação e, se for negativo, seu 255º bit é definido como `1`, tornando-o um inteiro sem sinal muito grande e fazendo com que a asserção falhe. Qualquer contrato com um `range(start, start + N)` em que `start` seja um inteiro com sinal e possa ser negativo é afetado. **Recomendações** Para as versões 0.3.8 a 0.4.0b1, atualize para a versão 0.4.0b1 ou posterior, que corrige o problema ao proibir a forma problemática de `range()`. Como solução temporária, considere evitar o uso de `range(start, start + N)` com valores negativos para `start` nos contratos afetados até que o problema seja resolvido.

**Nome do software vulnerável e versões afetadas** Versões do Vyper anteriores à 0.4.0 **Descrição** O problema ocorre ao usar a função integrada `extract32(b, start)` no Vyper, uma linguagem de contratos inteligentes em Python para a máquina virtual Ethereum. Se o índice `start` fornecido tiver um efeito colateral que atualize `b`, a matriz de bytes, isso pode levar à leitura e ao retorno de memória corrompida. **Recomendações** Para versões anteriores à 0.4.0, atualize para a versão 0.4.0 ou posterior para resolver o problema. Como solução temporária, considere evitar o uso da função `extract32(b, start)` quando o índice `start` tiver um efeito colateral que atualize `b`. Restrinja o acesso à função `extract32` para minimizar o risco de exploração.

**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.