Every internet-facing Critical looks the same in the queue: a network-exploitable vulnerability on a public origin, CVSS in the red, a due date that came and went. Something stands in front of it: a firewall, a network policy, a WAF at the edge. Everyone in the room assumes that counts for something, and nobody can say how much.

Those are compensating controls, the levers a Continuous Threat Exposure Management (CTEM) program can pull while a patch waits. A firewall rule that drops the port, a network policy that keeps a workload off the public internet, a segment with no inbound route: each one can make a vulnerability unreachable today. The WAF is the control everyone points to first, so that is the one we measured.

The environment is a real customer ZEST monitors. Every internet-facing origin proxied through the same enterprise WAF. Hundreds of managed rules, block mode switched on for hundreds of known vulnerabilities, over a hundred custom rules on top. A well-run edge by any standard.

Two things came out of it. In the ledger, the WAF dismissed nothing. And the shortlist of open vulnerabilities a WAF rule could even touch was seven long, which validation cut to one rule worth writing. This article is about both halves: what the edge does for your backlog today, and what automated remediation can make it do.

The WAF fronts every origin and dismissed zero vulnerabilities

ZEST reads the compensating controls around a vulnerability and dismisses it against a named control, with the evidence attached, rather than against a scanner's opinion. Of everything dismissed that way on these origins:

• about half went on runtime evidence: the vulnerable code path is never loaded
• about a quarter went on network isolation: the asset sits in a private segment with no path from the internet
• about a fifth went on impact: the only realistic outcome is denial of service
• a sliver went on private adjacency, or on several barriers stacked together
• none went on the WAF

Each dismissed vulnerability still exists, still shows which control dismissed it, and returns to the queue the moment that control goes away. That is the mechanism working, in production.

The WAF, the one control fronting every single origin, accounted for zero. Zero means no vulnerability had the evidence to be dismissed against it. It doesn't mean the WAF blocks nothing: a vendor-managed rule already blocks one of the open vulnerabilities below by default, and nobody had credited it.

Three conditions, or the rule is decoration

Coverage is not mitigation, and the distance between them is where WAF assumptions go to die.

A WAF mitigates a specific vulnerability only when three things are true at once:

• the rule inspects the class of request the vulnerability needs (a cross-site scripting rule does nothing for a deserialization bug)
• the rule is in block mode rather than monitor
• the origin is reachable only through the edge, because a rule bound to one hostname is decoration if the host also answers on a raw address

Managed rulesets are written for classes. Your vulnerability is a particular request shape, in a particular version, of a particular component. Those two things overlap far less often than a coverage dashboard implies.

So both statements are true at the same time: the WAF is a real control, and it is not currently dismissing anything in your backlog. Most programs assume only the first.

Seven vulnerabilities made the shortlist

Of the vulnerabilities still open on these origins, roughly three in four are network-exploitable. Of those, about one in six falls in the web-application classes a WAF is built for: injection, cross-site scripting, SSRF, path traversal, deserialization, request parsing. That slice collapses into seven distinct vulnerabilities.

Every scanner known-exploited flag on the open network-exploitable vulnerabilities was checked against CISA's catalog. None held.

Seven. In an environment with hundreds of managed rules and over a hundred custom ones, the full list of live vulnerabilities a WAF rule might touch is seven long. "Virtual patching" sounds like a program: a workstream, a quarter, a headcount request. Here it starts as a list you can read in one sitting.

CVSS picks one, EPSS another, KEV none

Put the seven on the table and every signal you could rank them by disagrees with every other one.

