6123 matches found
GHSA-853P-5678-HV8F ink! vulnerable to incorrect decoding of storage value when using `DelegateCall`
Summary The return value when using delegate call mechanics, either through CallBuilder::delegate or inkenv::invokecontractdelegate, is being decoded incorrectly. Description Consider this minimal example: rust // First contract, this will be performing a delegate call to the Callee. inkstorage p...
CVE-2023-34449 ink! vulnerable to incorrect decoding of storage value when using `DelegateCall`
ink! is an embedded domain specific language to write smart contracts in Rust for blockchains built on the Substrate framework. Starting in version 4.0.0 and prior to version 4.2.1, the return value when using delegate call mechanics, either through CallBuilder::delegate or...
User ETH will be stacked on Executor contract if the target script doesn't handle ETH.
Lines of code Vulnerability details Description When user wants to execute an action, he must send ETH equal to the actionInfo.value, this ETH should be forwarded to executor.execute contract. Note: the function currently does't forward the ETH, it's explained on another issue 48, the fix is to...
Incorrect validation in LlamaRelativeQuorum results in improper approvals/disapprovals
Lines of code Vulnerability details Impact The LlamaRelativeQuorum contract is intended to allow for approvals/disapprovals to be configured such that, for example, an approval is triggered when a certain percentage of the total quantity for a role with this quantity being fixed at the creation o...
Inconsistent Use of Error Handling in LlamaAccount Contract
Lines of code Vulnerability details Description: The LlamaAccount contract contains a bug that allows an attacker to execute arbitrary calls with the delegatecall opcode, which can lead to unintended consequences and potential security vulnerabilities. Steps to Reproduce: Deploy the LlamaAccount...
LlamaAccount can be tricked to selfdestruct with an upgradable contract
Lines of code Vulnerability details Impact The LlamaAccount contract will be destroyed and all the assets can be lost. Proof of Concept In execute, we use readSlot0 to prevent a malicious or buggy target from taking ownership of this contract. But the malicious target can send all the assets and...
[ H ] In executeAction function, ETH can remain stuck after reverting due to a failed call.
Lines of code Vulnerability details Impact If and when the executeAction function reverts at either of the checks, the amount of ETH sent along with the call will be locked in the contract forever, with no current measures of recovery. Proof of Concept executeAction is called, but the call fails ...
Unsafe delegatecall functionality can break core protocol functionality
Lines of code Vulnerability details Impact There are multiple contracts which include delegatecall functionality, including the execute function of the LlamaAccount contract and the execute function of the LlamaExecutor contract. The issue is that there's no controls, other than the standard role...
The initial total supply of the role can be miscalculated in some cases
Lines of code Vulnerability details Impact Due to miscalculations during LlamaPolicy contract deployment the initial supply of the role can be set wrongly. And most of strategies will not work as intended. Moreover users will not be able to start an Action for some strategies as well. Proof of...
Technically the seven days period is not guaranteed and it's possible for the challenger to delete a withdrawal even if it hasn't been challenged during the seven days
Lines of code Vulnerability details Proof of Concept There's an existing logic to prevent the CHALLENGER from deleting a l2Output after the finalization period has ended. This is done to prevent having user withdrawals blocked after the finalization period has elapsed without challenges. The...
Incorrect Handling of Return Value in onlyWhenNotPaused Modifier
Lines of code Vulnerability details Description: contract named "L1ChugSplashProxy" which is a proxy contract with additional functionality for code and storage modification. However, there is a bug in the code that needs to be addressed. Bug: The bug is in the modifier onlyWhenNotPaused function...
When deploying a contract in PermissionlessNodeRegistry.deployNodeELRewardVault(), an attacker can find out in advance the address of the future deployed contract and deploy his own at this address
Lines of code Vulnerability details Impact The address of the new contract depends solely on the salt parameter, which is calculated from user-provided data. Once a user's create transaction is broadcast, the parameters for calculating salt can be viewed by anyone viewing the public mempool. This...
Anyone Can selfdestruct The VaultProxy Contract.
Lines of code Vulnerability details Vulnerability Details -Since the initialise function is missing initializer modifier as it's inteded to be not protected as per ETHx smart contract functions documentation , And Since VaultFactory contract doesn't initialize the VaultProxy upon its initializati...
accountsMap[ADMIN] not set in initialize function of StaderConfig contract
Lines of code Vulnerability details Impact When initializing the StaderConfig contract with the initialize function, the admin address is not set in accountsMapADMIN variable, so the getAdmin function will return address0. This will cause the loss of the ownership of the VaultProxy contract as it...
The claim() function has a reentrancy vulnerability
Lines of code Vulnerability details Impact The claim function has a reentrancy vulnerability . In the function, the UtilLib.sendValue function is called before emitting the Claimed event. This violates the "check-effect-interaction" model, which is a best practice for secure smart contract...
Recipient address is not appropriately validated or sanitized in the BaseFeeVault contract (loss of funds)
Lines of code Vulnerability details Impact If the recipient address is not properly validated, an attacker could supply a malicious address as the recipient. This could result in the accumulated fees being sent to an unintended or unauthorized party. It could lead to financial loss or disruption ...
Legacy version check should be removed to avoid double relaying message in CrossDomainMessager.sol
Lines of code Vulnerability details Impact Legacy version check should be removed to avoid double relaying message Proof of Concept In Optimism bedrock implementation, to handle the pre-bedrock migration, there is code check to make sure the transaction that finalized and relayed in pre-bedrock...
Aunction DOS
Lines of code Vulnerability details Impact All auction functions are under a potential DOS or exploitability vulnerability A 2 day duration is added to the current block.number when creating a lot. This introduces a critical flaw, Adding 2 86400correct value of 2 days / 27200wrong value used in...
When deploying contracts in PermissionedNodeRegistry.deployWithdrawVault(), PermissionlessNodeRegistry.deployWithdrawVault(), an attacker can find out in advance the address of the future deployed contract and deploy his own at this address
Lines of code Vulnerability details Impact The address of the new contract depends solely on the salt parameter, which is calculated from user-provided data. Once a user's create transaction is broadcast, the parameters for calculating salt can be viewed by anyone viewing the public mempool. This...
The owner is a single point of failure and a centralization risk
Lines of code Vulnerability details Impact Having a single EOA as the only owner of contracts is a large centralization risk and a single point of failure. A single private key may be taken in a hack, or the sole holder of the key may become unable to retrieve the key when necessary. Similar...