TL;DR - On 3 September 2026, security researcher Chaotic Eclipse (a.k.a. MSNightmare, Nightmare-Eclipse, INFINITE NIGHTMARE) released FalconFlank, a local privilege-escalation PoC targeting CrowdStrike Falcon Sensor. It works on fully-patched Windows 11 25H2 and Windows Server 2025 hosts running Falcon with the malicious macro remediation feature enabled. CrowdStrike has not assigned a CVE or shipped a fix, but has issued a customer mitigation: disable the "Microsoft Office File Suspicious Macro Removal" Windows policy and rely on the "Cloud Anti-malware for Microsoft Office Files" setting instead. FalconFlank is the third endpoint-security vendor zero-day from the same researcher in five weeks. The takeaway for ANZ blue teams is not about this specific PoC. It is that containment planning, not patching, is now the load-bearing discipline when the security tool itself becomes the attack surface.
I have been deliberately holding off on publishing about CrowdStrike FalconFlank for the last three days while the story matured. The initial reports on 3 September were thin: a single BleepingComputer story citing an anonymous researcher, no vendor confirmation, no CVE, no second source. That is not enough to publish on. The picture is different now, and I think the angle is worth doing, but I want to be honest with you about why I waited and what I still do not know.
What FalconFlank actually does
Chaotic Eclipse's published PoC abuses the "Office malicious macros remediation" feature inside CrowdStrike Falcon Sensor. The feature is designed to clean up malicious macros embedded in Office documents - it runs with the elevated privileges Falcon needs to do its job. The PoC manipulates that remediation workflow so that the privileged cleanup operation acts on an attacker-controlled file path instead of the legitimate Office file. The end result is local privilege escalation: an attacker with limited user-level access on the host can spawn a command prompt with NT AUTHORITY\SYSTEM privileges.
The PoC is published on GitHub under the researcher's MSNightmare account. It targets fully-updated Windows 11 25H2 and Windows Server 2025 systems running CrowdStrike Falcon with "Phase 3 - Optimal Protection" enabled and the macro remediation feature enabled. The researcher themselves notes that by the time they published, CrowdStrike may already have detections for the PoC in place, so testing requires exclusions or payload obfuscation.
Two important caveats: First, the PoC works on the researcher's machine. Independent reproduction by a third party is still pending as of writing. Second, this is a local privilege-escalation, not a remote code execution. The attacker needs existing access to the host (a limited user account, an unprivileged shell) before FalconFlank is useful. The exposure is not "anyone on the internet can compromise your Falcon endpoint." The exposure is "anyone who already has local user access can become SYSTEM."
That distinction matters for the operational response. A local privilege escalation on a fully-patched, EDR-protected endpoint is a serious finding, but it is not in the same urgency class as a remote pre-authentication RCE on the same endpoint. Treat it accordingly.
What CrowdStrike has said
CrowdStrike has confirmed it is actively investigating and has issued a FalconFlank Tech Alert in the customer support portal. The vendor-recommended mitigation is to disable the "Microsoft Office File Suspicious Macro Removal" Windows policy setting, and rely on the "Cloud Anti-malware for Microsoft Office Files" setting as the alternative detection path. CrowdStrike has not assigned a CVE, has not issued a CVSS score, and has not shipped a fix. The vendor guidance is the only customer-actionable step at the moment.
The mitigation is a workaround, not a fix. It removes the specific feature that the PoC abuses, but it also removes a layer of macro-based detection that Falcon customers have been relying on. Whether that tradeoff is acceptable depends on your environment: if you have other compensating controls (network segmentation, application allowlisting, user training) that reduce the macro-as-an-attack-vector surface, the workaround is fine. If you rely on Falcon's macro remediation as a primary control, you need to think about what fills the gap.
Why this matters: the third endpoint-security zero-day in five weeks
Chaotic Eclipse has been on a run. In the last five weeks, the same researcher has published:
- BlueHammer / CVE-2026-33825 (Microsoft Defender, 2 April 2026, fixed)
- RedSun (Microsoft Defender, fixed)
- RoguePlanet / CVE-2026-50656 (Microsoft Defender, fixed, then bypassed)
- ShieldBreak / CVE-2026-69414 (Microsoft Defender bypass of RoguePlanet, unfixed as of 3 September)
- HardBreacher (Kaspersky Endpoint Security for Windows, days before FalconFlank, resolved via auto-update)
- FalconFlank (CrowdStrike Falcon Sensor, 3 September 2026, unfixed)
Two of those are Microsoft Defender bugs that Microsoft has not fully resolved. One is a Kaspersky bug that was resolved quickly. The FalconFlank disclosure is the third endpoint-security vendor zero-day in the series, and it is the first one to target a CrowdStrike product specifically.
The pattern is not about CrowdStrike being uniquely vulnerable. It is about the broader shift in the threat model: security tools that run with elevated privileges inside the OS kernel, userland services, and file-system watchers are now the primary attack surface for local privilege escalation. The same architecture that lets Falcon detect a malicious Office macro is the architecture that lets Falcon become the macro-cleanup-via-attacker-payload primitive. This is not a CrowdStrike-specific problem. It is an EDR-class problem.
Why this matters: the disclosure dispute context
The Chaotic Eclipse disclosures are happening against the backdrop of a public dispute between the researcher and Microsoft. According to The Register and multiple other outlets, Microsoft has previously suspended the researcher's GitHub account, and the researcher has publicly stated that Microsoft refuses to communicate with them. The result is a researcher who is publishing PoCs as a form of public pressure, with the disclosure-vendetta framing explicitly named in some of the announcements.
For you as a defender, the dispute context is editorial context, not signal quality. Most of the researcher's prior PoCs have validated as genuine exploitable flaws (Kevin Beaumont confirmed HardBreacher works; multiple researchers have validated RoguePlanet; BlueHammer was patched by Microsoft). Huntress has reported observing the tooling in a real-world intrusion. The reliability track record is strong. The vendor-dispute framing is noise relative to the technical reality.
For me as a writer, the dispute context shapes how I frame the angle. "Researcher drops PoC after vendor dispute" is a different story than "researcher drops PoC during coordinated disclosure." The first framing is honest. The second would be misleading.
The containment plan, not the patch
The reason I held off on this angle for three days is that the operational response to FalconFlank is not "patch your Falcon endpoint." There is no patch. The operational response is the four-step containment plan below, and that plan is the same one you need for every future EDR-class zero-day. Build it now and you will use it again.
Step 1: Inventory your Falcon fleet and confirm the policy state
Run a query against your Falcon console (or your SIEM's view of Falcon policy state) to identify every endpoint where the "Microsoft Office File Suspicious Macro Removal" policy is enabled. This is your exposure surface for FalconFlank specifically. For ANZ enterprises running Falcon at scale, this will likely be a substantial percentage of your endpoints - the policy is enabled by default in many Falcon policy templates.
Step 2: Apply the workaround on the priority endpoints
Disable the "Microsoft Office File Suspicious Macro Removal" policy on the priority endpoints first. The priority order depends on your environment, but a reasonable starting point is:
- Endpoints used by privileged accounts (domain admins, service account operators)
- Endpoints that handle sensitive data (finance, HR, legal)
- Endpoints that are externally reachable (VPN concentrators, remote-access jump hosts)
- The rest of the fleet, scheduled through your normal change window
For each endpoint, document the policy change in your change management system. The vendor will likely ship a fix in the coming weeks; when it does, you will need to revert the workaround and re-enable the policy. Having the documentation now saves you the archaeology later.
Step 3: Audit for indicators of exploitation
The PoC requires existing local user access to be useful. That means FalconFlank is more likely to be used as the second stage of an attack chain (initial access via phishing, then FalconFlank for privilege escalation) than as a standalone exploit. Audit for the indicators:
- New local user accounts created in the last 30 days, especially on hosts with Falcon enabled
- Unexpected processes spawned by the Falcon service account
- Office file writes to unusual paths during macro remediation events (Falcon logs should show these)
- Falcon policy-change events without a corresponding change ticket
- The MSNightmare PoC binary or related artefacts on disk - search for the PoC GitHub hash in your EDR telemetry
If you find any of these, treat the host as compromised and follow your standard incident response playbook. FalconFlank is high-impact but the indicators are not exotic - standard Falcon telemetry should catch a successful exploit.
Step 4: Brief your IT helpdesk
The helpdesk is going to get questions. "Is our CrowdStrike vulnerable to FalconFlank?" is going to be the ask from the executive team within the week. Have a one-paragraph answer ready that says: yes, this is a known disclosed local privilege escalation, the workaround is in progress, the audit is in progress, no patch from CrowdStrike yet. The one-paragraph answer buys you time to do the work properly without fielding ad-hoc status requests.
What this is not
This is not "CrowdStrike is uniquely bad." The same pattern of disclosure has hit Kaspersky (HardBreacher, fixed quickly), Microsoft Defender (ShieldBreak / CVE-2026-69414, unfixed as of writing), and BitLocker (YellowKey). Falcon is the third endpoint-security vendor zero-day in this researcher's series. It is the highest-profile one because CrowdStrike is the largest EDR vendor by market share.
This is also not "the researcher is wrong about the vulnerability." Independent researchers have validated most of the prior disclosures. Huntress has observed the tooling in a real-world intrusion. The technical signal is real.
This is, however, an editorial call about whether to publish. The angle is publishable, with the caveats I have already named: the PoC is unverified by independent parties, the vendor has not assigned a CVE, and the disclosure-vendetta context is real. Those caveats are part of the post, not absent from it.
What to do this week
- Identify every CrowdStrike Falcon endpoint in your fleet. Query your Falcon console for endpoints with the "Microsoft Office File Suspicious Macro Removal" policy enabled. That is your FalconFlank exposure surface.
- Apply the workaround on priority endpoints. Disable the policy on the highest-value endpoints first (privileged accounts, sensitive data, externally reachable). Schedule the rest through your normal change window.
- Audit for indicators of exploitation. Look for new local user accounts, unexpected Falcon-spawned processes, unusual Office file write paths during remediation, Falcon policy changes without tickets.
- Brief your helpdesk and your executive team. One paragraph each: what FalconFlank is, what the workaround is, what the audit found, when a patch is expected (no firm timeline from CrowdStrike yet).
- Build the EDR-class containment playbook. This is not a one-time event. The same playbook applies to the next EDR zero-day (which is probably weeks away, not months). Document it as a reusable runbook, not a one-off response.
Further reading
- The Hacker News: Researcher Releases FalconFlank PoC Showing Privilege Escalation in CrowdStrike Falcon (3 September 2026)
- BleepingComputer: New CrowdStrike 'FalconFlank' zero-day grants SYSTEM privileges (4 September 2026)
- The Register: Prolific Microsoft 0-day hunter drops CrowdStrike Falcon exploit PoC (3 September 2026)
- Security Affairs: Chaotic Eclipse Releases Crowdstrike Falcon ZeroDay FalconFlank (3 September 2026)
- SOCRadar: FalconFlank: CrowdStrike Falcon 0-Day PoC (3 September 2026) - vendor mitigations and disclosure context
- Huntress: Nightmare-Eclipse Tooling Seen in Real-World Intrusion (independent third-party corroboration)
- CrowdStrike customer support portal: FalconFlank Tech Alert (vendor mitigation guidance - requires customer login)
Mathew Clark / Founder, SecureInSeconds / Currently: drafting the EDR-class containment runbook from the third zero-day in five weeks, with a clearer picture than I had on day one but still holding the publish decision until at least one independent PoC reproduction surfaces
