Smart Contract Vulnerabilities That Target ERC20 Approvals

When I first watched a friend swap a handful of ETH for a brand‑new token, I didn’t see a single line of code. I saw a tap on a phone, a promise of quick gains, and a sense of community. The friend looked up, eyes wide, and asked, “Do I need to worry about smart contracts?” I shrugged. “It’s just a transfer,” I said. The reality was that behind that simple interface lay a set of rules and a potential for abuse that most investors never think about.

ERC20 Approvals: The Basics

An ERC20 token is a standard contract on Ethereum that defines how tokens are transferred, how balances are kept, and how other contracts can interact with those balances. One of its core functions is approve, which lets a token holder allow a third‑party address—often a decentralized exchange (DEX) or a lending platform—to spend a specified amount of their tokens. The approved address can then call transferFrom to move the tokens from the owner’s balance to another account.

The flow looks like this:

1. Owner calls approve(spender, amount) on the token contract.
2. The token contract records that spender is allowed to move up to amount tokens.
3. Later, spender calls transferFrom(owner, recipient, amount) to move the tokens.

On paper this is straightforward. In practice, the pattern has a handful of hidden pitfalls that can turn a seemingly safe approval into a lever for loss.

The TransferFrom Pattern and Why It Matters

When building a DEX or a lending protocol, the most common operation is “pull tokens from a user.” Instead of forcing the user to send tokens directly (which would require them to send a transaction), the protocol relies on the ERC20 approve/transferFrom mechanism. The user approves the protocol, and the protocol pulls the funds when needed. This abstraction is convenient, but it also shifts responsibility: the protocol must trust that the transferFrom call will execute as intended and that the allowance hasn’t been manipulated.

Vulnerability 1: The Approval Race Condition

The most notorious flaw is the race condition between two separate approve calls. Imagine you want to trade 100 tokens. You approve 100, then you submit a trade. Meanwhile, a malicious actor watches the network and submits a second approve for a smaller amount (say 1 token) before the first transaction finalizes. Because the token contract doesn’t enforce an allowance reset, the second approve overrides the first. The trade now only pulls 1 token, potentially leaving you with 99 tokens that still sit idle, or worse, the protocol may have logic that incorrectly assumes the full 100 were transferred.

The underlying cause is that the ERC20 standard does not require the allowance to be reset to zero before a new approval. Some developers adopt the “reset‑then‑set” pattern to mitigate this:

function safeApprove(address spender, uint256 amount) public {
    require(allowance[msg.sender][spender] == 0 || amount == 0,
        "Non‑zero to non‑zero approvals are risky");
    allowance[msg.sender][spender] = amount;
}

Even with this, front‑running remains a threat because transactions can still be reordered if an attacker front‑runs the approval transaction itself.

Vulnerability 2: Malicious Token Contracts

Not all tokens behave the same. Some implement their own custom logic in approve, transferFrom, or even in a fallback function. A notorious example is the BUSD token’s approve function, which calls an external address before setting the allowance. If that external address is malicious, it can manipulate the state of the token or even drain funds.

In some cases, tokens override transferFrom to impose additional checks, such as a blacklist or a whitelist, that may silently fail or revert, leaving the user unaware that the transfer didn't go through. Users often assume that if the transaction succeeded on the blockchain, the tokens moved, but the contract can silently change the state in subtle ways.

Vulnerability 3: Allowance Overflows and Underflows

Solidity’s uint256 type can hold very large numbers. If a contract does not use safe math, adding to an allowance can overflow and wrap around to zero, effectively resetting the allowance. Conversely, subtracting from an allowance can underflow, making the allowance a huge number and allowing a spender to transfer more than intended. Though modern compilers enable overflow checks by default, older contracts or those that use unchecked blocks are still vulnerable.

Example:

allowance[msg.sender][spender] += addedValue; // could overflow

Even if the code compiles without error, the logic might still allow a user to unintentionally grant a huge allowance due to an overflow.

Vulnerability 4: Re‑Entrancy via Approve and TransferFrom

Re‑entrancy is a classic attack vector in smart contracts, famously exploited in the DAO hack. While ERC20 tokens themselves are not susceptible to re‑entrancy in the approve function (since it doesn’t call external contracts), the surrounding logic in a protocol that calls transferFrom could be. For instance, a protocol might call token.transferFrom(msg.sender, address(this), amount) and then immediately call a function that updates user balances. If the token contract triggers a callback during the transfer (some tokens support ERC223 callbacks), a malicious contract could re‑enter the protocol before the balances are updated, allowing double spending.

To guard against this, designers should:

• Keep external calls to the smallest number possible.
• Use re‑entrancy guards (nonReentrant modifiers).
• Prefer “pull over push” patterns: let users withdraw rather than the protocol pushing funds.

Vulnerability 5: Front‑Running and Gas‑Based Attacks

