167 Bytes That Take Down a WordPress Site

Security vulnerabilities are usually complex — buffer overflows, race conditions, cryptographic weaknesses that need a doctorate to follow. This one is not. A 167-byte HTTP request, a $5 VPS, and 19 concurrent connections take a WordPress site offline — Cloudflare, firewall, reCAPTCHA and all. The mechanism is not a bug. It is amplification.

What 167 bytes buys

Strip a Contact Form 7 REST submission down to its shortest valid form — the form ID, a one-character name, a throwaway email, a two-character message — and the whole request, headers included, is about 167 bytes. The question is what the server does with them.

The server's work per request

Every submission triggers a cascade: a cold framework bootstrap (~300ms, since WordPress does not stay resident between requests), a firewall scan of the payload, form validation against the database, an outbound reCAPTCHA round-trip (100–400ms where the worker waits but stays occupied), an email dispatch, and response serialization. Total: 1.2–3 seconds of wall-clock time, several database queries, and outbound network calls. The attacker sent 167 bytes; the server generated thousands of bytes of work.

The amplification ratio

Amplification is the ratio of attacker cost to defender cost. Classic network amplification (DNS, NTP, memcached) abuses protocols that return large responses to small queries. Application-layer amplification is different: the attacker sends a small request straight to the victim, and the victim's own server does disproportionate work.

Measured on live installations, the resource-cost ratio runs from roughly 43,000:1 to 113,000:1. With 19 concurrent requests, all 19 workers saturate and the site goes down. The OWASP write-up on denial of service frames this class of asymmetry well.

Why the firewall makes it worse

There is a painful irony here. After a few requests from one IP, a security plugin bans it and returns a block page instead of processing the form. But that block page can be 18,900 bytes — roughly 94× the size of the attack payload — and generating it still booted the framework, still ran the scan, still occupied a worker. The defense consumes more resources than the thing it defends against. The attacker simply rotates to the next proxy and the plugin bans that one too.

Per-IP banning is the wrong layer for this attack, because the attacker has more IPs than your server has workers.

The form ID is not a secret

A common instinct is "I'll keep my form ID secret." It is not secret — it sits in your page source:

<input type="hidden" name="_wpcf7" value="50">

Anyone can read it in ten seconds, and the REST API will often enumerate every form for an unauthenticated caller anyway. Hiding the ID is not a control.

Why a $5 VPS is enough

The constraint is worker count, not bandwidth. An origin with 19 workers needs only 19 concurrent requests to saturate — and at 167 bytes each, cycling every ~1.2 seconds, the attack generates under 2.5 KB/s of outbound traffic. A modem from 1995 could run it. Throwing more workers at the problem just raises the threshold and the attacker raises their concurrency to match. It is an arms race you lose at the origin.

The lesson

167 is not a magic number; it is just the minimum valid payload. What makes it dangerous is the asymmetry. Any WordPress endpoint that is unauthenticated, bypasses CDN caching, and triggers expensive work is a potential exhaustion vector — the contact form, core search, certain cart and login paths. The durable fix is to rate-limit at the edge so the cost to your origin drops to zero, which is exactly the move we make in the Cloudflare myth and lay out fully in the hardening guide. The same mindset underpins how we build for reliability under load.

All research conducted on authorized test infrastructure and submitted for responsible disclosure. Only test systems you own or have explicit written permission to test.