One assumption shows up again and again when we review a client's defenses: we're behind Cloudflare, so we're protected. For volumetric DDoS — millions of packets flooding the network — that is genuinely true. Cloudflare absorbs it at the edge. For an application-layer attack aimed at your PHP worker pool, it is not just false; the CDN never even sees the problem.

Here is exactly why, and why it matters for the millions of sites running a contact form behind a CDN.

How a CDN actually protects you

Cloudflare sits between the internet and your origin. When a request can be answered from cache, an edge node thousands of miles from your server serves it and your origin never wakes up. That is the whole economy of it — a tiny VPS can survive enormous traffic if most of it is cached at the edge. The origin only runs code when it absolutely must.

The load-bearing word is cached.

The exception that breaks everything

There is one rule a CDN cannot break: POST requests are never cached. That is not a bug — it is correct. POST requests are stateful; they carry form data and trigger transactions. So when a POST arrives, Cloudflare does the only thing it can: forward it to your origin, every time. The response header says so plainly:

cf-cache-status: DYNAMIC

DYNAMIC means "I forwarded this to origin and I will never cache it." Now consider any plugin that handles form submissions through the WordPress REST API:

POST /wp-json/contact-form-7/v1/contact-forms/{id}/feedback

Every submission returns DYNAMIC. The CDN forwards every one to your origin. No caching, no edge-side filtering. For one human submitting a form, that is exactly right. For an attacker sending 25 concurrent submissions a second, the CDN helpfully forwards all 25 to a server that has perhaps 19 workers.

The PHP worker pool is the real bottleneck

PHP-FPM works as a fixed pool of workers — a set number of slots, each occupied for the full duration of a request. A form submission is not cheap: a typical one spends 1.2–3 seconds of execution per request once you count framework bootstrap, plugin validation, a firewall scan, an outbound reCAPTCHA call, and email dispatch. A small VPS runs 15–25 workers.

When every worker is busy, new requests queue. When the queue fills, visitors get HTTP 522 and HTTP 524 timeouts — and not just people using the form. The worker pool is shared across the whole site, so the homepage, the shop, and checkout all go down together.

Cloudflare never fires a rate limit. It sees an ordinary spread of POST requests from many IPs. Your origin sees 25 simultaneous executions and runs out of workers.

Why reCAPTCHA does not save you

"But the form has reCAPTCHA." reCAPTCHA prevents a successful submission. It does nothing about worker exhaustion, because of execution order: the worker is occupied the moment the POST arrives, the framework boots, the firewall scans, and only then is reCAPTCHA checked and the request rejected. The worker was busy the entire time. Twenty-five concurrent requests with junk tokens exhaust the pool before a single real submission is processed.

The fix lives at the edge, not in WordPress

The fix is not a plugin. It is a Cloudflare rate-limiting rule you have to add by hand, because CDNs do not rate-limit POSTs to your REST API by default:

(http.request.uri.path contains "/wp-json/contact-form-7")
AND (http.request.method eq "POST")

Action: Block
Rate:   5 requests per 10 seconds per IP

This runs at the edge; your PHP never executes. No human submits five contact forms in ten seconds, so it is generous for real users and lethal for a flood.

The broader pattern

This is one instance of a general rule: CDN protection only covers what the CDN can cache. Any endpoint that must be dynamic — REST APIs, form submissions, search, login — bypasses the cache. If it can be called cheaply by an attacker but is expensive for your origin, it is an exhaustion vector. We dug into two more in 167 bytes that take down a WordPress site and WordPress search as a DoS vector, and pulled the defenses together in the hardening guide. It is also why we treat edge rules as part of platform integrity rather than an afterthought, alongside our wider cyber defense work.

Until "behind Cloudflare" is understood to mean "behind Cloudflare's cache," it will keep being a false sense of security for application-layer attacks.

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