Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
42 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Impact In versions 0.2.15, 0.2.16 and 0.3.0, named re-entrancy locks are allocated incorrectly. Each function using a named re-entrancy lock gets a unique lock regardless of the key, allowing cross-function re-entrancy in contracts compiled with the susceptible versions. A specific set of conditions is required to result in misbehavior of affected contracts, specifically: - A .vy contract compiled with either of the following vyper versions: 0.2.15, 0.2.16, 0.3.0 - A primary function that utilizes the @nonreentrant decorator with a specific key and does not strictly follow the check-effects-interaction pattern (i.e. contains an external call to an untrusted party before storage updates) - A secondary function that utilizes the same key and would be affected by the improper state caused by the primary function Patches https://github.com/vyperlang/vyper/pull/2439, https://github.com/vyperlang/vyper/pull/2514 Workarounds Upgrade to 0.3.1 or higher References Technical post-mortem…
Recommended action: Upgrade to 0.3.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact the ecrecover precompile does not fill the output buffer if the signature does not verify, see https://github.com/ethereum/go-ethereum/blob/b058cf454b3bdc7e770e2b3cec83a0bcb48f55ee/core/vm/contracts.go#L188. however, the ecrecover builtin will still return whatever is at memory location 0. this means that the if the compiler has been convinced to write to the 0 memory location with specially crafted data (generally, this can happen with a hashmap access or immutable read) just before the ecrecover, a signature check might pass on an invalid signature. A contract search was performed. Most uses of ecrecover are used for erc2612-style permit implementations, which typically look like: in this case, the immutable PERMITTYPEHASH is loaded into ecrecover's output buffer right before ecrecover(), and so the output of ecrecover() here when the signature is invalid will be the value of PERMITTYPEHASH. in this case, since PERMITTYPEHASH is not a valid address, it will never compare ==…
Recommended action: Upgrade to 0.3.10 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact in contracts with at least one regular nonpayable function, due to the callvalue check being inside of the selector section, it is possible to send funds to the default function by using less than 4 bytes of calldata, even if the default function is marked nonpayable. this applies to contracts compiled with vyper<=0.3.7. Patches this was fixed by the removal of the global calldatasize check in https://github.com/vyperlang/vyper/commit/02339dfda0f3caabad142060d511d10bfe93c520. Workarounds don't use nonpayable default functions
Recommended action: Upgrade to 0.3.8 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact during codegen, the length word of a dynarray is written before the data, which can result in OOB array access in the case where the dynarray is on both the lhs and rhs of an assignment. here is a minimal example producing the issue: and here is an example demonstrating the issue can cause data corruption across call frames: examples involving append and pop: the expected behavior in all of the above cases is to revert due to oob array access. Patches patched in 4f8289a81206f767df1900ac48f485d90fc87edb Workarounds Is there a way for users to fix or remediate the vulnerability without upgrading? References Are there any links users can visit to find out more?
Recommended action: Upgrade to 0.3.8 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact 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. 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 Patches patched in 3de1415ee77a9244eb04bdb695e249d3ec9ed868 Workarounds
Recommended action: Upgrade to 0.3.8 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Internal calls to internal functions with more than 1 default argument are compiled incorrectly. Depending on the number of arguments provided in the call, the defaults are added not right-to-left, but left-to-right. If the types are incompatible, typechecking is bypassed. In the bar() function in the following code, self.foo(13) is compiled to self.foo(13,12) instead of self.foo(13,1337). note that at the time of publication, the ability to pass kwargs to internal functions is an undocumented feature that does not seem to be widely used. Patches patched in c3e68c302aa6e1429946473769dd1232145822ac Workarounds Is there a way for users to fix or remediate the vulnerability without upgrading? References Are there any links users can visit to find out more?
Recommended action: Upgrade to 0.3.8 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The storage allocator does not guard against allocation overflows. This can result in vulnerabilities like the following: Per @toonvanhove, "An attacker can overwrite the owner variable by calling this contract with calldata: 0x04bc52f8 fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff5 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff (spaces inserted for readability) 0x04bc52f8 is the selector for foo(uint256, uint256), and the last argument fff...fff is the new value for the owner variable." Patches patched in 0bb7203b584e771b23536ba065a6efda457161bb Workarounds Is there a way for users to fix or remediate the vulnerability without upgrading? References Are there any links users can visit to find out more?
Recommended action: Upgrade to 0.3.8 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Background During the audit of Lido's Gate Seals code statemind team identified a weird behavior of the code that uses rawcall: https://github.com/lidofinance/gate-seals/blob/051593e74df01a4131c485b4fda52e691cd4b7d8/contracts/GateSeal.vy#L164 . Construction like this: was not fully documented: https://docs.vyperlang.org/en/v0.3.7/built-in-functions.html#rawcall . The documentation says that: if maxoutsize=0 it should return nothing and then it says that if revertonfailure=False it should return a success flag in the tuple of response, but what if maxoutsize=0 and revertonfailure=False. <img width="715" alt="image" src="https://user-images.githubusercontent.com/22330612/232125364-d2b3bbac-0b4f-40cb-80ff-f55d8eafef44.png" So the team started researching what exactly happened in that case, after some research we found that the Vyper compiler generates the wrong bytecode in that case, it generates the sequence: Impact Example of buggy code: any contract that uses the rawcall with…
Recommended action: Upgrade to 0.3.8 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact when a calling an external contract with no return value, the contract address could be evaluated twice. this is usually only an efficiency problem, but if evaluation of the contract address has side effects, it could result in double evaluation of the side effects. in the following example, Foo(msg.sender).bar() is the contract address for the following call (to .foo()), and could get evaluated twice Patches 6b4d8ff185de071252feaa1c319712b2d6577f8d Workarounds assign contract addresses to variables. the above example would change to References For more information
Recommended action: Upgrade to 0.3.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact in the following code, the return of <iface.returnsint128() is not validated to fall within the bounds of int128. as of v0.3.0, <iface.returnsint128() is validated in simple expressions, but not complex expressions. Patches 0.3.2 (as of https://github.com/vyperlang/vyper/commit/049dbdc647b2ce838fae7c188e6bb09cf16e470b) Workarounds Break up operations involving external calls into multiple statements. For instance, instead of the example above, use
Recommended action: Upgrade to 0.3.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Importing a function from a JSON interface which returns bytes generates bytecode which does not clamp bytes length, potentially resulting in a buffer overrun. Patches 0.3.2 (as of https://github.com/vyperlang/vyper/commit/049dbdc647b2ce838fae7c188e6bb09cf16e470b) Workarounds Use .vy interfaces.
Recommended action: Upgrade to 0.3.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact bytestrings can have dirty bytes in them, resulting in the word-for-word comparison to give incorrect results, e.g. even without dirty nonzero bytes, because there is no comparison of the length, two bytestrings can compare to equal if one ends with "\x00". Patches fixed in https://github.com/vyperlang/vyper/commit/2c73f8352635c0a433423a5b94740de1a118e508
Recommended action: Upgrade to 0.3.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact When performing a function call inside a literal struct, there is a memory corruption issue that occurs because of an incorrect pointer to the the top of the stack. Patches 0.3.0 / #2447
Recommended action: Upgrade to 0.3.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The following code does not properly validate that its input is in bounds. Patches 0.3.0 / #2447 Workarounds Don't use decimal args
Recommended action: Upgrade to 0.3.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Background When attempting to use the v0.2.14 release, @pandadefi discovered an issue using the @nonreentrant decorator. Impact Reentrancy protection storage slots get allocated to the same slots as storage variables, leading to the corruption of storage variables when using the @nonreentrant decorator. Patches This issue was fixed in v0.2.15 in #2391, #2379 Workarounds Don't use the @nonreentrant decorator in these versions.
Recommended action: Upgrade to 0.2.15 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact When performing a function call inside an array, there is a memory corruption issue that occurs because of an incorrect pointer to the the tip of the stack. Patches This issue was partially fixed in VVE-2020-0004, however the fix did not update similar code for arrays, which had a similar issue. The issue is fully fixed in https://github.com/vyperlang/vyper/pull/2345
Recommended action: Upgrade to 0.2.12 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Background @tjayrush reported a data handling issue with certain Web3 libraries using Vyper-deploy forwarder proxy contracts using our Vyper's built-in createforwarderto function prior to our change to support EIP-1167 style forwarder proxies. Impact If you are an end user of a forwarder-style proxy deployed using Vyper's built-in createforwarderto function AND you have a function that returns 4096 bytes AND you do no return data sanitation on the value returned, you could potentially see a data corruption issue. Otherwise, if you are handling the result of a return call AND you expect a specific RETURNDATASIZE that is less than 4096 (such as SafeERC20.safeTransfer) then the call will fail that check. Patches The issue was patched when we upgraded to EIP-1167 style forwarder proxies in #2281. Workarounds If you are making a call to a contract method that is expected to return <= 4096 bytes, there is no issue as the ABI decoders in both Solidity and Vyper will truncate the data…
Recommended action: Upgrade to 0.2.9 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.