How to address zero-day vulnerabilities

When a vendor ships a zero-day patch, the work is far from over. Log4Shell sat inside applications most teams hadn’t inventoried, and its first fix turned out to be incomplete. ToolShell repeated the pattern in 2025. For every IT department involved, the gap between “patch installed” and “exposure closed” is where a known flaw turns into one of your biggest IT issues.

The scale of the problem is real. Google Threat Intelligence Group tracked 75 zero-day vulnerabilities exploited in the wild in 2024, and 44% of them targeted enterprise technology.

Patching is essential, but in a good vulnerability management strategy it’s the final step of readiness, not the first. Here’s what should be in place before the next advisory lands, and how to respond when it does.

Why zero-day vulnerabilities break normal patch management strategies

A zero-day vulnerability is a software flaw that attackers can exploit before the vendor has released a fix. That single fact is what breaks the usual patching playbook.

Most patch programs run on a predictable rhythm where the vendor discloses a flaw, ships a fix, and your team tests and deploys it inside an agreed maintenance window. Each stage rests on the assumption that a fix exists to solve the problem, but that doesn’t really hold with a zero-day.

The terminology varies, but the main terms you’ll see include:

• Zero-day vulnerability: The flaw itself, either unknown to the vendor or known but not yet patched.
• Zero-day exploit: The code or technique that takes advantage of the flaw.
• Zero-day attack: An exploit used against a real target.

Until a fix ships, there’s nothing to deploy and no universal mitigation to fall back on. What works depends on the operating system, the software version, and how the flaw is exploited. A vulnerability technically stops being a zero-day once a patch is available, but the exposure doesn’t just end.

Every unpatched system is as vulnerable the day after release as the day before, and public disclosure tells every other attacker where to look. The window that matters to an IT team runs from first exploitation until a working fix is verified on every affected device.

The vulnerability isn’t always where you patch

Log4Shell (CVE-2021-44228) was publicly disclosed on December 9, 2021. It was a remote code execution flaw in Apache Log4j 2, a Java logging library, triggered through unsafe JNDI lookups when an application processed attacker-controlled input. It carried a CVSS 3.1 base score of 10.0, the maximum, and CISA added it to its Known Exploited Vulnerabilities Catalog the following day.

The problem for patching teams was that Log4j wasn’t an operating system component. It was packaged inside applications, sometimes in several copies at different versions on the same server, and every vendor that embedded it had its own remediation path.

The guidance also kept moving. Apache released Log4j 2.15.0 on December 10 as the initial correction, but CVE-2021-45046 showed that fix was incomplete under certain configurations, and 2.16.0 followed on December 13. Any team that closed out its response after the first update had to reopen it within days.

The first patch isn’t always the last

In July 2025, Microsoft patched two SharePoint Server vulnerabilities, CVE-2025-49704 and CVE-2025-49706. Within days, attackers were exploiting new variants that got around those fixes. The activity (known as ToolShell) was tracked as CVE-2025-53770 and CVE-2025-53771, and Microsoft had to issue emergency patches.

ToolShell exposed two gaps in standard patch logic:

• First, an installed update doesn’t prove the exploit path is closed: Servers that showed the original fixes as installed were still exposed to the variants.
• Second, a patch can stop further exploitation without removing access an attacker already has: Microsoft’s customer guidance went beyond installing updates, directing administrators to rotate SharePoint ASP.NET machine keys and restart IIS, since a compromised server can stay compromised after it’s patched.

Neither incident was a failure of patching tools, and both show why zero-day response can’t be measured by deployment status alone.

What zero-day readiness looks like

IT teams have to accept that they can’t stop a vendor from shipping a flawed product, and they won’t see most zero-days coming. So preventing zero-day attacks comes down to two things you do control: how much of your environment an attacker can reach, and how quickly your team can find, contain, and confirm exposure once a new flaw surfaces.

Teams that handle zero-days well typically have these four capabilities in place before an incident starts.

1: A smaller attack surface

Every zero-day needs a path to a vulnerable component. So the fewer paths you leave open, the fewer flaws can be exploited at all, and the less ground you have to cover when one is. Google Threat Intelligence Group’s defender guidance treats least-privilege access and network segmentation as a minimum standard rather than an advanced posture.

