Every CVE Search/ Get API key

CVE-2023-31146

Vyper vulnerable to OOB DynArray access when array is on both LHS and RHS of an assignment

7.5 HighFix available

Vyper is a Pythonic smart contract language for the Ethereum virtual machine. Prior to version 0.3.8, during codegen, the length word of a dynarray is written before the data, which can result in out-of-bounds array access in the case where the dynarray is on both the lhs and rhs of an assignment. The issue can cause data corruption across call frames. The expected behavior is to revert due to out-of-bounds array access. Version 0.3.8 contains a patch for this issue.

Attack profile

How easy it is to exploit

Attack vector
Network
Complexity
Low
Privileges needed
None
User interaction
None

What an attacker can affect

Confidentiality
None
Integrity
High
Availability
None

Exploit likelihood

1.25%Up 1.2 points since May 12, 2023
90%50%10%1%

What each source reports

CVE List Score used 7.5

Vyper vulnerable to OOB DynArray access when array is on both LHS and RHS of an assignment

Vyper is a Pythonic smart contract language for the Ethereum virtual machine. Prior to version 0.3.8, during codegen, the length word of a dynarray is written before the data, which can result in out-of-bounds array access in the case where the dynarray is on both the lhs and rhs of an assignment. The issue can cause data corruption across call frames. The expected behavior is to revert due to out-of-bounds array access. Version 0.3.8 contains a patch for this issue.

Record
CVE-2023-31146
CVSS 3.1
7.5 HighCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
CVSS 3.1
9.1 CriticalCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H
Weakness
CWE-787, CWE-787
Updated
2026-11-02
EUVDEUVD-2023-0270 7.5

Vyper is a Pythonic smart contract language for the Ethereum virtual machine. Prior to version 0.3.8, during codegen, the length word of a dynarray is written before the data, which can result in out-of-bounds array access in the case where the dynarray is on both the lhs and rhs of an assignment. The issue can cause data corruption across call frames. The expected behavior is to revert due to out-of-bounds array access. Version 0.3.8 contains a patch for this issue.

Record
EUVD-2023-0270
CVSS 3.1
7.5 HighCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
Updated
2026-11-03
GitHub AdvisoriesGHSA-3p37-3636-q8wv 8.7

Vyper vulnerable to OOB DynArray access when array is on both LHS and RHS of an assignment

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:

a:DynArray[uint256,3]
@external
def test() -> DynArray[uint256,3]:
    self.a = [1,2,3]
    self.a = empty(DynArray[uint256,3])
    self.a = [self.a[0],self.a[1],self.a[2]]
    return self.a # return [1,2,3]

and here is an example demonstrating the issue can cause data corruption across call frames:

@external
def test() -> DynArray[uint256,3]:
    self.a()
    return self.b() # return [1,2,3]

@internal
def a():
    a: uint256 = 0    
    b: uint256 = 1    
    c: uint256 = 2    
    d: uint256 = 3

@internal
def b() -> DynArray[uint256,3]:
    a: DynArray[uint256,3] = empty(DynArray[uint256,3])
    a = [a[0],a[1],a[2]]
    return a

examples involving append and pop:

@internal
def foo():
    c: DynArray[uint256, 1] = []
    c.append(c[0])
@internal
def foo():
    c: DynArray[uint256, 1] = [1]
    c[0] = c.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?

Record
GHSA-3p37-3636-q8wv
CVSS 4.0
8.7 HighCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N
CVSS 3.1
7.5 HighCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
Weakness
CWE-787
Updated
2026-11-02
NVD 7.5

Vyper is a Pythonic smart contract language for the Ethereum virtual machine. Prior to version 0.3.8, during codegen, the length word of a dynarray is written before the data, which can result in out-of-bounds array access in the case where the dynarray is on both the lhs and rhs of an assignment. The issue can cause data corruption across call frames. The expected behavior is to revert due to out-of-bounds array access. Version 0.3.8 contains a patch for this issue.

