Ten Hours

On the collapsing gap between disclosure and exploitation — and what vDefend’s April update actually means for the people running the change board.

Three time bars: 10 hours from disclosure to exploitation, 5–7 days for a traditional change-management cycle, and minutes for a virtual patch signature push. — The defender side of the timeline has to catch up.

Picture the change-advisory-board meeting on a Monday morning. Someone pulls up a freshly disclosed critical RCE in a library three of your production services import. The room does the math everyone in it already knows by heart: staging tomorrow if QA clears the regression suite, pre-prod Wednesday if the app team can get ten minutes, production Friday at the absolute earliest — assuming nothing else preempts it. A week, give or take. That was the world until roughly eighteen months ago.

Lately that window has collapsed. A Python notebook tool used across a lot of data-science teams was being exploited ten hours after its CVE went public this month. An Apache message broker made it onto CISA’s actively-exploited list within days of its disclosure. Microsoft’s April Patch Tuesday carried an Active Directory flaw that an authenticated low-privileged user can leverage over an adjacent network — the exact shape of a lateral-movement vulnerability, sitting in the service most east-west trust is built on. None of that is unusual anymore. It is the new rhythm.

The people running the change board aren’t slow. Staging, regression tests, maintenance windows, and app-owner sign-offs are real work — not bureaucratic friction. The problem is that the attacker’s side of the timeline compressed, and the defender’s side didn’t. That is the exact gap VMware’s security team was writing about on April 11, when they published a post framing the next couple of years as a tsunami of AI-discovered exploits and positioning vDefend’s virtual patching as the bridge between “we know about the vuln” and “we’ve shipped the patch.” Read it as a product post if you want, but the diagnosis underneath is the one the practitioner community has been working through for months.

What virtual patching actually is

The idea is old in concept, newer in where it now lives. You leave the vulnerable service running. You don’t roll a code change. What you do is drop the specific traffic pattern that exploits the vulnerability — at the network layer, before it reaches the application. The vulnerability stays in the code. The exploitability doesn’t.

Historically this has been a WAF or a perimeter IDS/IPS job, and in the north-south direction it still is. What vDefend brings is the same idea enforced at the vNIC of every workload running in the VCF fabric. Distributed IDS/IPS lives inside the hypervisor, sees every packet every workload sends and receives, and can block a specific exploit pattern the moment a signature ships — at whatever cadence the vDefend signature feed ships it. That cadence is not the same as your change-management cadence, which is the whole point.

The April 11 post walks through a concrete example: a recent exploit against the n8n automation platform, blocked by a signature that matches the malformed JSON payloads and header mismatches the exploit depends on. The n8n service itself keeps running. The patch lands when the patch lands. In between, the workload is not exploitable over the network. That is what a virtual patch looks like when it’s actually working.

Illustrative virtual patch rule card: signature VDF-2026-01179, scoped to production workloads, matching an HTTP path and body pattern, action drop+alert, 847 hits blocked in the last 24 hours. — Illustrative — a virtual-patch signature as it lands on the distributed firewall.

Where it fits with the rest of the stack

Virtual patching alone isn’t a complete answer, and the post doesn’t oversell it. It’s a piece, and the piece that fits it best is lateral-containment on the distributed firewall side.

Signatures catch what is already known. A policy that restricts which workloads can reach which other workloads catches what isn’t. A DFW rule that says production Kubernetes namespaces don’t accept inbound from developer VDIs is a small policy — but it’s the kind of policy that makes the Active Directory-class lateral-movement flaw dramatically less useful to an attacker, because now the attacker has to find a workload pair you actually allow before the authenticated-lateral-movement primitive goes anywhere. The policy follows the workload; it doesn’t break when a VM moves.

NDR, the third leg, is for the signatures you don’t have yet. AI-generated exploit variants will evade static signatures; that is what “AI-discovered exploits” means for the defender. What variants won’t evade as easily is behavior: beaconing, service enumeration, authentication from places that have never authenticated before. That’s where the east-west traffic analysis in vDefend NDR earns its keep — not as a primary prevention layer but as the backstop that catches the class of attack you couldn’t pre-define a signature for. Detection without enforcement is a ticket queue. Enforcement without detection is a policy that ages badly. The pair does the work.

For the north-south direction, the April post pairs vDefend with Avi, which is where L7 inspection at the edge lives. That’s a separate layer, not a substitute for the distributed pieces. Covering one direction and leaving the other thin has been the unintended consequence of “we have a WAF” thinking for years. The suite framing is the correction.

Where to spend the next two weeks

If the exploitation-window story is real — and the last few months of timeline data suggest strongly that it is — the next two weeks in a vDefend shop are probably worth spending on the boring-but-important side of readiness rather than on new capability deployments.

Pull the list of workloads with Distributed IDS/IPS actually enabled and cross-reference it against the tier-1 asset list; coverage gaps on crown-jewel services are the first thing to fix. Give vDefend signature updates a real place in the change-management pipeline, in a fast lane separate from the monthly maintenance window — signatures that sit in a queue for three weeks aren’t virtual patching, they’re a spreadsheet. Write a quarantine-on-disclosure DFW rule template now, not during the next incident: something you can apply in a single change to restrict east-west access to workloads flagged as vulnerable, while signatures deploy and the real patch works its way through. Confirm NDR alerts route into a queue someone actually watches, with enrichment that lets the analyst reach for the right DFW rule. And if you’re running Avi alongside vDefend, take thirty minutes to look at where the WAF policies and distributed IDS coverage overlap, and where they don’t — the goal is complementary, not redundant.

None of that is glamorous. All of it compresses the defender side of the timeline closer to where the attacker side already is. Which, on the evidence of the last two weeks, is where it needs to be.

Ten Hours

What virtual patching actually is

Where it fits with the rest of the stack

Where to spend the next two weeks

Further reading