Microsoft disclosed CVE-2026-40402 on May 12, 2026, as a Critical Windows Hyper-V elevation-of-privilege vulnerability in its May Patch Tuesday release, describing a use-after-free flaw that can let an attacker in a guest virtual machine gain SYSTEM privileges on the Hyper-V host. The vulnerability is not merely another local privilege escalation buried in the monthly Windows pile; it sits at the boundary that makes virtualization worth trusting. Microsoft says the flaw was not publicly disclosed and was not known to be exploited when the update shipped, but its CVSS 9.3 rating tells administrators what matters most: if the guest-to-host wall cracks, the blast radius changes.
Hyper-V is not just another Windows feature. It is the layer Microsoft asks customers to trust for server consolidation, developer sandboxes, test labs, virtual desktop infrastructure, security features, and in many environments, workload separation between systems that should never fully trust one another.
That is why CVE-2026-40402 lands differently from a desktop-only privilege bug. A normal local elevation-of-privilege vulnerability usually assumes the attacker already has code running on the affected machine and wants to become more powerful there. A Hyper-V elevation flaw can begin inside a guest VM and, if successfully exploited, pressure the host itself.
The technical description now circulating is concise but serious: a use-after-free condition in Windows Hyper-V can allow a guest VM to force the Hyper-V host kernel to read from an arbitrary, potentially invalid address. That class of memory-safety issue is familiar to exploit developers because it often turns stale object references into footholds for corruption, disclosure, or control-flow manipulation, depending on the exact code path.
Microsoft’s public posture is simultaneously calming and urgent. The company’s exploitability notes reportedly place public disclosure and observed exploitation at “No,” with exploit code maturity listed as unproven and exploitation assessed as less likely. But “less likely” is not “low impact,” and “unproven” is not “impossible.” It means defenders get a window, not a waiver.
For CVE-2026-40402, the high score reflects the security boundary at stake. Hypervisor escapes are among the more consequential virtualization failures because the host is supposed to be the root of trust for every guest workload it manages. If an attacker can move from guest to host, the result may be SYSTEM-level access in the place administrators least want to lose control.
The distinction matters for patch prioritization. A remote DNS or Netlogon code execution bug may deserve faster internet-facing triage because it can be reached over a network without prior placement. But a Hyper-V guest-to-host elevation bug deserves special attention in environments where guests are numerous, semi-trusted, externally supplied, developer-managed, or used as detonation and testing sandboxes.
The monthly patch calculus is therefore not “Critical beats Important” or “remote beats local” in every case. It is: where is the security boundary, who can reach it, and what happens if that boundary fails? In Hyper-V, that answer can be uncomfortable.
That ambiguity is the real operational problem. Hyper-V is often used precisely because organizations want to run workloads without fully trusting them. The host is supposed to enforce that bargain. CVE-2026-40402 asks administrators to revisit which environments actually depend on that separation.
The most obvious high-risk systems are multi-tenant Hyper-V hosts, lab clusters that run unknown images, virtual desktop pools, build farms, and any environment where users can create or import VMs without the same level of scrutiny applied to host administrators. A single-purpose host running a handful of tightly managed line-of-business servers is still affected, but the attacker’s path to a guest is narrower.
That does not make the flaw academic. Virtualization bugs have a long tail because estate owners routinely underestimate how many machines have Hyper-V components enabled or how many endpoints rely on virtualization-adjacent Windows security features. Inventory, not fear, is the first useful reaction.
That restraint is defensible. Publishing a more complete trigger path on Patch Tuesday would help defenders understand exposure, but it would also help attackers compare binaries, diff the update, and test exploitability. The early period after a patch is when many organizations are most vulnerable because the fix is public but deployment is incomplete.
Still, the thinness of the detail has consequences. Security teams must decide whether to emergency-patch hosts without knowing whether the bug requires a specific VM configuration, device assignment, synthetic device path, integration service, or guest behavior. That uncertainty pushes mature organizations toward compensating controls and prioritization based on exposure rather than waiting for perfect clarity.
This is where Microsoft’s exploitability metrics matter. They are not guarantees; they are estimates. In this case, the reported “not exploited,” “not publicly disclosed,” and “unproven exploit code” signals should prevent panic. They should not delay patching on hosts where untrusted or loosely trusted guests run.
That accounting dispute is less important than the pattern. The headline-grabbing items in May include remote code execution possibilities in foundational services and collaboration-adjacent products. A Hyper-V privilege boundary issue can disappear beneath those louder risks, especially when Microsoft has not observed exploitation.
For WindowsForum readers, that would be the wrong takeaway. Hyper-V is the kind of component that often matters most in places where downtime is hardest to schedule. Patching a Hyper-V host is not like updating a utility workstation. It may involve guest migration, maintenance windows, cluster-aware updating, backup coordination, and application owner approvals.
The operational friction is precisely why this bug should not be left to “we’ll get to it after the desktops.” Hypervisor patches require planning. If the host fleet is critical, the remediation plan needs to start before exploit chatter appears.
In a hypervisor context, the bug class becomes more interesting because guest-controlled inputs are constantly crossing into host-managed virtualization code. Hyper-V must emulate devices, manage memory mappings, broker hypercalls, handle synthetic hardware, and move data between trust domains at high speed. Every one of those transitions is an opportunity for a parser, state machine, or object lifetime assumption to go wrong.
That does not mean CVE-2026-40402 is easily exploitable. Microsoft’s “less likely” assessment suggests there may be constraints that make weaponization difficult. Attackers may need a carefully shaped guest environment, precise timing, knowledge of host builds, or a way to turn a read from an invalid address into reliable privilege escalation.
But difficult exploitation is not the same as low value. Hypervisor escape research has always attracted skilled actors because the payoff is unusually high. A bug that crosses a VM boundary is worth more work than a bug that merely crashes a service nobody exposes.
For many individual Windows enthusiasts, the likely exposure is a local lab, a few test VMs, maybe Windows Sandbox or development workloads. The sensible move is still to install the cumulative update, but the threat model is not the same as a hosting provider or enterprise VDI environment. The attacker first needs meaningful access to a VM that can interact with the vulnerable Hyper-V path.
For administrators, the question is sharper. Who can create VMs? Who can upload VHDX files? Are developers running unvetted images on shared hosts? Are security teams detonating unknown malware on Hyper-V infrastructure that also touches production networks? Are contractors or students given guest access in a way that assumes the host remains unreachable?
The boring inventory questions decide the risk. CVE-2026-40402 is not a reason to distrust virtualization wholesale. It is a reminder that virtualization is a security boundary only when the host is patched, the guest supply chain is controlled, and administrative delegation is not treated as harmless convenience.
CVE-2026-40402 should be read through the Windows update lens unless Microsoft states otherwise for a specific service. On-premises Hyper-V hosts, Windows Server systems with the Hyper-V role, and Windows client systems running Hyper-V-based workloads belong in the customer’s patch plan. The fact that Microsoft may patch its own infrastructure does not patch yours.
This is especially important for hybrid shops. The same organization may have Azure VMs, Azure Stack HCI, on-prem Hyper-V clusters, developer laptops, and lab hosts. Patch responsibility differs across those layers, and the existence of cloud automation can lull teams into assuming more of the estate is managed than actually is.
The fix path for most customers is ordinary but not trivial: apply the relevant May 2026 Windows security updates through Windows Update, Windows Server Update Services, Microsoft Configuration Manager, Intune, or whatever patch orchestration platform governs the host fleet. The hard part is not finding the patch. The hard part is sequencing it without breaking workloads.
Clustered environments have better options. Live migration, Cluster-Aware Updating, draining roles, and staged host patching can reduce disruption. But smaller shops often run Hyper-V as a pragmatic consolidation tool without the operational maturity of a full virtualization platform team. In those environments, patch urgency collides with limited redundancy.
CVE-2026-40402 should push teams to separate “we cannot patch today” from “we have not planned to patch.” Those are different failures. If a host cannot be rebooted quickly, administrators can still reduce exposure by tightening who can start or modify guests, pausing import of untrusted images, isolating lab workloads, and monitoring for unusual VM-to-host behavior.
None of those measures replaces the update. They are holding actions for the gap between disclosure and maintenance. The longer that gap lasts, the more the balance shifts toward the attacker, especially after reverse engineers have time to compare patched and unpatched Hyper-V binaries.
In this case, the confidence that CVE-2026-40402 exists is high because Microsoft has acknowledged and patched it. The confidence that it is operationally important is also high because the affected component is Hyper-V and the reported outcome is guest-to-host privilege elevation. The confidence that attackers can immediately weaponize it is lower, at least based on Microsoft’s release-time assessment.
That distinction is useful. It lets defenders avoid two bad habits: dismissing the vulnerability because exploit code is not public, or treating every Critical CVE as an active emergency with identical urgency. The right response is contextual urgency: patch Hyper-V hosts quickly, prioritize those running less trusted guests, and keep an eye on post-release research.
The metric also hints at attacker knowledge. When Microsoft says exploit code maturity is unproven, it is not saying nobody will figure it out. It is saying the known public technical base is limited at the time of publication. Patch diffing exists precisely to change that.
Most of the time, that border works. Hyper-V has matured into a core Windows platform component, not an exotic add-on. Microsoft uses virtualization not only for servers but also for security primitives such as virtualization-based security, credential isolation, and application containment.
That ubiquity cuts both ways. The more Windows leans on virtualization, the more valuable hypervisor bugs become. Attackers do not need every organization to run a public virtualization farm. They need enough high-value environments where a guest foothold is easier to obtain than host administrator access.
CVE-2026-40402 is therefore less a referendum on Hyper-V than a case study in platform concentration. When one layer becomes foundational, bugs in that layer inherit foundational importance.
For client systems, the calculus is simpler. Windows enthusiasts and developers using Hyper-V should install the May cumulative update through normal channels and avoid running untrusted VM images until patched. If a machine only has Hyper-V available but no guest workloads, the immediate practical risk is lower, though staying current remains the right answer.
For server administrators, the best move is to treat this as a host-fleet hygiene test. If you cannot quickly answer which systems run Hyper-V, who can create guests, and how fast hosts can be patched, CVE-2026-40402 has exposed a process weakness even before any exploit appears.
Security teams should also watch for follow-on research. The most useful information often arrives after Patch Tuesday: binary-diff notes, researcher write-ups, proof-of-concept claims, scanner signatures, and vendor-specific advisories. The absence of exploitation on May 12 is a snapshot, not a permanent condition.
Source: MSRC Security Update Guide - Microsoft Security Response Center
Hyper-V’s Promise Is Isolation, and This Bug Aims at the Promise
Hyper-V is not just another Windows feature. It is the layer Microsoft asks customers to trust for server consolidation, developer sandboxes, test labs, virtual desktop infrastructure, security features, and in many environments, workload separation between systems that should never fully trust one another.That is why CVE-2026-40402 lands differently from a desktop-only privilege bug. A normal local elevation-of-privilege vulnerability usually assumes the attacker already has code running on the affected machine and wants to become more powerful there. A Hyper-V elevation flaw can begin inside a guest VM and, if successfully exploited, pressure the host itself.
The technical description now circulating is concise but serious: a use-after-free condition in Windows Hyper-V can allow a guest VM to force the Hyper-V host kernel to read from an arbitrary, potentially invalid address. That class of memory-safety issue is familiar to exploit developers because it often turns stale object references into footholds for corruption, disclosure, or control-flow manipulation, depending on the exact code path.
Microsoft’s public posture is simultaneously calming and urgent. The company’s exploitability notes reportedly place public disclosure and observed exploitation at “No,” with exploit code maturity listed as unproven and exploitation assessed as less likely. But “less likely” is not “low impact,” and “unproven” is not “impossible.” It means defenders get a window, not a waiver.
The CVSS Number Is Doing More Than Signaling Severity
A 9.3 CVSS score for an elevation-of-privilege flaw can look odd to readers trained to reserve the highest numbers for wormable network bugs. That instinct is useful but incomplete. CVSS is not a vibes meter; it is trying to model conditions, privileges, user interaction, scope, and impact.For CVE-2026-40402, the high score reflects the security boundary at stake. Hypervisor escapes are among the more consequential virtualization failures because the host is supposed to be the root of trust for every guest workload it manages. If an attacker can move from guest to host, the result may be SYSTEM-level access in the place administrators least want to lose control.
The distinction matters for patch prioritization. A remote DNS or Netlogon code execution bug may deserve faster internet-facing triage because it can be reached over a network without prior placement. But a Hyper-V guest-to-host elevation bug deserves special attention in environments where guests are numerous, semi-trusted, externally supplied, developer-managed, or used as detonation and testing sandboxes.
The monthly patch calculus is therefore not “Critical beats Important” or “remote beats local” in every case. It is: where is the security boundary, who can reach it, and what happens if that boundary fails? In Hyper-V, that answer can be uncomfortable.
A Guest VM Is Not Always a Trusted VM
Administrators sometimes mentally categorize Hyper-V hosts as internal infrastructure and therefore less exposed than domain controllers or perimeter services. That can be true in simple estates, but modern virtualization makes the trust model messier. A “guest” might be a developer’s test image, a contractor-provided appliance, a restored backup, a malware-analysis sample, or a workload owned by a different team.That ambiguity is the real operational problem. Hyper-V is often used precisely because organizations want to run workloads without fully trusting them. The host is supposed to enforce that bargain. CVE-2026-40402 asks administrators to revisit which environments actually depend on that separation.
The most obvious high-risk systems are multi-tenant Hyper-V hosts, lab clusters that run unknown images, virtual desktop pools, build farms, and any environment where users can create or import VMs without the same level of scrutiny applied to host administrators. A single-purpose host running a handful of tightly managed line-of-business servers is still affected, but the attacker’s path to a guest is narrower.
That does not make the flaw academic. Virtualization bugs have a long tail because estate owners routinely underestimate how many machines have Hyper-V components enabled or how many endpoints rely on virtualization-adjacent Windows security features. Inventory, not fear, is the first useful reaction.
Microsoft’s Silence on Exploit Details Is a Feature and a Frustration
Microsoft’s Security Update Guide has become more structured over the years, but it is still designed for risk management rather than exploit education. For CVE-2026-40402, the public facts appear intentionally spare: Windows Hyper-V, elevation of privilege, use-after-free, guest-to-host implications, Critical severity, CVSS 9.3, and no known public exploitation at release.That restraint is defensible. Publishing a more complete trigger path on Patch Tuesday would help defenders understand exposure, but it would also help attackers compare binaries, diff the update, and test exploitability. The early period after a patch is when many organizations are most vulnerable because the fix is public but deployment is incomplete.
Still, the thinness of the detail has consequences. Security teams must decide whether to emergency-patch hosts without knowing whether the bug requires a specific VM configuration, device assignment, synthetic device path, integration service, or guest behavior. That uncertainty pushes mature organizations toward compensating controls and prioritization based on exposure rather than waiting for perfect clarity.
This is where Microsoft’s exploitability metrics matter. They are not guarantees; they are estimates. In this case, the reported “not exploited,” “not publicly disclosed,” and “unproven exploit code” signals should prevent panic. They should not delay patching on hosts where untrusted or loosely trusted guests run.
The Patch Tuesday Crowd Can Hide the One Bug Your Estate Actually Cares About
May 2026’s Patch Tuesday is crowded. Independent patch trackers counted a large Microsoft release, with SANS Internet Storm Center listing 137 Microsoft CVEs and a separate batch of Chromium-related Edge issues. Other summaries emphasized a smaller count depending on how they grouped Microsoft, Edge, and third-party-origin vulnerabilities.That accounting dispute is less important than the pattern. The headline-grabbing items in May include remote code execution possibilities in foundational services and collaboration-adjacent products. A Hyper-V privilege boundary issue can disappear beneath those louder risks, especially when Microsoft has not observed exploitation.
For WindowsForum readers, that would be the wrong takeaway. Hyper-V is the kind of component that often matters most in places where downtime is hardest to schedule. Patching a Hyper-V host is not like updating a utility workstation. It may involve guest migration, maintenance windows, cluster-aware updating, backup coordination, and application owner approvals.
The operational friction is precisely why this bug should not be left to “we’ll get to it after the desktops.” Hypervisor patches require planning. If the host fleet is critical, the remediation plan needs to start before exploit chatter appears.
Use-After-Free Is an Old Bug Class in a Modern Attack Surface
The phrase use-after-free sounds generic because it is. A program allocates memory, frees it, and later uses a stale reference as though the object still exists. The practical outcomes vary, but the attacker’s hope is usually to influence what occupies that freed memory next, then turn confusion into a controlled read, write, crash, or execution path.In a hypervisor context, the bug class becomes more interesting because guest-controlled inputs are constantly crossing into host-managed virtualization code. Hyper-V must emulate devices, manage memory mappings, broker hypercalls, handle synthetic hardware, and move data between trust domains at high speed. Every one of those transitions is an opportunity for a parser, state machine, or object lifetime assumption to go wrong.
That does not mean CVE-2026-40402 is easily exploitable. Microsoft’s “less likely” assessment suggests there may be constraints that make weaponization difficult. Attackers may need a carefully shaped guest environment, precise timing, knowledge of host builds, or a way to turn a read from an invalid address into reliable privilege escalation.
But difficult exploitation is not the same as low value. Hypervisor escape research has always attracted skilled actors because the payoff is unusually high. A bug that crosses a VM boundary is worth more work than a bug that merely crashes a service nobody exposes.
The Real Risk Is Not Every Laptop With Hyper-V Enabled
It is tempting to treat every Windows Pro or Enterprise machine with Hyper-V available as equally endangered. That overstates the practical risk. CVE-2026-40402 matters most where an attacker can already run code in a guest VM and where the host is valuable enough to justify the effort.For many individual Windows enthusiasts, the likely exposure is a local lab, a few test VMs, maybe Windows Sandbox or development workloads. The sensible move is still to install the cumulative update, but the threat model is not the same as a hosting provider or enterprise VDI environment. The attacker first needs meaningful access to a VM that can interact with the vulnerable Hyper-V path.
For administrators, the question is sharper. Who can create VMs? Who can upload VHDX files? Are developers running unvetted images on shared hosts? Are security teams detonating unknown malware on Hyper-V infrastructure that also touches production networks? Are contractors or students given guest access in a way that assumes the host remains unreachable?
The boring inventory questions decide the risk. CVE-2026-40402 is not a reason to distrust virtualization wholesale. It is a reminder that virtualization is a security boundary only when the host is patched, the guest supply chain is controlled, and administrative delegation is not treated as harmless convenience.
Azure, On-Prem, and the Uneven Geography of Hyper-V Exposure
Microsoft’s own cloud and hosted services complicate how customers interpret Hyper-V vulnerabilities. Hyper-V underpins major parts of Microsoft’s virtualization story, but not every customer-facing cloud exposure maps neatly onto an on-premises patch action. Some Azure-related vulnerabilities are marked “no customer action required” when Microsoft owns the service-side remediation.CVE-2026-40402 should be read through the Windows update lens unless Microsoft states otherwise for a specific service. On-premises Hyper-V hosts, Windows Server systems with the Hyper-V role, and Windows client systems running Hyper-V-based workloads belong in the customer’s patch plan. The fact that Microsoft may patch its own infrastructure does not patch yours.
This is especially important for hybrid shops. The same organization may have Azure VMs, Azure Stack HCI, on-prem Hyper-V clusters, developer laptops, and lab hosts. Patch responsibility differs across those layers, and the existence of cloud automation can lull teams into assuming more of the estate is managed than actually is.
The fix path for most customers is ordinary but not trivial: apply the relevant May 2026 Windows security updates through Windows Update, Windows Server Update Services, Microsoft Configuration Manager, Intune, or whatever patch orchestration platform governs the host fleet. The hard part is not finding the patch. The hard part is sequencing it without breaking workloads.
Host Patching Is Still a Change-Management Problem
Hyper-V administrators already know the unpleasant truth: the most security-sensitive machines are often the most politically difficult to reboot. Hosts carry other systems. A reboot is a negotiation with every application owner whose workload rides on that hardware.Clustered environments have better options. Live migration, Cluster-Aware Updating, draining roles, and staged host patching can reduce disruption. But smaller shops often run Hyper-V as a pragmatic consolidation tool without the operational maturity of a full virtualization platform team. In those environments, patch urgency collides with limited redundancy.
CVE-2026-40402 should push teams to separate “we cannot patch today” from “we have not planned to patch.” Those are different failures. If a host cannot be rebooted quickly, administrators can still reduce exposure by tightening who can start or modify guests, pausing import of untrusted images, isolating lab workloads, and monitoring for unusual VM-to-host behavior.
None of those measures replaces the update. They are holding actions for the gap between disclosure and maintenance. The longer that gap lasts, the more the balance shifts toward the attacker, especially after reverse engineers have time to compare patched and unpatched Hyper-V binaries.
The Confidence Metric Cuts Both Ways
The text attached to the CVE highlights a subtle but important point: confidence in a vulnerability is not the same thing as confidence in every technical detail surrounding it. Sometimes a vulnerability’s existence is known before its root cause is understood. Sometimes researchers infer the bug class from patch behavior. Sometimes the vendor confirms the issue but withholds exploitation mechanics.In this case, the confidence that CVE-2026-40402 exists is high because Microsoft has acknowledged and patched it. The confidence that it is operationally important is also high because the affected component is Hyper-V and the reported outcome is guest-to-host privilege elevation. The confidence that attackers can immediately weaponize it is lower, at least based on Microsoft’s release-time assessment.
That distinction is useful. It lets defenders avoid two bad habits: dismissing the vulnerability because exploit code is not public, or treating every Critical CVE as an active emergency with identical urgency. The right response is contextual urgency: patch Hyper-V hosts quickly, prioritize those running less trusted guests, and keep an eye on post-release research.
The metric also hints at attacker knowledge. When Microsoft says exploit code maturity is unproven, it is not saying nobody will figure it out. It is saying the known public technical base is limited at the time of publication. Patch diffing exists precisely to change that.
Security Boundaries Fail Quietly Before They Fail Loudly
A guest-to-host vulnerability is frightening because it undermines a clean diagram. In diagrams, the guest is boxed in, the host is outside reach, and the hypervisor is a firm border. In implementation, the border is thousands of code paths handling memory, interrupts, devices, scheduling, storage, networking, and management operations.Most of the time, that border works. Hyper-V has matured into a core Windows platform component, not an exotic add-on. Microsoft uses virtualization not only for servers but also for security primitives such as virtualization-based security, credential isolation, and application containment.
That ubiquity cuts both ways. The more Windows leans on virtualization, the more valuable hypervisor bugs become. Attackers do not need every organization to run a public virtualization farm. They need enough high-value environments where a guest foothold is easier to obtain than host administrator access.
CVE-2026-40402 is therefore less a referendum on Hyper-V than a case study in platform concentration. When one layer becomes foundational, bugs in that layer inherit foundational importance.
The May Patch Queue Needs a Hyper-V Lane
The practical remediation advice is not glamorous. Identify Hyper-V hosts. Confirm which ones are already covered by automatic patching and which are manually maintained. Prioritize hosts running untrusted, semi-trusted, or user-controlled VMs. Apply the May 2026 security updates. Reboot when required. Validate guest health afterward.For client systems, the calculus is simpler. Windows enthusiasts and developers using Hyper-V should install the May cumulative update through normal channels and avoid running untrusted VM images until patched. If a machine only has Hyper-V available but no guest workloads, the immediate practical risk is lower, though staying current remains the right answer.
For server administrators, the best move is to treat this as a host-fleet hygiene test. If you cannot quickly answer which systems run Hyper-V, who can create guests, and how fast hosts can be patched, CVE-2026-40402 has exposed a process weakness even before any exploit appears.
Security teams should also watch for follow-on research. The most useful information often arrives after Patch Tuesday: binary-diff notes, researcher write-ups, proof-of-concept claims, scanner signatures, and vendor-specific advisories. The absence of exploitation on May 12 is a snapshot, not a permanent condition.
The Guest-to-Host Warning Label Belongs on This Month’s Dashboard
This is the part of the May 2026 release that should survive the noise of the full CVE list: CVE-2026-40402 is not known to be exploited, but it targets a boundary administrators rely on heavily and rarely inspect closely. Treat it as a priority item for Hyper-V estates, not as background Patch Tuesday debris.- CVE-2026-40402 is a Critical Windows Hyper-V elevation-of-privilege vulnerability disclosed in Microsoft’s May 12, 2026 security updates.
- The reported bug class is use-after-free, with the concerning scenario being movement from a guest VM toward SYSTEM-level privileges on the host.
- Microsoft reportedly listed the vulnerability as not publicly disclosed and not exploited at release, with exploit code maturity unproven.
- The highest-risk environments are those running untrusted, semi-trusted, user-managed, or frequently changing guest virtual machines.
- The correct remediation path is to patch Hyper-V hosts promptly through the May 2026 Windows security updates and plan reboots with workload owners.
- Temporary risk reduction should focus on restricting VM creation, blocking untrusted image imports, isolating lab workloads, and accelerating host inventory.
Source: MSRC Security Update Guide - Microsoft Security Response Center
