Next-Gen WAF: What the Evidence Supports

24 September 2026

I spent years on the data side of a WAF, and the question I keep getting asked now is whether a local language model can sit in the request path and judge SQL, XSS and shell injection payloads. This post is the answer as far as the published record supports it, as of 24 September 2026. It has three parts: what has actually been measured, what those measurements force on an architecture, and the experiments I would run next.

One rule governs the whole text. Every number is taken from a dated source that I opened and read, and is linked where it appears. Where the literature is silent, I say so instead of filling the gap. Several of the most useful figures come from adjacent problems (prompt-injection guards, network-flow classification) rather than from HTTP payload inspection itself; each of those is labelled as a proxy, not as evidence about WAF traffic.

The short version: no 2025–2026 study I could find measures a generative local LLM (Llama, Qwen, Gemma, Phi) classifying SQLi/XSS/CMDi payloads inline with a per-request latency figure. The papers that do report timing on this exact task use encoders or classical ML, and every one of them concludes the transformer is the bottleneck.

Part 1: what has been measured

The latency budget a WAF actually has

The only production number in the public record is Cloudflare's, and it is measured in microseconds, not milliseconds. In July 2024 Cloudflare reported that its WAF Attack Score model (HTTP normalisation, n-gram tokenisation, TensorFlow Lite inference, covering SQLi, XSS and RCE) ran at 1,519 µs per request end to end before optimisation and 275 µs after, a 5.5× speed-up, on x86-64 CPUs with AVX2 and no GPU. The preprocessing was rewritten in Rust; inference moved to TFLite 2.16.1 with XNNPACK, which alone cut model time by 77.17%. A cache in front of the model hit roughly 70% of the time (Cloudflare, 25 Jul 2024). That is the bar for "inline at scale": a few hundred microseconds on a CPU core, at what the post describes as tens of millions of requests per second across the fleet.

The practitioner thresholds quoted for inline model checks are looser but come from the LLM-guardrail world, not from WAFs. A June 2026 write-up on running six guardrail tools inline states that "anything over about 50ms inline and users feel it; over about 200ms and someone disables it", and offers no measured latencies per tool (dev.to, Jun 2026). I treat the 50 ms / 200 ms figures as opinion, not measurement.

So the budget has two very different readings depending on who is asked: sub-millisecond if you are a CDN-scale WAF vendor on CPU, tens of milliseconds if you are guarding a chat endpoint that already spends seconds generating a reply. Everything that follows has to be read against the first number, because that is the traffic profile a WAF sees.

What the payload-classification papers measured

Three recent papers report both accuracy and timing on SQLi/XSS-class payloads, and the timing gap between classical ML and a transformer is two to three orders of magnitude in each.

The WAMM figures are the cleanest: same CPU box, same augmented SR-BH 2020 dataset covering SQLi, XSS, LFI, RFI, OS command injection, SSTI and SSRF, and a per-sample inference time for each model. The DistilBERT number, 14.7 ms on CPU, is already 50× over Cloudflare's whole-pipeline budget above, and its macro-F1 is the worst of the four.

Two caveats on the table. The ICAIIC "samples per second" is the throughput printed by a batched evaluation run, so it is an upper bound on per-request rate, not a latency. And the Aug 2026 paper reports elapsed time for the full test set without stating its size in the abstract; the PDF was not machine-readable when I tried it, so the 140× ratio is the only usable figure. Notably, its fast path still depends on DistilBERT embeddings being computed at inference; the abstract does not say whether the 0.0136 s includes that step.

Accuracy that does not survive contact

The 99% accuracies in the table above are benchmark-internal, and three recent results show how far they fall outside the benchmark.

First, macro-F1 versus accuracy. In WAMM, XGBoost scores 99.59% accuracy but 86.07% macro-F1, and the three neural models sit at 57–60% macro-F1 despite 96–97% accuracy (WAMM, Table VI). The gap is the rare classes: accuracy is dominated by benign traffic and the common attack types, while SSTI and SSRF drag the macro average down. A WAF is judged on exactly those tails.

