<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://cve.radiocsirt.org</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Tue, 20 Oct 2026 04:44:00 +0000</lastBuildDate>
    <item>
      <title>EUVD-2026-211721</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-211721</link>
      <description>EUVD-2026-211721</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-211721</guid>
    </item>
    <item>
      <title>fkie_cve-2023-31146</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2023-31146</link>
      <description>&lt;p&gt;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.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;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.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2023-31146</guid>
    </item>
    <item>
      <title>GHSA-3p37-3636-q8wv — Vyper vulnerable to OOB DynArray access when array is on both LHS and RHS of an assignment</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-3p37-3636-q8wv</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: vyper&lt;/p&gt;
&lt;p&gt;### 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:
```vyper
a:DynArray[uint256,3]
@external
def test() -&amp;gt; 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]
```&lt;/p&gt;
&lt;p&gt;and here is an example demonstrating the issue can cause data corruption across call frames:&lt;/p&gt;
&lt;p&gt;```vyper
@external
def test() -&amp;gt; DynArray[uint256,3]:
    self.a()
    return self.b() # return [1,2,3]&lt;/p&gt;
&lt;p&gt;@internal
def a():
    a: uint256 = 0    
    b: uint256 = 1    
    c: uint256 = 2    
    d: uint256 = 3&lt;/p&gt;
&lt;p&gt;@internal
def b() -&amp;gt; DynArray[uint256,3]:
    a: DynArray[uint256,3] = empty(DynArray[uint256,3])
    a = [a[0],a[1],a[2]]
    return a
```&lt;/p&gt;
&lt;p&gt;examples involving append and pop:
```vyper
@internal
def foo():
    c: DynArray[uint256, 1] = []
    c.append(c[0])
```&lt;/p&gt;
&lt;p&gt;```vyper
@internal
def foo():
    c: DynArray[uint256, 1] = [1]
    c[0] = c.pop()
```&lt;/p&gt;
&lt;p&gt;the expected behavior in all of the above cases is to revert due to oob array access.&lt;/p&gt;
&lt;p&gt;### Patches
patched in 4f8289a81206f767df1900ac48f485d90fc87edb&lt;/p&gt;
&lt;p&gt;### Workarounds
_Is there a way for users to fix or remediate the vulnerability without upgrading?_&lt;/p&gt;
&lt;p&gt;### References
_Are there any links users can visit to find out more?_&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: vyper&lt;/p&gt;
&lt;p&gt;### 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:
```vyper
a:DynArray[uint256,3]
@external
def test() -&amp;gt; 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]
```&lt;/p&gt;
&lt;p&gt;and here is an example demonstrating the issue can cause data corruption across call frames:&lt;/p&gt;
&lt;p&gt;```vyper
@external
def test() -&amp;gt; DynArray[uint256,3]:
    self.a()
    return self.b() # return [1,2,3]&lt;/p&gt;
&lt;p&gt;@internal
def a():
    a: uint256 = 0    
    b: uint256 = 1    
    c: uint256 = 2    
    d: uint256 = 3&lt;/p&gt;
&lt;p&gt;@internal
def b() -&amp;gt; DynArray[uint256,3]:
    a: DynArray[uint256,3] = empty(DynArray[uint256,3])
    a = [a[0],a[1],a[2]]
    return a
```&lt;/p&gt;
&lt;p&gt;examples involving append and pop:
```vyper
@internal
def foo():
    c: DynArray[uint256, 1] = []
    c.append(c[0])
```&lt;/p&gt;
&lt;p&gt;```vyper
@internal
def foo():
    c: DynArray[uint256, 1] = [1]
    c[0] = c.pop()
```&lt;/p&gt;
&lt;p&gt;the expected behavior in all of the above cases is to revert due to oob array access.&lt;/p&gt;
&lt;p&gt;### Patches
patched in 4f8289a81206f767df1900ac48f485d90fc87edb&lt;/p&gt;
&lt;p&gt;### Workarounds
_Is there a way for users to fix or remediate the vulnerability without upgrading?_&lt;/p&gt;
&lt;p&gt;### References
_Are there any links users can visit to find out more?_&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-3p37-3636-q8wv</guid>
    </item>
    <item>
      <title>gsd-2023-31146</title>
      <link>https://cve.radiocsirt.org/vuln/gsd-2023-31146</link>
      <description>gsd-2023-31146</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/gsd-2023-31146</guid>
    </item>
    <item>
      <title>PYSEC-2023-77</title>
      <link>https://cve.radiocsirt.org/vuln/pysec-2023-77</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: vyper&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: vyper&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/pysec-2023-77</guid>
    </item>
  </channel>
</rss>
