A CVE drops with a CVSS score of 9.8. Your monitoring screams. Marketing wants uptime. Security wants it patched yesterday. You're stuck in the middle wondering: do I patch right now or can this wait until the maintenance window?
I've handled enough emergency patching cycles to know the answer is never simple. CVSS scores give you a number, not a timeline. The real question is whether attackers are actively exploiting the vulnerability and whether your specific configuration is exposed.
What CVSS actually tells you
CVSS scores measure theoretical severity on a 0-10 scale. A critical rating (9.0-10.0) means the vulnerability is easy to exploit, requires no authentication, and can lead to complete system compromise. High scores grab headlines.
But they don't account for whether exploits exist in the wild, whether your firewall blocks the attack vector, or whether the vulnerable service is even running. A 9.8 OpenSSH bug matters if you expose SSH to the internet. It matters less if you only allow access through a VPN and enforce key-based auth.
The metrics inside a CVSS score:
- Attack Vector (AV): Network, adjacent, local, or physical
- Attack Complexity (AC): Low or high
- Privileges Required (PR): None, low, or high
- User Interaction (UI): None or required
- Scope (S): Unchanged or changed
- Impact (CIA): Confidentiality, integrity, availability
A network-accessible RCE with no authentication required and low complexity will always score critical. That doesn't mean every server running that software is about to be compromised.
Exploit timelines move faster than patch cycles
The clock starts when a CVE goes public, not when you hear about it. Attackers monitor security mailing lists and GitHub commits. Mass scanning for vulnerable endpoints begins within hours for high-profile bugs.
I've watched attack traffic spike 6-12 hours after disclosure for remotely exploitable flaws in popular software. By day two, automated tooling is usually available. By day three, script kiddies are running scans.
Zero-day exploits skip the disclosure step entirely. You find out when logs show unusual traffic or a breach is already underway. These are rare but devastating.
Most CVEs follow a predictable timeline:
- Day 0: Public disclosure, patches available (if you're lucky)
- Hours 1-12: Security researchers verify, POC code appears
- Day 1-2: Mass scanning begins, early exploitation attempts
- Day 3-7: Exploit frameworks add modules, broad exploitation
- Week 2+: Worm variants, automated attacks become background noise
Your patching window sits somewhere in that first 72 hours if the vulnerability is remotely exploitable and affects internet-facing services.
Realistic SLAs for production environments
Organizations love to publish strict patching policies: critical vulnerabilities within 24 hours, high within 7 days, medium within 30. Reality is messier.
Patching a WordPress plugin on a single site takes minutes. Patching glibc across 200 production servers with 99.9% uptime SLAs takes planning, testing, and maintenance windows. You can't reboot everything instantly without breaking things.
Here's what actually works in hosting environments:
Remotely exploitable RCE, active exploitation, internet-facing: Patch or mitigate within 4-24 hours. This is your drop-everything scenario. If a proof-of-concept exists and the service is exposed, you're in a race. Apply the patch in staging, verify it doesn't break critical functionality, then roll it out. If patching takes longer than a few hours, add a firewall rule or take the service offline temporarily.
Remotely exploitable, no active exploitation, internet-facing: Patch within 48-72 hours. You have slightly more time to test. Still urgent, but you can schedule an off-hours maintenance window instead of waking the entire team at 2 AM. Monitor for scanning activity while you prepare.
Authentication required or non-network attack vector: Patch within 7 days. These still matter—privilege escalation bugs let attackers move laterally after initial access—but they're not immediate apocalypse material. Follow your normal change management process.
Local exploit, requires existing access: Patch within 14-30 days during regular maintenance. Important for defense in depth, but not an emergency unless you're already dealing with a breach.
These timelines assume patches are available and stable. If the vendor hasn't released a fix yet, your options narrow to mitigation and monitoring.
When to patch immediately vs. schedule maintenance
Does the vulnerability affect a service you expose to the internet? Check what's actually listening:
ss -tlnp | grep LISTEN
If the vulnerable port isn't in that list, you have more breathing room. A kernel bug that requires local access is less urgent when you enforce SSH keys and disable password auth.
Is active exploitation happening? Check for:
- Published exploits on GitHub or exploit-db
- Mentions of mass scanning on Twitter/security forums
- Your own logs showing unusual traffic patterns
- CISA KEV (Known Exploited Vulnerabilities) catalog inclusion
If attackers are already weaponizing the CVE, patch fast or block the attack vector now. Add a firewall rule while you test the update:
# Block external access to vulnerable service temporarily
iptables -I INPUT -p tcp --dport 8080 -s ! 10.0.0.0/8 -j DROP
Can you test the patch safely? Spin up a staging environment that mirrors production. Apply the update, run automated tests, check application functionality. If the patch breaks something, you need time to troubleshoot or wait for a fixed version.
Some patches are worse than the bug. I've seen kernel updates that panicked systems on boot and PHP security releases that broke session handling. Test before you push to production, even under time pressure.
What's your rollback plan? Document the current package version, have backups ready, know how to downgrade if the patch causes outages. Blindly updating without a safety net is how small security issues become major incidents.
Mitigation when patches aren't ready
Vendors don't always ship fixes immediately. Open source projects might take days to prepare a stable release. Commercial software vendors sometimes take weeks.
You can't leave vulnerable services exposed while you wait. Temporary mitigations buy time:
Firewall rules — Block access to the vulnerable service from untrusted networks. If only internal apps need it, restrict to private IPs.
WAF rules — Web application firewalls can block specific exploit patterns while you wait for patches. Cloudflare, ModSecurity, and cloud provider WAFs often push rules quickly for high-profile CVEs.
Disable the feature — If the vulnerability is in an optional module or rarely-used functionality, turn it off. Nobody needs SMTP VRFY enabled anyway.
Service isolation — Move the vulnerable service behind a VPN or authentication proxy. Eliminates the unauthenticated remote attack vector even if the underlying bug remains.
Monitoring and alerting — Set up detection for exploitation attempts. Won't stop an attack, but you'll know immediately if someone tries it:
# Watch for suspicious patterns in logs
tail -f /var/log/apache2/access.log | grep -E 'pattern|from|exploit'
Mitigation isn't a permanent fix. It reduces risk while you prepare proper patching. Keep the mitigation in place until the update is deployed and verified.
Building a patching workflow that doesn't break things
Ad-hoc emergency patching creates chaos. You need a process that handles both planned updates and critical surprises.
-
Subscribe to security advisories for every piece of software you run. Vendor mailing lists, distro security feeds, GitHub security alerts. Find out about CVEs when they're announced, not when someone posts "are you vulnerable to X" in a forum.
-
Maintain an accurate inventory of what you're running and where. You can't patch what you don't know exists. Track versions, dependencies, and which servers run which services.
-
Classify your assets by exposure and criticality. Internet-facing production systems get patched faster than internal dev boxes. Customer data stores get more attention than log aggregators.
-
Test in non-production first, even for emergency patches. Break one staging server instead of 50 production ones.
-
Automate where possible. Use configuration management (Ansible, Puppet, Chef) to push updates consistently. Reduces human error when you're moving fast.
-
Monitor for issues post-patch. Check error logs, application metrics, and user reports after deploying updates. Catch problems before they cascade.
-
Document what you did and when. Track patch dates, what was updated, and any issues encountered. Useful for compliance, troubleshooting, and training.
Emergency patches will still happen. A solid workflow means they're controlled chaos instead of complete panic.
What matters more than the score
CVSS scores are a starting point, not a decision. A 9.8 that requires local access is less urgent than an 8.1 with active internet exploitation. Check what's actually exposed, whether exploits exist, and how fast you can test and deploy.
Patch internet-facing critical vulnerabilities within hours if exploitation is happening. Everything else gets a realistic timeline based on your testing capability and change management process. Speed matters, but stability matters more—breaking production while rushing a patch helps nobody.
Monitor your attack surface, keep software current, and have a plan before the next CVE drops. Because it will.