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 When performing a function call inside a tuple or as an argument inside another function call, there is a memory corruption issue that occurs because of an incorrect pointer to the the tip of the stack. Example code: Please see #2186 for further information Patches This problem was fixed in #2186, and released as a part of v0.2.6.
Recommended action: Upgrade to 0.2.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact When we pass a multi-dimensional array (like [[1, 2], [3, 4]]) as an argument to internal/external functions we get incorrect output. This is due to a stack management issue, because it was assumed that the size of each subtype of an array/struct is 32, which is not always correct. Example code: Please see #2183 for further information Patches This problem was fixed in #2184, and released as a part of v0.2.6.
Recommended action: Upgrade to 0.2.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
VVE-2020-0002 Earlier today, we received a responsible disclosure of a potential issue from @michwill (developer of @curvefi) for Vyper users who use return statements inside for loops of nested internal calls. Returning inside a for loop causes an invalid jump dest, reverting the transaction unnecessarily. MWE: Impact Impact is minor, it is unlikely a user would encounter this problem unless they were working with nested calls, and return statements inside calls. Even in that scenario, you would encounter a revert which should be noticeable with adequate testing. In limited circumstances, this could cause a DoS attack for public contracts under certain conditions. Patches Fixed in https://github.com/vyperlang/vyper/pull/2110. Please upgrade to Vyper 0.2.3 Workarounds Not returning inside a for loop nested 2+ internal calls deep works as is: For more information If you have any questions or comments about this advisory: Chat with us in our gitter Open an issue in…
Recommended action: Upgrade to 0.2.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Multiple evaluation of a single expression is possible in the iterator target of a for loop. While the iterator expression cannot produce multiple writes, it can consume side effects produced in the loop body (e.g. read a storage variable updated in the loop body) and thus lead to unexpected program behavior. Specifically, reads in iterators which contain an ifexp (e.g. for s: uint256 in ([read(), read()] if True else [])) may interleave reads with writes in the loop body. The fix is tracked in https://github.com/vyperlang/vyper/pull/4488. Vulnerability Details Vyper for loops allow two kinds of iterator targets, namely the range() builtin and an iterable type, like SArray and DArray. During codegen, iterable lists are required to not produce any side-effects (in the following code, rangescope forces iterlist to be parsed in a constant context, which is checked against isconstant). However, this does not prevent the iterator from consuming side effects provided by the body of the…
Recommended action: Upgrade to 0.4.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Vyper handles AugAssign statements by first caching the target location to avoid double evaluation. However, in the case when target is an access to a DynArray and the rhs modifies the array, the cached target will evaluate first, and the bounds check will not be re-evaluated during the write portion of the statement. In other words, the following code is equivalent to: rather than:
Recommended action: Upgrade to 0.4.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Vyper's sqrt() builtin uses the babylonian method to calculate square roots of decimals. Unfortunately, improper handling of the oscillating final states may lead to sqrt incorrectly returning rounded up results. the fix is tracked in https://github.com/vyperlang/vyper/pull/4486 Vulnerability Details Vyper injects the following code to handle calculation of decimal sqrt. x is the input provided by user. Notably, the terminal condition of the algorithm is either zcur == zprev, or the algorithm runs for 256 rounds. However, for certain inputs, z might actually oscillate between N and N + epsilon, where N 2 <= x < (N + epsilon) 2. This means that the current behavior does not define whether it will round up or down to the nearest epsilon. The example snippet here returns 0.9999999999, the rounded up result for sqrt(0.9999999998). This is due to the oscillation ending in N + epsilon instead of N. Note that sqrt() diverges from isqrt() here -- isqrt() consistently rounds down, so it is…
Recommended action: Upgrade to 0.4.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When looping over a range of the form range(start, start + N), if start is negative, the execution will always revert. Details This issue is caused by an incorrect assertion inserted by the code generation of the range (stmt.parseForrange()): https://github.com/vyperlang/vyper/blob/9136169468f317a53b4e7448389aa315f90b95ba/vyper/codegen/stmt.py#L286-L287 This assertion was introduced in https://github.com/vyperlang/vyper/commit/3de1415ee77a9244eb04bdb695e249d3ec9ed868 to fix https://github.com/advisories/GHSA-6r8q-pfpv-7cgj. The issue arises when start is signed, instead of using sle, le is used and start is interpreted as an unsigned integer for the comparison. If it is a negative number, its 255th bit is set to 1 and is hence interpreted as a very large unsigned integer making the assertion always fail. PoC Patches patched in v0.4.0, specifically, https://github.com/vyperlang/vyper/pull/3679 disallows this form of range(). Impact Any contract having a range(start, start + N)…
Recommended action: Upgrade to 0.4.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Incorrect values can be logged when rawlog builtin is called with memory or storage arguments to be used as topics. A contract search was performed and no vulnerable contracts were found in production. In particular, no uses of rawlog() were found at all in production; it is apparently not a well-known function. Details The buildIR function of the RawLog class fails to properly unwrap the variables provided as topics. Consequently, incorrect values are logged as topics. PoC Patches Fixed in https://github.com/vyperlang/vyper/pull/3977. Impact Incorrect values can be logged which may result in unexpected behavior in client-side applications relying on these logs.
Recommended action: Upgrade to 0.4.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Using the slice builtin can result in a double eval vulnerability when the buffer argument is either msg.data, self.code or <address.code and either the start or length arguments have side-effects. A contract search was performed and no vulnerable contracts were found in production. Having side-effects in the start and length patterns is also an unusual pattern which is not that likely to show up in user code. It is also much harder (but not impossible!) to trigger the bug since 0.3.4 since the unique symbol fence was introduced (https://github.com/vyperlang/vyper/pull/2914). Details It can be seen that the buildadhocslicenode function of the slice builtin doesn't cache the mentioned arguments to the stack: https://github.com/vyperlang/vyper/blob/4595938734d9988f8e46e8df38049ae0559abedb/vyper/builtins/functions.py#L244 As such, they can be evaluated multiple times (instead of retrieving the value from the stack). PoC with Vyper version 0.3.3+commit.48e326f the call to foo…
Recommended action: Upgrade to 0.4.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Using the createfromblueprint builtin can result in a double eval vulnerability when rawargs=True and the args argument has side-effects. A contract search was performed and no vulnerable contracts were found in production. In particular, the rawargs variant of createfromblueprint was not found to be used in production. Details It can be seen that the buildcreateIR function of the createfromblueprint builtin doesn't cache the mentioned args argument to the stack: https://github.com/vyperlang/vyper/blob/cedf7087e68e67c7bfbd47ae95dcb16b81ad2e02/vyper/builtins/functions.py#L1847 As such, it can be evaluated multiple times (instead of retrieving the value from the stack). PoC The vulnerability is demonstrated in the following boa test: The output of c2.deployed() is 2 although create was called only once and the value was initialized to 0. Patches Patched in https://github.com/vyperlang/vyper/pull/3976. Impact No vulnerable production contracts were found. Additionally, double…
Recommended action: Upgrade to 0.4.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Prior to v0.3.0, default() functions did not respect the @nonreentrancy decorator and the lock was not emitted. This is a known bug and was already visible in the issue tracker (https://github.com/vyperlang/vyper/issues/2455), but it is being re-issued as an advisory so that tools relying on the advisory publication list can incorporate it into their searches. A contract search was additionally performed and no vulnerable contracts were found in production. PoC after codegen: Impact No vulnerable production contracts were found. Additionally, using a lock on a default function is a very sparsely used pattern. As such, the impact is low.
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.
Using the sqrt builtin can result in multiple eval evaluation of side effects when the argument has side-effects. The bug is more difficult (but not impossible!) to trigger as of 0.3.4, when the unique symbol fence was introduced (https://github.com/vyperlang/vyper/pull/2914). A contract search was performed and no vulnerable contracts were found in production. Details It can be seen that the buildIR function of the sqrt builtin doesn't cache the argument to the stack: https://github.com/vyperlang/vyper/blob/4595938734d9988f8e46e8df38049ae0559abedb/vyper/builtins/functions.py#L2151 As such, it can be evaluated multiple times (instead of retrieving the value from the stack). PoC With at least Vyper version 0.2.15+commit.6e7dba7 the following contract: passes the following test: Patches Patched in https://github.com/vyperlang/vyper/pull/3976. Impact No vulnerable production contracts were found.
Recommended action: Upgrade to 0.4.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When using the built-in extract32(b, start), if the start index provided has for side effect to update b, the byte array to extract 32 bytes from, it could be that some dirty memory is read and returned by extract32. As of v0.4.0 (specifically, commit https://github.com/vyperlang/vyper/commit/3d9c537142fb99b2672f21e2057f5f202cde194f), the compiler will panic instead of generating bytecode. Details Before evaluating start, the function Extract32.buildIR caches only: - The pointer in memory/storage to b: https://github.com/vyperlang/vyper/blob/10564dcc37756f3d3684b7a91fd8f4325a38c4d8/vyper/builtins/functions.py#L916-L918 - The length of b: https://github.com/vyperlang/vyper/blob/10564dcc37756f3d3684b7a91fd8f4325a38c4d8/vyper/builtins/functions.py#L920-L922 but do not cache the actual content of b. This means that if the evaluation of start changes b's content and length, an outdated length will be used with the new content when extracting 32 bytes from b. PoC Calling the…
Recommended action: Upgrade to 0.4.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
If an excessively large value is specified as the starting index for an array in abidecode, it can cause the read position to overflow. This results in the decoding of values outside the intended array bounds, potentially leading to bugs in contracts that use arrays within abidecode. The advisory has been assigned low severity, because it is only observable if there is a memory write between two invocations of abidecode on the same input. Proof of Concept Sending the following calldata results in Pwn being emitted. Patches Patched in https://github.com/vyperlang/vyper/pull/3925, https://github.com/vyperlang/vyper/pull/4091, https://github.com/vyperlang/vyper/pull/4144, https://github.com/vyperlang/vyper/pull/4060.
Recommended action: Upgrade to 0.4.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Arrays can be keyed by a signed integer, while they are defined for unsigned integers only. The typechecker doesn't throw when spotting the usage of an int as an index for an array. Typically, negative integers are filtered out at runtime by the bounds checker, but small enough (i.e. large in magnitude, ex. -2255 + 5) quantities combined with large enough arrays (at least 2255 in length) can pass the bounds checker, resulting in unexpected behavior. A contract search was performed, and no production contracts were found to be impacted. Details The typechecker allows the usage of signed integers to be used as indexes to arrays. The vulnerability is present in different forms in all versions. Here is an example from 0.3.10: https://github.com/vyperlang/vyper/blob/c150fc49ee9375a930d177044559b83cb95f7963/vyper/semantics/types/subscriptable.py#L127-L137 As can be seen, the validation is performed against IntegerT.any(). PoC If the array is sufficiently large, it can be indexed…
Recommended action: Upgrade to 0.4.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
There is an error in the stack management when compiling the IR for sha364. Concretely, the height variable is miscalculated. The vulnerability can't be triggered without writing the IR by hand. That is, it cannot be triggered from regular vyper code, it can only be triggered by using the fang binary directly (this binary used to be called vyper-ir prior to v0.3.4). Details To compile sha364, the arg[0] and arg[1] have to be compiled: https://github.com/vyperlang/vyper/blob/c150fc49ee9375a930d177044559b83cb95f7963/vyper/ir/compileir.py#L585-L586 As can be seen, after compiling the 0th arg, the height variable isn't increased. If new withargs are defined in the inner scope, they are manipulated correctly, because both their height is off and also the global height is off and thus their placement on the stack is computed correctly. sha364 is used for retrieval in mappings. No flow that would cache the key was found, the issue shouldn't be possible to trigger when compiling the…
Recommended action: Upgrade to 0.4.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When calls to external contracts are made, we write the input buffer starting at byte 28, and allocate the return buffer to start at byte 0 (overlapping with the input buffer). When checking RETURNDATASIZE for dynamic types, the size is compared only to the minimum allowed size for that type, and not to the returned value's length. As a result, malformed return data can cause the contract to mistake data from the input buffer for returndata. This advisory is given a severity of "Low" because when the called contract returns invalid ABIv2 encoded data, the calling contract can read different invalid data (from the dirty buffer) than the called contract returned. Details When arguments are packed for an external call, we create a buffer of size max(args, returndata) + 32. The input buffer is placed in this buffer (starting at byte 28), and the return buffer is allocated to start at byte 0. The assumption is that we can reuse the memory becase we will not be able to read past…
Recommended action: Upgrade to 0.4.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The bounds check for slices does not account for the ability for start + length to overflow when the values aren't literals. If a slice() function uses a non-literal argument for the start or length variable, this creates the ability for an attacker to overflow the bounds check. This issue can be used to do 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. tracking in issue https://github.com/vyperlang/vyper/issues/3756. patched in https://github.com/vyperlang/vyper/pull/3818. Details Here the flow for storage is supposed, but it is generalizable also for the other locations. When calling slice() on a storage value, there are compile time bounds checks if the start and length values are literals, but of course this cannot happen if they are passed values: At runtime, we perform the following equivalent check, but the…
Recommended action: Upgrade to 0.4.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Vyper compiler allows passing a value in builtin rawcall even if the call is a delegatecall or a staticcall. But in the context of delegatecall and staticcall the handling of value is not possible due to the semantics of the respective opcodes, and vyper will silently ignore the value= argument. A contract search was performed and no vulnerable contracts were found in production. Details The IR for rawcall is built in the RawCall class: https://github.com/vyperlang/vyper/blob/9136169468f317a53b4e7448389aa315f90b95ba/vyper/builtins/functions.py#L1100 However, the compiler doesn't validate that if either delegatecall or staticall are provided as kwargs, that value wasn't set. For example, the following compiles without errors: Impact If the semantics of the EVM are unknown to the developer, he could suspect that by specifying the value kwarg, exactly the given amount will be sent along to the target. However in fact, no value will be sent. Here is an example of an potentially…
Recommended action: Upgrade to 0.4.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 buildIR for concat doesn't properly adhere to the API of copy functions (for =0.3.2 the copybytes function). A contract search was performed and no vulnerable contracts were found in production. Tracked in issue https://github.com/vyperlang/vyper/issues/3737 Details The buildIR allocates a new internal variable for the concatenation: https://github.com/vyperlang/vyper/blob/3b310d5292c4d1448e673d7b3adb223f9353260e/vyper/builtins/functions.py#L534-L550 Notice that the buffer is allocated for the maxlen + 1 word to actually hold the length of the array. Later the copybytes function is used to copy the actual source arguments to the destination: https://github.com/vyperlang/vyper/blob/3b310d5292c4d1448e673d7b3adb223f9353260e/vyper/builtins/functions.py#L569-L572 The dstdata is defined via: - data ptr - to skip the 1 word…
Recommended action: Upgrade to 0.4.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact contracts containing large arrays might underallocate the number of slots they need. prior to v0.3.8, the calculation to determine how many slots a storage variable needed used math.ceil(type.sizeinbytes / 32): https://github.com/vyperlang/vyper/blob/6020b8bbf66b062d299d87bc7e4eddc4c9d1c157/vyper/semantics/validation/datapositions.py#L197 the intermediate floating point step can produce a rounding error if there are enough bits set in the IEEE-754 mantissa. roughly speaking, if type.sizeinbytes is large ( 246), and slightly less than a power of 2, the calculation can overestimate how many slots are needed. if type.sizeinbytes is slightly more than a power of 2, the calculation can underestimate how many slots are needed. the following two example contracts can result in overwriting of the variable vulnerable: note that in the latter case, the risk of vulnerable being overwritten is relatively small, since it would cost roughly $1.45 million trillion USD at today's gas prices…
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 abidecode() does not validate input when it is nested in an expression. the following example gets correctly validated (bounds checked): however, the following example is not bounds checked the issue can be triggered by constructing an example where the output of abidecode is not internally passed to makesetter (an internal codegen routine) or other input validating routine. Patches https://github.com/vyperlang/vyper/pull/3626 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.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 certain conditions, the memory used by the builtins rawcall, createfromblueprint and createcopyof can be corrupted. - For rawcall, the argument buffer of the call can be corrupted, leading to incorrect calldata in the sub-context. - For createfromblueprint and createcopyof, the buffer for the to-be-deployed bytecode can be corrupted, leading to deploying incorrect bytecode. Below are the conditions that must be fulfilled for the corruption to happen for each builtin: rawcall - memory is not fully initialized, ex. all parameters to an external function live in calldata and - The data argument of the builtin is msg.data. and - The to, value or gas passed to the builtin is some complex expression that results in writing to uninitialized memory (e.g. calling an internal function) createcopyof - memory is not fully initialized, ex. all parameters to an external function live in calldata and - The value or salt passed to the builtin is some complex expression that results in…
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 Locks of the type @nonreentrant("") or @nonreentrant('') do not produce reentrancy checks at runtime. Patches Patched in #3605 Workarounds The lock name should be a non-empty string. References Are there any links users can visit to find out more?
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 The order of evaluation of the arguments of the builtin functions uint256addmod, uint256mulmod, ecadd and ecmul does not follow source order. • For uint256addmod(a,b,c) and uint256mulmod(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. Patches https://github.com/vyperlang/vyper/pull/3583 Workarounds 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.
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.