In practice, a reduced attack surface looks like this:

• Admin-only management interfaces: Firewalls, VPN gateways, hypervisors, and other appliances accept management connections only from a dedicated admin network, never the open internet
• Scoped service accounts: Each account can reach only the systems it runs on, so one compromised application can’t authenticate everywhere else.
• Hardening baselines: Unused services, ports, and features are disabled by default, enforced through tools like firewalld and SELinux on Red Hat Enterprise Linux or Group Policy on Windows.
• Segmentation: Internet-facing workloads are separated from internal systems, so an exploited web server isn’t a direct route to everything behind it.
• Restricted outbound traffic: Servers with no reason to initiate external connections can’t make them. Many Log4Shell exploitation attempts depended on vulnerable servers calling out to attacker-controlled infrastructure, which tight egress rules could have blocked.

» Learn how to simplify group policy management with Atera and safely pilot Conditional Access for privileged users

Capability 2: Visibility down to the component

Log4Shell showed that an operating system version tells you very little about exposure. Readiness means having an inventory that can answer three questions within the first hour of an advisory:

• Which software (and which versions) run on each system?
• Which systems are internet-facing or process untrusted input?
• Which ones are business-critical?

Those answers set the triage order. Externally accessible systems that handle attacker-controllable input come first, followed by business-critical workloads. CISA’s Known Exploited Vulnerabilities Catalog is a useful signal for which advisories need that treatment immediately, since inclusion means exploitation has been confirmed.

Atera’s asset and software inventory gives you the device and application layer across your whole fleet. Libraries bundled inside application archives, like Log4j JAR files, won’t appear in a standard installed-software list. Plan for that gap in advance by having a detection script you can run across selected devices when you need to search for a specific component.

Capability 3: Compensating controls you can prove

When no patch exists, a compensating control is only worth something if it interrupts the specific exploitation path. Here are some non-negotiables:

• Firewall rules that restrict access to the vulnerable service
• Disabling the vulnerable functionality itself, such as removing the JndiLookup class from affected Log4j versions
• Limiting exposed interfaces
• Isolating affected systems outright

Check any vendor-recommended mitigation against your exact OS and software version before you apply it.

Each of these controls carries a dependency risk. Restricting SSH access to a vulnerable server looks simple until you find out that scheduled file transfers, application integrations, and service accounts all run through the same connection. A control that breaks a payroll export can do as much damage as the exploit it was meant to stop.

Capability 4: A definition of “remediated” agreed in advance

The final piece of readiness is deciding what “fixed” means before an incident begins. When a zero-day hits, there’s pressure to close tickets as soon as deployment reports turn green, so agreeing on that standard ahead of time means nobody has to argue about it at 2 AM.

A defensible standard covers four checks:

• The installed version matches the vendor’s latest advisory, not the first one
• Every bundled copy of the vulnerable component has been addressed
• Critical services are healthy
• Any possible compromise has been investigated separately from the patch

How to respond from triage to fleet-wide patch

Readiness determines how fast you can move once a zero-day surfaces. The response determines whether you move in the right order. Here are the steps you should follow:

Step 1: Triage and contain in the first 24 hours

The first day is about establishing true exposure and buying time. Work through it in this order:

• Hours 0-2. Scope from the advisory: Read the original disclosure and every affected vendor’s advisory, then list the systems that could host the vulnerable component. Prioritize internet-facing and business-critical services. Don’t let OS version alone decide which systems are in or out.
• Hours 2-4. Confirm exposure at the component level: Check application dependencies, installed versions, and libraries bundled inside application archives. Separate components maintained by the original project from those embedded in other vendors’ products, since each will follow its own remediation path.
• Hours 4-8. Apply compensating controls: Where no update exists, apply controls that break the exploitation path, test each one directly, and check its dependencies before enforcing it.
• Hours 8-12. Validate and watch: Confirm that application startup, authentication, service dependencies, and critical transactions still work under the new controls. Review application logs and security monitoring for signs of exploitation attempts. On servers running several applications, check each one individually because fixing one bundled copy doesn’t fix the others.
• Hours 12-24. Document and prepare: Record what’s still exposed, re-verify temporary mitigations, and stage available vendor updates for the Test, UAT, and Production sequence. Check the advisories again before you stage anything.

