Back to feed
News Story
InfoQ AI/ML/Data Eng
1 sources

Cloudflare Uses an AI Harness to Probe and Harden Its WAF

Cloudflare placed frontier AI models inside a controlled testing harness to probe its Web Application Firewall (WAF). The company used blocked attacks as starting points for the models to generate and refine new variations, aiming to harden the WAF. The work was reported by Matt Foster.

SynthePulse Insight · AI deep reading

Putting AI in a Cage to Attack Its Own WAF: The Boundaries and Outputs of Cloudflare's Exercise

Version 1 · 1 source

Cloudflare let frontier models mutate already-blocked attack payloads inside a controlled framework; 45 scenarios generated 1,107 attempts, human triage left 49 findings, and the work ultimately produced three changes to the Managed Ruleset. What is truly noteworthy is not how well the models could attack, but what they were allowed to do and what they were not.

  • The experiment started from attack payloads the WAF had already blocked, rather than replaying fixed test cases.
  • 45 scenarios generated 1,107 attempts in total, and human triage left 49 findings.
  • The models could not see WAF rules, source code, or internal security signals, so from the model's perspective the testing was black-box.
  • Request construction, replay, state maintenance, and constraint enforcement were handled by a Python framework; the models did not directly control request execution.
  • Of the 1,107 attempts, 607 produced a post-triage result set, in which 558 requests were blocked by the WAF.
  • Of the 49 findings, 48 involved command injection or SSRF, ultimately producing two new detection rules and one improvement to an existing rule.
Open section navigationA Counterintuitive Starting Point: Beginning from Attacks That Were 'Already Blocked'

A Counterintuitive Starting Point: Beginning from Attacks That Were 'Already Blocked'

Cloudflare placed frontier AI models inside a controlled testing framework to probe its own Web Application Firewall (WAF). The starting point of this approach was not a fixed list of test cases, but attack payloads the WAF had already blocked—the models used these blocked payloads as material to generate and refine new variants.

This choice determined the nature of the entire exercise. Replaying fixed cases repeatedly can only verify whether known rules are still in effect; starting from already-blocked payloads is equivalent to treating 'why the rule blocked it' as an assumption that can be probed for bypass. Model calls would propose modifications to payload encoding, position, or delivery method based on the responses returned by previous attempts, making subsequent attempts adaptive.

The Shape of the Cage: Models Propose, the Framework Executes

The division of labor in this framework was deliberately designed. A Python framework took on the parts Cloudflare was unwilling to hand to the models: constructing and replaying HTTP requests, maintaining scenario state, enforcing constraints, and collecting responses. The models did not directly control request execution.

On the model side, one model call was responsible for proposing the next mutation, and another model call was responsible for reviewing the returned response, so that subsequent attempts could be adaptive. At the same time, the models had no access to Cloudflare's WAF rules, source code, or internal security signals, so from the model's perspective this testing was effectively black-box.

Separating 'proposing hypotheses' from 'executing actions' is the most noteworthy constraint in this design. The models could keep guessing at encoding, position, and delivery method, but what actually sent the requests was the framework, and the boundaries were held by the framework rather than the models.

The Feedback Loop Demonstrated by One SSRF Attempt

One SSRF test can illustrate how this feedback loop operated. The tester repeatedly changed the representation and position of a cloud metadata address, trying decimal, octal, and other forms, and eventually a request using decimal representation was blocked.

In the next attempt, the model kept the same request shape but switched to an address representation with a trailing dot; this time the client encountered a redirect rather than a WAF block. Cloudflare preserved that result for investigation rather than treating it as evidence that the attack had succeeded.

This handling is itself a judgment standard: the client encountering a redirect and the request actually reaching the target and causing harm are two different things. The source did not state the conclusion of the follow-up investigation into that redirect result.

From 1,107 to 49: Every Gate on the Chain of Numbers

The scale data is the most verifiable part of this exercise. The experiment covered 45 scenarios, the system generated 1,107 attempts in total, and human triage left 49 findings.

Of the 1,107 recorded mutation attempts, 607 produced a post-triage result set; in that result set, 558 requests were blocked by the WAF, and 49 findings were considered relevant to subsequent remediation work. Of the 49 findings, 48 involved command injection or server-side request forgery (SSRF).

Human review remained the final verification step. Reviewers had to check whether the request actually reached the target, whether it was still malicious, whether it was clearly unblocked, whether it fell within the WAF's responsibility, and whether it could be safely reproduced. Only cases that passed these checks were replayed and evaluated as candidate changes to rules, normalization, or other mitigations.

The source did not state how the remaining attempts between the 607 post-triage result set and the 1,107 total attempts were handled, nor did it state the specific type of the remaining 1 finding among the 49 besides command injection and SSRF.

Outputs: Three Managed Ruleset Changes

This exercise ultimately produced three changes to the Cloudflare Managed Ruleset: two new detection rules, SSRF - Obfuscated Host and SSRF - Restricted Protocol, and an improvement to the existing SSRF - Cloud rule.

All three changes fell in the SSRF direction, corroborating the distribution in which 48 of the 49 findings involved command injection or SSRF. However, the source did not state the actual blocking effectiveness or false-positive situation of these three changes after they went live, so 'the changes are in effect and have improved protection' can currently only be regarded as an expectation awaiting verification, not a confirmed result.

The Applicable Boundaries and Unresolved Questions of This Framework

Based on the disclosed information, what is transferable in this approach is the framework rather than the models: enforcing constraints, preserving state, and verifying findings, turning probabilistic exploration into evidence that existing security processes can use. What the models provided was the search capability for mutation directions, not the authority to judge.

But several key dimensions were not addressed by the source. The source did not state which specific frontier AI models or versions were used, did not state the time span, operating cost, or number of model calls of the experiment, and did not state whether the testing framework has been routinely used for continuous probing or was only a one-off exercise.

Therefore, understanding this exercise as an exploration with clear outputs but boundaries and sustainability not yet disclosed is closer to the disclosed facts than understanding it as 'AI can now autonomously break through the WAF.'

Credibility boundary

All facts in this article come from InfoQ's report on this Cloudflare WAF exercise; this is secondhand retelling and does not cite Cloudflare's first-party original text. Figures such as 45 scenarios, 1,107 attempts, 607 post-triage result set, 558 blocked requests, 49 findings, 48 involving command injection or SSRF, and three Managed Ruleset changes are all recorded as stated by the source. The source did not disclose the specific models and versions used, the experiment's time span and cost, the post-launch effectiveness and false-positive situation of the three changes, or whether the framework runs routinely; this article does not speculate on these gaps.

Insight takeaway

The most reusable lesson from this exercise is not how many attack variants the models can generate, but placing the models inside a framework where they cannot directly execute actions: requests are constructed and replayed by a Python framework, the models only propose mutations and review responses, and human review provides final verification. The 1,107 attempts converging into 49 findings and three rule changes—this funnel itself is the evidence for the methodology; while the model versions, cost, post-launch effectiveness, and whether it runs routinely remain questions the source has not answered.

Primary report

InfoQ AI/ML/Data Eng

Primary source