Second, distribution shift from LLM-generated attacks. An IEEE Access paper from January 2026 tested 14 LLMs with 100 expert-crafted prompts and then ran four detector families (regex, classical ML, a CNN, and a RoBERTa contextual model) on the resulting SQL. Overall detection accuracy "plummeted from roughly 98% on standard SQLi benchmarks to just 60%" on that test set (IEEE Access, Jan 2026). The RoBERTa model, the most expensive of the four, did not escape the collapse.

Third, the rule-based baseline is worse than either. On the Drupal dataset, ModSecurity with OWASP CRS v3 reaches 29.55% TPR at 15.57% FPR at paranoia level 1 and 77.89% TPR at 49.93% FPR at level 2; on SR-BH 2020 it detects 26.62% and 28.48% at 0% FPR (arXiv 2609.26860, Sept 2026, Table VIII). The same paper's own FastText + one-class SVM detector, trained on benign traffic only, reaches 80.11% TPR at 0.79% FPR on Drupal and 90.09% at 3.43% on SR-BH 2020, and it reports no timing at all. Its authors dropped contextual embeddings on cost grounds, citing "high computational costs and increased processing times" in near-real-time settings.

The pattern across the three: the cheap models win on in-distribution benchmarks, every model family loses on adversarially generated payloads, and no paper yet shows a transformer buying back enough generalisation to justify its 100–140× latency cost on this task.

Generative local LLMs: what has been measured, and what has not

No paper in the 2025–2026 record puts a generative local LLM in front of HTTP payloads and reports per-request latency. What exists is three proxies, each one step removed from the WAF problem.

The closest is the ICAIIC 2025 result already in the table above: an 8B Llama-3 derivative with a classification head runs at 6.8 samples/s on a V100 against 285 samples/s for DistilBERT on the same data, a 42× gap, with no accuracy gain on SQLi or XSS (ICAIIC 2025). That is a fine-tuned discriminative use of a decoder, not prompting.

The second proxy is network-flow classification. A January 2026 study fine-tuned GPT-2, GPT-Neo-125M and LLaMA-3.2-1B on Zeek flow records from CIC IoT 2023 and measured 104–105 flows/s for the 1B model and up to 517 flows/s for GPT-Neo-125M, against 1.5 million flows/s for XGBoost and 6.25 million for a decision tree, on an Intel Xeon Silver 4210 with an RTX 2060 6 GB. The authors write that "LLMs are 10,000 times slower than ML models" and place them in "applications that process only tens to hundreds of flows per second" (AIRE, 9 Jan 2026). Flow records are structured, not free-text payloads, so this is a lower bound on the work an HTTP body would demand.

The third proxy is the prompt-injection guard literature, which has the same shape as payload inspection (short adversarial string in, binary label out) and is where the latency numbers are densest. Meta's Prompt Guard 2 encoders run at 19.3 ms (22M, DeBERTa-xsmall) and 92.4 ms (86M, mDeBERTa-base) for 512 tokens on an A100 (model card). Qualifire's Sentinel, a 395M ModernBERT-large, reports about 20 ms per inference on an L4 (arXiv 2506.05446). An August 2026 comparison cites roughly 9.5 ms per item for an encoder on commodity CPU, under 4 ms batched, and lists the LLM-as-judge alternatives (Llama Guard 3, ShieldGemma 2B, Qwen3-Guard 0.6B/4B/8B) without latency figures (ARMO, 20 Aug 2026). The one head-to-head timing I found is from September 2026: a classifier judged a 12,000-character document in 1.1 s median (1.4 s p95) where the LLM judge needed 11.4 s, and the same LLM judge ran 2.07 s to over 4 s on shorter inputs (Prismor, 20 Sept 2026). The same post reports the classifier's false-positive rate at 0% on its benchmark and 41% on real traffic, which is the generalisation problem from the previous section again.

One more data point on small generative models as detectors, from a different input type. A WebShell paper prompted Qwen-2.5 at 0.5B, 1.5B and 3B, Qwen-2.5-Coder at 3B and 14B, LLaMA-3.1-70B and GPT-4 on 26.59K PHP files. Without scaffolding the best open model (Qwen-2.5-Coder 14B) reached 96.39% F1, below a graph-attention baseline at 98.87%; with the authors' behavioural-function framework the 0.5B model gained +51.23 F1 points. No latency is reported (arXiv 2504.13811). The result cuts both ways: prompting a sub-1B model naively fails, and the fix that rescues it is engineering around the model, not the model.

