GHSA-5824-CM3X-3C38 Vyper has incorrectly allocated named re-entrancy locks

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...

Incorrect Re-Entrancy Lock Allocation

vyper is vulnerable to Incorrect Re-Entrancy Lock Allocation. The allocation of named re-entrancy locks is flawed, which makes cross-function re-entrancy possible in contracts, because each function employing a named re-entrancy lock receives a distinct lock independent of the key under a specifi...

PYSEC-2023-142

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...

PYSEC-2023-142

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...

CVE-2023-39363 Vyper incorrectly allocated named re-entrancy locks

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...

PT-2023-26896 · Vyper · Vyper

Name of the Vulnerable Software and Affected Versions: Vyper versions 0.2.15 through 0.3.0 Description: The issue arises from the incorrect allocation of named re-entrancy locks in Vyper versions 0.2.15, 0.2.16, and 0.3.0. Each function using a named re-entrancy lock gets a unique lock regardless...

Use of globalState.unlocked state change outside lock modifier allows for Re-entrancy which would cause huge loss to pool

Lines of code Vulnerability details I guess I can put this into one report since the issue affects two seperate functions in a contract. Impact The functions AlgebraPool.swap and AlgebraPool.swapSupportingFeeOnInputTokens attempt to not use the lock modifier to update the globalState.unlocked sta...

Lack of lock modifier on sell() can lead to reentrancy

Lines of code Vulnerability details Impact NibblVault.sell does not possess the lock modifier that protects against reentrancy. The only attack vector due to reentrancy in this function was found to be executable by the factory that receives the admin fees which is not plausible due to the curren...

In the lend() function state updates are made after the callback

Handle jayjonah8 Vulnerability details Impact In TimeswapPair.sol, the lend function has a callback to the msg.sender in the middle of the function while there are still updates to state that take place after the callback. The lock modifier guards against reentrancy but not against cross function...