{"id":"CVE-2023-39363","aliases":["EUVD-2023-0265","GHSA-5824-cm3x-3c38","PYSEC-2023-142"],"status":"published","title":"Vyper incorrectly allocated named re-entrancy locks","description":"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.","severity":{"version":"4.0","score":9.1,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:H/SC:N/SI:H/SA:H/E:A","level":"critical","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-12","score":0.00821,"percentile":0.57779,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-863"],"published":"2023-08-07T18:40:25Z","modified":"2026-10-28T02:30:30Z","fixes":[{"ecosystem":"PyPI","package":"vyper","fixed_in":["0.3.1"],"sources":["ghsa","osv"]}],"affected":[{"source":"ghsa","ecosystem":"PyPI","package":"vyper","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0.2.15"},{"fixed":"0.3.1"}]}]},{"source":"osv","ecosystem":"PyPI","package":"vyper","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0.2.15"},{"fixed":"0.3.1"}]}],"versions":["0.2.15","0.2.16","0.3.0"]},{"source":"osv","ecosystem":"PyPI","package":"vyper","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"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.2","0.3.3","0.3.4","0.3.5","0.3.6","0.3.7","0.3.8","0.3.9","0.3.10","0.3.10rc1","0.3.10rc2","0.3.10rc3","0.3.10rc4","0.3.10rc5","0.4.0","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","0.4.1","0.4.1b1","0.4.1b2","0.4.1b3","0.4.1b4","0.4.1rc1","0.4.1rc2","0.4.1rc3","0.4.2","0.4.2rc1","0.4.3","0.4.3rc1"]}],"products":[{"vendor":"vyperlang","product":"vyper"}],"references":[{"url":"https://github.com/vyperlang/vyper/security/advisories/GHSA-5824-cm3x-3c38","tags":["x_refsource_CONFIRM","x_transferred","Exploit","Patch","Third Party Advisory","advisory","web"]},{"url":"https://github.com/vyperlang/vyper/pull/2439","tags":["x_refsource_MISC","x_transferred","Patch","fix","web"]},{"url":"https://github.com/vyperlang/vyper/pull/2514","tags":["x_refsource_MISC","x_transferred","Patch","fix","web"]},{"url":"https://hackmd.io/@LlamaRisk/BJzSKHNjn","tags":["x_refsource_MISC","x_transferred","Exploit","Third Party Advisory","web"]},{"url":"https://hackmd.io/@vyperlang/HJUgNMhs2","tags":["x_refsource_MISC","x_transferred","Exploit","Third Party Advisory","web"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2023-39363","tags":["advisory"]},{"url":"https://github.com/pypa/advisory-database/tree/main/vulns/vyper/PYSEC-2023-142.yaml","tags":["web"]},{"url":"https://github.com/advisories/GHSA-5824-cm3x-3c38"},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2023/39xxx/CVE-2023-39363.json","tags":["advisory"]},{"url":"https://github.com/vyperlang/vyper","tags":["package"]}],"sources":{"cve":[{"id":"CVE-2023-39363","title":"Vyper incorrectly allocated named re-entrancy locks","description":"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.","status":"published","published":"2023-08-07T18:40:25.615Z","modified":"2024-10-11T14:05:03.824Z","cvss":[{"version":"4.0","score":9.1,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:H/SC:N/SI:H/SA:H/E:A","level":"critical","assessor":"cna"}],"cwes":["CWE-863"],"updated_at":"2026-11-02T14:35:33.138994Z"}],"euvd":[{"id":"EUVD-2023-0265","description":"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.","status":"published","published":"2023-08-07T18:40:25Z","modified":"2024-10-11T14:05:03Z","cvss":[{"version":"4.0","score":9.1,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:H/SC:N/SI:H/SA:H/E:A","level":"critical"}],"updated_at":"2026-11-03T00:27:39.67018Z"}],"ghsa":[{"id":"GHSA-5824-cm3x-3c38","title":"Vyper has incorrectly allocated named re-entrancy locks","description":"### Impact\n\nIn 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:\n\n- A `.vy` contract compiled with either of the following `vyper` versions: `0.2.15`, `0.2.16`, `0.3.0`\n- 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)\n- A secondary function that utilizes the same `key` and would be affected by the improper state caused by the primary function\n\n### Patches\nhttps://github.com/vyperlang/vyper/pull/2439, https://github.com/vyperlang/vyper/pull/2514\n\n### Workarounds\nUpgrade to 0.3.1 or higher\n\n### References\nTechnical post-mortem report: https://hackmd.io/@vyperlang/HJUgNMhs2","status":"published","published":"2023-08-09T14:27:57Z","modified":"2024-10-11T14:04:47Z","cvss":[{"version":"4.0","score":9.1,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:H/SC:N/SI:H/SA:H/E:A","level":"critical"},{"version":"3.1","score":8.7,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:H/A:H","level":"high"}],"cwes":["CWE-863"],"updated_at":"2026-11-02T14:38:09.785133Z"}],"nvd":[{"id":"CVE-2023-39363","description":"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.","status":"published","published":"2023-08-07T19:15:11.873Z","modified":"2026-06-17T06:12:08.867Z","cvss":[{"version":"4.0","score":9.1,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:H/SC:N/SI:H/SA:H/E:A/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X","level":"critical","assessor":"secondary"},{"version":"3.1","score":5.9,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N","level":"medium","assessor":"primary"}],"cwes":["CWE-863"],"updated_at":"2026-11-02T14:08:20.798312Z"}],"osv":[{"id":"CVE-2023-39363","title":"Vyper incorrectly allocated named re-entrancy locks","description":"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.","status":"published","published":"2023-08-07T18:40:25.615Z","modified":"2026-10-28T02:30:30.076966957Z","cvss":[{"version":"4.0","score":9.1,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:H/SC:N/SI:H/SA:H/E:A","level":"critical"}],"cwes":["CWE-863"],"updated_at":"2026-11-02T15:44:32.922049Z"},{"id":"GHSA-5824-cm3x-3c38","title":"Vyper has incorrectly allocated named re-entrancy locks","description":"### Impact\n\nIn 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:\n\n- A `.vy` contract compiled with either of the following `vyper` versions: `0.2.15`, `0.2.16`, `0.3.0`\n- 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)\n- A secondary function that utilizes the same `key` and would be affected by the improper state caused by the primary function\n\n### Patches\nhttps://github.com/vyperlang/vyper/pull/2439, https://github.com/vyperlang/vyper/pull/2514\n\n### Workarounds\nUpgrade to 0.3.1 or higher\n\n### References\nTechnical post-mortem report: https://hackmd.io/@vyperlang/HJUgNMhs2","status":"published","published":"2023-08-09T14:27:57Z","modified":"2026-09-10T03:49:57.451549676Z","cvss":[{"version":"3.1","score":8.7,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:H/A:H","level":"high"},{"version":"4.0","score":9.1,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:H/SC:N/SI:H/SA:H/E:A","level":"critical"}],"cwes":["CWE-863"],"updated_at":"2026-11-02T15:46:38.213481Z"},{"id":"PYSEC-2023-142","description":"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.","status":"published","published":"2023-08-07T19:15:00Z","modified":"2025-10-09T08:26:23.283831Z","cvss":[{"version":"3.1","score":5.9,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N","level":"medium"}],"updated_at":"2026-11-02T15:52:53.837392Z"}]}}