Treat the response as open until the last advisory stops changing, not when the first update ships.

Step 2: Stress-test an emergency patch before you trust it

An emergency patch is a fast answer to a moving problem, so test it as though it might be incomplete. Your validation should prove that the exploit path is closed and that the system still works:

• Confirm the target: Match the affected product, build, and configuration against the vendor’s most recent advisory, and check for superseding updates, revised mitigations, or extra post-installation steps.
• Patch a canary that mirrors production: Use a representative test system with the same configuration, integrations, and dependencies as your live environment.
• Test function, not just installation: Cover startup, authentication, integrations, and the business transactions the system exists to run.
• Test the vulnerability itself: Run authenticated vulnerability scans and any vendor-provided verification method. Where it’s safe and authorized, reproduce the original exploit conditions in a controlled way to confirm the vulnerable behavior is gone.
• Investigate compromise separately: Check for web shells, unexpected accounts, and stolen credentials or keys. If you suspect exploitation, keep the system isolated until investigation and recovery are complete.

Step 3: Fast-track change control without skipping it

An actively exploited zero-day justifies compressing your CAB timeline without bypassing the stages that protect production. Approval can be accelerated if these three conditions are true:

• The vulnerability is actively exploited
• Affected systems are exposed
• Waiting for the standard cycle presents an unacceptable risk

Emergency authorization is still required, and the Test, UAT, and production sequence still applies. In production, deploy to a small set of representative hosts first. A canary passes only when:

• It has rebooted cleanly
• Critical services are healthy
• Core transactions have completed
• Infrastructure monitoring is reporting
• A recovery method has been confirmed

Only then does rollout continue to the next production group, with the same checks applied at each stage. If a patch starts causing failures, stop deployment immediately, assess whether the update can be safely reversed before reaching for a full restore, pick and validate your recovery point, then re-apply compensating controls.

Step 4: Automate the repeatable work and keep the judgment calls

Atera’s Patch Management turns a validated patch into consistent, tracked deployment across the fleet. The goal is to automate execution and keep engineers in control of risk.

Here’s what it can handle:

• Scoping across the fleet: Asset and software inventory shows which devices run the affected software. AI Copilot can generate a detection script from a plain-language description, such as searching application directories for vulnerable Log4j JAR files. You can then run that script across selected devices through remote scripting.
• Staged Windows deployment: Once a patch clears canary validation, automation profiles handle scheduled software deployment to each production group in turn. Patch approval keeps unvalidated updates out of the rollout.
• macOS updates: Atera installs these through the native macOS software update tool.
• Tracking progress: The patch management dashboard shows which devices are patched, pending, or failed, so stragglers don’t quietly stay exposed.

» Make sure you know the difference between automation and Autonomous IT

What to keep manual

• Routine schedules and deferred maintenance windows: These are built for predictable patch cycles and will hold an emergency fix back.
• Unattended fleet-wide deployment: Every production stage waits for its canary to pass before the next group goes out.
• Exploitability and control decisions: Choosing compensating controls, mapping dependencies, and coordinating high-risk restarts or cluster failovers all depend on knowledge of your environment that no patching engine has.
• Recovery and final verification: An installed status confirms deployment activity. Engineers confirm remediation.

» Don’t miss our guide to autonomous patch management

Verified fixes beat fast installs

Zero-days punish teams that measure success by what their tooling reports. Log4Shell and ToolShell both showed that a patch can install cleanly and still leave the exploit path open, or leave an attacker already inside. The response that holds up is the one that shrinks exposure before a disclosure, contains the flaw with controls that have been tested, and only calls a system fixed once the build, the services, and the compromise check all agree.

Atera Patch Management takes the repeatable half of that work off your plate. Asset inventory shows which devices are in scope, AI Copilot writes the detection scripts you’d otherwise build at 2 AM, and automation profiles carry a validated patch through each production group while the dashboard flags every device that falls behind.

» Learn more about vulnerability risk management or try Atera for free