March Patch Tuesday Analysis: 2 Zero-Days and a Privilege Escalation Party
Just finished scrubbing through the March release, and it’s a heavy one. Microsoft dropped patches for 84 vulnerabilities, and while the 8 Critical ratings usually grab the headlines, I’m more concerned about the breakdown of the rest.
We have two public zero-days (CVE-2026-21433 and CVE-2026-21441) that are reportedly being exploited in the wild. While details are still emerging, early indicators suggest one involves a SmartScreen bypass (again) and the other is a local privilege escalation (LPE) in the Windows Common Log File System (CLFS).
However, the sheer volume of LPE bugs is staggering—46 of the 84 flaws. If an attacker pops a web shell or gets initial user access, this update cycle is basically a cheat sheet for Domain Admin. The remaining 18 Remote Code Execution (RCE) flaws are mostly in Windows OLE and Microsoft SharePoint, so make sure your external attack surface is covered.
Immediate Action Items:
- Patch the zero-days immediately.
- Review your SharePoint logs for unusual serialization activity.
Here is a quick KQL query to hunt for potential CLFS exploitation attempts associated with the LPE vector, looking for suspicious handle operations:
DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName in~ ("cmd.exe", "powershell.exe", "pwsh.exe")
| where ProcessCommandLine contains "clfs" or ProcessCommandLine contains "\Device\HarddiskVolume"
| project Timestamp, DeviceName, InitiatingProcessAccountName, ProcessCommandLine
| order by Timestamp desc
With the high count of privilege escalation bugs, are you re-authenticating users or strictly prioritizing patching this month?
The CLFS LPE (CVE-2026-21441) is nasty. It's a kernel-level race condition, meaning detection is incredibly difficult once the exploit runs—it happens in Ring 0 before your EDR sensors even wake up. We are prioritizing this one over the RCEs for internal workstations because an attacker doesn't need network access to use it; just a low-privileged user account.
We're using PowerShell to check the version of clfs.sys across the fleet to identify unpatched hosts instantly:
Get-CimInstance Win32_SystemDriver | Where-Object {$_.Name -eq 'clfs'} | Select-Object DisplayName, State, Version
If your version is older than what the March update provides, isolate that machine.
I'm more worried about the SharePoint RCEs. We've seen a massive spike in automated scanning for *.aspx endpoints since the release notes dropped. The patching cadence for SharePoint in our environment is slower than Windows due to the farm reboots, so we've put WAF rules in place as a temporary mitigation.
We're blocking requests containing the X-InfoPath-FormSource header and specific ViewState patterns known to trigger the deserialization bug in older versions. It's noisy, but better than ransomware.
Don't sleep on that SmartScreen bypass (CVE-2026-21433). It’s the perfect opener for phishing campaigns. We've been testing delivery vectors using signed executables that strip the Mark of the Web (MOTW).
If you're hunting for post-exploitation artifacts or testing the bypass, check for executables in user directories missing the Zone.Identifier stream:
Get-ChildItem -Path "C:\Users\*\Downloads" -Filter *.exe -File | Where-Object { -not (Get-Item $_.FullName -Stream 'Zone.Identifier' -ErrorAction SilentlyContinue) }
@Threat_Intel_Omar Good point on the SharePoint scanning. If you're using Sentinel, you can correlate that traffic with endpoint signals. I’ve been using this KQL query to hunt for suspicious POST requests to those .aspx endpoints, which often precede exploitation attempts.
DeviceNetworkEvents
| where RemoteUrl has ".aspx"
| where ActionType == "ConnectionSuccess"
| where InitiatingProcessFileName !in ("iexplore.exe", "chrome.exe", "msedge.exe")
| summarize count() by RemoteUrl, DeviceName
Excellent breakdown on the CLFS race condition. Since catching it in Ring 0 is a nightmare, I'd suggest verifying the patch status of clfs.sys immediately. We've seen chatter suggesting exploit POCs are circulating in certain circles. Here’s a quick PowerShell snippet to audit the driver version across your environment to ensure you’re fully patched against CVE-2026-21441:
Get-Item C:\Windows\System32\drivers\clfs.sys | Select-Object FullName, VersionInfo
Good catch on the delivery vectors, Carlos. Since patching isn't always immediate, we're enforcing ASR rules specifically targeting the SmartScreen bypass aftermath. Enabling 'Block Office applications from creating child processes' helps contain the payload if the initial bypass succeeds.
You can quickly audit your ASR status with this PowerShell snippet:
Get-MpPreference | Select-Object AttackSurfaceReductionRules_Ids, AttackSurfaceReductionRules_Actions
It’s a decent temporary bandage while you push out the `clfs.sys` and SmartScreen updates.
Managing a fleet this size, manual verification isn't an option. I'm prioritizing the CLFS driver check immediately. Here is a quick PowerShell snippet to check the clfs.sys version across your endpoints to ensure they match the patched build:
Get-Item C:\Windows\System32\drivers\clfs.sys | Select-Object FullName, VersionInfo
If the version is lower than what's in the bulletin, that machine gets disconnected from the network until it's patched. Don't wait for the POC to spread.
Validating clfs.sys is smart, but for those running Windows containers, remember that a compromised pod gives you access to the underlying kernel. That LPE is a potential container escape vector. We’re checking our node images immediately to ensure the base OS includes the patch.
Here’s a quick PowerShell check for the driver version on your nodes:
Get-Item "C:\Windows\System32\drivers\clfs.sys" | Select-Object Name, VersionInfo
Make sure that FileVersion matches the latest security update before you reschedule workloads.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access