Full Report
Uniswap X is a signature-based order book protocol. This allows for order fillers to perform arbitrary execution during the fulfillment, as long as the result of the execution is the order being filled properly. This allows a filler to get the best price from all of the various protocols, not just Uniswap, to fill the order. The author of this post had recently written a similar protocol called FloodPlain. In this protocol, the author wrote a bug that was caught by Spearbit. So, he wondered if the issue existed within the Uniswap X protocol. And, it turns out that it did! UniswapX will do a balance check before and after on the user to ensure that the user got the proper amount of tokens. However, this has a consequence: what if the user has another order in another protocol going on at the same time for the same token? If this happens, then it's possible to trick the accounting of the system. For instance, say a user made an order for 70 USDC on OpenSea and Uniswap at the same time. While taking the order from Uniswap (via the callback), the other platform could be resolved. Now, the user has 70K USDC in the account. So, upon entering back into the function, Uniswap believes that the user fairly got their funds. However, this came from ANOTHER order. So, the attacker gets a large amount of money in profit from it. The author got 200K USDC reward for this vulnerability; I appreciate how seriously Uniswap takes these bugs! Although this situation was possible, it wasn't something that could be trivially triggered. Additionally, I enjoyed the outlook on this from a developer perspective. A video going into the details can be found at here.
Analysis Summary
# Vulnerability: Unsafe Balance Check Leading to Accounting Manipulation in UniswapX
## CVE Details
- CVE ID: Not explicitly assigned in the text. (Likely assigned by vendor but not public at time of writing.)
- CVSS Score: Not explicitly provided, but classified as **High Severity** by Uniswap Labs.
- CWE: Likely related to CWE-843: Access of Object after Free (or similar logic/design flaw related to state management during callbacks).
## Affected Systems
- Products: UniswapX
- Versions: UniswapX v1.0 (Prior to the fix deployed on or around July 28, 2023).
- Configurations: Any user with an active order in the UniswapX protocol that involves arbitrary execution via callbacks.
## Vulnerability Description
The UniswapX protocol utilized a balance check mechanism (checking the user's token balance before and after settlement) similar to Uniswap V3 pools to ensure the order offerer received the correct amount of consideration tokens. However, this approach is unsafe in the context of UniswapX because fillers are allowed arbitrary execution (callbacks) that can interact with *external* protocols.
If a user has an active order for the same token on another DeFi protocol concurrently, a malicious filler can resolve that external order during the UniswapX callback. This manipulation allows the external protocol to resolve first, artificially inflating the user's token balance. When the execution returns to the UniswapX function, the pre-set balance check passes, leading UniswapX to incorrectly confirm the user received the consideration tokens, while in reality, those tokens originated from the external, concurrent transaction, resulting in profit for the attacker (filler/attacker). The attacker effectively gets the offer tokens from UniswapX without sending the corresponding consideration tokens back to the counterparty or protocol.
## Exploitation
- Status: **Not exploited in the wild.** The vulnerability was disclosed early, and a Proof of Concept (PoC) was provided by the reporter to the bounty program.
- Complexity: **Medium.** The attack requires precise timing and coordination with a concurrent order on an external protocol.
- Attack Vector: **Network** (via the malicious order filler interaction).
## Impact
- Confidentiality: **None** (Not primary impact)
- Integrity: **High.** Funds could be transferred incorrectly, leading to a loss of value for the counterparty or protocol integrity failure.
- Availability: **Low.** (Not a denial of service, but protocol logic is compromised.)
## Remediation
### Patches
- The issue was fixed by Uniswap Labs by redeploying contracts. The specific code change is located at: `https://github.com/Uniswap/UniswapX/commit/cf53fc7dd48029a9189d26812d676a4ea9d08d6c` (The specific version post-patch is not numerically designated, but it is the version deployed after this commit).
### Workarounds
- Immediately following disclosure, Uniswap Labs initially disabled the UniswapX toggle from the UI to prevent new vulnerable orders from being created.
## Detection
- **Indicators of Compromise:** Transactions involving complex multi-protocol interactions during a single UniswapX fulfillment process, especially those that resolve external orders during a callback, should be flagged for review.
- **Detection Methods and Tools:** Monitoring state changes in user balances immediately before and after contract callbacks within the settlement functions. Comparing intended token flows against actual token movements across external contract boundaries.
## References
- Vendor Advisory/Fix: `https://github.com/Uniswap/UniswapX/commit/cf53fc7dd48029a9189d26812d676a4ea9d08d6c`
- Researcher Report: `https://kebabsec.xyz/posts/critical_vulnerability_in_uniswapx/`
- PoC Example (referenced in article): The author wrote a coded POC (`https://kebabsec.xyz/uniswapx/poc.diff` - *deflanged*)