Cloudflare Adds Full Transaction Detection to WAF to Help Identify Successful Exploits

Cloudflare has expanded its Web Application Firewall (WAF) with two capabilities: full transaction detection and response rules. The new features let security teams evaluate an incoming HTTP request alongside the response returned by the origin server, helping them identify evidence that an attempted exploit may have succeeded.

Traditional WAF protections focus on incoming requests. While this approach can identify known attack patterns before they reach an application, a suspicious request alone does not always reveal whether an application was successfully exploited. The server's response can provide additional evidence.

Cloudflare's new approach correlates the request with its response, giving security teams more context for deciding whether to allow or block the resulting traffic. Response rules can replace an origin server's response with a Cloudflare WAF block page or a custom response before it reaches the requester.

Cloudflare says both managed and custom response rules are generally available to all customers, including those on Free plans.

The announcement comes as AI models and agents are helping uncover vulnerabilities in widely used software. Cloudflare highlights the recently disclosed php2shell vulnerability as an example of why defenders need better ways to distinguish suspicious activity from evidence of successful exploitation.

Why Request Inspection Alone Is Not Always Enough

Cloudflare WAF already protects websites and APIs through managed rules, custom rules, and rate limiting. These controls can use information such as IP addresses, URL paths, request headers, and request bodies to identify and stop unwanted traffic.

For many attacks, request-level inspection is an effective control. However, a difficult trade-off emerges when a rule matches suspicious activity without confirming its impact.

Broad signatures may identify more potential attacks, but they can also trigger false positives by matching legitimate requests. This can disrupt normal application behavior. More restrictive rules may reduce that risk but allow ambiguous requests to reach the origin.

The origin response provides another piece of evidence. A suspicious request followed by a rejection or error tells a different story from a response that appears to expose sensitive information.

Cloudflare's full transaction detection correlates these two parts of an HTTP transaction. This allows detection logic to consider not only what was requested, but also what the application returned.

Example: Detecting a File-Disclosure Attempt

Cloudflare illustrates the concept with an application that allows users to download files. An attacker might manipulate a file parameter to try to retrieve a private configuration file:

GET /download?file=../../config/database.ini

Request inspection may identify this as a path traversal attempt. But the request itself cannot establish whether the application would expose the file. The application could reject the request, ignore the traversal, or return an error.

A response that appears to contain configuration data would provide stronger evidence of potential exposure. Cloudflare's example includes a successful HTTP response containing database configuration fields and placeholder credentials.

The key is the combination of signals. Configuration-like text might legitimately appear in documentation or example files. When it follows a suspicious traversal request, however, the two signals together provide stronger evidence that sensitive information may have been exposed.

A response rule can then replace the origin response with a WAF block page and HTTP 403 before it reaches the requester. This can prevent the sensitive response from being delivered to the requester, although it cannot undo actions already performed by the origin application.

How Cloudflare Separates Exploit Detection From Blocking

Cloudflare separates identifying suspicious activity from deciding what action to take.

Full transaction detections analyze traffic and attach metadata to the request and response. Security teams can review those results before deciding how to configure a policy. Rules can then use detection outcomes to log or block matching transactions.

This separation allows teams to understand how detections behave across their own applications before applying a mitigation policy. It also allows the same detection information to support different responses depending on the application's requirements.

Cloudflare is adding the following response-signature fields:

These fields can be used in response custom rules or in managed detections to help block traffic. Cloudflare says the first full transaction detections focus on confirming potential exploitation of high-profile vulnerabilities by correlating suspicious inputs with response signals.

The company plans to expand coverage to additional use cases, including signals associated with data exposure and exfiltration. Additional details were not disclosed in the announcement about the timing or scope of that expansion.

Response Rules Can Block Content Before It Reaches the Requester

Detecting evidence of exploitation is most useful when security teams can act on it in real time. Cloudflare's response custom rules let customers combine request properties, response properties, and detection results to decide which responses should be blocked.

When a blocking rule matches, Cloudflare replaces the origin's response with either a standard WAF block page or a custom response.

