8,096 IPs, One WooCommerce Cart Attack: How We Protected the Cart Without Blocking AI Commerce

In a recent incident involving WooCommerce, a store experienced an unusual surge in traffic with suspicious patterns. The traffic appeared impressive, with thousands of sessions and active users, but the engagement was almost zero and revenue was zero. The requests were hitting WooCommerce URLs containing ?add-to-cart=..., indicating an attack on the cart functionality.

Investigating the situation, the team noticed that blocking the IP addresses or browser User-Agent would have been incorrect solutions. This was because they were actively building infrastructure that allowed legitimate AI shopping agents to interact with WooCommerce. They needed to stop abusive automation without breaking agentic commerce.

The team examined the server logs and discovered that the requests had a consistent pattern: GET /shop/example-product/?add-to-cart=1234 and sometimes GET /basket/ with the second request arriving only a few seconds after the first. The User-Agent often looked ordinary, but the high volume of requests made it clear that this was not legitimate traffic.

To address the issue, the team decided to focus on protecting the state transition in WooCommerce rather than blocking specific IP addresses or User-Agent strings. They built a separate WooCommerce protection layer around the legacy GET add-to-cart flow, ensuring that clients could not perform state-changing operations without valid proof. This proof was signed using HMAC and stored in a secure first-party cookie with expiration after five minutes.

By verifying the signature and age of the proof before processing the legacy add-to-cart operation, the team prevented blind, stateless cart mutations. This approach did not attempt to determine whether the client was human but instead changed the economics and state requirements of the attack.