What is missing from the record is the experiment that matters: a 0.5B–3B decoder used as a single-forward-pass classifier (logits over a yes/no token, no generation) on SR-BH or CSIC payloads, with p50/p99 per request on a consumer GPU and on CPU. That absence is the first item in Part 3.

The attacker already has the LLM

The measured impact of LLMs on the WAF problem so far is on the offensive side, and the numbers are large. GenXSS used GPT-4o and Gemini Pro to generate obfuscated XSS payloads by in-context learning: 220 of GPT-4o's 264 payloads (83%) were valid, and of those 80% bypassed ModSecurity and nearly 100% bypassed AWS WAF; Gemini Pro's valid payloads bypassed ModSecurity at 74% (GenXSS, arXiv 2504.08176). The same paper then clustered the successful attacks and had the LLM write rules from the clusters, blocking 86% of the previously successful payloads with an F1 of 0.9259 for the generated rule set. Latency is not reported for either direction, and the rule-writing step is offline by construction.

The defensive corollary is in the training data. A WiseML 2025 paper fine-tuned CodeT5-small to produce obfuscated variants of XSS samples: a Random Forest trained on the original data fell to 0.523 recall under obfuscation, and retraining on the LLM-generated variants brought it back to 0.995 accuracy and 0.993 F1 (arXiv 2504.21045). An MDPI study built its SQLi corpus by generating 72,304 malicious queries with GPT-4o against 17,695 legitimate ones and reached 96.86% accuracy with a voting ensemble of XGBoost and LightGBM (Electronics, Sept 2025). WAMM's best dataset variant is the one where an LLM filtered noisy synthetic payloads out of the augmented set (WAMM).

Read together with the 98%→60% collapse above on LLM-generated SQLi: the attacker's LLM moves the payload distribution faster than a static training set can follow, and the only published defences that recover are the ones that put an LLM in the data-generation loop, offline, and keep the cheap classifier inline.

Part 2: what the numbers force

Part 1 collected the measured numbers: a production WAF pipeline at 275 µs per request on CPU, XGBoost at 49 µs per payload, DistilBERT at 14.7 ms, an 8B model 42× slower than DistilBERT for no accuracy gain, and every detector family collapsing from 98% to 60% on LLM-generated SQLi. This part is what those numbers force on an architecture.

A tiered pipeline, and where each model class can sit

The latency ladder in Part 1 spans five orders of magnitude, from 49 µs for XGBoost to seconds for an LLM judge, and no single model covers it. The architecture the evidence supports is a cascade: a cheap model on every request, an expensive one on the fraction it cannot decide, and the generative model outside the request path altogether.

Each tier's figure is the one measured in Part 1; the escalation thresholds and the fraction of traffic that reaches Tier 2 are not in any source and are the subject of Part 3, experiment 4. The Tier 0 cache figure is Cloudflare's ~70% hit ratio on its ML pipeline; whether a verdict cache holds at that rate on a different traffic mix is not established.

Two consequences follow. Tier 2's cost is only bearable if Tier 1 escalates a small fraction: at 14.7 ms per escalated request on CPU (WAMM's DistilBERT), escalating 5% of traffic adds 0.74 ms of mean latency, escalating 50% adds 7.4 ms, and the p99 is Tier 2's full latency either way. And the generative LLM's only measured contributions (Part 1, last section) are all batch jobs: payload generation, data filtering, rule synthesis. Nothing in the record shows it earning its seconds-per-item cost inline.

Where the LLM earns its cost

The generative model has three measured uses in this literature, and all three run offline against a corpus, not inline against a request.

The first is red-teaming the deployed detector. GenXSS's numbers (80% ModSecurity bypass from GPT-4o-generated XSS, near-100% on AWS WAF) are the only quantified evasion rates in the recent record, and they were obtained with API models, not local ones (GenXSS). A local model in the same role has no published bypass rate; whether a 7B–14B open model generates evasions of comparable validity is an open question, and experiment 5 in Part 3 is built around it.

