Cloudflare let AI models attack a staging site behind its WAF. Of 607 counted requests, 558 were blocked and 48 of the 49 findings were command injection or SSRF. The test used Enterprise-only settings, so here is what a Free or Pro zone can copy.
How the Test Worked
On September 29, 2026, Cloudflare described a test in which AI models attacked a site protected by its own WAF. A model proposed each attack variation and read the response, while ordinary code sent the requests, kept them inside an allowlist and stopped each scenario after 25 attempts. The target was a customer's staging environment, with the customer's permission, and the post does not name the models.
The run covered 45 scenarios and recorded 1,107 attempts across six categories, namely cross-site scripting, SQL injection, command injection, server-side request forgery (SSRF), path traversal, and Log4j. A request that got through counted as a lead for a person to investigate, not as a working exploit.
The Configuration Was Stricter Than Most
The test zone blocked every request with a WAF attack score of 30 or lower, had all of the Cloudflare Managed Ruleset enabled, and ran the OWASP Core Ruleset at paranoia level 3. Few production sites run that tight, and as the table further down shows, some of it is only available on Enterprise plans.
What Got Through
After Cloudflare removed malformed, benign and duplicate requests, 607 remained. The WAF blocked 558 of them, and 49 were documented as findings worth investigating. 48 of those 49 were command injection or SSRF. Cross-site scripting, SQL injection, path traversal and Log4j were almost entirely blocked.
The post walks through one SSRF session. The model sent the address of a cloud metadata service written in several forms, as a plain address, as a single integer and in octal, and the WAF blocked each one. At attempt 18 it tried the same address with a trailing dot, and that request met a redirect instead of a block. Cloudflare notes there was no successful response from the application and no sign that metadata was fetched.
What Cloudflare Changed
The findings led to three changes in the Managed Ruleset. Two new detections, SSRF - Obfuscated Host and SSRF - Restricted Protocol, went out in the July 21 release, and the existing SSRF - Cloud rule was improved and set to block in August. Later releases in September added further SSRF and command injection detections. The obfuscated-host rule exists because of exactly the trick above, internal addresses written in unusual numeric forms.
What You Can Copy on Your Plan
| Setting used in the test | Free | Pro | Business | Enterprise |
|---|---|---|---|---|
| Cloudflare Free Managed Ruleset | yes | yes | yes | yes |
| Cloudflare Managed Ruleset | no | yes | yes | yes |
| OWASP Core Ruleset | no | yes | yes | yes |
| WAF attack score | no | no | score class only | full score |
| Log action for trying rules first | no | no | no | yes |
Cloudflare's advice is to run managed rules in log mode first, review what they match in Security Events, and switch them to block once legitimate traffic is unaffected. The Log action behind that advice is Enterprise only. On the other plans the safer route is gradual.
- Enable what matches your stack. Cloudflare's documentation recommends turning on the managed rules tagged for your technology, such as the WordPress rules, and warns against enabling every rule outside a proof of concept.
- Start the OWASP ruleset gently. Cloudflare warns that it produces false positives. A low paranoia level with a high score threshold is the documented low-noise starting point, which you tighten step by step.
- Read Security Events right after each change. Every plan has them, but Free and Pro keep only the last 24 hours and Free shows sampled events, so a false positive has to be caught the same day.
What It Means for a Store
SSRF and command injection were where the WAF had the most trouble, and those are also the bugs that turn up in store extensions that fetch a remote URL, such as image importers, feed importers, webhook testers and PDF generators. A WAF rule is the second line of defense against them. The first is patching the extension and limiting what the server itself can reach.
On AWS, requiring IMDSv2 on every instance closes the classic target of an SSRF attack. With IMDSv2, reading instance metadata first needs a token obtained through a PUT request, which a typical SSRF through a URL fetcher cannot make.
Cloudflare's own conclusion is the right one to end on. A request that slips past the WAF still needs an application that is vulnerable, so keeping the stack patched remains one of the strongest defenses. Tuning the rules without locking out real customers is covered in How to Block an Attack Without Blocking Your Own Client, and setting up the WAF for a real store is part of Security & Compliance.
Sources
- Cloudflare: We tested our own WAF with frontier AI models
- Cloudflare WAF managed rules and plan availability
- Cloudflare Managed Ruleset reference
- Cloudflare OWASP Core Ruleset concepts
- Cloudflare WAF attack score
- Cloudflare rule actions
- Cloudflare Security Events
- Cloudflare WAF changelog
- AWS: Access instance metadata with IMDSv2
Frequently asked questions
How well did Cloudflare's WAF hold up against AI-driven attacks?
Cloudflare's WAF blocked 558 of 607 counted requests in a test published on September 29, 2026, where AI models attacked a customer's staging site with the customer's permission. Of the rest, 49 were documented as findings worth investigating, and 48 of those were command injection or SSRF. Cross-site scripting, SQL injection, path traversal and Log4j attempts were almost entirely blocked.
How did Cloudflare test its own WAF with AI models?
In Cloudflare's test, a model proposed each attack variation and read the response, while ordinary code sent the requests, kept them inside an allowlist and stopped each scenario after 25 attempts. The run covered 45 scenarios and 1,107 attempts across six categories. A request that got through counted as a lead for a person to investigate, and Cloudflare does not name the models used.
How strict was the WAF configuration in Cloudflare's AI attack test?
The test zone blocked every request with a WAF attack score of 30 or lower, enabled all of the Cloudflare Managed Ruleset and ran the OWASP Core Ruleset at paranoia level 3. Few production sites run that tight. Some of those settings need a paid plan, and the full attack score is available only on Enterprise.
Which Cloudflare WAF features are available on the Free and Pro plans?
The Free plan includes only the Cloudflare Free Managed Ruleset. Pro adds the full Cloudflare Managed Ruleset and the OWASP Core Ruleset, Business adds the WAF attack score as a score class, and Enterprise has the full score plus the Log action for trying rules before they block. Every plan has Security Events, though Free and Pro keep only the last 24 hours and Free shows sampled events.
How should I roll out Cloudflare WAF managed rules without blocking real customers?
Cloudflare advises running managed rules in log mode first, but the Log action is Enterprise only, so other plans have to go gradually. Turn on the managed rules tagged for the site's technology, such as the WordPress rules, and avoid enabling every rule outside a proof of concept. Start the OWASP Core Ruleset at a low paranoia level with a high score threshold, tighten it step by step, and read Security Events right after each change.
What SSRF bypass did an AI model find against Cloudflare's WAF?
A trailing dot on a cloud metadata service address. The model first sent the address as a plain address, as a single integer and in octal, and the WAF blocked each one. At attempt 18 the same address with a trailing dot met a redirect instead of a block, although Cloudflare found no successful response from the application and no sign that metadata was fetched.
What new SSRF rules did Cloudflare add to its Managed Ruleset?
Two new detections, SSRF - Obfuscated Host and SSRF - Restricted Protocol, went out in the July 21 release of the Cloudflare Managed Ruleset. The existing SSRF - Cloud rule was improved and set to block in August, and later releases in September added further SSRF and command injection detections. The obfuscated-host rule targets internal addresses written in unusual numeric forms.
Does IMDSv2 protect AWS instances against SSRF attacks?
Requiring IMDSv2 on every AWS instance closes the classic target of an SSRF attack. With IMDSv2, reading instance metadata first needs a token obtained through a PUT request, which a typical SSRF through a URL fetcher cannot make. SSRF bugs tend to turn up in store extensions that fetch a remote URL, such as image importers, feed importers, webhook testers and PDF generators, so patching those extensions and limiting what the server can reach come first, with a WAF rule as the second line of defense.
Or read how we handle it in Security & Compliance.
Related Articles
How to Set Up SPF, DKIM and DMARC So Mail Actually Lands
Three DNS records decide whether your invoices reach the inbox or the spam folder, and most setups have all three and still fail. The reason is alignment: DMARC does not ask whether SPF passed, it asks whether the domain SPF authenticated matches the domain in the From header. This is the working order to set them up, why SPF alone breaks the moment a message is forwarded, the ten lookup limit that silently voids your record, and how to move from p=none to p=reject without losing a week of mail.
SecurityThe APT Flaw in Debian and Ubuntu and How to Close It
Fixed APT packages for Debian and Ubuntu shipped on November 4 and close CVE-2026-109518, a flaw that let someone on the network path swap a package during an upgrade. Here is who is exposed, how to check a server, and how to install the fix safely.
SecurityHow to Handle Secrets in CI Without Leaking Them Into Logs
The safest credential in your pipeline is the one that does not exist between jobs. OpenID Connect lets a workflow authenticate directly to a cloud provider and receive a token that expires on its own, which removes the stored key entirely. Masking is the backstop for everything left over, and it is worth knowing exactly where it stops working, because it relies on finding an exact match for the value. This guide covers the short-lived credential setup, the limits of redaction, and what to actually do in the ten minutes after a secret reaches a log.