Some risks are visible the moment they appear. Others sit quietly for months or years before they show their impact.
Zero-day vulnerabilities fall into the latter category. These are flaws in software or hardware that attackers discover before the vendor or defenders know they exist.
There is no alert. No advisory.
No patch.
But there is often already an exploit in play.
Â
In 2024, more than 2,800 zero-day vulnerabilities were observed in production environments protected by AppTrana’s WAAP.
These were not found during audits. They were detected during live traffic inspection. That number points to a structural problem. Most environments do not fail because teams lack coverage. They fail because something critical remained unknown for too long.
Â
Understanding how zero-days are discovered, used, and mitigated requires looking beyond tooling. It starts with accepting how these risks move through systems long before anyone is ready to stop them.
What Zero-Day Actually Means
A zero-day vulnerability is a flaw that is unknown to the software vendor. There is no documented fix. There is no known signature. In many cases, the flaw may have already been found, studied, and exploited by attackers before the development team is even aware it exists.
Â
The exploit timeline usually begins long before disclosure. By the time a vulnerability is made public, it may have already been traded or used in multiple attacks. The absence of prior knowledge is what defines the risk.
Â
It helps to separate the terms clearly:
Â
- A zero-day vulnerability is the coding or logic flaw.
- A zero-day exploit is the method that takes advantage of it.
- A zero-day attack is when that method is used in real systems, often quietly and without immediate detection.
The vulnerability exists regardless of whether anyone knows about it.
That knowledge gap is what attackers use.
How Exploits Outpace Defensive Controls
Once an attacker or broker identifies a flaw, the window of advantage begins. The flaw may be tested in isolated environments, packaged into a working exploit, or held for sale. It can also be used immediately, depending on the target and intent.
Â
The common belief is that zero-days are rare or reserved for high-level operations. In practice, they are integrated into broader attack chains that include phishing, malware loaders, and lateral movement. The exploit itself might not leave obvious traces. Detection usually comes later, during incident response or forensic analysis, when security teams review how initial access was obtained.
Â
The average time it takes to develop a usable exploit after discovering a vulnerability is estimated to be around 22 days, based on data cited in multiple studies.
Â
For attackers working with internal capabilities or brokered access, this gap is often shorter than most patch testing cycles.
Â
Â
The Window Is Wider Than Most Realise
Zero-day risks are not limited to the time before disclosure. Exploits often remain viable long after a patch is released. This happens because fixing code in production environments takes time, and attackers know how to work within that gap.
Vulnerabilities tend to fall into a few operational states:
- Alive: The flaw exists and is not yet publicly known or patched
- Dead: The vulnerability has been disclosed, but no fix has been applied
- Zombie: A patch exists in newer versions, but older deployments remain exposed
In theory, patching closes the window.
Â
In practice, the gap between disclosure and remediation is where most real-world attacks occur.
Â
Â
Research from RAND found that zero-day vulnerabilities remain exploitable for an average of 6.9 years. Even those sourced through third-party brokers tend to stay usable for over 1.4 years.
Â
That gap exists because remediation is not a single event. Vendors must first reproduce the issue, develop a fix, validate it, and push the update. Organisations receiving the patch must then test it in their environments, confirm that it does not disrupt functionality, and schedule deployment.
Â
In some cases, updates are delayed indefinitely because of integration complexity, legacy dependencies, or concerns about downtime. This creates an extended lifecycle for vulnerabilities that should, in theory, be short-lived.
Â
Several factors contribute to this extended exposure:
- Delays in vendor response or patch release cycles
- Hesitation in deploying updates without full compatibility testing
- Lack of visibility into where vulnerable components are running
- Dependency chains that obscure the presence of the affected code
Even when patches are applied in current versions, older software often remains in use across distributed infrastructure. These are known as zombie vulnerabilities. They have been technically fixed, but still exist in systems that remain exposed.
Â
What Detection Looks Like in the Absence of Signatures
Â
Security systems built around known indicators cannot respond to what they have never seen before. Most zero-day exploits are not flagged by antivirus engines or SIEM correlation rules. There is no CVE to match, hashes to check or log line that clearly shows what just happened.
In these cases, detection comes from behaviour. Analysts may observe:
- A process behaving in ways that are inconsistent with its baseline profile
- Memory allocation patterns that suggest shellcode execution
- Outbound connections that fall outside expected network patterns
- Activity from accounts or endpoints that had no history of privilege escalation
These are not definitive signs, they are weak signals that something is off.
Â
Detecting them consistently requires tuned baselines, good alert thresholds, and enough internal context to know what constitutes normal behaviour.
Â
Even with strong detection infrastructure, the burden falls on response teams to interpret and act quickly. That is rarely straightforward, especially in environments with high alert volume or inconsistent asset visibility.
Â
The Economics Behind Zero-Day Exploits
Zero-days go beyond security risks. They are tradeable assets in global markets that operate with varying levels of transparency and control. The buyer’s intent, not just the flaw itself, determines how the vulnerability will be used.
| Market | Participants | Purpose | Characteristics |
|---|---|---|---|
| White Market | Security researchers, vendors, bug bounty platforms | Responsible disclosure and coordinated remediation | Often includes public CVEs, patches, and vendor acknowledgements |
| Grey Market | Governments, military contractors, surveillance firms | Offensive use, national security operations, strategic access | Vulnerabilities may be stockpiled; disclosure is rare or delayed |
| Black Market | Cybercriminal groups, access brokers, exploit kits | Ransomware, espionage, persistent access, resale | Often based on half-patched or unpatched known flaws; operates via closed channels |
Examples That Weren’t Caught Early
Â
Some of the most impactful breaches in recent years involved zero-days that remained active for long periods before being detected or even acknowledged.
Â
Â
MOVEit Transfer (CVE-2023-34362)
Â
A SQL injection vulnerability in Progress Software’s MOVEit Transfer application was used by a ransomware group to gain unauthorised access and deploy malicious code across hundreds of organisations. Victims included government agencies, educational institutions, and financial service providers. The exploit was used at scale before public disclosure.
Â
Â
JetBrains TeamCity (CVE-2023-42793)
Â
A critical authentication bypass vulnerability in on-premises TeamCity CI/CD servers allowed unauthenticated attackers to execute remote code with administrative privileges. Multiple threat actors began exploiting the flaw days after public disclosure. Thousands of exposed instances remained unpatched well into the following month.
Â
Â
Pegasus Spyware (CVE-2021-30860, CVE-2021-30900)
Â
The Pegasus spyware platform, developed by NSO Group, used a combination of zero-click vulnerabilities to compromise iOS devices without any user interaction. The CVEs associated with the campaign included flaws in CoreGraphics and XNU kernel components. These vulnerabilities enabled full device compromise and were used against high-risk targets globally, including journalists, lawyers, and activists.
Â
Â
In all three cases, exploitation occurred before any defensive measures were in place. Detection was either delayed or surfaced only after third-party investigations revealed widespread compromise. The common thread wasn’t just the sophistication of the exploit.
Â
It was the timing. Each flaw was used before most environments knew it existed.
Patching Alone Doesn’t Contain the Risk
Â
Patching is a critical control, but its effectiveness begins only after the vulnerability has been identified, verified, and addressed upstream. That timeline is rarely predictable. A zero-day may be actively exploited for months before a patch is even in development. Once a fix is released, deployment across large or distributed environments often takes additional weeks.
Â
This delay isn’t always due to negligence.
Â
Patches must be tested for compatibility.
Â
Dependencies need to be reviewed.
Â
In some environments, downtime is not acceptable, and rollback risks are tightly controlled. These constraints are especially common in regulated sectors and critical infrastructure, where operational stability takes precedence over fast updates.
Â
To close that gap, many teams rely on virtual patching. This approach applies security controls at the network or application edge, often through web application firewalls or managed WAAP platforms. These controls are configured to block known exploit paths, even if the underlying code remains unchanged.
Â
Virtual patching does not replace remediation. It reduces the window between public disclosure and full deployment of a fix. That window is often when exploitation is most likely to occur, especially when attackers reverse-engineer the patch to develop their own exploit code.
Â
Â
Designing for Containment, Not Assumption
Most environments are still designed with the assumption that security begins once a vulnerability is published. That assumption no longer holds. By the time a CVE is issued or a patch is available, active use of the vulnerability may already be underway.
Mitigating that risk requires structural changes that limit how far an attacker can move once access is gained. These actions do not eliminate the vulnerability itself. They reduce the potential damage before containment begins.
Approaches that help include:
- Isolating systems through strong segmentation to prevent lateral movement
- Applying least privilege consistently across user, application, and network layers
- Monitoring system and application behaviour against established operational baselines
- Automating patch deployment and maintaining real-time visibility into asset versions
- Running breach simulation exercises to test how teams respond under uncertainty
These are not bolt-on controls. They change how systems behave under pressure and how quickly an environment can adapt when something unexpected is detected.
The Takeaway
Zero-day vulnerabilities highlight more than technical flaws – they expose weaknesses in how organisations manage security under pressure. Leadership has a direct role to play in ensuring that patching is not just a policy, but a capability that holds up when it matters most.
Â
Building a resilient patch management process means investing in the right tools, enforcing accountability, and preparing your teams to act fast, even when conditions are far from ideal. If your organisation’s current approach depends on everything going smoothly, now is the time to rethink it – before the next zero-day tests your defences.
Â
RankSecure helps organisations strengthen patch management with structured processes, real-time visibility, and expert guidance. To explore how we can support your business in building a more resilient security posture, get in touch with us today.
