{"id":"CVE-2024-22419","aliases":["EUVD-2024-0173","GHSA-2q8v-3gqq-4f8p","PYSEC-2024-103"],"status":"published","title":"concat built-in can corrupt memory in vyper","description":"Vyper is a Pythonic Smart Contract Language for the Ethereum Virtual Machine. 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 (for `\u003e=0.3.2` the `copy_bytes` function). 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. This issue has been addressed in 0.4.0.","severity":{"version":"3.1","score":7.3,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L","level":"high","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-11","score":0.0077,"percentile":0.56077,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-120","CWE-787"],"published":"2024-01-18T18:45:55Z","modified":"2026-10-28T02:30:42Z","fixes":[{"ecosystem":"PyPI","package":"vyper","fixed_in":["0.4.0","0.4.0b1"],"sources":["ghsa","osv"]}],"affected":[{"source":"ghsa","ecosystem":"PyPI","package":"vyper","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0.3.0"},{"last_affected":"0.3.10"},{"fixed":"0.4.0"}]}]},{"source":"osv","ecosystem":"PyPI","package":"vyper","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0.3.0"},{"fixed":"0.4.0"}]}],"versions":["0.3.0","0.3.1","0.3.10","0.3.10rc1","0.3.10rc2","0.3.10rc3","0.3.10rc4","0.3.10rc5","0.3.2","0.3.3","0.3.4","0.3.5","0.3.6","0.3.7","0.3.8","0.3.9","0.4.0b1","0.4.0b2","0.4.0b3","0.4.0b4","0.4.0b5","0.4.0b6","0.4.0rc1","0.4.0rc2","0.4.0rc3","0.4.0rc4","0.4.0rc5","0.4.0rc6"]},{"source":"osv","ecosystem":"PyPI","package":"vyper","ranges":[{"type":"GIT","events":[{"introduced":"0"},{"fixed":"55e18f6d128b2da8986adbbcccf1cd59a4b9ad6f"}]},{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.4.0b1"}]}],"versions":["0.1.0b1","0.1.0b10","0.1.0b11","0.1.0b12","0.1.0b13","0.1.0b14","0.1.0b15","0.1.0b16","0.1.0b17","0.1.0b2","0.1.0b3","0.1.0b4","0.1.0b5","0.1.0b6","0.1.0b7","0.1.0b8","0.1.0b9","0.2.1","0.2.10","0.2.11","0.2.12","0.2.13","0.2.14","0.2.15","0.2.16","0.2.2","0.2.3","0.2.4","0.2.5","0.2.6","0.2.7","0.2.8","0.2.9","0.3.0","0.3.1","0.3.10","0.3.10rc1","0.3.10rc2","0.3.10rc3","0.3.10rc4","0.3.10rc5","0.3.2","0.3.3","0.3.4","0.3.5","0.3.6","0.3.7","0.3.8","0.3.9"]}],"products":[{"vendor":"vyperlang","product":"vyper"}],"references":[{"url":"https://github.com/vyperlang/vyper/security/advisories/GHSA-2q8v-3gqq-4f8p","tags":["x_refsource_CONFIRM","x_transferred","Exploit","Vendor Advisory","advisory","web"]},{"url":"https://github.com/vyperlang/vyper/issues/3737","tags":["x_refsource_MISC","x_transferred","Exploit","Issue Tracking","Vendor Advisory","report","web","advisory"]},{"url":"https://github.com/vyperlang/vyper/commit/55e18f6d128b2da8986adbbcccf1cd59a4b9ad6f","tags":["x_refsource_MISC","x_transferred","Patch","fix","web"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-22419","tags":["advisory"]},{"url":"https://github.com/pypa/advisory-database/tree/main/vulns/vyper/PYSEC-2024-103.yaml","tags":["web"]},{"url":"https://github.com/advisories/GHSA-2q8v-3gqq-4f8p"},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2024/22xxx/CVE-2024-22419.json","tags":["advisory"]},{"url":"https://github.com/vyperlang/vyper","tags":["package"]}],"sources":{"cve":[{"id":"CVE-2024-22419","title":"concat built-in can corrupt memory in vyper","description":"Vyper is a Pythonic Smart Contract Language for the Ethereum Virtual Machine. 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 (for `\u003e=0.3.2` the `copy_bytes` function). 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. This issue has been addressed in 0.4.0.","status":"published","published":"2024-01-18T18:45:55.731Z","modified":"2025-06-02T15:03:38.99Z","cvss":[{"version":"3.1","score":7.3,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L","level":"high","assessor":"cna"}],"cwes":["CWE-120"],"updated_at":"2026-11-02T14:34:00.254134Z"}],"euvd":[{"id":"EUVD-2024-0173","description":"Vyper is a Pythonic Smart Contract Language for the Ethereum Virtual Machine. 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 (for `\u003e=0.3.2` the `copy_bytes` function). 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. This issue has been addressed in 0.4.0.","status":"published","published":"2024-01-18T18:45:55Z","modified":"2025-06-02T15:03:38Z","cvss":[{"version":"3.1","score":7.3,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L","level":"high"}],"updated_at":"2026-11-02T20:32:33.292081Z"}],"ghsa":[{"id":"GHSA-2q8v-3gqq-4f8p","title":"concat built-in can corrupt memory in vyper","description":" ### Summary\n`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 (for `\u003e=0.3.2` the `copy_bytes` function).\n\nA contract search was performed and no vulnerable contracts were found in production.\n\nTracked in issue https://github.com/vyperlang/vyper/issues/3737\n\n### Details\nThe `build_IR` allocates a new internal variable for the concatenation: https://github.com/vyperlang/vyper/blob/3b310d5292c4d1448e673d7b3adb223f9353260e/vyper/builtins/functions.py#L534-L550\n\nNotice that the buffer is allocated for the `maxlen` + 1 word to actually hold the length of the array.\n\nLater the `copy_bytes` 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\n\nThe `dst_data` is defined via:\n- `data ptr` - to skip the 1 word that holds the length\n- `offset`  - to skip the source arguments that were already written to the buffer\n  - the `offset` is increased via: `[\"set\", ofst, [\"add\", ofst, arglen]]`, ie it is increased by the length of the source argument\n\nNow, the `copy_bytes` function has multiple control flow paths, the following ones are of interest:\n1) https://github.com/vyperlang/vyper/blob/3b310d5292c4d1448e673d7b3adb223f9353260e/vyper/codegen/core.py#L270-L273\n2)  https://github.com/vyperlang/vyper/blob/3b310d5292c4d1448e673d7b3adb223f9353260e/vyper/codegen/core.py#L301-L320\n\nNote that the function itself contains the following note: \nhttps://github.com/vyperlang/vyper/blob/3b310d5292c4d1448e673d7b3adb223f9353260e/vyper/codegen/core.py#L245-L247\n\nThat is we can ask for a copy of `1B` yet a whole word is copied.\n\nConsider the first interesting path -  if the `dst_data`'s distance to the end of the concat data buffer is `\u003c 32B`, the `copy_op = STORE(dst, LOAD(src))` from `copy_bytes` will result in buffer overflow as it essentially will `mstore` to `dst_data` the `mload` of the source (mload will load whole word and the distance of the `dst_data` to the word boundary is `\u003c32B`).\n\nFrom the two mentioned paths in `copy_bytes` it can be seen that both sources from memory and storage can cause the corruption.\n\n### PoC\nThe main attack vector that was found was when the `concat` is inside an `internal` function.  Suppose we have an `external` function that calls `internal` one. In such case the address space is divided such that the memory for the internal function is in _lower_  portion of the adr space. As such the buffer overflow can overwrite _valid_ data of the caller.\n\nHere is a simple example:\n```python\n#@version ^0.3.9\n\n@internal\ndef bar() -\u003e uint256:\n    sss: String[2] = concat(\"a\", \"b\") \n    return 1\n\n\n@external\ndef foo() -\u003e int256:\n    a: int256 = -1\n    b: uint256 = self.bar()\n    return a \n```\n\n`foo` should clearly return `-1`, but it returns `452312848583266388373324160190187140051835877600158453279131187530910662655`\n\n`-1` was used intentionally due to its bit structure but the value here is fairly irelevant. In this example during the second iteration of the for loop in the `build_IR` `mload` to `dst+1` will be executed (because len('a') == 1), thus the function will write `1B` over the bounds of the buffer. The string 'b' is stored such that its right-most byte is a zero byte. So a zero byte will be written over the bounds.  So when `-1` is considered it's left-most B will be overwritten to all 0. Therefore it can be seen: `452312848583266388373324160190187140051835877600158453279131187530910662655 == (2**248-1)` will output `True`.\n\n#### IR\nIf we look at the contract's IR (vyper --no optimize -f ir), we see:\n```\n# Line 30\n                          /* a: int256 = -1 */ [mstore, 320, -1 \u003c-1\u003e],\n```\nAnd for the second iteration of the loop in concat:\n```\n len,\n                        [mload, arg],\n                        [seq,\n                          [with,\n                            src,\n                            [add, arg, 32],\n                            [with,\n                              dst,\n                              [add, [add, 256 \u003cconcat destination\u003e, 32], concat_ofst],\n                              [mstore, dst, [mload, src]]]],\n                          [set, concat_ofst, [add, concat_ofst, len]]]]],\n                    [mstore, 256 \u003cconcat destination\u003e, concat_ofst],\n                    256 \u003cconcat destination\u003e]],\n```\nSo the address of the `int` is 320. \n\nThe `dst` is defined as: `[add, [add, 256 \u003cconcat destination\u003e, 32], concat_ofst],`.\nIn the second iteration the `concat_ofst` will be 1 because `len('a)==1` so `256+32+1 = 289`. Now this address will be `mstored` to - so the last mstored B will have the address `289+32=320` which clearly overlaps with the address of the `int a`.\n\n#### PoC 2\nDue to how `immutables` are handled, they can be corrupted too:\n```python\n#@version ^0.3.9\n\ni: immutable(int256)\n\n@external\ndef __init__():\n    i = -1\n    s: String[2] = concat(\"a\", \"b\")\n\n@external\ndef foo() -\u003e int256:\n    return i\n```\n\nOutput of calling `foo()` = `452312848583266388373324160190187140051835877600158453279131187530910662655`.\n\n### Impact\nThe 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.\n\nHowever, 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. \n\n### Concluding remarks\nThe bug based on the fast path in `copy_bytes` was likely introduced in: `548d35d720fb6fd8efbdc0ce525bed259a73f0b9`. `git bisect` was used between v0.3.1 and v0.3.2, `forge test` was run and the test asserted that the function indeed returns -1.\n\nFor the general case, `0.3.0` and `0.3.1` are also affected.","status":"published","published":"2024-01-19T16:19:51Z","modified":"2024-10-10T14:46:32Z","cvss":[{"version":"3.1","score":7.3,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L","level":"high"}],"cwes":["CWE-120","CWE-787"],"updated_at":"2026-11-02T14:38:09.785133Z"}],"nvd":[{"id":"CVE-2024-22419","description":"Vyper is a Pythonic Smart Contract Language for the Ethereum Virtual Machine. 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 (for `\u003e=0.3.2` the `copy_bytes` function). 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. This issue has been addressed in 0.4.0.","status":"published","published":"2024-01-18T19:15:10.55Z","modified":"2026-06-17T07:11:22.5Z","cvss":[{"version":"3.1","score":7.3,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L","level":"high","assessor":"secondary"},{"version":"3.1","score":9.8,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H","level":"critical","assessor":"primary"}],"cwes":["CWE-120","CWE-787"],"updated_at":"2026-11-02T14:09:32.147098Z"}],"osv":[{"id":"CVE-2024-22419","title":"concat built-in can corrupt memory in vyper","description":"Vyper is a Pythonic Smart Contract Language for the Ethereum Virtual Machine. 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 (for `\u003e=0.3.2` the `copy_bytes` function). 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. This issue has been addressed in 0.4.0.","status":"published","published":"2024-01-18T18:45:55.731Z","modified":"2026-10-28T02:30:42.235119858Z","cvss":[{"version":"3.1","score":7.3,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L","level":"high"}],"cwes":["CWE-120"],"updated_at":"2026-11-02T15:44:38.577405Z"},{"id":"GHSA-2q8v-3gqq-4f8p","title":"concat built-in can corrupt memory in vyper","description":" ### Summary\n`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 (for `\u003e=0.3.2` the `copy_bytes` function).\n\nA contract search was performed and no vulnerable contracts were found in production.\n\nTracked in issue https://github.com/vyperlang/vyper/issues/3737\n\n### Details\nThe `build_IR` allocates a new internal variable for the concatenation: https://github.com/vyperlang/vyper/blob/3b310d5292c4d1448e673d7b3adb223f9353260e/vyper/builtins/functions.py#L534-L550\n\nNotice that the buffer is allocated for the `maxlen` + 1 word to actually hold the length of the array.\n\nLater the `copy_bytes` 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\n\nThe `dst_data` is defined via:\n- `data ptr` - to skip the 1 word that holds the length\n- `offset`  - to skip the source arguments that were already written to the buffer\n  - the `offset` is increased via: `[\"set\", ofst, [\"add\", ofst, arglen]]`, ie it is increased by the length of the source argument\n\nNow, the `copy_bytes` function has multiple control flow paths, the following ones are of interest:\n1) https://github.com/vyperlang/vyper/blob/3b310d5292c4d1448e673d7b3adb223f9353260e/vyper/codegen/core.py#L270-L273\n2)  https://github.com/vyperlang/vyper/blob/3b310d5292c4d1448e673d7b3adb223f9353260e/vyper/codegen/core.py#L301-L320\n\nNote that the function itself contains the following note: \nhttps://github.com/vyperlang/vyper/blob/3b310d5292c4d1448e673d7b3adb223f9353260e/vyper/codegen/core.py#L245-L247\n\nThat is we can ask for a copy of `1B` yet a whole word is copied.\n\nConsider the first interesting path -  if the `dst_data`'s distance to the end of the concat data buffer is `\u003c 32B`, the `copy_op = STORE(dst, LOAD(src))` from `copy_bytes` will result in buffer overflow as it essentially will `mstore` to `dst_data` the `mload` of the source (mload will load whole word and the distance of the `dst_data` to the word boundary is `\u003c32B`).\n\nFrom the two mentioned paths in `copy_bytes` it can be seen that both sources from memory and storage can cause the corruption.\n\n### PoC\nThe main attack vector that was found was when the `concat` is inside an `internal` function.  Suppose we have an `external` function that calls `internal` one. In such case the address space is divided such that the memory for the internal function is in _lower_  portion of the adr space. As such the buffer overflow can overwrite _valid_ data of the caller.\n\nHere is a simple example:\n```python\n#@version ^0.3.9\n\n@internal\ndef bar() -\u003e uint256:\n    sss: String[2] = concat(\"a\", \"b\") \n    return 1\n\n\n@external\ndef foo() -\u003e int256:\n    a: int256 = -1\n    b: uint256 = self.bar()\n    return a \n```\n\n`foo` should clearly return `-1`, but it returns `452312848583266388373324160190187140051835877600158453279131187530910662655`\n\n`-1` was used intentionally due to its bit structure but the value here is fairly irelevant. In this example during the second iteration of the for loop in the `build_IR` `mload` to `dst+1` will be executed (because len('a') == 1), thus the function will write `1B` over the bounds of the buffer. The string 'b' is stored such that its right-most byte is a zero byte. So a zero byte will be written over the bounds.  So when `-1` is considered it's left-most B will be overwritten to all 0. Therefore it can be seen: `452312848583266388373324160190187140051835877600158453279131187530910662655 == (2**248-1)` will output `True`.\n\n#### IR\nIf we look at the contract's IR (vyper --no optimize -f ir), we see:\n```\n# Line 30\n                          /* a: int256 = -1 */ [mstore, 320, -1 \u003c-1\u003e],\n```\nAnd for the second iteration of the loop in concat:\n```\n len,\n                        [mload, arg],\n                        [seq,\n                          [with,\n                            src,\n                            [add, arg, 32],\n                            [with,\n                              dst,\n                              [add, [add, 256 \u003cconcat destination\u003e, 32], concat_ofst],\n                              [mstore, dst, [mload, src]]]],\n                          [set, concat_ofst, [add, concat_ofst, len]]]]],\n                    [mstore, 256 \u003cconcat destination\u003e, concat_ofst],\n                    256 \u003cconcat destination\u003e]],\n```\nSo the address of the `int` is 320. \n\nThe `dst` is defined as: `[add, [add, 256 \u003cconcat destination\u003e, 32], concat_ofst],`.\nIn the second iteration the `concat_ofst` will be 1 because `len('a)==1` so `256+32+1 = 289`. Now this address will be `mstored` to - so the last mstored B will have the address `289+32=320` which clearly overlaps with the address of the `int a`.\n\n#### PoC 2\nDue to how `immutables` are handled, they can be corrupted too:\n```python\n#@version ^0.3.9\n\ni: immutable(int256)\n\n@external\ndef __init__():\n    i = -1\n    s: String[2] = concat(\"a\", \"b\")\n\n@external\ndef foo() -\u003e int256:\n    return i\n```\n\nOutput of calling `foo()` = `452312848583266388373324160190187140051835877600158453279131187530910662655`.\n\n### Impact\nThe 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.\n\nHowever, 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. \n\n### Concluding remarks\nThe bug based on the fast path in `copy_bytes` was likely introduced in: `548d35d720fb6fd8efbdc0ce525bed259a73f0b9`. `git bisect` was used between v0.3.1 and v0.3.2, `forge test` was run and the test asserted that the function indeed returns -1.\n\nFor the general case, `0.3.0` and `0.3.1` are also affected.","status":"published","published":"2024-01-19T16:19:51Z","modified":"2026-09-10T03:50:04.648916948Z","cvss":[{"version":"3.1","score":7.3,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L","level":"high"}],"cwes":["CWE-120","CWE-787"],"updated_at":"2026-11-02T15:46:34.700741Z"},{"id":"PYSEC-2024-103","description":"Vyper is a Pythonic Smart Contract Language for the Ethereum Virtual Machine. 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 (for `\u003e=0.3.2` the `copy_bytes` function). 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. This issue has been addressed in 0.4.0.","status":"published","published":"2024-01-18T19:15:00Z","modified":"2024-10-09T23:44:14.237516Z","cvss":[{"version":"3.1","score":9.8,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H","level":"critical"}],"updated_at":"2026-11-02T15:52:53.837392Z"}]}}