Skip to main content
Sigvex

ERC-165 Interface Spoofing

Detects contracts that falsely claim ERC-165 interface support, enabling type confusion attacks in routers, marketplaces, and bridges.

ERC-165 Interface Spoofing

Overview

The ERC-165 spoofing detector identifies contracts whose supportsInterface implementation returns true for interfaces they do not actually implement. Routers, marketplaces, and bridges that rely on ERC-165 to detect token standards (ERC-721, ERC-1155, ERC-2981) can be tricked into treating a malicious contract as a legitimate token.

Why This Is an Issue

When a contract claims to support ERC-721 but does not implement transferFrom, a marketplace calling transferFrom will either revert (DoS) or, if the fallback function processes the call, execute unexpected logic. An attacker can exploit this to:

  • Bypass token type validation in multi-standard marketplaces
  • Trigger fallback functions during what should be safe token transfers
  • Exploit type confusion when bridges handle cross-chain token bridging

How to Resolve

Callers should verify not just supportsInterface but also test critical functions:

function isERC721(address token) internal view returns (bool) {
    try IERC165(token).supportsInterface(type(IERC721).interfaceId) returns (bool supported) {
        if (!supported) return false;
        // Also verify critical function exists
        try IERC721(token).balanceOf(address(0)) returns (uint256) {
            return true;
        } catch {
            return false;
        }
    } catch {
        return false;
    }
}

Examples

Sample Sigvex Output

{
  "detector_id": "erc165-spoofing",
  "severity": "medium",
  "confidence": 0.72,
  "description": "supportsInterface() at offset 0x1c returns true for ERC-721 (0x80ac58cd) but the contract does not implement transferFrom(address,address,uint256). Callers relying on ERC-165 will encounter unexpected behavior.",
  "location": { "function": "supportsInterface(bytes4)", "offset": 28 }
}

Detection Methodology

  1. supportsInterface analysis: Decompiles the function and identifies which interface IDs return true.
  2. Interface verification: For each claimed interface, checks whether the contract implements the required functions by selector presence.
  3. Mismatch reporting: Reports interfaces claimed but not implemented.

Limitations

  • Proxy contracts where the implementation has the functions but the proxy’s supportsInterface is checked may produce false positives.
  • Dynamic interface support (computed at runtime based on storage) is hard to verify statically.

References