Executive summary. Strumpsnodden.se was running at almost 100% CPU, above 92% RAM and unusually heavy disk I/O despite modest visible traffic. Analysis of the host access logs found that meta-externalagent/1.1 dominated the dataset and repeatedly requested dynamic WooCommerce cart URLs. The technical effect resembled an application-layer denial of service, although we have no evidence that Meta intentionally attempted to attack the website.
What triggered the investigation?
WPMU DEV Live Stats showed approximately 99.7% CPU, 92.3% used RAM, 150.8 MiB/s disk read and 79.6 MiB/s disk write. At the same time the site was seeing only a few web requests per second. That combination suggested expensive dynamic processing rather than ordinary visitor traffic.
WooCommerce Action Scheduler was checked first and showed no runaway queue capable of explaining the live resource exhaustion. The decisive evidence came from the access logs.
77% of logged traffic identified itself as Meta-ExternalAgent
The WPMU DEV export contained the active access.log plus seven rotated logs, covering roughly 9–16 August 2026. Across 210,298 requests, 161,989 presented as Meta-ExternalAgent — 77.0% of the entire dataset.
Cloudflare Radar lists Meta-ExternalAgent as a verified bot operated directly by Meta and documents the same user agent.
154,206 Meta requests — 95.2% of its traffic — targeted /varukorg/. 124,326 contained both add-to-cart and remove_item. A further 29,878 contained remove_item without add-to-cart.
Why was the cart so expensive?
WooCommerce documents that Cart, Checkout and My Account must remain dynamic because their output depends on the customer and session. WooCommerce also recommends bypassing cache for requests containing ?add-to-cart=. This helps explain why the observed requests were far more expensive than normal cached product pages.
Working diagnosis: a combinatorial crawler trap
The pattern is consistent with a crawler repeatedly traversing state-changing WooCommerce links. Each request invoked dynamic session/cart processing and could expose another cart state. The logs prove the URL pattern and the resulting load, but they do not expose Meta’s internal crawl scheduler. “Crawler trap” is therefore our technical interpretation of the observed behaviour.
Request duration made the traffic destructive
The median Meta request lasted 67.7 seconds and the average 86.5 seconds. 85,951 Meta requests exceeded one minute, 51,420 exceeded two minutes and 23,090 exceeded three minutes. The longest observed request was approximately 300.64 seconds.
Summing the duration field across Meta traffic yields approximately 14,019,250 seconds: 3,894 hours or 162.3 days of accumulated request time. This is not 162 CPU-days because requests overlap and may wait on I/O, but it is a useful measure of how much concurrent application capacity was occupied.
The mitigation produced a clear before/after result
We deployed a lightweight WordPress/MU guard that rejects Meta-ExternalAgent early and separately blocks dangerous add/remove combinations for crawlers before normal WooCommerce processing.
The store continued receiving normal web traffic. What changed was that the crawler no longer reached expensive WooCommerce processing. That real-world before/after result is the strongest evidence in this incident that Meta-ExternalAgent traffic was the primary trigger for the resource exhaustion.
The crawler kept trying after mitigation
Crawler Shield deliberately samples only 1 in 50 blocks so the telemetry itself does not create database load during a bot storm.
Between 16 August 16:50 and 17 August 14:28 local WordPress time, the shield recorded 33 actual samples, corresponding to an estimated 1,650 blocked requests. About 1,600 were classified as Meta-ExternalAgent. New samples continued to show GET /varukorg/ while server utilisation remained normal.
Is this a DDoS attack?
We are not alleging that Meta intentionally attacked Strumpsnodden.se.
We have strong evidence of technical effect, not malicious intent. The observed effect resembled an application-layer denial of service: automated requests repeatedly invoked expensive dynamic functionality until server resources were effectively exhausted.
The more precise term is therefore crawler-induced application-layer denial of service. We believe Meta should review how Meta-ExternalAgent handles transactional URLs, per-host concurrency, request cost and state-changing GET flows.
Could this have affected sales?
Severe e-commerce slowdown can interfere with browsing, cart operations and checkout. Strumpsnodden has also experienced unexplained performance pressure over a longer period and previously changed hosting infrastructure. However, this report proves the August 2026 dataset only. We cannot yet prove that Meta-ExternalAgent caused historical performance problems over previous years or quantify lost sales.
Evidence and reproducibility
The original WPMU DEV log export is retained privately because raw logs may contain IP addresses, query parameters and WooCommerce nonces. We therefore publish aggregates, redacted representative requests and the analysis method.
SHA-256 of the original archive:
Meta, WooCommerce, WPMU DEV or independent security researchers who want to review the methodology can contact info@3on.se.
Sources
Disclosure note
This report documents observed technical behaviour and our incident analysis. It is not an allegation that Meta intentionally attacked the website. Metrics labelled as estimates are derived from Crawler Shield’s documented 1:50 sample rate; access-log metrics are direct counts from the hosting logs.