The WooCommerce Cart Abuse Problem Hidden by Modern Bot Traffic

Residential proxy networks have become a significant part of the infrastructure used for automated internet activity. They can route requests through consumer connections, rotate addresses rapidly, and make traffic difficult to classify using IP reputation or request frequency alone. This is no longer a hypothetical security concern. In July 2026, Lumen's Black Lotus Labs reported tracking nearly 20 million distinct IP addresses per day across more than 30 malicious proxy botnet clusters, with more than 20 clusters regularly exceeding 100,000 daily victims. Its research describes a market in which proxy operators can replenish their inventory through interconnected botnets and reselling arrangements. [1]

The same month, Reuters reported that Google, working with the FBI, Lumen and other partners, had disrupted infrastructure associated with NetNut, a residential proxy service operated by Israeli company Alarum Technologies. Google said the intervention reduced the available proxy-device population by millions. The reported investigation concerned the relationship between NetNut and the Popa botnet. [2] Ynet/Calcalist also reported an FBI investigation into whether devices were enrolled without owners' consent, Alarum's temporary suspension of relevant traffic, and the company's statements that it was cooperating and disputed some outside findings. [3] These reports concern NetNut and do not establish that NetNut was responsible for the traffic described in our WooCommerce investigation.

Google Threat Intelligence Group published its own technical account on July 2, 2026. It estimated that the NetNut network included at least 2 million devices worldwide and reported observing 316 distinct threat clusters using suspected NetNut exit nodes during one week in June, including cybercriminal and espionage activity. Google described SDKs embedded in smart TVs and streaming boxes, disabled Google services used for command and control, and said Play Protect was acting against applications incorporating known NetNut SDKs. These findings are also discussed in Michael Kan’s July 2 PCMag report, This Proxy Service Is Using TV Streaming Devices to Host Cybercrime. [5][6] The figures describe Google’s investigation, not the size or attribution of the traffic hitting House of Parfum.

The significance for online stores is practical. A store does not need to be the target of a conventional denial-of-service flood to experience unwanted application work. Distributed automation can invoke legitimate-looking endpoints at scale, while each individual address appears only once.

During an investigation of automated traffic against House of Parfum, a live WooCommerce store, Zologic observed exactly this pattern. In one correctly parsed server-log interval, we recorded 2,167 direct add-to-cart operations from 2,156 unique source IP addresses. Of those operations, 2,139 returned HTTP 403 after protective controls were introduced. That is approximately 1.005 operations per IP address. We built Zologic WooCommerce Cart Guard to address this specific application-level problem.

What the server was actually processing

The activity centered on WooCommerce's legacy direct add-to-cart mechanism:

?add-to-cart=<product_id>

This is legitimate WooCommerce functionality. It is also a cart-changing operation that can be requested directly. A syntactically valid URL and an ordinary browser user agent do not establish that a request came through the intended storefront interaction.

We extracted operations from the HTTP request field of the web-server access logs, rather than searching the entire line for add-to-cart. That distinction prevents an unrelated referrer URL from being miscounted as a cart operation.

Measurement	Observed result
Actual direct add-to-cart operations	2,167
Unique source IP addresses	2,156
HTTP 403 responses	2,139
Operations per source IP	1.005

The result explains why per-IP rate limiting was poorly matched to this traffic. A rule looking for repeated requests from one address has almost no history to work with when the address changes after approximately one operation. Blocking the first IP can still be useful, but it does not prevent the next request from arriving through a different address.

This is not evidence that all 2,156 IP addresses belonged to one operator, one proxy provider, or one botnet. It is evidence of a highly distributed pattern of direct WooCommerce operations.

What our traffic, ASN and Analytics analysis showed

We investigated several layers of data: raw access-log requests and response codes, source IP addresses, ASN/network ownership, geographic distribution, user-agent strings, Google Analytics observations, and later Cart Guard telemetry.

The traffic included rotating addresses, ordinary-looking Chrome user agents, and source networks associated with multiple geographies, including Chinese and Singaporean address space. Some infrastructure was consistent with proxy use. An IP's geolocation is not the location or nationality of the person directing the traffic, and an ASN alone does not establish who initiated a request.