Because ERC20 approvals and transfers are on-chain, anyone can observe pending transactions. An attacker can see an approval for 1,000 tokens and then immediately submit a transferFrom with a higher gas price, making the transaction mine before the approval transaction is finalized. The result is that the spender receives tokens even though the user didn’t approve that amount yet.

This front‑running is more difficult to mitigate because it’s a game of speed rather than logic. Protocol designers can:

• Use time‑locked approvals or multi‑signature approval flows.
• Encourage users to send low‑gas approvals, making them less attractive to front‑rollers.
• Use on‑chain mechanisms like permit (EIP‑2612) that allow off‑chain approvals via signatures, reducing the need for an on‑chain approval transaction that can be front‑run.

Vulnerability 6: Delegate Calls and EIP‑777

Some tokens implement the EIP‑777 standard, which introduces a “hook” mechanism where the token contract can call a function on the recipient before completing the transfer. If a protocol uses transferFrom with an ERC777 token and doesn’t expect the hook to modify state or emit events, it might incorrectly assume the transfer succeeded. If the recipient contract reverts or performs additional actions, the overall logic may fail or behave unpredictably.

Protocols that need to interact with EIP‑777 tokens should:

• Explicitly handle the tokensReceived callback.
• Test thoroughly with a variety of token contracts.

Real‑World Examples

1. The Uniswap v2 Router’s “SafeApprove”
   Early versions of Uniswap v2’s router had a bug that allowed users to approve the same amount twice without resetting to zero, enabling a race condition that could be exploited by front‑running bots. The fix introduced the safeApprove pattern and the safeTransferFrom wrapper.

2. The PancakeSwap “Token” Bugs
   A batch of tokens on BSC had faulty approve implementations that allowed anyone to approve arbitrary amounts on behalf of any address, effectively giving them full control of the user’s tokens. PancakeSwap users had to pause transactions until the bug was fixed.

3. The ERC20 “approveAndCall” Hack
   Some tokens implemented an approveAndCall function that sent an arbitrary payload to a recipient contract upon approval. If that recipient was malicious, it could drain funds or trigger a re‑entrancy attack. The standard itself didn’t forbid it, but the community discouraged its use.

These incidents underscore that a seemingly innocuous function like approve can be a vector for loss if not carefully audited.

Practical Mitigation Strategies

1. Adopt the “Reset‑Then‑Set” Pattern

Before setting a new allowance, force the old allowance to zero. This reduces the window where a malicious actor could front‑run an approval change. Even though it increases the number of transactions, it adds a safety layer that is worth the cost for high‑value tokens.

function approveWithReset(address spender, uint256 amount) external returns (bool) {
    allowance[msg.sender][spender] = 0;
    return token.approve(spender, amount);
}

2. Use permit (EIP‑2612)

permit allows approvals to be signed off‑chain and submitted as part of a transaction, eliminating the need for an on‑chain approve transaction. Since the signature is verified on-chain, there is no window for a front‑run attack.

token.permit(msg.sender, spender, amount, deadline, v, r, s);

3. Integrate Re‑entrancy Guards

If your protocol interacts with ERC20 tokens that may call external contracts, wrap state updates in a nonReentrant modifier or perform all external calls after state changes.

4. Audit Token Contracts

If you’re deploying your own token, test approve and transferFrom with a variety of scenarios: race conditions, zero approvals, large numbers, etc. Use automated tools like Slither or MythX to spot common patterns.

5. Educate Users

Let your users understand that they should:

• Approve only the amount they truly need.
• Revoke unused allowances.
• Use time‑locked or single‑use approvals when possible.
• Check token source code before interacting.

6. Employ Time‑Locked Approvals

Some protocols introduce a delay between an approval request and its execution. This gives users a chance to cancel a malicious approval before it becomes effective.

Takeaway: Think of Approvals as a Garden Fence

Imagine your portfolio as a garden. ERC20 approvals are fences that allow certain tools (protocols) to access your plants (tokens). If you leave a fence open for an extra hour, a wind‑blown stone can pass through. If you set the fence to allow a specific size of stone, you’re more in control.

In practice, that means:

• Reset before setting – always close the fence before opening it again.
• Use off‑chain signatures – think of it as a pre‑approved key that doesn’t require the fence to be physically opened.
• Keep a watchdog – have a script that checks for open fences and revokes them after a day.
• Test thoroughly – before letting your garden grow, make sure the fence behaves as expected.

When you step back and look at the whole ecosystem, you’ll see that vulnerabilities are not inevitable; they’re simply places where the rules were misunderstood or overlooked. By applying these modest, disciplined practices, you can give your users confidence that the smart contracts they trust are as sturdy as the fences they build.

Remember, the goal isn’t to eliminate risk—impossible. It’s to manage it with clear, repeatable patterns that make the worst cases rare and the good cases predictable. Let’s keep our gardens healthy, and our investors informed.