How We Triage Three Critical Vulnerabilities in One Week

The week of May 12, 2026, dropped a Netlogon RCE on domain controllers, an actively exploited cPanel authentication bypass, six Office Preview Pane zero-days, and a memory corruption flaw in NGINX that attackers were already using in the wild. That’s not a normal week. That’s a week where your IT provider’s triage process either holds up or falls apart.

We patched every affected client environment across all four vulnerability families within the priority windows our framework dictates. This post walks through how we actually made those decisions, what got patched first and why, and what the communication looked like from the client’s side.

What Dropped and Why It Matters

Four distinct vulnerability families landed within days of each other. Each one, on its own, would be a significant event for any IT team. Together, they forced hard choices about sequencing.

CVE-2026-41089: Netlogon RCE (CVSS 9.8). A buffer overflow in the Windows Netlogon Remote Protocol that gives an attacker SYSTEM-level access to domain controllers. Every Windows Server version since 2012 is affected. Domain controllers manage authentication, group policy, and access control for the entire network. Compromise here means the attacker owns everything.

CVE-2026-41940: cPanel Authentication Bypass (CVSS 9.1). An authentication bypass in cPanel/WHM that lets unauthenticated attackers gain administrative access to hosting environments. Multiple threat actors were actively exploiting this before many hosting providers had even reviewed the advisory.

Six Office Preview Pane Zero-Days (CVSS 7.8-8.8). A cluster of remote code execution vulnerabilities triggered by previewing malicious files in Outlook or Windows Explorer. No click required beyond selecting a file. Microsoft confirmed active exploitation for several of these through the May Patch Tuesday disclosure.

CVE-2026-42945: NGINX Memory Corruption (CVSS 8.1). A memory corruption flaw in NGINX’s HTTP/2 handling, confirmed under active exploitation. Affects any public-facing application running behind NGINX.

Any one of these alone triggers our escalation process. All four in the same week turns the conversation from “patch this” to “patch this first, then this, then this, and explain to 40+ client organizations why we made those choices.”

The Triage Framework: CVSS Is Just the Starting Point

CVSS scores are a useful baseline, but they don’t tell you what to patch first. A CVSS 9.8 vulnerability with no public exploit and limited client exposure can wait a few hours behind a CVSS 8.1 that’s being mass-exploited against infrastructure you know your clients run.

Our triage framework evaluates four factors in order:

1. Exploit availability. Is there active exploitation in the wild? Is proof-of-concept code public? A vulnerability with confirmed exploitation moves to the front of the line regardless of its CVSS score.
2. Client exposure. How many of our managed environments run the affected software? A critical flaw in software none of our clients use is a monitoring note, not an emergency. Domain controllers, on the other hand, exist in every single client environment with Active Directory.
3. Blast radius. What happens if this vulnerability is exploited? Domain controller compromise gives the attacker access to the entire network. An Office Preview Pane exploit compromises one workstation. Both are bad, but the scope of damage is fundamentally different.
4. Mitigation options. Can we reduce exposure before the patch deploys? EDR rules, firewall signatures, and email filtering can buy time for some vulnerability types. Others have no effective mitigation short of the patch itself.

Applying this framework to the May cluster produced a clear priority order, even though the CVSS scores alone might suggest a different sequence.

Why Netlogon Gets Patched Before Office Preview Pane

Both vulnerability families came from the same May Patch Tuesday release. The Office zero-days had confirmed active exploitation. The Netlogon RCE did not, at least not publicly, at the time of disclosure. On a surface reading, you’d patch the one already being exploited first.

We patched Netlogon first. Here’s why.

Blast radius wins the tiebreaker. A compromised domain controller gives attackers SYSTEM-level access to the authentication backbone of the entire network. From there, they can create admin accounts, push malicious group policy, access every file share, and disable security tooling across every connected endpoint. One successful exploit equals total network compromise. An Office Preview Pane exploit compromises a single workstation, which is serious but containable.

Mitigation availability matters. The Office Preview Pane vulnerabilities can be partially mitigated. Our email security tools block malicious attachments before they reach the inbox. EDR detects exploitation attempts on the endpoint. These layers don’t eliminate the risk, but they reduce the exposure window to something manageable. Netlogon, by contrast, has limited effective mitigation. The domain controller either has the patch or it doesn’t.

Exploitation timeline is predictable. When a CVSS 9.8 RCE targeting domain controllers gets disclosed with full technical details in a Patch Tuesday release, exploit development follows quickly. Attackers reverse-engineer the patch diff to build working exploits. The window between “no known exploitation” and “active exploitation” for a vulnerability this valuable is days, not weeks.

