CVE-2025-27105
criticalpriority · track · 0EPSS 0.006 · 47 %ileEUUSEPSS · scored 2026-10-27
vyper is a Pythonic Smart Contract Language for the EVM. Vyper handles AugAssign statements by first caching the target location to avoid double evaluation. However, in the case when target is an access to a DynArray and the rhs modifies the array, the cached target will evaluate first, and the bounds check will not be re-evaluated during the write portion of the statement. This issue has been addressed in version 0.4.1 and all users are advised to upgrade. There are no known workarounds for this vulnerability.
cvss
Technical severity, 0–10. One row per scoring source.
base score 0–10 · higher = more severe · hover a vector to decode⚠ sources disagree · low–critical · 0.6–9.1
ssvc
A stakeholder decision — act, attend, or track — from exploitation and impact.
weaknesses
The CWE weakness classes this flaw belongs to.
affected products (3)
Products and version ranges known to be affected.
advisories (2)
Vendor and ecosystem advisories describing this.
- GHSA-4w26-8p97-f4jpAugAssign evaluation order causing OOB write within the object in Vyper2025-02-21ghsa · osvUS
Vyper handles AugAssign statements by first caching the target location to avoid double evaluation. However, in the case when target is an access to a DynArray and the rhs modifies the array, the cached target will evaluate first, and the bounds check will not be re-evaluated during the write portion of the statement. In other words, the following code ```vyper def poc(): a: DynArray[uint256, 2] = [1, 2] a[1] += a.pop() ``` is equivalent to: ```vyper def poc(): a: DynArray[uint256, 2] = [1, 2] a[1] += a[len(a) - 1] a.pop() ``` rather than: ```vyper def poc(): a: DynArray[uint256, 2] = [1, 2] s: uint256 = a[1] t: uint256 = a.pop() a[1] = s + t # reverts due to oob access ```
- PYSEC-2025-312025-02-21vendor · osvUS
vyper is a Pythonic Smart Contract Language for the EVM. Vyper handles AugAssign statements by first caching the target location to avoid double evaluation. However, in the case when target is an access to a DynArray and the rhs modifies the array, the cached target will evaluate first, and the bounds check will not be re-evaluated during the write portion of the statement. This issue has been addressed in version 0.4.1 and all users are advised to upgrade. There are no known workarounds for this vulnerability.
also known as (6)
Other names and identifiers for this entity.
sources
Which sources assert this record, and when.
references (5)
External citations — patches, advisories, analysis.
- https://access.redhat.com/security/cve/cve-2025-27105cnnvd
- https://github.com/vyperlang/vyper/security/advisories/GHSA-4w26-8p97-f4jpcnnvd
- https://vigilance.fr/vulnerability/Vyper-write-access-via-AugAssign-Statements-46579cnnvd
- https://github.com/vyperlang/vyper/security/advisories/GHSA-4w26-8p97-f4jpenisa_euvd
- https://github.com/vyperlang/vyper/security/advisories/GHSA-4w26-8p97-f4jpExploitVendor Advisorynvd
Attackers weaponise vulnerabilities like this against internet-exposed services. See what is exposed on your perimeter with a free passive scan.
Free scan