How to Fix the Windows Speculative Execution Configuration Check (Nessus 132101, Qualys QID 91462)

The Windows Speculative Execution Configuration Check (Nessus plugin 132101) flags hosts where Spectre, Meltdown and related CPU side-channel mitigations are not active. To fix it, install current cumulative updates and CPU microcode, set FeatureSettingsOverride and FeatureSettingsOverrideMask under the Memory Management registry key as Microsoft KB4072698 describes, then restart the host.

What the scanner is actually detecting

This is a configuration finding, not a missing patch. Cumulative updates deliver the mitigation code, but on Windows Server several mitigations stay off until you opt in through the registry. KB4072698 lists the Spectre Variant 2 mitigation (CVE-2017-5715) as disabled by default on the Windows Server versions it covers, and Meltdown and several MDS mitigations as disabled by default on Windows Server 2016 and earlier. Windows 10 and 11 clients enable most of these, but Speculative Store Bypass protection (CVE-2018-3639) is off there too, according to KB4073119.

• Nessus: plugin 132101 is a credentialed local check. It reads the registry, Windows build and processor identifier to decide which mitigations should be on, covering Spectre, Meltdown, Rogue System Register Read, Speculative Store Bypass, L1 Terminal Fault, Microarchitectural Data Sampling (MDS) and TSX Asynchronous Abort (TAA).
• Qualys: reports the same condition as QID 91462 (ADV180012, SSB), QID 91426 (ADV180002, Spectre/Meltdown) and QID 91537 (ADV190013, MDS).

Real-world risk

Tenable rates plugin 132101 as Medium severity (CVSS v3 base 6.5) and notes that exploit code exists in commercial frameworks. Every one of these attacks needs the attacker to run code on the same physical processor: a local process, a guest VM on the same hypervisor, or a tenant on a shared host. They leak memory across privilege or VM boundaries; they do not give remote code execution on their own.

Hyper-V hosts, Remote Desktop Session Hosts, VDI pools and machines running code from untrusted users or tenants carry the real exposure. A single-purpose server running vetted software has much lower practical risk, but auditors still track the gap, so it belongs in your Windows Server hardening checklist baseline.

How to confirm it on the host

Read the current override values. “Unable to find the specified registry key or value” means no override is set and the OS defaults apply.

reg query "HKLMSYSTEMCurrentControlSetControlSession ManagerMemory Management" /v FeatureSettingsOverride
reg query "HKLMSYSTEMCurrentControlSetControlSession ManagerMemory Management" /v FeatureSettingsOverrideMask
reg query "HKLMSOFTWAREMicrosoftWindows NTCurrentVersionVirtualization" /v MinVmVersionForCpuBasedMitigations

Identify the CPU vendor, whether Hyper-Threading is active (more logical processors than cores means it is on) and whether Hyper-V is installed:

Get-CimInstance Win32_Processor | Select-Object Name, Manufacturer, NumberOfCores, NumberOfLogicalProcessors
Get-WindowsFeature Hyper-V                                          # Windows Server
Get-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V   # Windows 10/11

Then check the runtime state with Microsoft’s SpeculationControl module, which reports what the kernel is actually doing:

Install-Module SpeculationControl
$SaveExecutionPolicy = Get-ExecutionPolicy
Set-ExecutionPolicy RemoteSigned -Scope CurrentUser
Import-Module SpeculationControl
Get-SpeculationControlSettings
Set-ExecutionPolicy $SaveExecutionPolicy -Scope CurrentUser

Install-Module needs PowerShellGet, which ships with WMF 5.0/5.1. On Windows Server 2012/2012 R2 without WMF 5.1, or on hosts without internet access, download SpeculationControl.zip from https://aka.ms/SpeculationControlPS, extract it (for example to C:ADV180002), then run Import-Module .SpeculationControl.psd1 from the SpeculationControl folder (KB4072698 Method 2).

A WindowsSupportEnabled field (such as BTIWindowsSupportEnabled) reading False next to a True WindowsSupportPresent field means the update is installed but the mitigation is off. BTIHardwarePresent reading False means microcode is missing.

How to fix it

Step 1: updates and microcode

Install the latest cumulative update, then the BIOS or UEFI firmware update from the hardware vendor that carries current CPU microcode. Registry settings cannot enable a mitigation the processor does not support. Virtual machines get microcode from the host, so fix the host before the guests.

Step 2: set the registry values for your CPU

All values are REG_DWORD under HKLMSYSTEMCurrentControlSetControlSession ManagerMemory Management, taken from KB4072698. The mask stays 3 in every case.

