What breaks and who should care
If your scanner has just shouted about CVE-2024-30088, you are looking at a Windows kernel flaw that can let an attacker climb from a low‑privilege account to full system rights. Anyone running an affected Windows client or server should treat this as a high‑priority ticket. The vulnerability is already being used in ransomware campaigns, so you don’t have the luxury of waiting for a perfect maintenance window.
Related remediation guides
Other vulnerabilities in the same family or affecting the same products:
- CVE-2024-49039 – Windows Task Scheduler privilege escalation fix guide
- CVE-2021-43226 – Windows CLFS Driver Privilege Escalation – What You Need to Do
- CVE-2025-29824 – Windows CLFS driver privilege‑escalation – what you need to know
For the wider picture, our Known Exploited Vulnerabilities tracker lists every flaw CISA has confirmed under active attack.
What the vulnerability actually is
The NVD describes CVE-2024-30088 as a time‑of‑check‑to‑time‑of‑use (TOCTOU) race condition inside the Windows kernel. In plain English, the kernel checks a condition – for example, whether a caller is allowed to perform a certain operation – and then, a split second later, uses the result of that check to decide what to do. If an attacker can change the state of the system between the check and the use, they can trick the kernel into doing something it shouldn’t.
Because the kernel runs with the highest level of privilege, any successful exploitation gives the attacker full control over the machine. The exact code path that is vulnerable has not been publicly disclosed, but the class of bug is well understood: a race window that can be triggered from user space, leading to privilege escalation.
The CVSS score of 7.0 reflects a high impact on confidentiality, integrity and availability. It is not a remote code execution flaw on its own – an attacker needs some foothold on the system – but once that foothold exists the escalation is trivial.
How bad is it really?
Two facts make this more than a theoretical concern. First, the vulnerability has been confirmed exploited in the wild. Second, the Cybersecurity and Infrastructure Security Agency (CISA) has listed it in the Known Exploited Vulnerabilities catalog and explicitly notes its use in ransomware attacks. That combination of confirmed exploitation and a high severity score pushes this into the “must fix now” category.
In practice, an attacker who already has a low‑privilege account on a workstation or a service account on a server can use this flaw to gain SYSTEM rights. With SYSTEM rights they can disable security tools, encrypt data, or move laterally across the network. The damage chain is well‑known: privilege escalation → credential dumping → lateral movement → ransomware payload. If you run any of the affected Windows releases, you are in the attacker’s cross‑hairs.
Are you affected?
The table below lists every Windows release that is vulnerable and the point at which Microsoft released a fix. If your machine is running a version that appears in the “affected” column, you are vulnerable until you apply the corresponding patched release for your branch.
To find out where you stand, you need to check the exact build number of your OS. Do not guess – use the built‑in tools.
- Open a PowerShell window and run
Get-ComputerInfo -Property WindowsVersion, WindowsBuildLabEx. TheWindowsBuildLabExfield shows the full build string. - Alternatively, from a Command Prompt type
systeminfo | findstr /B /C:"OS Version". The output will contain the build number after the version string. - If you prefer a GUI, press Win + R, type
winverand hit Enter. The dialog that appears displays the build.
Compare the build you see with the entries in the table below. If your build is listed as “up to” the vulnerable range, you need to update.
How to fix it – step by step
Microsoft has released patches for every affected branch. The fix is delivered through Windows Update, so the simplest path is to let the OS download and install the latest cumulative update for your edition.
1. Run Windows Update immediately
- Open Settings → Update & Security → Windows Update.
- Click Check for updates. Windows will list any pending patches.
- Install all available updates, especially those marked as “Security Update”.
After the reboot, re‑run the version check commands above to confirm you are now on a patched build.
2. Use WSUS or SCCM for bulk environments
- In WSUS, approve the latest security updates for the affected product families.
- In SCCM, create a deployment package that targets the same updates and set the deadline to the next maintenance window.
- Force a client sync with
wuauclt /detectnoworInvoke-WSUSServerCleanupfrom PowerShell.
Again, verify the build after the rollout.
3. Verify the patch is present
- Open PowerShell and run
Get-HotFix -Id KB*(replace the asterisk with the KB number you expect – you can find the exact KB in the Microsoft security advisory). The presence of that KB indicates the patch is installed. - Alternatively, run
wmic qfe list brief /format:table | find "KB"and scan for the relevant entry.
If the KB is missing, the machine has not been patched and remains vulnerable.
What if you cannot patch right now?
Sometimes a server cannot be rebooted immediately – think of a domain controller or a critical database node. In those cases you have two options: apply mitigations or isolate the system.
Mitigations supplied by Microsoft
CISA’s guidance says to apply mitigations per vendor instructions. Microsoft’s advisory recommends enabling the following defence‑in‑depth features, which reduce the chance of a successful TOCTOU exploit:
- Turn on Windows Defender Exploit Guard’s “Controlled Folder Access” and “Network Protection”.
- Enable Credential Guard and Device Guard where hardware support exists.
- Restrict the use of legacy admin accounts – prefer just‑in‑time elevation via Remote Server Administration Tools.
- Audit for any suspicious privilege‑escalation attempts using the built‑in event logs (
Microsoft-Windows-Security-Auditing/4624and4648).
These settings do not replace the patch, but they raise the bar for an attacker.
Isolation as a stop‑gap
If you cannot apply the update and mitigations are not enough, consider moving the host to a segmented network zone. Block inbound SMB traffic, limit RDP access to a jump host, and ensure that any accounts with local admin rights are monitored closely.
Document the risk, set a firm deadline for patching, and inform your change‑management board that the system is operating with a known high‑severity vulnerability.
Summary checklist
- Identify the exact Windows build on every machine.
- Cross‑reference with the table below to see if you are in the vulnerable range.
- Apply the latest Windows security update via Windows Update, WSUS or SCCM.
- Confirm the patch is installed with
Get-HotFixorwmic qfe. - If you cannot patch, enable the recommended mitigations and isolate the host.
- Monitor event logs for any unexpected privilege‑escalation activity.
Time is of the essence. The vulnerability is already being weaponised, and the impact of a successful exploit is total system compromise. Follow the steps above, verify your patch level, and you’ll close the gap before an attacker can take advantage of it.
Version table (auto‑generated)
The table below is pulled directly from the National Vulnerability Database. It lists every Windows release that is affected and the point at which Microsoft released a fix. Use it only as a reference – your own version check is the authoritative source.
Affected versions
Straight from the NVD record for CVE-2024-30088. If your build is inside one of these ranges, treat it as vulnerable.
| Product | Affected range | Fixed in |
|---|---|---|
windows_10_1507 |
* up to 10.0.10240.20680 | 10.0.10240.20680 |
windows_10_1607 |
* up to 10.0.14393.7070 | 10.0.14393.7070 |
windows_10_1809 |
* up to 10.0.17763.5936 | 10.0.17763.5936 |
windows_10_21h2 |
* up to 10.0.19044.4529 | 10.0.19044.4529 |
windows_10_22h2 |
* up to 10.0.19045.4529 | 10.0.19045.4529 |
windows_11_21h2 |
* up to 10.0.22000.3019 | 10.0.22000.3019 |
windows_11_22h2 |
* up to 10.0.22621.3737 | 10.0.22621.3737 |
windows_11_23h2 |
* up to 10.0.22631.3737 | 10.0.22631.3737 |
windows_server_2016 |
* up to 10.0.14393.7070 | 10.0.14393.7070 |
windows_server_2019 |
* up to 10.0.17763.5936 | 10.0.17763.5936 |
windows_server_2022 |
* up to 10.0.20348.2522 | 10.0.20348.2522 |
windows_server_2022_23h2 |
* up to 10.0.25398.950 | 10.0.25398.950 |