We also escalated traffic involving HostRoyale infrastructure. In its response, HostRoyale identified Bright Data Ltd. as its customer for the reported infrastructure and stated that it had asked Bright Data to investigate its user. That is a specific provider relationship documented by the correspondence; it is not proof that Bright Data itself directed the requests, nor that every source address in the broader dataset was part of its network.

Google Analytics gave us a different perspective from the origin logs. An HTTP operation may be processed by WooCommerce without appearing as a meaningful Analytics shopping session. This makes Analytics alone an incomplete measurement of automated application work. We used it alongside server and application telemetry, not as a substitute for them.

Why residential proxy infrastructure matters

Black Lotus Labs' July 2026 report provides broader context for what we observed. Its researchers describe malicious proxy ecosystems that combine compromised routers, Android devices and other consumer hardware with commercial storefronts and resellers. Some operators reportedly regain capacity quickly after disruptions because the supply chain connects multiple proxy pools. [1]

That research does not identify the operator of our WooCommerce traffic. It does, however, explain why an attacker or automated client can obtain many unrelated-looking source addresses and why static IP lists are an incomplete answer.

Google’s primary technical report adds detail beyond the news coverage: it identifies consumer streaming hardware as part of the proxy supply chain, describes how home devices can become exit nodes, and reports the use of suspected NetNut exit nodes by hundreds of distinct threat clusters. Google also warned that disrupted proxy operators may purchase capacity from competitors or resell other networks, complicating attempts to block a single provider. [5] PCMag reported these findings and the FBI domain seizures, including Alarum’s statement that it would cooperate with the investigation. [6]

The NetNut/Popa reporting is another illustration of the scale and enforcement attention surrounding the proxy market. Reuters described Google's July 2026 disruption and Alarum's cooperation statement. [2] Ynet described allegations being investigated about device enrollment and also reported the company's position and response. [3] Investigations, allegations, observed infrastructure links, and proven wrongdoing are not interchangeable.

For a merchant, the immediate problem is simpler: the request still reaches an application endpoint, regardless of how many intermediary devices or providers carried it.

Why this activity can be missed

WooCommerce security discussions often focus on compromised accounts, vulnerable plugins, malicious uploads, credential attacks and payment fraud. Direct cart abuse can generate none of those indicators.

The site may see valid HTTP syntax, a recent Chrome user agent, and a source IP with no previous history. Yet processing a cart mutation can involve PHP execution and WooCommerce application work. Depending on configuration, sessions, cookies, cache and database operations may also be involved. The actual performance impact depends on traffic volume and store configuration; our request counts alone do not quantify lost revenue or resource consumption.

A firewall may correctly find no known exploit signature. A rate limiter may find no repeat offender. Analytics may not represent the requests as ordinary customer sessions. The store is still receiving attempts to perform a cart operation.

What Cart Guard changes

Zologic developed WooCommerce Cart Guard around authorization of the cart operation, rather than a universal classification of the client.

For the legacy ?add-to-cart= path covered by the current implementation, a normal first-party storefront flow obtains short-lived cryptographic proof. Cart Guard verifies that proof before permitting the protected mutation. A direct request without the required proof can be rejected before the protected WooCommerce operation proceeds.

The proof is not a human-verification mechanism. It establishes the expected storefront context. Browser automation capable of obtaining and replaying legitimate proof within its validity window is a different threat model, so this should not be described as an absolute barrier to all bots or AI agents.

The design also preserves explicitly supported machine-commerce interfaces. WooCommerce REST/Store API routes and UCP discovery or agent interfaces are not indiscriminately blocked simply because their callers may be automated. The current protected scope is the legacy direct add-to-cart flow, not every possible WooCommerce cart mutation.

Production results and telemetry

A later Cart Guard production snapshot recorded 223 direct cart mutations from 222 unique observed sources, with 162 blocked requests, 59 suspicious/no-proof requests, and 2 validated storefront requests. The near one-to-one relationship between mutations and unique sources remained visible at the application layer. These counters span different operating modes: some suspicious/no-proof requests were recorded during Observation mode, so 162/223 should not be interpreted as an Enforcement-mode block rate.

The telemetry matters because a single blocked-request number does not describe whether a store is seeing repeated requests from one client or one request each from hundreds of clients. In our case, the latter pattern persisted.

Where Cloudflare, Wordfence and Fail2ban fit

