Conceptual illustration of the request and response path the article describes: a request, a security panel, the origin, an inspection step and two possible outcomes, delivered or blocked. It is not Cloudflare's actual architecture.
Cloudflare has introduced web application firewall capabilities that examine HTTP requests alongside their origin responses. The approach helps distinguish suspicious requests from evidence that exploitation may have succeeded, while allowing selected responses to be blocked before they reach the requester.
A web application firewall can identify an attempt to access a sensitive file before the request reaches an application. But when that request is allowed through, a different question becomes important: how did the application respond?
Cloudflare’s announcement illustrates the problem with a hypothetical file-download endpoint receiving this request:
GET /download?file=../../config/database.ini
The path traversal sequence suggests an attempt to escape the permitted download directory. A request-based web application firewall (WAF) might identify the pattern and block it before the origin processes it.
If the request reaches the application, however, its contents alone cannot establish the outcome. The server might reject the path, return an error or expose a configuration file.
On October 21, 2026, Cloudflare introduced full-transaction detection, extending its WAF to evaluate incoming HTTP requests together with their corresponding origin responses.
The company also introduced response rules that can prevent selected origin responses from reaching the requester.
The technical change is straightforward in principle: defenders gain another opportunity to evaluate an HTTP exchange after the application has processed the request, rather than relying entirely on indicators visible beforehand.
Following the request through Cloudflare’s WAF
A request-phase WAF operates before the origin application handles an incoming request.
Cloudflare can examine properties such as the URL path, query parameters, headers and other available request data. Depending on the configured rules, it can allow the request, block it or apply another supported action.
For the file-download example, an early block would prevent the origin from processing the traversal attempt.
But applications do not all interpret suspicious inputs in the same way. A particular payload may be harmless in one environment and exploitable in another because of differences in routing, input validation, filesystem permissions or application behavior.
Full-transaction detection introduces a second observation point.
When a request proceeds to the origin, Cloudflare can correlate the original request with the HTTP response produced by the application. Managed detection signatures can consider response signals alongside the suspicious input to identify evidence consistent with exploitation.
Suppose the download endpoint returns HTTP 200 and content recognizable as a protected configuration file. That combination may support a stronger conclusion about information exposure than the traversal string alone.
The status code itself would not prove the exposure. The relevant evidence would be the relationship between the requested operation and what the response actually contained.
If a response-phase blocking rule matches, Cloudflare can replace the origin response with a WAF block page (served with HTTP 403 in Cloudflare’s example) or a configured alternative rather than forwarding the original response.
The resulting processing model contains two enforcement points: one before the origin executes the request, and another after the origin responds but before the response is delivered.
TechiesJournal conceptual diagram of the processing model described in the article, not an official Cloudflare diagram.
Text version of Figure 1
- A client sends an HTTP request.
- Before the origin: the request-phase WAF is enforcement point 1. If it blocks, the request is rejected before the origin.
- If it continues, the origin processes the request and produces an HTTP response.
- After the origin responds and before delivery: request and response signals are correlated.
- The response rule is enforcement point 2. If it allows or logs, the origin response is delivered. If it blocks, the response is replaced with a WAF block.
What response evidence changes
A suspicious request can reveal an attack attempt without proving that the application was vulnerable.
Response information can help establish whether the application behaved in a way consistent with successful exploitation.
A path traversal payload followed by an access-denied response is different from one followed by recognizable private configuration data. Likewise, a suspicious input that produces only a generic error provides different evidence from a response containing information normally unavailable to the requester.
Cloudflare’s initial full-transaction detections focus on selected high-profile vulnerabilities. The company says it intends to expand coverage to other forms of data exposure and exfiltration.
This additional context can improve the investigation of suspicious traffic, particularly when large volumes of probes make request-only alerts difficult to prioritize.
It is not a universal method for determining whether an attack succeeded. Some successful attacks produce no distinctive HTTP response, while legitimate application responses can occasionally resemble suspicious output.
The value depends on the detection signatures, the specific application behavior and the relationship between request-side and response-side indicators.
Detection metadata and response rules
Cloudflare separates detection from enforcement.
A detection identifies a matching pattern and makes the result available as transaction metadata. A rule determines whether that result should be logged or used to block the response.
For full-transaction signatures, Cloudflare introduced three response-side metadata fields:
| Field | Meaning |
|---|---|
cf.waf.signature.response.confidence | Confidence values for matching signatures |
cf.waf.signature.response.categories | Categories associated with matching signatures |
cf.waf.signature.response.ref | Reference IDs of matching signatures, up to 10 |
These fields allow security teams to combine response-side detection results with request context when creating tailored policies.
For example, a team might apply an additional restriction to a sensitive administrative path, while leaving unrelated application routes unaffected.
A response rule can also operate without those signature fields by evaluating request and response properties directly.
Cloudflare’s published example combines an /admin URL prefix, a request header representing internal authentication, an HTTP 200 response and an HTML content type.
The rule is intended to block a successful administration-page response when the expected authentication marker is absent, without treating every visit to /admin as an exposure.
That distinction is useful because response rules can consider the origin’s actual HTTP behavior rather than only the request URL.
When a configured response rule blocks a transaction, the origin response is replaced before delivery to the requester.
However, blocking a response does not undo actions already performed by the application, as Cloudflare’s announcement notes.
If the request caused a database change, executed a command or triggered another server-side operation, the response rule cannot reverse that side effect.
Response-phase blocking is therefore a containment mechanism for selected response disclosures, not a replacement for request-phase protection, application authorization or vulnerability remediation.
What is available to Cloudflare customers?
According to Cloudflare’s October 21 announcement, full-transaction detection is generally available for zones whose traffic is proxied through Cloudflare.
Managed response protections and custom response rules were released across all plans, including Free.
Cloudflare provides a managed response ruleset, the Cloudflare Managed Response Firewall Default, which Cloudflare says runs on every request by default and, according to its PHP post, was automatically deployed for customers on all plans, including Free. Customers are therefore covered without constructing individual signature-based policies. A matching managed rule can block the response and return a standard WAF block page. The scope can be adjusted to limit where those protections apply.
All plans can also create up to three custom response rules, supporting Log and Block actions. These rules can combine the request and response properties available under the customer’s plan.
There are two important restrictions.
First, custom response rules cannot yet be written on the response body. Cloudflare’s managed full-transaction detection signatures may examine response signals, but customers cannot yet write their own response-body conditions.
Second, the new cf.waf.signature.response.* fields for building tailored policies from managed detections are intended for paying customers. Cloudflare said those fields were still being rolled out to customer accounts when the capability was announced.
The availability of the response-rule engine should therefore not be confused with access to every detection field.
Administrators can find response-phase controls under Security → Security Rules in the Cloudflare dashboard. Cloudflare also exposes relevant detection information in Security Analytics and records matching rule actions in Security Events.
For a production application, the initial task is to inspect which signatures are matching, identify the affected routes and decide whether the configured response action is appropriate. A broad blocking policy may be unnecessary when the relevant exposure is limited to a particular endpoint.
Why the PHP2Shell response mattered
Cloudflare introduced the new capability while developing protections for the October 2026 PHP vulnerabilities commonly called PHP2Shell.
The company described attackers modifying request payloads as they attempted to evade earlier request-based protections. Examining origin responses offered additional evidence about which attempts may have succeeded.
That experience contributed to the initial full-transaction signatures.
TechiesJournal has already covered the vulnerabilities and patching requirements in its PHP2Shell security report. The development relevant here is the WAF processing model that emerged from those defensive efforts.
Instead of relying exclusively on suspicious request patterns, the system can now use selected signals from the application’s response to support detection and enforcement.
This is particularly relevant for potential information disclosures, where the response itself may contain evidence of what escaped the application.
It does not eliminate the need to patch the vulnerable software. A response rule can sometimes prevent information from being delivered, but it cannot guarantee that every exploit will produce a detectable response or stop damage already completed at the origin.
Where this changes security operations
For application security teams, the practical distinction is between preventing execution, containing a response and investigating the outcome.
Request-phase controls can stop a suspicious operation before the application processes it.
Response-phase controls can prevent a matching origin response from reaching the client after processing has occurred.
Request-response correlation can provide additional evidence for incident investigation, helping responders distinguish attempted attacks from activity associated with observable impact.
These capabilities complement one another, but they do not perform the same security function.
Cloudflare’s full-transaction detection adds visibility into a part of the HTTP exchange that request-only inspection cannot explain. Its response rules create a corresponding enforcement point before selected origin content leaves the edge.
The meaningful change is that a WAF can now use evidence of how an application responded, not just what the requester attempted, to make selected detection and containment decisions. The remaining boundary is equally important: once the origin has performed an action, blocking its response cannot undo that action.
Go deeper
- Cloudflare: Introducing full transaction detection for Cloudflare WAF, Daniele Molteni, Elie Roudninski and Nick Downie, October 21, 2026. Primary engineering and product disclosure covering full-transaction detection, response rules, signature metadata, availability and enforcement limitations.
- Cloudflare: Cloudflare deploys protections against php2shell vulnerability, Daniele Molteni, Dan Jones and Kuber Nandwani, October 21, 2026, updated October 23, 2026. Operational context for the PHP vulnerability response that contributed to Cloudflare’s request-and-response detection work.
- Cloudflare Developer Documentation: Attack Signature Detection. Background documentation on Cloudflare’s separation of attack detection from mitigation. The new response-specific metadata fields are described in the October 21 announcement.
- Related reading on this site: Critical PHP Vulnerabilities: Who Is Affected, What Could Happen, and How to Patch Safely, on the vulnerabilities and patching requirements, distinct from the WAF architecture examined here.
Source review: October 26, 2026. Product behavior, plan availability and rollout information derive from Cloudflare’s official disclosure. This article does not claim independent validation of the detection system’s effectiveness.