Cloudflare says response-phase controls are available in the dashboard under Security > Security Rules. Both managed protections and custom response rules have been released to all plans, including Free plans.

Managed response detections

Cloudflare provides a Cloudflare Managed Response Firewall Default ruleset. It is designed for straightforward deployment and simplified configuration. When a managed detection signature matches, the ruleset can block the response and return a standard WAF block page.

The default ruleset runs on every request. Customers can narrow its scope to selected applications or paths to reduce the risk of false positives.

Cloudflare's approach to managed detections differs by plan over time. The company says free plans will focus on high-profile vulnerabilities, while paying customers will receive a broader catalog of managed detections.

Custom response rules

Custom rules give security teams control over the conditions that trigger an action. For example, a team might want to prevent an administration interface from being exposed when an authentication gateway has not marked a request as internal.

Cloudflare provides this example rule:

http.request.uri.path starts_with "/admin" and not http.request.headers["x-internal-user"][0] eq "true" and http.response.code eq 200 and http.response.headers["content-type"][0] contains "text/html"

The rule combines several conditions:

• The request targets a path beginning with /admin.

• The request does not contain the expected internal-user header value of true.

• The origin returns HTTP status 200.

• The response content type contains text/html.

Together, these conditions target a successful HTML response from an administration path when the expected internal-user marker is absent.

All Cloudflare customers can create up to three custom response rules, with Log and Block actions. The available fields and functions mirror those provided by the customer's existing request custom-rule plan.

One limitation remains: creating rules based on the response body is not yet available. Cloudflare also says the response-signature fields are being rolled out across accounts. Customers who do not yet have access are advised to contact their account team.

Investigating Matching Requests in Security Events

When a managed or custom response rule logs or blocks a transaction, the resulting event is available in Security Events. Responders can use this information to trace a detection back to the relevant request context and the rule that took action.

Cloudflare currently displays request-only and full-transaction rule events together in the same analytics page. Events generated by response rules appear under the Managed Rules or Custom Rules service, depending on the rule. Users can filter events by a specific rule ID within the corresponding rule list.

This investigation workflow connects detection and enforcement with the visibility needed to understand why a transaction was logged or blocked.

Availability and How to Get Started

Cloudflare says full transaction detection is generally available for all zones proxying traffic through its platform. Both managed and custom response rules are available across all plans, including Free plans.

Customers can check their configuration in the Cloudflare dashboard:

1. Open Security > Security Rules.

2. Review the available full transaction detections and response-phase controls.

3. Review detection activity in Security Analytics.

4. Configure a managed or custom response policy appropriate for the application.

Customers can also adjust the scope of the managed response ruleset to apply protections only to selected parts of an application.

Cloudflare's initial managed protections using full transaction detection address the recently disclosed php2shell vulnerability. The company says it intends to extend the approach to other scenarios, including data exposure and exfiltration signals.

What This Means for Application Security

The announcement highlights a broader shift in web application protection: identifying an attack pattern is not always the same as establishing its impact.

Evaluating a request alongside its response can give defenders stronger evidence when deciding whether to intervene. It may also help teams avoid treating every suspicious request as a confirmed exploit, while enabling more targeted blocking policies.

For organizations, the practical value will depend on how well the detections fit their applications and how carefully response rules are scoped. Overly broad blocking policies can still disrupt legitimate traffic, so reviewing detection results and testing rule behavior remain important operational steps.

Cloudflare's support for response rules on Free plans also makes the capability accessible to smaller website operators, although the available managed detections and custom-rule options differ by plan.

Conclusion

Cloudflare's full transaction detection extends WAF inspection beyond incoming requests by correlating them with the responses returned by origin applications. Its new response rules allow customers to use that context to log suspicious transactions or block responses before they reach the requester.

The initial focus is on confirming potential exploitation of high-profile vulnerabilities, with additional use cases planned for data exposure and exfiltration signals. For security teams, the central change is the ability to base response decisions on evidence from both sides of an HTTP transaction, rather than relying on request patterns alone.