7 matches found
Integer overflow
The mintToken function of a smart contract implementation for FuturXe, an Ethereum token, has an integer overflow that allows the owner of the contract to set the balance of an arbitrary user to any value...
CVE-2018-13718
CVE-2018-13718 concerns the FuturXe Ethereum token where the mintToken function has an integer overflow that lets the contract owner set an arbitrary user’s balance. This is a developer-facing vulnerability in the smart contract implementation, with the root cause described as an integer overflow...
Bugged Smart Contract FuturXE: How Could Someone Mess up with Boolean? (CVE-2018–12025)
Recently SECBIT team found a serious bug about the if condition in a deployed ERC20 smart contract called FuturXE FXE and here is the bugged part: //Function for transer the coin from one address to another function transferFromaddress from, address to, uint value returns bool success //checking...
FuturXE has an unspecified vulnerability
FuturXE FXE is an ethereum-based virtual currency. A security vulnerability exists in the 'transferFrom' function of the smart contract implementation in FXE, which stems from a logic error in the program. An attacker could exploit the vulnerability to make an unauthorized transfer of digital...
Input validation
The transferFrom function of a smart contract implementation for FuturXE FXE, an Ethereum ERC20 token, allows attackers to accomplish an unauthorized transfer of digital assets because of a logic error. The developer messed up with the boolean judgment - if the input value is smaller than or equa...
CVE-2018-12025
The transferFrom function of a smart contract implementation for FuturXE FXE, an Ethereum ERC20 token, allows attackers to accomplish an unauthorized transfer of digital assets because of a logic error. The developer messed up with the boolean judgment - if the input value is smaller than or equa...
CVE-2018-12025
The CVE-2018-12025 entry concerns FuturXE (FXE) ERC20 token. Connected sources provide concrete details: transferFrom is vulnerable due to a logic error in the allowance check—the condition if (allowed[from][msg.sender] >= value) return false misorders the logic, allowing an underflow on allow...