The final triage order for the week:

1. CVE-2026-41089 (Netlogon) patched within hours of the Tuesday release
2. CVE-2026-41940 (cPanel) patched within the same cycle for affected clients, with log review for compromise indicators
3. Office Preview Pane cluster patched within standard critical window, with email filtering and EDR providing interim protection
4. CVE-2026-42945 (NGINX) patched on affected web infrastructure, coordinated with application teams to avoid downtime

Client Communication: Emergency vs. Standard Cycle

Not every critical vulnerability warrants an emergency notification. Sending urgent alerts for every CVSS 9.0+ disclosure trains clients to ignore them, which is exactly the wrong outcome when something truly dangerous arrives.

Our communication strategy uses two tracks:

Emergency notification goes out when three conditions are met: the vulnerability is being actively exploited, client environments are confirmed affected, and the blast radius is severe. The cPanel authentication bypass triggered this track because exploitation was already widespread and clients with hosting infrastructure were directly exposed. Emergency notifications include a plain-language description of the risk, confirmation that we’re deploying patches, and a timeline for completion.

Standard critical cycle communication covers vulnerabilities that are severe but where interim mitigations are in place and the patch deployment follows our normal rapid cadence. The Office Preview Pane zero-days fell into this category. Clients received updates through our ticketing system confirming the patch deployment schedule and the interim protections active in their environment.

In both cases, the communication goes out during the response, not after. Clients know what’s happening while it’s happening. They don’t get a “your systems have been updated” email three days later with no context about what the risk was or what we did about it.

Patch Available Is Not Patch Deployed

This is the gap that trips up organizations without a structured patching process. Microsoft releases a patch on Tuesday morning. When is your environment actually protected?

The answer depends on several steps that happen between “vendor publishes fix” and “every affected system in your environment is running the patched version.”

Testing. Critical patches for domain controllers and production servers get validated against representative systems before broad deployment. We’ve seen patches that fix the vulnerability but break a line-of-business application, or patches that require a specific installation order to apply correctly. Pushing an untested patch to every domain controller simultaneously is its own kind of risk.

Staged deployment. Patches deploy in waves. Test systems first, then non-critical servers, then production infrastructure. For the Netlogon patch, the window between testing and full deployment was compressed to hours because the risk justified the urgency, but the stages still happened.

Verification. After deployment, our RMM platform confirms that every affected system reports the patched version. Systems that failed to update get flagged for manual follow-up. A pending reboot, a software conflict, or a connectivity issue can all prevent a patch from completing. “We pushed the patch” is not the same as “the patch is installed and the system is running the fixed version.”

Post-deployment monitoring. Our SOC watches for exploitation attempts during and after the patching window. For the cPanel vulnerability, we reviewed logs going back several weeks to determine whether any client environments had been compromised before the patch was available. That retroactive analysis is just as important as the forward-looking patch deployment.

The total cycle from “advisory published” to “every affected system verified patched and monitored” can range from hours for the most critical items to a few days for lower-priority vulnerabilities in the same cluster. The point is that every step exists, every step is tracked, and nothing falls through the cracks because someone assumed “it probably installed fine.”

What This Week Looks Like Without an MSP

A business managing IT internally or working with a break-fix provider faces a very different version of this week.

The internal IT admin sees the May Patch Tuesday release and its 138 fixes. They need to figure out which of those 138 apply to their environment, which ones are critical, and what order to deploy them. That analysis alone takes time they probably don’t have, because they’re also handling help desk tickets, managing a cloud migration, and troubleshooting a printer issue.

Meanwhile, the cPanel advisory drops separately. If they don’t subscribe to the right feeds or follow the right sources, they might not see it for days. The NGINX disclosure comes from yet another vendor on yet another channel. Each vulnerability requires separate research, separate testing, and separate deployment.

There’s no SOC providing interim protection while patches are tested. There’s no automated asset inventory that instantly identifies every affected system. There’s no staged deployment process with verification scans. There’s no retroactive log analysis to check for pre-patch compromise.

The result is that some of these patches get applied within a reasonable window, some take weeks, and some get missed entirely. According to the Verizon 2025 Data Breach Investigations Report, exploitation of vulnerabilities as an initial access method increased 34% year over year. The businesses that get breached through known, patched vulnerabilities aren’t typically the ones that decided not to patch. They’re the ones that meant to patch but didn’t have a process that ensured it actually happened.

Our vulnerability response process exists specifically to close that gap. Every advisory gets triaged. Every affected system gets identified. Every patch gets deployed, verified, and monitored. That’s what managed security means in practice.