• CVE-2025-22871, net/http · class: request smuggling via invalid chunked data · cvss: 9.1 · epss: 0.34% · known-exploited: No · validation: no rule can see chunk framing; rebuild with a patched Go toolchain
• CVE-2026-24842, node-tar · class: path-traversal bypass in a hardlink check · cvss: 8.2 · epss: 0.02% · known-exploited: No · validation: the payload hides inside an archive; upgrade
• CVE-2026-42035, axios · class: header injection through a prototype-pollution gadget · cvss: 7.4 · known-exploited: No · validation: the injection lands in outbound requests; upgrade
• CVE-2025-55184, Next.js · class: denial of service in Server Components · cvss: 7.5 · epss: 38.42% · known-exploited: No · validation: a vendor-managed rule blocks it by default; credit it once the path is proven
• CVE-2025-15284, qs · class: denial of service in array parsing · cvss: 7.5 · epss: 0.07% · known-exploited: No · validation: the library's default parameter limit caps it; check the config
• CVE-2026-22028, preact · class: script execution through JSON injection · cvss: 7.2 · epss: 0.08% · known-exploited: No · validation: the exploit is an inbound JSON shape; write the rule
• CVE-2026-42037, axios · class: CRLF injection in multipart form data · cvss: 5.3 · known-exploited: No · validation: the injection lands in outbound requests; upgrade

Rank by CVSS and request smuggling wins at 9.1, while carrying a Medium severity label from the scanner, which is its own small indictment of severity labels. Rank by EPSS and the Next.js issue wins by two orders of magnitude: a 38% chance of exploitation activity inside thirty days, against 0.34% for the thing CVSS put first. Rank by known exploitation and nothing wins, because none of the seven is on the CISA list.

Three ranking systems, three answers, and one of them returns an empty set. So ZEST skips the ranking and validates each vulnerability against what a rule can actually do. That is the last column, and it reorders everything.

The Next.js issue is the surprise. One crafted request sends the server into an infinite loop, so rate limits do nothing for it, and it carries the highest EPSS in the set. It is also the one the WAF already handles: the vendor's managed ruleset ships a rule for it that blocks by default. Crediting that rule on this edge takes one more proof, the third condition from the checklist above: the origin can't be reached around the edge. Until that proof exists, the vulnerability stays open.

Request smuggling and node-tar sit where no rule can look. The qs issue is capped by the library's default parameter limit unless someone raised it. Both axios bugs inject into requests the service sends, so the upgrade is the whole fix.

What is left for a custom rule is Preact.

Block it today, patch it on schedule

The Preact vulnerability, CVE-2026-22028, is the one a rule can actually read. A regression in Preact loosened the check that stops parsed JSON from being treated as a virtual DOM node. An app that passes user-supplied JSON straight into its render tree can be handed an object that renders as HTML, script included. The exploit is a request body with a recognizable shape, and the real fix is a version bump.

So the agent derives that shape from the advisory, writes a rule that matches it in request bodies on the affected origin, and deploys it in log mode, which records matches without blocking anything. Legitimate clients have no reason to send JSON shaped like a Preact node, so the expected false-positive count is zero. If it is not zero, that is information you very much wanted before switching to block. Body inspection and log-only mode are enterprise-tier features on most WAFs, and this edge has both.

Once clean, it promotes to block. The exploit path closes at the edge the same day, while the actual fix, upgrading Preact to a patched release, ships on the normal cadence. The vulnerability stays open, marked mitigated against that rule, until the upgrade lands and a scan confirms it.

Now the boundary. Request smuggling tops CVSS at 9.1 and looks like the perfect rule until you check what a rule can read. The bug lives in how chunked request bodies are framed, and WAF rule languages never expose chunk framing. It gets closed by rebuilding the service with a patched Go toolchain. The node-tar payload hides inside an archive, usually compressed, where a rule can't reliably look.

That is the honest edge of the technique: a rule helps when the exploit is a request shape the edge can read, and nowhere else. Add a managed rule already doing its job, a library default that caps the qs issue, and two axios bugs an upgrade fixes outright, and seven candidates come down to one rule.

Two decades of virtual patching, finally automated

