No Patch Exists Yet: The Pre-Disclosure Exploitation Gap

Every vulnerability management programme is measured on speed. Time to patch, percentage remediated inside the service level agreement, the trend line that goes down and to the right. These are useful numbers and most teams have worked hard to improve them. They also share a limitation that almost never appears on the dashboard: pre-disclosure exploitation cannot be reduced by patching faster, because at the moment it happens there is nothing to install.

Our own analysis of exploitation activity in the first half of 2026 found that 32.1 percent of exploited vulnerabilities were attacked on or before the date their CVE was published. Roughly a third of the problem sits in a window where the fix does not exist yet. For that third, patch velocity is not a slow control. It is an absent one.

32.1% of exploited CVEs are attacked on or before their publication date

41 days of active exploitation before one critical flaw reached the KEV catalog

55,000+ CVEs projected for 2026, close to double the volume of three years ago

500+ days median time to patch in the slowest sectors

Timeline showing pre-disclosure exploitation in red with no shield, versus a shielded post-disclosure zone — The coverage gap shows pre- and post-disclosure patch deployment in cybersecurity.

The Ceiling Nobody Draws on the Dashboard

Consider a programme that patches every critical vulnerability within 24 hours of a fix being released. That is an exceptional result and very few organisations achieve it. It also covers exactly zero percent of the pre-disclosure exploitation, because in that window the vendor has not shipped anything to apply.

This produces a quietly misleading picture. Improving from a 30 day average to a 7 day average is real progress against the two thirds of exploitation that follows disclosure. It changes nothing about the remaining third. The dashboard shows a steep improvement, the uncovered share stays exactly where it was, and nobody on the call is looking at a number that represents it.

The mismatch gets worse with volume. Projections for 2026 point to somewhere between 55,000 and 60,000 published CVEs, close to double the figure from three years earlier, while median patch times in the slowest sectors still run beyond 500 days. Even the post disclosure two thirds is not fully covered, and the pre disclosure third was never in scope to begin with.

Pre-Disclosure Exploitation in Practice

A pre authentication command injection flaw in an internet facing load balancer appliance, scored 9.6, drew 792 exploitation attempts over 41 days from 65 unique IP addresses across 18 countries. It entered the CISA Known Exploited Vulnerabilities catalog on 7 August 2026, with a federal remediation deadline three days later.

An organisation whose prioritisation is triggered by KEV membership began work on day 42. Every one of those 792 attempts was pre-disclosure exploitation that had already landed. Nothing about that team was slow: the trigger simply fired after the event it was meant to warn about.

Find out which internet-facing assets sit in the window before a patch exists. — Discover which assets are exposed before a security patch is available.

Who Owns the Window

Ask most security organisations who is responsible for the period between hearing that something is being exploited and a vendor shipping a fix, and the answer is a pause followed by two department names.

Vulnerability management owns a well defined process that begins when a patch exists. Threat intelligence owns awareness of what is happening in the world. Between them sits a state that neither charter describes: something is being exploited, we may be exposed, and there is nothing to install.

The symptoms are consistent across organisations. Intelligence reports are read and filed because there is no route from a report to an action. Asset owners are not notified because the ticketing system has no category for a vulnerability with no fix. An executive asks whether the company is affected and the answer takes a day and a half to assemble, most of which is spent working out which systems are even in scope.

This is an ownership problem rather than a tooling problem. The window needs a named owner, a defined trigger for entering it, and pre agreed authority to act. None of those require a purchase.

Three-zone diagram showing the ownership gap between Threat Intelligence and Vulnerability Management during pre-disclosure exploitation — Visual overview of threat intelligence and vulnerability management in the pre-disclosure phase.

What Actually Works When There Is No Patch

CONTROL	WHY IT WORKS IN THIS WINDOW
Exposure reduction	The only measure that scales across unknown future vulnerabilities. An appliance that is not reachable from the internet is not in the pre disclosure population at all, regardless of what is discovered next month.
Product concentration awareness	Pre positioning concentrates on a predictable set of categories: edge security appliances, VPN concentrators, managed file transfer, load balancers. Knowing which of these you run, and where, converts a general worry into a short list.
Compensating controls and virtual patching	Rate limiting, request filtering, network segmentation and temporary access restriction do not require a vendor fix. They are imperfect and they buy the days that matter most.
Detection built on technique	Content written against a specific CVE cannot exist before the CVE does. Detection written against post exploitation behaviour, such as webshell placement or unexpected outbound connections from an appliance, works regardless of which flaw was used.
Pre agreed decision authority	Someone must be able to take a production appliance off the internet at two in the morning without convening a change board. Deciding who that is during an incident is how organisations lose the window.

