Automated market makers are targeted by front-running, sandwich attacks, oracle manipulation and liquidity exploitation. Attackers watch pending trades, distort pricing around those trades, or drain value from poorly designed pools and routing logic. Defenders should review slippage controls, oracle design, pool composition and transaction ordering assumptions before deployment.
What AMM attacks try to exploit
Automated market makers are attacked by exploiting how pricing, order flow, and liquidity interact in a public, fast-moving market. The attacker usually is not breaking the protocol in one step, but taking advantage of predictable trade execution, weak slippage assumptions, or pool designs that let value be extracted while ordinary users still think they are trading normally.
That is why the main attack classes cluster around transaction ordering, price distortion, and liquidity extraction. A pending trade can be observed and traded around, a price feed can be nudged at the wrong moment, or a pool can be drained through routes or composition choices that were safe on paper but fragile in practice.
In the Web3 and Crypto Security Guide, AMM security sits alongside front-end defence, oracle attack patterns and DeFi exploit paths because the weakness is often systemic rather than isolated to a single contract.
How front-running and sandwich attacks work
Front-running targets the visibility of pending transactions. If an attacker can see a large swap before it is confirmed, they can place their own transaction first, move the price against the victim, and then unwind after the victim trade lands. Sandwich attacks add a second step, with the attacker buying before and selling after the victim to capture the price movement they created.
The practical danger is that these attacks do not always require a contract bug. They exploit public mempool visibility, predictable execution ordering, and user tolerance for slippage. If slippage limits are too loose, or if routing assumptions assume fair ordering, the trade may still execute while transferring value to the attacker instead of to the trader.
Pending-order abuse is a recurring theme in real-world blockchain incident analysis, including attack chains that combine visible order flow with extraction or manipulation techniques. The State of NHI & AI Agent Breach Report 2026 is broader than DeFi, but it usefully shows how attackers turn observable execution paths into repeatable abuse patterns.
Why oracle manipulation and liquidity exploitation matter
Oracle manipulation targets the relationship between on-chain pricing and external reference pricing. If an AMM or a downstream protocol trusts a manipulable price source, an attacker can distort the reported value long enough to borrow, liquidate, mint, or trade on false assumptions. The risk grows when the pool is shallow, the oracle update path is weak, or the protocol uses a short-lived distorted price as if it were stable.
Liquidity exploitation is broader than price manipulation. Attackers may drain value from poorly balanced pools, exploit thin liquidity during volatile conditions, or route trades through paths that create losses for the pool and gains for the attacker. In practice, the weakness is often a design choice: the pool composition, fee model, rebalancing logic, and route selection all influence whether the AMM can absorb pressure or becomes easy to exploit.
For defenders, the useful question is not only whether the pool code is correct, but whether the market structure around it is robust enough to resist adversarial trading behaviour. That is why AMM review has to include pricing assumptions, oracle design and the economic impact of low-liquidity states, not just contract audits.
Risk and Threat Considerations
AMMs create a public, high-speed environment where small timing advantages can become material losses. The main risk is not just theft from one trade, but systematic value leakage when many users, routers, or downstream protocols assume execution will be fair and price updates will be stable.
Failure mechanism: Attackers exploit mempool visibility, weak slippage settings, shallow liquidity, or manipulable oracle inputs to shift pricing around a victim trade or to force a protocol to accept a false value.
Impact: Users receive worse execution, pools lose value, and dependent protocols can suffer bad debt, liquidations, or cascading losses if they trust the manipulated price or routing path.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API8 — Security Misconfiguration | AMM routing and price logic can fail when exposure and trust assumptions are misconfigured. |
| Recommendation — Harden exposed trade and pricing surfaces to prevent predictable manipulation. | ||
| MITRE ATT&CK | T1654 — Transaction and Tradecraft Interference | Front-running and sandwiching map to adversary interference with observable transaction flow. |
| Recommendation — Hunt for transaction-ordering abuse and flag suspicious pre- and post-trade timing patterns. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication, and Access Control | AMM admin, oracle and router access must be constrained because privileged changes affect pricing behavior. |
| Recommendation — Restrict and review privileged access to pricing, routing, and oracle configuration paths. | ||
Practitioner Guidance
What to verify: Confirm how the AMM handles transaction ordering, maximum slippage, oracle freshness, and pool depth under stress. If those assumptions are not explicitly tested, the protocol may be functionally live but economically fragile.
Decision rule: If a trade path depends on a price feed, route, or pool balance that can be moved quickly by an adversary, treat it as a manipulation surface and tighten the design before deployment. If the design can tolerate only ideal conditions, it is not ready for hostile markets.
Practitioner takeaway: AMM security is an economic and execution problem as much as a code problem, so the strongest controls are the ones that reduce observable advantage, constrain slippage, and make price assumptions harder to game.