Pre-disclosure exploitation is when attackers use a software flaw on or before the date its CVE is published, while no fix exists to install. In the first half 2026 analysis described in this post, 32.1 percent of exploited vulnerabilities fell into this group. Patching faster cannot reduce that share, so the window needs a named owner, a clear trigger and pre agreed authority to act.
Every vulnerability management program 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 | Rising CVE volume, projected to keep growing through 2026 | Slow median time to patch in the slowest sectors, far beyond a year |
The Ceiling Nobody Draws on the Dashboard
Consider a program that patches every critical vulnerability within 24 hours of a fix being released. That is an exceptional result and very few organizations 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.
| Topic | After disclosure | Before or on disclosure |
|---|---|---|
| Share of exploitation | About two thirds | Roughly a third |
| Fix available | Yes | No, nothing to install |
| Does faster patching help | Yes | No |
The mismatch gets worse with volume. Projections for 2026 point to a much larger number of published CVEs than three years earlier, while median patch times in the slowest sectors still run to well over a year. 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 organization whose prioritization 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.
- Days 1 to 41Exploitation attempts792 attempts from 65 unique IP addresses across 18 countries.
- 7 August 2026Added to the CISA KEV catalogFederal remediation deadline three days later.
- Day 42KEV-triggered team starts workEvery attempt had already landed.
Who Owns the Pre-Disclosure Window?
Ask most security organizations 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 organizations. 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.
What 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 behavior, 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 organizations 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 program loses credibility internally.
| SIGNAL | WHAT IT INDICATES | TYPICAL LEAD TIME | CONFIDENCE |
| Vendor advisory published before CVE assignment | The vendor knows and the catalog does not yet | Days | Medium to high |
| Proof of concept code appearing publicly | Weaponization is under way and mass scanning usually follows | Hours to days | High |
| Scanning behavior 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 organization 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 authorize 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: 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?: 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): brandefense.io/blog/why-cvss-scores-are-lying-to-your-security-team/ Why severity scores and catalog membership are the wrong triggers for this decision.
The 62% Problem: Why Most Enterprises Only See Two-Thirds of Their Real Attack Surface: 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 program 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 organizations 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.
