Full Report
Zora has a module for allowing users to list any NFT for sale at a fixed price and currency. This is referred to as AsksV1 or Buy Now in the ecosystem. A potential buyer is able to fill that listing by calling a method in the AsksV1. With this, Zora transfers the funds out of the buyers account and sends them to the seller for payment. In return, the NFT is transferred to the new owners account. In Ethereum, a transaction is put into the mempool where a miner selects which transactions will be put into a given block. If a transaction will pay out more (higher gas), it is more likely to be selected. The key component is that this is NOT a queue that is FIFO. Because of the transaction pool not being a queue that is FIFO, it creates an attack known as frontrunning - a type of race condition. This happens when something is in the mempool but somebody else can put another transaction at a higher gas price to do something malicious to you. In the case of our NFT trading site, there is a frontrunning issue. To make the payment for the NFT, a user must first approve Zora to pull funds from the account. A common pattern is for an infinite amount of user tokens to be allowed by the contract. This allows for a user experience improvement and saves on gas costs. What's the problem with this though? A seller places an NFT at a very discounted price. A buyer sees the good deal. They allow for Zora to spend an infinite amount of a users token. The buyer calls the functionality to purchase the token. The seller sees the purchase has been made in the mempool. As a result, they make a higher priority transaction to increase the price of the NFT. The buyer purchases the NFT for a bogus cost because of the infinite approval of spending on the token. This vulnerability does require user interaction in order to pull off. However, the frontrunning attack is very slick and could have been used to wipe the users wallet clean of a particular coin. To mitigate this bug in the future, V3 now has a field to specify the cost you would like to pay for it. Overall, neat bug!
Analysis Summary
# Vulnerability: Zora AsksV1 Frontrunning Exploitation via Infinite Token Approval
## CVE Details
- CVE ID: Not Assigned (Based on the provided context, this appears to be an analysis of a specific protocol flaw rather than a formal CVE entry)
- CVSS Score: N/A (Not formally assessed)
- CWE: CWE-362 (Race Condition)
## Affected Systems
- Products: Zora AsksV1 (Buy Now listing module)
- Versions: Prior to implementation of a fix resembling Zora V3 functionality enhancements.
- Configurations: Systems where users grant *infinite approval* for Zora contracts to spend their tokens for fixed-price NFT purchases.
## Vulnerability Description
The vulnerability exists in Zora's `AsksV1` (Buy Now) module due to a race condition exploitable via frontrunning. Zora requires two primary steps for a purchase:
1. **Approval:** The buyer grants an almost universal pattern in DeFi—an **infinite approval** for the Zora contract to spend a specific token on the buyer's behalf, improving UX and saving gas.
2. **Execution:** The buyer sends a transaction to fill the Ask/purchase the NFT.
When the buyer's purchase transaction enters the Ethereum mempool, a malicious seller (or attacker observing the mempool) can monitor this pending transaction. If the seller sees the buyer initiating a purchase at a previously set, discounted price, the seller can swiftly issue a **higher-priority transaction** (by paying a higher gas fee) that alters the *Ask* details (specifically, increasing the required price).
Since the buyer had already granted an *infinite approval*, the attacker's subsequent transaction successfully executes first, raising the price. The buyer's original transaction then executes immediately after, spending an allegedly "bogus cost" (the inflated price) because the approval was pre-authorized for an unlimited amount, potentially draining the user's token balance up to the intended purchase amount or beyond, depending on the contract logic related to the successful execution.
## Exploitation
- Status: Theoretical/Demonstrated through Proof-of-Concept scenario (Requires user interaction to set up the initial approval and attempt the purchase).
- Complexity: Medium (Requires monitoring the mempool and timing subsequent transactions with high gas fees).
- Attack Vector: Network (Via blockchain transaction manipulation).
## Impact
- Confidentiality: None directly.
- Integrity: **High**. The attacker can force the buyer to spend significantly more tokens than intended or potentially drain the wallet of that specific token, leading to unauthorized asset transfer.
- Availability: Low impact on the protocol itself, but the user suffers asset loss.
## Remediation
### Patches
- **Zora V3 Implementation:** The context indicates that a future version (V3) addresses this by introducing a mechanism to **specify the exact cost/price limit** the user is willing to pay within the V3 transaction structure, overriding the danger of the infinite allowance.
### Workarounds
- **Limit Approvals:** Users should avoid granting infinite allowances to DEX/marketplace contracts if the interaction involves pending, observable transactions (batch purchasing or complex asset exchanges). Users could set a finite allowance equal to the maximum expected purchase price.
- **Use Lower Priority Gas:** For known non-instantaneous transactions, buyers could attempt to avoid putting transactions that rely on a specific price being maintained into a highly competitive gas environment, though this is unreliable against a determined frontrunner.
## Detection
- **Detection Methods and Tools:** Monitoring for transactions that increase the gas price significantly immediately following a user-initiated token spending transaction involving protocols known to utilize infinite allowances. Analyzing historical transactions for patterns where a purchase appears executed immediately after a price update by the seller.
- **Indicators of Compromise:** A user transaction that executes at a price substantially higher than the listed price visible immediately preceding the transaction execution.
## References
- Analysis derived from the provided article context regarding Zora AsksV1 design flaws interacting with the Ethereum mempool mechanics.