Cart Guard does not replace network or general WordPress security controls. Edge services such as Cloudflare can provide WAF rules, bot management, challenges, reputation filtering and rate limiting. WordPress security plugins cover many other attack classes. Fail2ban can turn precise server-log events into temporary IP bans, and firewall rules can stop unwanted network ranges before PHP executes.

Those layers remain valuable. We used multiple layers during this incident.

The narrower issue is that a generic network control does not inherently know whether a WooCommerce direct cart operation followed the storefront sequence expected by the application. Cart Guard makes that decision with WooCommerce-specific context. A resulting HTTP 403 can then become a reliable signal for an additional layer such as Fail2ban.

We did not find an existing WordPress security control that addressed this exact one-operation-per-IP, legacy direct-cart authorization problem in the way we needed. That is a statement about our evaluation and design requirements, not a claim that no other plugin or Cloudflare configuration can ever mitigate related traffic.

AI agents and the changing definition of automated traffic

AI agents, search crawlers, browser automation, scrapers and abusive clients increasingly share the same transport techniques: ordinary browser identities, JavaScript execution, distributed networks and proxy services. The overlap makes source-based classification an imperfect basis for deciding whether an application operation should proceed.

At the same time, legitimate machine commerce is developing. Blocking everything that looks automated would interfere with supported integrations and emerging agent protocols. A store needs to decide which operations are permitted and through which interfaces.

For Zologic, the operational lesson was to keep IP intelligence, ASN analysis, analytics, edge controls and incident response, but to move the cart-operation authorization decision into WooCommerce itself. Cart Guard was developed and tested against the distributed traffic described here, with a deliberately limited and measurable scope.

You can purchase the battle-tested Zologic WooCommerce Cart Guard plugin here.

Sources

1. Lumen Black Lotus Labs, Symbiotic parasites: the modern proxy ecosystem, July 24, 2026. https://www.lumen.com/blog/en-us/symbiotic-parasites-the-modern-proxy-ecosystem
2. Reuters, Google disrupts NetNut proxy network used in malware operations, July 2, 2026. https://www.reuters.com/business/media-telecom/google-disrupts-netnut-proxy-network-used-malware-operations-2026-07-02/
3. Ynet / Calcalist, Israeli tech firm Alarum crashes after FBI probe into proxy network, July 5, 2026 (date displayed as 07.05.26). https://www.ynetnews.com/business/article/syvloyu7me
4. Zologic incident investigation, House of Parfum production web-server access logs, IP/ASN and geography analysis, Google Analytics review, HostRoyale abuse correspondence, and WooCommerce Cart Guard telemetry, October 2026. Internal evidence; not publicly linked.
5. Google Threat Intelligence Group, Google’s Continued Disruption of Malicious Residential Proxy Networks, July 2, 2026. https://cloud.google.com/blog/topics/threat-intelligence/google-continued-disruption-residential-proxy-networks
6. PCMag / Michael Kan, This Proxy Service Is Using TV Streaming Devices to Host Cybercrime, July 2, 2026 (updated July 7). Report text supplied for this article.

Independent research shows e-commerce is directly in the target set

This is not only a pattern we observed on one WooCommerce store. In June 2026, Synthient published research based on outbound traffic collected from residential-proxy SDKs. Its researchers reported that the majority of the proxy traffic they observed facilitated abuse against financial institutions, advertising networks and e-commerce platforms. The report also argues that the industry's increasing emphasis on AI use cases can obscure the abusive traffic that continues to move through these networks.

Synthient's dataset is especially relevant to what we measured because its analysis focused heavily on the Popa proxy botnet. The researchers reported observing Popa-connected devices routing traffic for both IPIDEA and NetNut, and described an ecosystem built in significant part from Android applications, TV boxes and routers. For May 2026 alone, Synthient reported approximately 9.2 million unique domains and subdomains targeted by residential proxies. Its examples of high-value targets included Walmart, alongside Google and Ticketmaster.

The defensive conclusion independently reaches the same problem we encountered in WooCommerce: traditional IP reputation alone is insufficient. Synthient explicitly recommends that defenders move beyond traditional IP-risk blocklists and use multiple layers of detection. Our production data shows why this becomes particularly difficult at the application level: when 2,167 cart operations arrive from 2,156 source IPs, there is almost no per-IP history on which a conventional rate limiter can act.

Source: Synthient Research — Who Are The Victims of Residential Proxies? (June 9, 2026)