Record
CVE-2023-31146
CVSS 3.1
7.5 HighCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
CVSS 3.1
9.1 CriticalCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H
CVSS 3.1
9.1 CriticalCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H
Weakness
CWE-787
Updated
2026-11-02
OSV 7.5

Vyper vulnerable to OOB DynArray access when array is on both LHS and RHS of an assignment

Vyper is a Pythonic smart contract language for the Ethereum virtual machine. Prior to version 0.3.8, during codegen, the length word of a dynarray is written before the data, which can result in out-of-bounds array access in the case where the dynarray is on both the lhs and rhs of an assignment. The issue can cause data corruption across call frames. The expected behavior is to revert due to out-of-bounds array access. Version 0.3.8 contains a patch for this issue.

Record
CVE-2023-31146
CVSS 3.1
7.5 HighCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
Weakness
CWE-787
Updated
2026-11-02
OSVGHSA-3p37-3636-q8wv 8.7

Vyper vulnerable to OOB DynArray access when array is on both LHS and RHS of an assignment

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:

a:DynArray[uint256,3]
@external
def test() -> DynArray[uint256,3]:
    self.a = [1,2,3]
    self.a = empty(DynArray[uint256,3])
    self.a = [self.a[0],self.a[1],self.a[2]]
    return self.a # return [1,2,3]

and here is an example demonstrating the issue can cause data corruption across call frames:

@external
def test() -> DynArray[uint256,3]:
    self.a()
    return self.b() # return [1,2,3]

@internal
def a():
    a: uint256 = 0    
    b: uint256 = 1    
    c: uint256 = 2    
    d: uint256 = 3

@internal
def b() -> DynArray[uint256,3]:
    a: DynArray[uint256,3] = empty(DynArray[uint256,3])
    a = [a[0],a[1],a[2]]
    return a

examples involving append and pop:

@internal
def foo():
    c: DynArray[uint256, 1] = []
    c.append(c[0])
@internal
def foo():
    c: DynArray[uint256, 1] = [1]
    c[0] = c.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?

Record
GHSA-3p37-3636-q8wv
CVSS 4.0
8.7 HighCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N
CVSS 3.1
7.5 HighCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
Weakness
CWE-787
Updated
2026-11-02
OSVPYSEC-2023-77 No score

Vyper is a Pythonic smart contract language for the Ethereum virtual machine. Prior to version 0.3.8, during codegen, the length word of a dynarray is written before the data, which can result in out-of-bounds array access in the case where the dynarray is on both the lhs and rhs of an assignment. The issue can cause data corruption across call frames. The expected behavior is to revert due to out-of-bounds array access. Version 0.3.8 contains a patch for this issue.

Record
PYSEC-2023-77
Updated
2026-11-02

Affected products

Affected packages

Affected packages
PackageAffectedFixed
vyper
PyPI
before 0.3.8
0.3.8
vyper
PyPI
before 0.3.8, plus listed versions
0.1.0b10.1.0b100.1.0b110.1.0b120.1.0b13
Show 36 moreShow less
0.1.0b140.1.0b150.1.0b160.1.0b170.1.0b20.1.0b30.1.0b40.1.0b50.1.0b60.1.0b70.1.0b80.1.0b90.2.10.2.100.2.110.2.120.2.130.2.140.2.150.2.160.2.20.2.30.2.40.2.50.2.60.2.70.2.80.2.90.3.00.3.10.3.20.3.30.3.40.3.50.3.60.3.7
0.3.8

History

History
RecordedChangedSources
aliases, publishedEUVD
first indexedCVE List, GitHub Advisories, NVD, OSV

Dates are when Every CVE recorded each change. Upstream dates may differ.

In short

CVE-2023-31146 is a high vulnerability (CVSS 7.5) in Vyperlang Vyper, published May 11, 2023. No source lists public exploit code. EPSS puts the chance of exploitation in the next 30 days at 1.25%, the 69th percentile. Fixed in vyper 0.3.8.

References

MoveEnter Open