Skip to main content
SecuritySeptember 30, 20264 min read

What AI Attacks Taught Cloudflare About Its Own WAF

Get technical support

Which of these can actually be exploited?

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 testFreeProBusinessEnterprise
Cloudflare Free Managed Rulesetyesyesyesyes
Cloudflare Managed Rulesetnoyesyesyes
OWASP Core Rulesetnoyesyesyes
WAF attack scorenonoscore class onlyfull score
Log action for trying rules firstnononoyes

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

Or read how we handle it in Security & Compliance.