Full Report
ERC777 is a well known token standard for Non-Fungible Token (NFT). There are hooks defined on these NFTs in order to allow for users to perform operations on either receiving or sending NFTs. How are these hooks implemented though? Instead of checking the sender/receiver of the check, it looks into the ERC1820 registry contract. This is done by taking a hash of the interface then checking if the sender/receiver has added a hook for this. Once this is set, it will execute the hook at the address provided. Only the owner of an address can specify these hooks. This is where the novel technique comes into play... what if you have arbitrary call to an address within the context of the contract? An attacker could set the hook for the contract! This can be used as an unexpected reentrancy hook. This becomes particular troublesome with swap paths being calculated before the transaction assuming that the hook will not modify the state. Additionally, an attacker could force all transactions within the context of the contract to fail. Arbitrary calls within a contract are typically very bad anyway. This registry setting is just another way to make use of it.
Analysis Summary
# Vulnerability: Arbitrary Hook Injection Leading to Reentrancy/Denial of Service in ERC777 Implementations
## CVE Details
- CVE ID: N/A (Specific CVE not assigned in the provided text)
- CVSS Score: N/A (Severity inferred from description)
- CWE: CWE-840 (Improper Restriction of Calls to $\text{msg.sender/msg.origin}$) or CWE-807 (Improper Validation of Synthesized Input) might be relevant contextually, but the core issue relates to unexpected external calls via hooks.
## Affected Systems
- Products: Smart contracts implementing or interacting significantly with the **ERC777** token standard, especially those that rely on assumed safety regarding sender/receiver hook execution.
- Versions: Any implementation relying on the standard ERC777/ERC1820 registry interaction that permits arbitrary external calls to contract addresses without validation.
- Configurations: Primarily affects systems that allow arbitrary calls within contract logic (e.g., DEX aggregators calculating routes based on static state assumptions, or any contract using hooks for state changes).
## Vulnerability Description
ERC777 introduces optional hooks via the ERC1820 registry, which executes code upon receiving or sending the token. These hooks are resolved by hashing the interface ID and checking the registry for an address set by the token owner.
The core vulnerability arises because an attacker who can influence the state of an address involved in a token transfer (the recipient or sender, or potentially the contract itself if it sets hooks) can set this hook to point back to an arbitrary contract address under the attacker's control.
If the target contract subsequently executes an operation involving this hooked ERC777 token, the token standard will call the attacker-controlled hook address arbitrarily. This enables:
1. **Reentrancy Attacks:** The hook executes arbitrary code during a sensitive operation, allowing the attacker to manipulate state before the transaction finishes (dangerous for swap path calculations that assume static state).
2. **Denial of Service (DoS):** The attacker can set the hook to an address that always reverts, poisoning the address and causing all subsequent transactions involving token movement to that address to fail.
## Exploitation
- Status: PoC available (Described as a known technique enabled by the standard's design).
- Complexity: Medium (Requires ability to set a hook on an address involved in the transfer, which might require specific control or a successful initial state manipulation).
- Attack Vector: Network (Requires sending or receiving the ERC777 token to trigger the state change).
## Impact
- Confidentiality: Potential leakage if reentrancy allows unauthorized state readout, though primarily an integrity/availability issue.
- Integrity: High. An attacker can modify the state based on reentrancy or force transactions to fail if the hook reverts.
- Availability: High. An attacker can permanently revert all subsequent transfers involving the compromised address by setting a reverting hook.
## Remediation
### Patches
Since this affects the *usage* pattern rather than a flaw in the ERC777 implementation itself, provided patches are context-specific:
- **Recommended Solution:** Projects allowing arbitrary calls must restrict utilizing the **ERC1820 Registry** address as a potential target for those arbitrary calls. This prevents an attacker from dynamically setting an interface implementer (hook) that the contract will later call.
### Workarounds
- Audit any code path that performs arbitrary calls against tokens that support transfer hooks (like ERC777).
- Do not trust computed state (like optimal swap paths) if an intermediate step involves an ERC777 transfer and subsequent hook execution, as this state can be modified mid-transaction.
## Detection
- Indicators of Compromise: Transactions involving ERC777 transfers followed immediately by unexpected state changes or transaction failures originating from the transfer address.
- Detection Methods and Tools: Security audits focused on interaction logic between smart contracts and ERC777/ERC1820 hooks. Monitoring for contract calls originating from token transfer routines that resolve back to external, non-trusted addresses via ERC1820 lookups.
## References
- Vendor Advisories: None explicitly named, this analysis is based on a security research article published by MixBytes.
- Relevant links - defanged:
- hxxps://mixbytes.io/blog/one-more-problem-with-erc777