Microsoft’s November 2 vulnerability research makes a practical case for changing the order of the patch queue: start with weaknesses that can give an attacker control of a reachable system, then assess the identities and resources that system can reach. For small businesses and government contractors, the objective is not merely to close the largest number of findings. It is to interrupt the shortest credible route to consequential access.
This is newly published analysis of historical vulnerability and exploitation data, not a newly disclosed vulnerability or a warning that every system in the study is currently under attack.
What the research found
In its original report, Microsoft analyzes CVEs published through September 2026 using its tracked-vulnerability catalog. It assigns each vulnerability its most consequential directly enabled impact and also examines affected platforms. A vulnerability can appear across multiple platforms, so those platform counts should not be treated as independent vulnerabilities.
Microsoft reports that server-side remote code execution accounts for 20% of the published CVE population but 37% of the exploited subset. Local privilege escalation rises from 11% to 18%, while client-side remote code execution rises from 4% to 13%. These are distributions in Microsoft’s analysis, not the probability that a particular finding on your network will be exploited.
The other important finding concerns remediation delay. Microsoft says its 2026 Security Exposure Management data shows median patching at about two weeks on Windows workstations, more than a month on Windows Servers, more than ten weeks on Linux Servers, and beyond a year on network appliances. Those observations describe the vendor’s dataset; they are not a recommended maintenance schedule or proof that every organization has the same delays.
Why exposure changes the decision
A remotely exploitable server with a broadly privileged service account presents a different business risk from an isolated test system with no sensitive access. Microsoft emphasizes that permissions, identities and trusted connections determine how an initial foothold can expand. A server does not need to store the most valuable data locally to become the route to it.
For a contractor, that means identifying which exposed applications can reach contract documents, administrative systems, deployment credentials or customer environments. This is a planning priority, not a claim that Microsoft documented a breach of those resources in this report.
A practical queue for lean teams
- Establish what is actually reachable. Reconcile vulnerability findings with internet-facing services, remote-access paths and vendor-managed equipment. Identify the owner and the running workload rather than relying on an asset name in an old spreadsheet.
- Put demonstrated exploitation and takeover impact into context. Give particular scrutiny to reachable remote-code-execution and authentication-bypass paths, and to privilege-escalation weaknesses that can complete a plausible intrusion chain. Use current vendor evidence and known-exploitation information; a proof of concept alone does not establish attacks in the wild.
- Map the authority behind the host. Review service accounts, cloud roles, stored secrets and trusted network routes. Remove unnecessary privileges and connectivity so one unpatched service cannot become an administrative bridge.
- Assign interim controls and an expiration date. Where patching needs a maintenance window, restrict access or disable the affected feature when vendor guidance supports it. Record what the control does not cover, who owns the exception and when it will be reviewed. Unsupported equipment needs a replacement decision, not an indefinite exception.
- Verify the deployed fix. Confirm the correct package or firmware is running on the affected asset and that required service restarts occurred. A completed change ticket or a patch downloaded to a management console is not sufficient evidence of remediation.
Do not turn prioritization into permission to ignore the rest
Microsoft explicitly notes that denial of service can be severe on availability-critical systems, and that disclosure of credentials can feed a much larger intrusion. Lower aggregate exploitation frequency does not make those findings harmless. Keep contractual obligations, supported-product guidance and operational consequences in the decision.
The catalog is also an observation set, not complete visibility into every attack. Lack of recorded exploitation does not establish safety. Avoid treating a population-level percentage as a reason to leave an individual exposed system unpatched.
Bulwark assessment
The useful unit of work is an attack path, not a CVE count. Pair urgent remediation with a review of the permissions and connections that make the affected asset valuable. Measure whether the reachable vulnerable service was fixed and its downstream authority reduced—not just whether the scanner’s total went down.
Original source: Microsoft Security Research, Yair Tsarfaty and Or Begam: What exploited vulnerabilities have in common, November 2, 2026.