GHSA-x2c2-q32w-4w6m CVE-2024-24567 PYSEC-2024-151

Vyper's raw_call `value=` kwargs not disabled for static and delegate calls

Medium PyPI

Severity: 4.8 / 10; Medium · CVSS 3.1
Exploit chance (EPSS): 0.48%; Chance of exploitation in the next 30 days. Higher than 41.75% of scored vulnerabilities.
Known exploited: No; Not in CISA's catalog
Weakness: CWE-754 Improper Check for Unusual or Exceptional Conditions
Fix: 0.4.0; Upgrade vyper to this version or later

Description

Summary

Vyper compiler allows passing a value in builtin raw_call 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 raw_call 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:

raw_call(self, call_data2, max_outsize=255, is_delegate_call=True, value=msg.value/2)

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 problematic implementation of multicall utilizing the raw_call built-in:

value_accumulator: uint256 = empty(uint256)
    results: DynArray[Result, max_value(uint8)] = []
    return_data: Bytes[max_value(uint8)] = b""
    success: bool = empty(bool)
    for batch in data:
        msg_value: uint256 = batch.value
        value_accumulator = unsafe_add(value_accumulator, msg_value)
        if (batch.allow_failure == False):
            return_data = raw_call(self, batch.call_data, max_outsize=255, value=msg_value, is_delegate_call=True)
            success = True
            results.append(Result({success: success, return_data: return_data}))
        else:
            success, return_data = \
                raw_call(self, batch.call_data, max_outsize=255, value=msg_value, is_delegate_call=True, revert_on_failure=False)
            results.append(Result({success: success, return_data: return_data}))
    assert msg.value == value_accumulator, "Multicall: value mismatch"
    return results

Patches

Fixed in https://github.com/vyperlang/vyper/pull/3755

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?

Affected versions

PyPI

Package	Vulnerable	Fixed in
vyper	`< 0.4.0`	`0.4.0`
vyper	`< 0.4.0b1`	`0.4.0b1`

How to fix

Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.

vyper PyPI → `0.4.0`

pip

pip install --upgrade "vyper>=0.4.0"

poetry

poetry add "vyper>=0.4.0"

uv

uv add "vyper>=0.4.0"

Severity breakdown

CVSS 3.1 4.8

CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:L

Attack vector: Network
Attack complexity: High
Privileges required: None
User interaction: None
Scope: Unchanged
Confidentiality: None
Integrity: Low
Availability: Low

Weakness

CWE-754: Improper Check for Unusual or Exceptional Conditions

The product does not check or incorrectly checks for unusual or exceptional conditions that are not expected to occur frequently during day to day operation of the product.

How to prevent it

Requirements: Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. Choose languages with features such as exception handling that force the programmer to anticipate unusual conditions that may generate exceptions. Custom exceptions may need to be developed to handle unusual business-logic conditions. Be careful not to pass sensitive exceptions back to the user (CWE-209, CWE-248).
Implementation: Check the results of all functions that return a value and verify that the value is expected.
Implementation: If using exception handling, catch and throw specific exceptions instead of overly-general exceptions (CWE-396, CWE-397). Catch and handle exceptions as locally as possible so that exceptions do not propagate too far up the call stack (CWE-705). Avoid unchecked or uncaught exceptions where feasible (CWE-248).
Implementation: Ensure that error messages only contain minimal details that are useful to the intended audience and no one else. The messages need to strike the balance between being too cryptic (which can confuse users) or being too detailed (which may reveal more than intended). The messages should not reveal the methods that were used to determine the error. Attackers can use detailed information to refine or optimize their original attack, thereby increasing their chances of success. If errors must be captured in some detail, record them in log messages, but consider what could occur if the log messages can be viewed by attackers. Highly sensitive information such as passwords should never be saved to log files. Avoid inconsistent messaging that might accidentally tip off an attacker about internal state, such as whether a user account exists or not. Exposing additional information to a potential attacker in the context of an exceptional condition can help the attacker determine what attack vectors are most likely to succeed beyond DoS.
Implementation: Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
Architecture and Design, Implementation: If the program must fail, ensure that it fails gracefully (fails closed). There may be a temptation to simply let the program fail poorly in cases such as low memory conditions, but an attacker may be able to assert control before the software has fully exited. Alternately, an uncontrolled failure could cause cascading problems with other downstream components; for example, the program could send a signal to a downstream process so the process immediately knows that a problem has occurred and has a better chance of recovery.
Architecture and Design: Use system limits, which should help to prevent resource exhaustion. However, the product should still handle low resource conditions since they may still occur.

References

Advisories

nvd.nist.gov/vuln/detail/CVE-2024-24567

Packages

github.com/vyperlang/vyper

Timeline

Jan 30, 2024 Published
Sep 10, 2026 Last updated by the source
Oct 31, 2026 Latest EPSS score

Advisory	Severity	Why it's related
GHSA-2r3x-4mrv-mcxf Vyper: Memory corruption using function calls within tuples / nested calls	Medium	Also affects vyper
GHSA-4v7v-gqf9-ww2g Vyper: Call stack corruption when passing complex type containing non-base type members as argument	Medium	Also affects vyper
GHSA-vg88-3v92-rjx2 Vyper: Return inside for loop more than 1 level deep	Low	Also affects vyper
GHSA-3vcg-j39x-cwfm Vyper's `slice()` may elide side-effects when output length is 0	Low	Also affects vyper
GHSA-qhr6-mgqr-mchm Vyper's `concat()` builtin may elide side-effects for zero-length arguments	Low	Also affects vyper
GHSA-h33q-mhmp-8p67 Vyper has a double eval in For List Iter	High	Also affects vyper
GHSA-4w26-8p97-f4jp AugAssign evaluation order causing OOB write within the object in Vyper	Critical	Also affects vyper
GHSA-2p94-8669-xg86 Vyper's sqrt doesn't define rounding behavior	High	Also affects vyper

Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor

Description

Summary

Details

Impact

Patches

Workarounds

References

Affected versions

PyPI

How to fix

vyper PyPI → 0.4.0

Severity breakdown

CVSS 3.1 4.8

Weakness

CWE-754: Improper Check for Unusual or Exceptional Conditions

References

Advisories

Packages

Other links

Timeline

Related advisories

vyper PyPI → `0.4.0`