The second is training-set construction. Three papers in the last section of Part 1 use a generative model to write, mutate or filter payloads and then train a cheap classifier on the result: CodeT5-small obfuscation lifting Random Forest from 0.523 to 0.995 under obfuscation (arXiv 2504.21045), GPT-4o generating 72,304 SQLi samples (Electronics, Sept 2025), and WAMM's LLM-filtered augmentation producing its best dataset variant (WAMM). This is the one use where the model's cost is amortised over every future request, because the inline model is unchanged.

The third is rule synthesis from clustered misses: GenXSS's generated rules blocked 86% of previously successful payloads at F1 0.9259. This keeps Tier 0 in the loop rather than replacing it, which matters because Tier 0 is where the 0% FPR lives (SR-BH 2020, CRS PL1/PL2, arXiv 2609.26860 Table VIII).

What none of the three does is put the LLM's judgement on a live request. The Prismor timing in Part 1, 2.07 s to over 4 s per LLM-judge call, is four orders of magnitude over Cloudflare's 275 µs. Even the encoder tier is 50× over that budget on CPU. The design question is therefore not "which LLM inline" but "how small can the inline model be while the LLM keeps its training data current".

Contradictions in the evidence

The sources do not agree with each other on four points, and the disagreements are informative.

DistilBERT is the worst model in WAMM (59.48% macro-F1, below XGBoost's 86.07%) and the best single model in the Aug 2026 SQLi paper (99.82% as DistilBERT-SVM). The two are not measuring the same thing: WAMM is a 7-class problem on honeypot traffic with rare classes, the Aug 2026 paper is binary SQLi. The reconciliation the second paper itself offers is to use DistilBERT as a frozen feature extractor and put a classical ensemble on top, which is what recovers the 140× speed-up. Read together: the encoder's value is in its embedding, not its classification head, and the rare-class problem is unsolved by either.

Rule-based WAFs have 0% FPR on SR-BH 2020 and 15.57–49.93% FPR on Drupal (arXiv 2609.26860 Table VIII). Same rule set, same paranoia levels. The FPR of CRS is a property of the protected application's benign traffic, not of the rules, so any FPR figure for a WAF that does not name the application is not a figure.

The 8B model in ICAIIC 2025 matches DistilBERT on accuracy and is 42× slower; the AIRE 2026 study finds LLaMA-3.2-1B at 104 flows/s against XGBoost's 1.5 M/s with no accuracy advantage reported for the LLM on the binary task. Against those, the WebShell paper reports a sub-1B Qwen jumping +51 F1 points with the right scaffolding (arXiv 2504.13811). The scaffolding there is file-level behavioural analysis, which has no equivalent for a single HTTP request; I do not read the WebShell result as evidence for inline payload inspection.

The IEEE Access 60% figure and the WAMM 99.59% figure describe the same model family (classical ML on SQLi) a few months apart. The difference is the test set: WAMM's is drawn from the same distribution as training, IEEE Access's is LLM-generated. Neither is wrong. A next-gen WAF has to report both numbers, and the second one is the one that predicts production.

Part 3: experiments

Six experiments, each aimed at a gap Part 1 left open, each with the published number it has to beat. Datasets are the ones the cited papers used, so results are comparable: SR-BH 2020 (real honeypot traffic, 12 attack categories), CSIC 2010 (synthetic), and the Drupal set from arXiv 2609.26860.

Three notes on running them. Every model in experiments 1, 2 and 4 must be timed at batch size 1 as well as batched, because every published throughput figure for the transformers (285 samples/s, 6.8 samples/s, 104 flows/s) comes from batched evaluation and a WAF sees one request at a time. Every accuracy figure must be reported twice, on the in-distribution test set and on the LLM-generated one, or it repeats the mistake Part 1 documents. And macro-F1 over all classes is the headline metric, not accuracy, because accuracy is where the 99% numbers come from and macro-F1 is where they go to die.

If experiment 1 fails, and the proxies say it will on CPU, the next-gen WAF is a cascade of classical ML and a small encoder with a local LLM feeding it data, and Part 2 already describes it. If it succeeds on a GPU at batch 1 under 5 ms, a decoder becomes a candidate Tier 2 and the question moves to experiment 4.

Sources