How long does it take for a CVE to get a patch?

The Vulnerability Disclosure Timeline

The time from vulnerability discovery to patch availability varies dramatically depending on how the vulnerability is disclosed and which vendor is involved. Understanding these timelines helps you plan response strategies and assess your vulnerability window.

The basic timeline typically follows this pattern:

1. Vulnerability Discovery (Day 0): A security researcher or vendor discovers a vulnerability
2. Responsible Disclosure (Days 0-90): The discoverer notifies the vendor
3. Vendor Analysis and Fix Development (Days 0-180+): The vendor analyzes the issue and develops a fix
4. Coordinated Disclosure (Day X): CVE is publicly assigned; patch becomes available
5. Patch Distribution (Days 0+): Organizations deploy patches

However, the timeline varies significantly based on circumstances.

Coordinated vs. Uncoordinated Disclosure

Coordinated Disclosure (Responsible Disclosure): The researcher privately notifies the vendor before disclosing publicly. This gives the vendor time to develop a patch before attackers learn about the vulnerability.

Typical timeline for coordinated disclosure:

• Day 1: Researcher notifies vendor
• Days 1-7: Vendor acknowledges the report
• Days 7-90: Vendor develops and tests patch (varies greatly)
• Day 90: Default disclosure deadline if no patch exists (can be negotiated)
• Day 90: Patch released and CVE publicly disclosed simultaneously or near-simultaneously

This approach attempts to minimize the window where vulnerabilities are known but unpatched.

Uncoordinated/Public Disclosure: The vulnerability is publicly disclosed without advance notification to the vendor. This occurs when:

• A researcher publishes exploits or vulnerability details without vendor coordination
• Vulnerabilities are discovered in abandoned or unsupported software
• A researcher loses patience with a slow vendor response
• Hackers discover and weaponize vulnerabilities independently

Timeline for uncoordinated disclosure:

• Day 1: Vulnerability becomes public
• Days 1-?: Vendor learns about the vulnerability from public disclosure
• Days 1+: Vendor develops patch (no advance notice, starting from scratch)
• Unknown timeline: Patch availability uncertain

Uncoordinated disclosure creates immediate risk because attackers can begin exploitation while vendors scramble to develop patches.

Patch Timeline by Vendor Category

Microsoft: Generally provides rapid patch response.

• Timeline: 7-30 days from disclosure to patch
• Patches typically released on monthly "Patch Tuesday" schedules
• Critical vulnerabilities might receive out-of-band patches within days
• Active support lifecycle varies (Windows 10, Windows 11, etc. have different support periods)

Apple: Varies by product and severity.

• Timeline: 3-60 days depending on severity and product
• Critical iOS security vulnerabilities might be patched within days
• macOS patches follow quarterly security update schedules
• Older OS versions receive slower patch response or none

Adobe: Releases monthly security updates.

• Timeline: 30 days typical for monthly updates
• Critical vulnerabilities might receive out-of-band patches
• Different products (Acrobat, Creative Cloud, etc.) have separate patch schedules

Apache/Open Source Projects: Highly variable.

• Timeline: 1-180+ days
• Depends on project activity and maintainer availability
• Popular projects (Tomcat, Log4j) respond quickly
• Dormant or abandoned projects might never receive patches
• Example: Apache Log4j (Log4Shell) was patched within days due to severity and attention

Enterprise Software (Salesforce, Oracle, SAP): Often slower.

• Timeline: 30-90 days or longer
• Quarterly or less frequent patch release cycles
• Critical vulnerabilities sometimes get faster treatment
• Legacy product versions might not receive patches at all

Web Framework/Library Maintainers: Varies by popularity.

• Timeline: 1-30 days for popular frameworks
• Less popular projects: Uncertain, possibly never
• Community-driven projects: Depends on maintainer responsiveness

Factors Affecting Patch Timeline

Several factors influence how long patching takes:

Vulnerability Severity: Critical vulnerabilities (CVSS 9.0+) receiving public attention get faster patches than low-severity issues. A critical remote code execution in widely used software might be patched in days, while a low-impact issue might take months or never be patched.

Vulnerability Exploitability: If exploits are publicly available or actively being used, vendors prioritize patches. A theoretical vulnerability with no known exploit takes longer than one being weaponized by attackers.

Affected Product Popularity: Widely used products (Windows, Chrome, Apache Tomcat) receive faster patches because the impact affects millions of systems. Niche software might not be patched for months.

Active Support Status: Products in active support receive faster patches than legacy or unsupported versions. Windows 10 in active support receives patches faster than Windows 7 (which is no longer supported).

Vulnerability Complexity: Simple vulnerabilities might be patched quickly; complex issues requiring extensive code changes take longer. A one-line fix might be patched in days; a change requiring architectural redesign might take months.

Vendor Resources: Well-resourced vendors (Microsoft, Apple, Google) respond faster than small vendors or open-source projects with limited maintainers.

Vendor Business Model: Subscription-based vendors might prioritize support for paying customers. Open-source projects depend on volunteer efforts.

Real-World Examples

Log4Shell (CVE-2021-44228): Critical Apache Log4j vulnerability.