The idea is not new. Virtual patching shipped with ModSecurity two decades ago, and every WAF vendor has sold a version of it since. The labor is the bottleneck. Writing a rule for one vulnerability means reading the advisory, working out the request that triggers the bug, translating it into the WAF's expression language, deploying it without breaking real traffic, watching it, and pulling it back out when the patch finally lands. It is fiddly, it is one vulnerability at a time, and every week it loses to something on fire.

What changed is that deriving the rule, rehearsing it against live traffic, and removing it when the patch ships is now work automated remediation carries continuously, without anyone giving up a Friday. Validation decides which vulnerabilities deserve a rule in the first place.

Four guardrails before an agent touches your edge

In most organizations past a couple hundred people, the security team does not own the WAF. Platform, web ops, or networking does. They hold the token, they carry the pager, and they have watched one bad rule take down checkout.

An agent writing rules into production edge configuration is a change-management conversation before it is a technical one:

• Scope the credential. A token scoped to one zone, with WAF edit rights and nothing else, is a different proposition from an account-wide key.
• Stage the promotion. Log mode is not optional, and neither is a human on the log-to-block promotion for the first rules a team accepts.
• Name the owner. Someone owns the rule after it ships, and it should be the team that already owns the edge.
• Make removal trivial and logged. A clean rollback only helps if the people who need it at 2am know it exists.

If the answer to "who approved this edge change" is "the tool did," that is not automation. It is an unattributed change in production.

The riskiest origins are too quiet for log mode

The honest failure case is the low-traffic origin. A forgotten service handling a few hundred requests a day never accumulates enough traffic to prove a rule is safe, and forgotten, low-traffic services are reliably the ones running the unpatched thing.

For those you have two options and no third: replay the exploit shape synthetically against the rule, or leave it in log mode and treat it as detection rather than mitigation. Calling it mitigation anyway is how a quiet origin becomes a Friday.

Rollback takes one API call

The edge is the remediation lane we trust most, for one reason: the rollback is a delete. Every other lane carries an asterisk, a snapshot to restore, a runtime to pin, a cluster to roll node by node, a database with no downgrade path at all. Remove a WAF rule and the configuration is exactly what it was.

One caveat, and it is the one that matters commercially: the rule rolls back instantly, the requests it blocked while it was live do not. Forty minutes of blocked checkout is not undone by deleting a rule. Which is exactly why log mode is not a formality.

A WAF rule never closes a vulnerability

A WAF rule does not change the host. Your scanner will look at that origin again and find the same vulnerable version, because it is still there. Any tool that marks the vulnerability closed because a rule was written is reporting something it has no way to know.

So the rule closes nothing. It changes urgency. The vulnerability stays open, marked mitigated against a named control, and returns to full weight the moment the rule is removed. It closes when the package is patched and the scanner that raised it can no longer detect it.

A rule at the edge is a tourniquet. What it buys is the difference between an emergency change and a normal one, which for a network-exploitable vulnerability under active exploitation is the entire game. A program that treats it as a cure has quietly stopped patching.

One WAF, two CTEM stages

Most vulnerability management programs own a WAF and use a sliver of it, as a wall to stand behind. It is also a control you can read and a lane you can remediate through, if you are honest about what it is doing for you today.

In CTEM terms, the two halves of this article are the two stages most programs never reach. Reading the edge is validation: proving which exposures a control already neutralizes, with the evidence attached, so they leave the queue on merit. Writing to it is mobilization, automated remediation in the strict sense: turning a validated exposure into a change that lands, holds, and rolls back cleanly. ZEST is built for that back half of the cycle, and the WAF is one lane through it.

In the environment above, the ledger showed the WAF dismissing nothing, and that was worth knowing. The controls that did the work were runtime reachability, network isolation, and impact analysis. The WAF's share is still ahead of it: one managed rule to credit once the path is proven, and one custom rule to write.

The vulnerability is real. The emergency usually is not. Telling those apart is the whole job.

See it on your own edge. We can read your WAF coverage against your live vulnerabilities and show you how many of your internet-facing Criticals are already gated, how many are the class a rule could gate, and how many rules that would actually take.

Book a demo