Kuroi8

**Name of the Vulnerable Software and Affected Versions** Vyper versions v0.2.0 through v0.3.10 **Description** There is an error in the stack management when compiling the `IR` for `sha3 64`. Concretely, the `height` variable is miscalculated. The vulnerability can't be triggered without writing the `IR` by hand, meaning it cannot be triggered from regular Vyper code. `sha3 64` is used for retrieval in mappings. No flow that would cache the `key` was found, so the issue shouldn't be possible to trigger when compiling the compiler-generated `IR`. This issue isn't triggered during normal compilation of Vyper code, so the impact is low. **Recommendations** For Vyper versions v0.2.0 through v0.3.10, update to a version that includes the patch from https://github.com/vyperlang/vyper/pull/4063 to resolve the issue. 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 0.3.10 and earlier **Description** The bounds check for slices in Vyper does not account for the ability for `start + length` to overflow when the values aren't literals. This issue can be used to do out-of-bounds (OOB) access to storage, memory, or calldata addresses. It can also be used to corrupt the `length` slot of the respective array. A contract search was performed, and no vulnerable contracts were found in production. **Recommendations** For versions 0.3.10 and earlier, update to a version that includes the fix for this issue, as patched in https://github.com/vyperlang/vyper/pull/3818. As a temporary workaround, consider restricting the use of the `slice()` function with non-literal arguments for the `start` or `length` variable until a patch is available. Avoid using the `slice()` function with user-inputted values for `start` or `length` to minimize the risk of exploitation.

**Name of the Vulnerable Software and Affected Versions** Vyper versions 0.3.0 through 0.3.9 **Description** The `concat` built-in can write over the bounds of the memory buffer that was allocated for it and thus overwrite existing valid data. The root cause is that the `build IR` for `concat` doesn't properly adhere to the API of copy functions. A contract search was performed and no vulnerable contracts were found in production. The buffer overflow can result in the change of semantics of the contract. The overflow is length-dependent and thus it might go unnoticed during contract testing. However, certainly not all usages of `concat` will result in overwritten valid data as we require it to be in an internal function and close to the return statement where other memory allocations don't occur. **Recommendations** For versions 0.3.0 through 0.3.9, update to version 0.4.0 to resolve the issue. As a temporary workaround, consider avoiding the use of the `concat` function in internal functions close to the return statement where other memory allocations don't occur. Restrict access to the vulnerable `concat` function to minimize the risk of exploitation.