8264 = 72 OR 0x2000. After a restart it enables the same mitigations as 72 and also turns SMT/Hyper-Threading off in Windows, which halves NumberOfLogicalProcessors on an HT-capable host. KB4457951 calls this software setting secondary to the BIOS/UEFI setting and offers it for when disabling HT in firmware is difficult or impossible, so prefer the firmware setting where you can. Deploy 8264 only where you accept losing the SMT logical processors. To undo it, set 72 again or delete the values, then restart.

For the common case (Intel with Hyper-Threading, or AMD with SSBD), run from an elevated prompt:

reg add "HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSession ManagerMemory Management" /v FeatureSettingsOverride /t REG_DWORD /d 72 /f
reg add "HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSession ManagerMemory Management" /v FeatureSettingsOverrideMask /t REG_DWORD /d 3 /f

The PowerShell equivalent:

$mm = 'HKLM:SYSTEMCurrentControlSetControlSession ManagerMemory Management'
New-ItemProperty -Path $mm -Name FeatureSettingsOverride -Value 72 -PropertyType DWord -Force
New-ItemProperty -Path $mm -Name FeatureSettingsOverrideMask -Value 3 -PropertyType DWord -Force

KB4072698 also lists values for newer issues, such as CVE-2022-23825 (AMD Branch Type Confusion), CVE-2023-20569 (AMD Return Address Predictor) and CVE-2022-0001 (Intel Branch History Injection). For CVE-2022-23825 it adds that full protection may also require disabling SMT. The KB says that to enable multiple mitigations you must “add” their REG_DWORD values together. Here “add” means bitwise OR. The KB’s own example is 0x800000 OR 0x2048 = 0x802048 (8,396,872). Do not add the decimal numbers: the AMD values already include 64, so 72 + 16777280 gives 16777352 (0x01000088), which clears bit 0x40 and sets an undocumented bit 0x80. Correct results:

• Intel BHI plus the 72 set: 72 | 0x800000 = 8388680 (0x00800048).
• AMD Branch Type Confusion plus SSBD: 16777280 | 8 = 16777288 (0x01000048).
• AMD Return Address Predictor plus SSBD: 67108928 | 8 = 67108936 (0x04000048).

Writing a newer KB value such as 16777280 or 0x00800000 on its own drops the SSBD bit (8) and brings plugin 132101 and QID 91462 back. To OR a bit into the existing value in PowerShell:

$cur = (Get-ItemProperty -Path $mm -Name FeatureSettingsOverride).FeatureSettingsOverride
New-ItemProperty -Path $mm -Name FeatureSettingsOverride -Value ($cur -bor 0x800000) -PropertyType DWord -Force

Step 3: Hyper-V hosts

If the Hyper-V role is installed, add this value so guests can use the CPU-based mitigations:

reg add "HKLMSOFTWAREMicrosoftWindows NTCurrentVersionVirtualization" /v MinVmVersionForCpuBasedMitigations /t REG_SZ /d "1.0" /f

After the firmware update, fully shut down all VMs (do not save or pause them) before restarting the host. Each guest OS needs its own registry values.

For Hyper-V hosts with Hyper-Threading on, KB4457951 offers the core hypervisor scheduler, which runs guest virtual processors only on physical core pairs so a core is never shared between VMs. It exists only on Windows Server 2016 and later and is the default from Windows Server 2019. On 2012/2012 R2 Hyper-V hosts, disabling HT is the only option. The core scheduler does not protect VBS (Credential Guard/Device Guard) secrets, so hosts that rely on VBS or run untrusted code may still need HT off. On Windows Server 2016, switch the scheduler and restart, then optionally expose SMT to guests per VM:

bcdedit /set hypervisorschedulertype core
Set-VMProcessor -VMName <VM> -HwThreadCountPerCore 2

After the restart, a scheduler type of 0x3 in the latest hypervisor launch event means core:

Get-WinEvent -FilterHashTable @{ProviderName="Microsoft-Windows-Hyper-V-Hypervisor"; ID=2} -MaxEvents 1

Step 4: deploy at scale and restart

In a domain, push both DWORDs with Group Policy Preferences registry items under Computer Configuration > Preferences > Windows Settings > Registry: Action = Update, Hive = HKEY_LOCAL_MACHINE, Key Path = SYSTEMCurrentControlSetControlSession ManagerMemory Management, Value type = REG_DWORD (not the default REG_SZ), Base = Decimal. Every change needs a restart, so schedule it through your reboot orchestration for patching window.

How to verify the fix and rescan

