https://cve.radiocsirt.org/rss/recent/all/10 Most recent entries from all 2026-10-20T21:48:32.968198+00:00 Vulnerability-Lookup csirt@opendfir.org python-feedgen Contains only the most 10 recent entries. https://cve.radiocsirt.org/vuln/euvd-2026-195070 EUVD-2026-195070 2026-10-20T21:48:32.992631+00:00 EUVD-2026-195070 https://cve.radiocsirt.org/vuln/fkie_cve-2023-39363 fkie_cve-2023-39363 2026-10-20T21:48:32.992674+00:00

Vyper is a Pythonic Smart Contract Language for the Ethereum Virtual Machine (EVM). In versions 0.2.15, 0.2.16 and 0.3.0, named re-entrancy locks are allocated incorrectly. Each function using a named re-entrancy lock gets a unique lock regardless of the key, allowing cross-function re-entrancy in contracts compiled with the susceptible versions. A specific set of conditions is required to result in misbehavior of affected contracts, specifically: a `.vy` contract compiled with `vyper` versions `0.2.15`, `0.2.16`, or `0.3.0`; a primary function that utilizes the `@nonreentrant` decorator with a specific `key` and does not strictly follow the check-effects-interaction pattern (i.e. contains an external call to an untrusted party before storage updates); and a secondary function that utilizes the same `key` and would be affected by the improper state caused by the primary function. Version 0.3.1 contains a fix for this issue.

 https://cve.radiocsirt.org/vuln/ghsa-5824-cm3x-3c38 GHSA-5824-cm3x-3c38 — Vyper has incorrectly allocated named re-entrancy locks 2026-10-20T21:48:32.992711+00:00

Affected: PyPI: vyper

### Impact

In versions 0.2.15, 0.2.16 and 0.3.0, named re-entrancy locks are allocated incorrectly. Each function using a named re-entrancy lock gets a unique lock regardless of the key, allowing cross-function re-entrancy in contracts compiled with the susceptible versions. A specific set of conditions is required to result in misbehavior of affected contracts, specifically:

- A `.vy` contract compiled with either of the following `vyper` versions: `0.2.15`, `0.2.16`, `0.3.0` - A primary function that utilizes the `@nonreentrant` decorator with a specific `key` and does not strictly follow the check-effects-interaction pattern (i.e. contains an external call to an untrusted party before storage updates) - A secondary function that utilizes the same `key` and would be affected by the improper state caused by the primary function

### Patches https://github.com/vyperlang/vyper/pull/2439, https://github.com/vyperlang/vyper/pull/2514

### Workarounds Upgrade to 0.3.1 or higher

### References Technical post-mortem report: https://hackmd.io/@vyperlang/HJUgNMhs2

 https://cve.radiocsirt.org/vuln/gsd-2023-39363 gsd-2023-39363 2026-10-20T21:48:32.992748+00:00 gsd-2023-39363 https://cve.radiocsirt.org/vuln/pysec-2023-142 PYSEC-2023-142 2026-10-20T21:48:32.992762+00:00

Affected: PyPI: vyper

Vyer is a Pythonic Smart Contract Language for the Ethereum Virtual Machine (EVM). In versions 0.2.15, 0.2.16 and 0.3.0, named re-entrancy locks are allocated incorrectly. Each function using a named re-entrancy lock gets a unique lock regardless of the key, allowing cross-function re-entrancy in contracts compiled with the susceptible versions. A specific set of conditions is required to result in misbehavior of affected contracts, specifically: a `.vy` contract compiled with `vyper` versions `0.2.15`, `0.2.16`, or `0.3.0`; a primary function that utilizes the `@nonreentrant` decorator with a specific `key` and does not strictly follow the check-effects-interaction pattern (i.e. contains an external call to an untrusted party before storage updates); and a secondary function that utilizes the same `key` and would be affected by the improper state caused by the primary function. Version 0.3.1 contains a fix for this issue.