CVE-2026-40058: Falcon sensor for Windows local privilege escalation

What it is

The Falcon sensor for Windows can remove malicious macros from Office files. That feature runs with high privileges. CrowdStrike’s advisory says a time-of-check to time-of-use race condition (CWE-367) in it allows an arbitrary file write to protected locations from an unprivileged context. That can lead to local privilege escalation.

This is not remote code execution. An attacker needs to run code on the host first, as a normal user. From there, a successful attack gives SYSTEM, which on an endpoint with an EDR sensor means a way to tamper with the machine and its protections. CrowdStrike scores it 8.8 (CVSS 3.1, high).

What makes it matter: a public proof of concept, called FalconFlank, was released on GitHub on September 3, 2026 by a researcher using the handle Chaotic Eclipse, before any fix existed. The Hacker News reported that the researcher said it works on a fully updated Windows 11 25H2 or Windows Server 2025 host running Falcon. CrowdStrike’s advisory says there is no indication of exploitation in the wild and that its threat hunting team is monitoring for abuse. We found no source that reports otherwise. The CVE does not appear in the visible part of the CISA KEV catalog.

Am I affected?

You are exposed only if both are true:

1. A Windows host runs a Falcon sensor build older than the fixed build for its branch (see the table above).
2. The Microsoft Office File Malicious Macro Removal Windows policy setting is enabled in the host’s prevention policy.

CrowdStrike’s spokesperson called the same setting “Microsoft Office File Suspicious Macro Removal” when the PoC was released. It is one setting with two names in CrowdStrike’s own wording.

The CrowdStrike Laroux Malware Cleanup Tool is built on the same feature and is also affected up to 1.3.65.0.

Not affected: the Falcon sensor for Mac, Linux and Legacy Systems.

Check the sensor version in the Falcon console and the setting in your Windows prevention policies. The advisory gives no menu path for this, so we have not invented one. Ask your CrowdStrike contact or the Customer Center if you can’t find it.

Version note. The CVE record and the advisory table don’t fully agree for the 7.39 and 7.32 LTS branches, and the advisory warns the pairing of affected and fixed builds is unclear for some rows. Confirm the exact target build for each host in the advisory or the Customer Center rather than relying on this page for those two branches.

What to do

1. Upgrade the sensor on Windows hosts to the fixed build for your branch. If you run 7.33, 7.31 or older, there is no hotfix: move to a supported, fixed release.
2. Replace the Laroux Malware Cleanup Tool with 1.4.70.0 or later wherever you use it.
3. If you can’t upgrade yet, CrowdStrike’s interim advice was to disable the Office macro removal policy setting. The cost is that the host loses that sensor-side macro removal. CrowdStrike says hosts stay protected by the Cloud Anti-malware for Microsoft Office Files settings, so confirm those are on before you disable anything.
4. After upgrading, re-enable the macro removal setting if you turned it off. CrowdStrike says no performance impact is expected.
5. Hunt on hosts that ran a vulnerable build with the setting on since at least September 3, 2026 (see Detection). If you find SYSTEM activity you can’t explain, treat the host as compromised.

Detection

No indicators of compromise have been published by CrowdStrike or any researcher we found, and CrowdStrike’s advisory gives no detection guidance. The sources describe behaviour, not artifacts.

The Cloud Security Alliance’s research note, a third-party reconstruction that CrowdStrike has not verified, suggests looking for:

• Unexplained library files, such as one resembling bcrypt.dll, written to the PowerShell v1.0 application directory.
• SYSTEM-context process creation that doesn’t match expected administrative activity.

Vega, which reproduced the attack in a lab, according to the Penligent write-up, points to broader behavioural signs: user-writable staging directories holding DLLs, reparse point or junction activity, a user-context process followed closely by SYSTEM execution, and SYSTEM processes loading recently modified DLLs. Don’t build detections only around the original PoC’s file names or strings. The researcher reportedly expected signature updates.