After the restart, run Get-SpeculationControlSettings again. Each WindowsSupportEnabled field for a mitigation your CPU needs should read True; KVAShadowRequired and similar fields reading False mean the processor is not affected. Then run a credentialed rescan: plugin 132101 in Nessus, or QIDs 91462, 91426 and 91537 in Qualys. Both read the registry, so a clean scan before the reboot proves nothing; keep the SpeculationControl output as runtime evidence.

What can break and how to roll back

Microsoft says the performance impact depends on chipset and workload and gives no fixed figure, so measure on a representative host per workload before a fleet-wide push.

Watch the hex versus decimal trap. The Registry Editor DWORD dialog defaults to Hexadecimal, so typing 72 there stores 0x72 (114). That sets the bit with value 2, which with mask 3 disables the Meltdown mitigation. reg add /d 72 writes decimal.

Record the current values first with the reg query commands above, and optionally export the key:

if not exist C:Temp mkdir C:Temp
reg export "HKLMSYSTEMCurrentControlSetControlSession ManagerMemory Management" C:Tempmemmgmt-backup.reg /y

• The values did not exist before (the usual case). Delete them and restart. Do not use reg import here: .reg contents merge into the registry, and removing a value requires the “ValueName”=- syntax, so importing the backup would leave 72 and 3 in place.
• The values existed before. Restore the previous numbers with reg add. Importing the export also works, but it rewrites every value in the Memory Management key and its subkeys (such as PrefetchParameters), so a targeted reg add is cleaner.

reg delete "HKLMSYSTEMCurrentControlSetControlSession ManagerMemory Management" /v FeatureSettingsOverride /f
reg delete "HKLMSYSTEMCurrentControlSetControlSession ManagerMemory Management" /v FeatureSettingsOverrideMask /f

KB4072698 also documents FeatureSettingsOverride = 3 with mask 3 to disable the Spectre V2, Meltdown and MMIO mitigations. Treat that as a documented risk acceptance, not a fix.

Common false positive reasons

• Wrong type or location. Both values must be REG_DWORD under HKLM. Delete a REG_SZ value or an HKCU copy and recreate it correctly.
• Different value, real gap. 64 and the AMD-only KB values (16777280, 67108928) leave SSBD off, so an SSBD flag there is real: OR in 8. If a host with 72 or 8264 is flagged, read the plugin output for the missing mitigation.
• Guest not cold-booted. A VM resumed from saved state may show the mitigation as unavailable until fully shut down and started.
• Scan access problems. Flaky remote registry access gives stale results; rule out the causes in Windows credentialed scan failures before editing hosts.

FAQ

Does installing the monthly cumulative update fix this finding?

No. On Windows Server the registry values above must also be set, followed by a restart.

Do Windows 10 and 11 clients need these settings?

Most mitigations are on by default on clients, but Speculative Store Bypass is off. If a client is flagged, KB4073119 uses the same 72 and 3 values.

What is the difference between 72 and 8264?

8264 enables the same mitigations as 72 and also turns Hyper-Threading off in Windows, halving the logical processor count. Use it only where you accept that capacity loss.

Is a restart really required?

Yes. The changes take effect only after a restart. On Hyper-V hosts, fully shut down the VMs first.

Tracking this finding across many hosts

Because this finding needs the right value per CPU vendor plus a coordinated restart, it tends to linger on a few hosts long after the bulk rollout. SITEY is a self-hosted vulnerability management platform that imports Nessus results from uploaded .nessus exports, can have AI draft host-specific remediation scripts that run only after human approval through its agents on Windows endpoints, and supports per-finding retest for Nessus to confirm closure after the fix.

Sources

• Tenable: Windows Speculative Execution Configuration Check (plugin 132101)
• Microsoft KB4072698: Windows Server guidance for speculative execution side-channel vulnerabilities
• Microsoft KB4457951: Windows guidance to protect against speculative execution side-channel vulnerabilities (Mitigations C and D)
• Microsoft KB4073119: Windows client guidance for IT pros
• Microsoft SpeculationControl PowerShell module
• Microsoft Learn: Manage Hyper-V hypervisor scheduler types
• Microsoft Support: How to add, modify, or delete registry subkeys and values by using a .reg file (archived copy; the live URL now redirects elsewhere)
• Qualys ThreatPROTECT: Meltdown and Spectre detection QIDs, including QID 91426 (ADV180002)
• Qualys: About Mitigating Speculative Store Bypass (SSB), CVE-2018-3639 (QID 91462) (Qualys Success portal, login required)
• Qualys: Registry Keys for QID 91462 and QID 91537 (Qualys Success portal, login required)