Detecting zero-days before zero-day

The zero-day problem

Every WAF vendor quotes statistics about the volume of malicious traffic they block, the growth of API attacks, and the frequency of exploit attempts. These numbers support the business case for deploying a WAF. But the metric that actually measures a WAF's value is simpler: how quickly can it mitigate a newly disclosed vulnerability?

By definition, a zero-day exploit is not widely known, and the first malicious payload targeting your application may be the one that compromises it. If a WAF cannot detect new attack vectors quickly, its value drops considerably. The industry term for this is "time to mitigate," and it should be the focus of any WAF evaluation.

Realistic mitigation windows

To understand what "fast enough" means in practice, consider two well-documented events.

Log4Shell (CVE-2021-44228) affected Log4J, a widely used logging library from the Apache Software Foundation, and was disclosed in December 2021. The proof of concept appeared on GitHub on December 9 at 15:27 UTC, with a tweet following shortly after. Cloudflare began observing substantial attack payload volumes around December 10 at 10:00 UTC — roughly 19 hours after the PoC publication.

The second example is Atlassian Confluence CVE-2022-26134 from June 2, 2022. Atlassian published its security advisory at 20:00 UTC. Cloudflare had rules globally deployed by 23:38 UTC, under four hours later. Exact payload matches were only observed on June 3 at 10:30 UTC, more than ten hours after deployment.

The pattern repeats across other vulnerabilities: for most organizations, having mitigations in place within a few hours of public disclosure is sufficient. But that observation is not a target. Some applications face highly targeted attacks before a vulnerability is widely known, and a "few hours" is still too slow. The only acceptable time to mitigate is zero.

Why signatures alone will not get there

Every WAF on the market includes a signature-based component. Signatures are predictable, can be tuned for low false positive rates, and improve over time. Cloudflare maintains its own set of over 320 signatures as the Cloudflare Managed Ruleset, refined over the company's 13-year history.

Signatures at Cloudflare are written in wirefilter, the language understood by the global proxy. A Log4Shell signature in this language serves as an example:

The network's scale — over 64 million HTTP/S requests per second at peak — allows rapid testing of new or updated signatures to determine if they are well written.

The limitation is structural. Signatures only match what is known and verified, because they are designed to minimize false positives. Humans write them, and humans are bounded by speed. That makes signatures insufficient to reach zero time to mitigate on their own. They remain a vital component of the solution and will stay necessary, but they are not the complete answer.

Building a faster path from novel attack to blocked request

Closing the gap between a zero-day disclosure and a deployed mitigation requires shifting away from purely reactive, signature-based detection. Cloudflare's approach augments its existing WAF signatures with a machine learning classifier that can score requests inline, before a human analyst has ever seen the payload.

The project's foundation is a training set built from the same signature-based system it's meant to augment. Because Cloudflare's managed rules were written to keep false positives low, and because the WAF runs horizontally across the network, the company has access to millions of true positive examples per second. Customer configurations and tools like Bot Management help identify true negatives. The global and self-service nature of the service also keeps the data diverse, reducing bias. Before any of this is used, data is anonymized, PII is removed, and data localization boundaries are respected.

Real traffic alone isn't enough. The training set is enhanced with artificial but realistic data, generated by studying the statistical distribution of existing traffic and mutating benign content with noise, language-specific keywords, and other variations.

Building and deploying a fast classifier

Any machine learning system that runs inline on proxy traffic has a hard constraint: latency. If classification degrades the experience for legitimate users, it's not viable. This drove the choice of features and the underlying tooling, resulting in a classifier built with TensorFlow Lite.

At the time of writing, classification completes in under 1ms at the 50th percentile, with a goal of reaching that figure at the 90th percentile.

Getting the model into production required more than just training it. A pipeline takes a raw HTTP request, normalizes it for safe parsing, extracts relevant features (currently over 6,000), and runs inference to classify payloads. The model currently targets cross-site scripting (XSS), SQL injection (SQLi), and remote code execution (RCE). Outputs are consolidated into a single WAF Attack Score.

A familiar output format

Rather than introducing a novel interface, the WAF Attack Score mirrors the existing Bot Management output: a score from 1 to 99. Lower scores mean a higher probability the request is malicious; higher scores indicate clean traffic.

This fixed range makes two things easy. First, blocking traffic is just a simple rule:

cf.waf.score < 10 then **BLOCK**

Second, choosing a threshold is straightforward. Traffic distributions can be visualized in colored "buckets" in the dashboard, allowing users to zoom in and validate classifications. This visualization is available to all Business and Enterprise customers.

Results from production traffic

The classifier has been running on Cloudflare's network for over a year. To evaluate it, Cloudflare tracks classification output for new CVEs that are missed by existing Managed Rules. The results so far: for any CVE or bypass that uses syntax similar to existing vulnerabilities, the classifier performs very well, catching malicious payloads that signatures missed while keeping false positives very low at a threshold of 15 or below.

A concrete example came from a set of Sitecore vulnerabilities disclosed in June 2023:

None of these CVEs were caught by Cloudflare Managed Rules, but the model correctly detected and classified them. Customers who had a score-based rule deployed at that time were protected with zero delay.

The limits and the feedback loop

The system has a clear boundary. It excels at attack types that align with existing ones. A brand new, never-before-seen syntax remains a challenge. Log4Shell is instructive: if another zero-day were disclosed that leveraged the same JNDI Java syntax, the existing model would handle it. But genuinely novel syntax still needs work.

Near-term work includes adding detection for web shells and open redirects or path traversal.

The signature-based system isn't going away. It serves a dual purpose: it's the seed for training set generation, and it provides a productive delta for analysts. By focusing on traffic that the machine learning system flags but signatures miss, the security team can tune rules to catch those bypasses and reduce false positives.

This creates a continuous improvement loop:

Better signatures lead to better training data, which produces a better model. That model generates a more interesting delta, which human review turns into better signatures — and the cycle repeats. The goal is to automate the loop so that humans simply review and approve deployments.

Summary

The core value of a web application security product is catching new attack vectors before they cause damage, giving teams time to patch. The ideal time to mitigation is zero. Cloudflare's machine learning system, exposed as the WAF Attack Score, has demonstrated that for many CVEs — including the Sitecore examples — it can classify novel malicious payloads on first sight.

The system is live and available to all Business and Enterprise customers.