Signals That Arrive Before Disclosure

Signals do exist in this window. They are less useful than vendors usually imply and more useful than most teams currently assume, and the honest framing matters because overstating them is how a programme loses credibility internally.

SIGNAL	WHAT IT INDICATES	TYPICAL LEAD TIME	CONFIDENCE
Vendor advisory published before CVE assignment	The vendor knows and the catalogue does not yet	Days	Medium to high
Proof of concept code appearing publicly	Weaponisation is under way and mass scanning usually follows	Hours to days	High
Scanning behaviour shifting toward a specific path or port	Mass exploitation has started or is imminent	Hours	Medium
Patch diffing activity after a vendor release	An exploit is being derived from the fix itself	Hours to days	Medium
Closed channel discussion of a product family	Interest is building and may precede an exploit	Days to weeks	Low
Exploit broker listings	A capability exists and is for sale	Weeks	Low and rarely specific

Three honest caveats belong with that table. Most of these signals are low confidence individually and become useful only in combination. The warning they buy is measured in hours and days rather than weeks. And none of them tells you that your organisation specifically is a target, only that a category of software is under pressure.

Used correctly, that is still worth having. A signal that a product family you operate is being probed is enough to justify restricting access to it for 48 hours. It is not enough to justify a public statement, and treating it as though it were is how teams stop trusting the feed.

An Operating Model That Fits in One Quarter

STEP	WHAT IT DELIVERS
1. Name the owner	One person accountable for the state between first signal and available patch. Without this the remaining four steps have nowhere to land.
2. Define the entry trigger	Write down what causes the window to open: a vendor advisory without a CVE, a public proof of concept, or a credible report affecting a product you operate. Ambiguous triggers produce inconsistent responses.
3. Build the product inventory that matters	Not every asset, only the concentrated categories: internet facing appliances, VPN, file transfer, load balancers. Which products, which versions, which are externally reachable. This is the single highest value preparatory task.
4. Pre authorise the containment actions	Agree in advance which restrictions can be applied without a change board, by whom, and how they are reversed. Decide it once, in daylight.
5. Run one rehearsal	Take a past example, walk the process end to end, and time it. The exercise reliably surfaces the gap between the documented process and what people actually do.

Brandefense Coverage

CAPABILITY	WHAT IT ADDRESSES IN THIS WINDOW
EASM	Continuous discovery of externally exposed assets, subdomains, certificates and shadow IT. When an advisory names a product, this is what turns the question of which of our systems are reachable into an answer measured in minutes rather than days.
Cyber Threat Intelligence	Threat actor tracking, initial access broker monitoring, ransomware group activity and technique mapping. This is the layer that shows a product family drawing attention before a fix exists.
Dark Web Monitoring	Collection across surface, deep and dark web through more than 190 sensors in over 40 countries, running continuously, covering the channels where access and capability are discussed and traded.
Brand Protection and DRPS	Detection of phishing and lookalike domains registered against the brand, including the ones stood up quickly to exploit attention around a newly public flaw.

RELATED READING

Vulnerability Exploitation Trends: H1 2026: What Threat Actors Are Actually Using: https://brandefense.io/blog/vulnerability-exploitation-trends-h1-2026/ The analysis the 32.1 percent figure comes from, with the full exploitation picture behind it.

From Disclosure to Exploit: How Fast Are Threat Actors Weaponizing New CVEs?: https://brandefense.io/blog/disclosure-to-exploit-speed/ What happens immediately after the window closes, when the fix exists and the race begins.

Why CVSS Scores Are Lying to Your Security Team (And What to Use Instead): https://brandefense.io/blog/why-cvss-scores-are-lying-to-your-security-team/ Why severity scores and catalogue membership are the wrong triggers for this decision.

The 62% Problem: Why Most Enterprises Only See Two-Thirds of Their Real Attack Surface: https://brandefense.io/blog/the-62-percent-problem-external-attack-surface/ Why the affected systems list takes days to assemble, and what fixes that.

None of this argues against patching faster. The two thirds of exploitation that follows disclosure is real, and speed is the right answer to it. The argument is narrower: a programme built entirely on patch velocity has an a pre-disclosure exploitation gap third, that third contains the fastest moving attacks, and it will stay uncovered no matter how good the velocity number gets. The organisations that close it are not patching more quickly. They decided in advance who owns the part of the timeline where patching is not yet an option.