CVE-2018-10376
published 2018-04-25CVE-2018-10376: An integer overflow in the transferProxy function of a smart contract implementation for SmartMesh (aka SMT), an Ethereum ERC20 token, allows attackers to…
PriorityP271high7.5CVSS 3.0
AVNACLPRNUINSUCNIHAN
ITWVulnCheck KEV
Exploited in the wild
EPSS
1.82%
76.1th percentile
An integer overflow in the transferProxy function of a smart contract implementation for SmartMesh (aka SMT), an Ethereum ERC20 token, allows attackers to accomplish an unauthorized increase of digital assets via crafted _fee and _value parameters, as exploited in the wild in April 2018, aka the "proxyOverflow" issue.
Detection & IOCsextracted from sources · hover to see the quote
- →The proxyOverflow exploit targets the transferProxy function in the SmartMesh (SMT) ERC20 contract; monitor for calls to transferProxy where fee+value overflows a 256-bit unsigned integer (i.e., fee+value wraps to 0 or a small number), bypassing the sender balance check at line 2. ↗
- →Flag any transferProxy transaction where the crafted inputs satisfy fee+value = 0 (mod 2^256), as this makes all three sanity checks (lines 2, 4, and 5) evaluate to false, allowing unauthorized token minting. ↗
- →Alert on post-transaction token balance increases of extreme magnitude (e.g., ~5×10^57 USD equivalent) in ERC20 contracts, which is a strong indicator of a proxyOverflow-style integer overflow exploit. ↗
- →The vulnerability class 'proxyOverflow' affected 9 tradable ERC20 tokens simultaneously in April 2018; audit all ERC20 contracts with a transferProxy function for the same integer overflow pattern in the fee+value guard condition. ↗
- ·The attacker-controlled inputs require from=to≠msg.sender to be false (i.e., from=to=msg.sender is NOT required; the two unspecified address values are given as the same but different from the sender) — verify address relationship assumptions when writing detection logic. ↗
- ·The overflow occurs specifically in the guard expression (fee+value) used to check the sender's balance, not in the actual token transfer arithmetic at lines 8–10; detection must target the guard computation, not just the transfer lines. ↗
CVSS provenance
nvdv3.07.5HIGHCVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
nvdv2.05.0MEDIUMAV:N/AC:L/Au:N/C:N/I:P/A:N
vulncheck7.5HIGH
CVEs like this are exactly what “Exploited This Week” covers.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
GHSA
GHSA-65c2-c54h-rp7q: An integer overflow in the transferProxy function of a smart contract implementation for SmartMesh (aka SMT), an Ethereum ERC20 token, allows attacker
ghsa_unreviewed·2022-05-14
CVE-2018-10376 [HIGH] CWE-190 GHSA-65c2-c54h-rp7q: An integer overflow in the transferProxy function of a smart contract implementation for SmartMesh (aka SMT), an Ethereum ERC20 token, allows attacker
An integer overflow in the transferProxy function of a smart contract implementation for SmartMesh (aka SMT), an Ethereum ERC20 token, allows attackers to accomplish an unauthorized increase of digital assets via crafted _fee and _value parameters, as exploited in the wild in April 2018, aka the "proxyOverflow" issue.
VulnCheck
smartmesh smartmesh Integer Overflow or Wraparound
vulncheck·2018·CVSS 7.5
CVE-2018-10376 [HIGH] smartmesh smartmesh Integer Overflow or Wraparound
smartmesh smartmesh Integer Overflow or Wraparound
An integer overflow in the transferProxy function of a smart contract implementation for SmartMesh (aka SMT), an Ethereum ERC20 token, allows attackers to accomplish an unauthorized increase of digital assets via crafted _fee and _value parameters, as exploited in the wild in April 2018, aka the "proxyOverflow" issue.
Affected: smartmesh smartmesh
Required Action: Apply remediations or mitigations per vendor instructions or discontinue use of the product if remediation or mitigations are unavailable.
Exploitation References: https://nvd.nist.gov/vuln/detail/CVE-2018-10376; https://www.cve.org/CVERecord?id=CVE-2018-10376
No detection rules found.
No public exploits indexed.
arXiv
sGUARD: Towards Fixing Vulnerable Smart Contracts Automatically
arxiv_fulltext·2021-01-06
sGUARD: Towards Fixing Vulnerable Smart Contracts Automatically
## Abstract
Smart contracts are distributed, self-enforcing programs executing on top of blockchain networks. They have the potential to revolutionize many industries such as financial institutes and supply chains. However, smart contracts are subject to code-based vulnerabilities, which casts a shadow on its applications. As smart contracts are unpatchable (due to the immutability of blockchain), it is essential that smart contracts are guaranteed to be free of vulnerabilities. Unfortunately, smart contract languages such as Solidity are Turing-complete, which implies that verifying them statically is infeasible. Thus, alternative approaches must be developed to provide the guarantee. In this work, we develop an approach which automatically transforms smart contracts so that they are pro
arXiv
VeriSmart: A Highly Precise Safety Verifier for Ethereum Smart Contracts
arxiv_fulltext·2019-08-30
VeriSmart: A Highly Precise Safety Verifier for Ethereum Smart Contracts
: A Highly Precise Safety Verifier for
Ethereum Smart Contracts
To appear in the IEEE Symposium on Security & Privacy, May 2020
Sunbeom So, Myungho Lee, Jisu Park, Heejo Lee, Hakjoo Oh^*
^*Corresponding author: Hakjoo Oh, [email protected]
Department of Computer Science and Engineering
Korea University
(^*corresponding author)
Sunbeom So
Korea University
[email protected]
Myungho Lee
Korea University
[email protected]
Jisu Park
Korea University
[email protected]
Heejo Lee
Korea University
[email protected]
Hakjoo Oh^*
Korea University
[email protected]
## Abstract
We present , a highly precise verifier for ensuring
arithmetic safety of Ethereum smart contracts. Writing safe smart
contracts without unintended behavior is critically important
becau
2018-04-25
Published
Exploited in the wild