Allowance is consistent in different functions

Handle jonah1005 Vulnerability details Impact Allowance in the contract stands for shares while the other functions use the balance. When a user tries to deposit 100 ibBTC to a contract, he calls approve, 100. The allowance would not be zero after the contract takes 100 ibBTC from the user. Users...

ERC20 return values not checked

Handle cmichel Vulnerability details The ERC20.approve function returns a boolean value indicating success. This parameter needs to be checked for success. The Basket.approveUnderlying function does not check the return value of the IERC20tokensi.approve call. Neither does it work with tokens tha...

nTokenAction does not emit Approval events

Handle cmichel Vulnerability details Vulnerability Details The nTokenAction is supposed to mimic the ERC20 but the allowance changes do not emit the Approval event in nTokenTransferFrom. Impact Off-chain scripts will have the wrong allowance value as it's tracked in nTokenTransferApproveAll but t...

Allowance checks not correctly implemented

Handle cmichel Vulnerability details Vulnerability Details The nTokenAction implements two token approvals, the nTokenWhitelist which is always used first, and the nTokenAllowance which is checked second. If the nTokenWhitelist does not have enough allowance for the transfer, the transaction fail...

Use of safeApprove will always cause approveMax to revert

Handle 0xRajeev Vulnerability details Impact Unlike SwappableYieldSource which uses safeIncreaseAllowance to increase the allowance to uint256.max, mStableYieldSource uses OpenZeppelin’s safeApprove which has been documented as 1 Deprecated because of approve-like race condition and 2 To be used...

redeemToken can fail for certain tokens

Handle cmichel Vulnerability details The SwappableYieldSource.redeemToken function transfers tokens from the contract back to the sender, however, it uses the ERC20.transferFromaddressthis, msg.sender, redeemableBalance function for this. Some deposit token implementations might fail as...

The approveMax function of MStableYieldSource always reverts

Handle shw Vulnerability details Impact The approveMax function of MStableYieldSource calls the safeApprove function to set the allowance to the maximum. However, at the time of call, the allowance should be non-zero since it was set to the maximum in the constructor function. The non-zero...

Yield sources cannot be swapped back

Handle shw Vulnerability details Impact The setYieldSource function of SwappableYieldSource calls the safeApprove function to approve the yield sources with the maximum allowance of transferring underlying tokens. However, according to OpenZeppelin's implementation, the safeApprove function...

Allowance cannot be reset once it is set to the maximum

Handle shw Vulnerability details Impact The approve functions of the pool LP tokens and synths do nothing if the allowances is already the maximum number, i.e., typeuint256.max. Therefore, Alice cannot change her allowance to Bob once she approved him with the maximum approval. Proof of Concept...

Synth: cannot change approval once set to max value

Handle cmichel Vulnerability details The Synth.approve function performs a no-op if the allowance is currently set to typeuint256.max. This leads to the issue that approvals cannot be changed anymore once they are set to the max value. Impact Imagine someone approving an operator with the max val...

Transaction-Order-Dependence race condition for approveTransferERC20()

Handle 0xRajeev Vulnerability details Impact Similar to ERC20 approve being susceptible to double-spend allowance due to front-running, approveTransferERC20 here is also susceptible. For reference, see . This is the classic ERC20 approve race condition where a malicious spender can double-spend...

Protect

FortiOS Explicit Web Proxy by default allows non-standard HTTP traffic.Â...

CVE-2019-10134

A flaw was found in Moodle before 3.7, 3.6.4, 3.5.6, 3.4.9 and 3.1.18. The size of users' private file uploads via email were not correctly checked, so their quota allowance could be exceeded...

CVE-2019-10134

A flaw was found in Moodle before 3.7, 3.6.4, 3.5.6, 3.4.9 and 3.1.18. The size of users' private file uploads via email were not correctly checked, so their quota allowance could be exceeded...

DRUPAL-CONTRIB-2019-047

In certain configuration cases, when a learning path is configured as semi-private, anonymous users are allowed to join a learning path when they should not...

Cross-site Scripting (XSS)

cumin is vulnerable to cross-site scripting XSS. The vulnerability exists through the Max Allowance field in the Set limit form...

CVE-2018-18344

CVE-2018-18344 affects Google Chrome/Chromium before 71.0.3578.80 where the setDownloadBehavior devtools protocol feature in Extensions could be abused by a remote attacker who controls an installed extension to access local files. The issue is described as an inappropriate implementation in the ...

CVE-2018-18344

Inappropriate allowance of the setDownloadBehavior devtools protocol feature in Extensions in Google Chrome prior to 71.0.3578.80 allowed a remote attacker with control of an installed extension to access files on the local file system via a crafted Chrome Extension...

SUSE-SU-2017:1997-1 Security update for apache2

This update provides apache2 2.2.34, which brings many fixes and enhancements: Security issues fixed: - CVE-2017-9788: Uninitialized memory reflection in modauthdigest. bsc1048576 Bug fixes: - Remove /usr/bin/http2 link only during package uninstall, not upgrade. bsc1041830 - Don't put the backen...

PT-2013-5004 · Red Hat · Red Hat Enterprise Mrg Grid

Name of the Vulnerable Software and Affected Versions: Red Hat Enterprise MRG Grid version 2.4 Description: A cross-site scripting XSS issue exists in the web interface for cumin, allowing remote attackers to inject arbitrary web script or HTML via the Max allowance field in the "Set limit" form...