• Discovery: Early November 2021 (approximate)
• Public disclosure: December 9, 2021
• First patch: December 10, 2021 (next day)
• Timeline: Near-instantaneous response due to severity and widespread use
• Impact: Despite rapid patch availability, exploitation was widespread because many organizations couldn't deploy patches immediately

Heartbleed (CVE-2014-0160): Critical OpenSSL vulnerability.

• Discovery: Late 2013
• Disclosure: April 7, 2014
• Patch: Same day as disclosure (April 7, 2014)
• Timeline: Extremely rapid response due to severity
• Impact: Despite same-day patching, millions of systems remained vulnerable for months

Equifax Data Breach (Apache Struts vulnerability, CVE-2017-5645):

• Vulnerability disclosure: July 2017
• Patch availability: August 2017
• Equifax compromised: Before they deployed the patch
• Timeline: Patch available within weeks, but wasn't applied before breach
• Lesson: Patch availability doesn't equal patching; organizations must deploy patches

Windows Zero-Day vulnerabilities:

• Discovery: Often unknown until exploitation begins
• Public disclosure: When Microsoft learns of active exploitation
• Patch timeline: Sometimes days, sometimes weeks
• Example: ProxyLogon (CVE-2021-27065) was patched in March 2021 after exploitation was discovered

The Patch Deployment Gap

Just because a patch is available doesn't mean organizations deploy it immediately. There's typically a significant gap between patch availability and deployment:

Typical deployment timeline:

• Day 0: Patch released
• Days 1-3: Security teams assess patch compatibility and criticality
• Days 3-7: Patch is tested in non-production environments
• Days 7-14: Patch is deployed to less critical systems
• Days 14-30: Patch is deployed to production systems
• Days 30-60: Legacy or non-compliant systems still unpatched

For critical vulnerabilities:

• Organizations with strong patch management: Deployment within 3-7 days
• Average organizations: Deployment within 2-4 weeks
• Organizations with poor patch management: Months or never

This deployment gap means the window of vulnerability extends far beyond patch availability.

Vulnerability Window Duration

The complete vulnerability window has multiple phases:

Phase 1: Pre-disclosure vulnerability window (unknown duration)

• Vulnerability exists but isn't widely known
• Attackers might discover and exploit it privately
• Timeline: Could be days to years

Phase 2: Coordinated disclosure and patch development (0-90+ days)

• Vulnerability is known to researchers and vendor but not public
• Vendor develops patch
• Timeline: Usually 30-90 days if coordinated well

Phase 3: Public disclosure but pre-patch (rare, 0-14 days)

• Vulnerability is public but patch isn't available yet
• Timeline: Usually avoided through coordinated disclosure

Phase 4: Patch available but pre-deployment (7-60+ days)

• Patch exists but many organizations haven't deployed it
• Most dangerous phase—vulnerability is public and patches are available, but exploitation is widespread
• Timeline: Often 30-90 days for average organizations

Phase 5: Patch deployed (ongoing monitoring)

• Organizations deploy patch and vulnerability is addressed
• However, some systems never get patched (legacy, EOL, etc.)

Strategies for Reducing Time-to-Patch

Organizations can reduce their vulnerability window:

Rapid response procedures:

• Have documented procedures for evaluating and deploying patches
• Establish SLAs for critical vulnerabilities (e.g., deploy within 7 days)
• Pre-arrange downtime windows for emergency patching if needed

Automated patching:

• Enable automatic security updates for operating systems
• Implement automated deployment of patches in production (with testing)
• Use containerization to enable rapid replacement of vulnerable containers

Risk prioritization:

• Focus on critical vulnerabilities in critical systems first
• Defer non-critical patches to scheduled maintenance
• Accept risk on non-vulnerable systems even if patches are available

Monitoring for exploits:

• Track whether vulnerabilities are being actively exploited
• Implement mitigations (WAF rules, network segmentation) for vulnerable systems while patch is being tested

Vendor management:

• Include patch response requirements in vendor contracts
• Understand support timelines for the software you use
• Plan for migration from unsupported products

Unpatched Vulnerabilities

Some vulnerabilities never receive patches:

• Abandoned/EOL software: No longer supported vendors
• Legacy systems: Can't be updated without breaking business processes
• Expensive migrations: Fixing would require complete system replacement
• No viable patch: Sometimes no patch exists; only workarounds or compensating controls

For unpatched vulnerabilities:

• Implement compensating controls (WAF for web app vulnerabilities, network segmentation)
• Increase monitoring for exploitation attempts
• Accept documented risk
• Plan for eventual system replacement

Conclusion

The time-to-patch varies from same-day patches for critical, high-profile vulnerabilities to never for abandoned software. Most patches are available within 30-90 days of disclosure. However, the critical vulnerability window isn't just about patch development time—organizations typically take 2-4 weeks to deploy patches after availability. For maximum security, organizations should maintain current asset inventory, establish patch deployment SLAs, monitor for actively exploited vulnerabilities, and prioritize rapid deployment of critical patches. Understanding patch timelines for the software in your environment helps you plan effective vulnerability response and assess your risk exposure.