Patch CrowdStrike Falcon on Windows: Fix CVE-2025-42701 and CVE-2025-42706

CrowdStrike has issued urgent fixes for two medium‑severity flaws in the Falcon sensor for Windows — tracked as CVE‑2025‑42701 and CVE‑2025‑42706 — that, while not enabling initial remote compromise, permit a local attacker who already has code execution on a host to delete arbitrary files and thereby amplify post‑compromise damage; patches and hotfixes are available now and organizations should treat this as a high‑priority operational remediation.

Background / Overview​

CrowdStrike’s advisory and multiple CVE trackers describe two distinct but related issues in the Falcon Windows sensor that were discovered internally and disclosed through the company’s bug bounty program. Both vulnerabilities are local in scope (attacker must already be able to run code on the machine) and have been assigned medium CVSS scores: CVE‑2025‑42701 (TOCTOU race condition) is scored 5.6, and CVE‑2025‑42706 (origin/logic validation error) is scored 6.5. CrowdStrike reports no evidence of exploitation in the wild at the time of disclosure and has released fixed sensor builds and branch hotfixes.
Why this matters: endpoint sensors like Falcon run with privileged access to operate effectively. That privilege is a double‑edged sword — it gives defenders deep visibility and control, but implementation defects in privileged code paths can dramatically increase the blast radius when an attacker already has a foothold. The real risk here is post‑compromise amplification: deletion of logs, telemetry, sensor components, or OS files can obstruct detection and remediation, or cause instability.

---

The vulnerabilities at a glance​

CVE‑2025‑42701 — TOCTOU race condition (CWE‑367)​

• Nature: Time‑of‑check / time‑of‑use (TOCTOU) race that can be exploited by a local actor to cause the sensor to operate on the wrong filesystem object, enabling arbitrary file deletion when the attacker controls timing and I/O.
• CVSS v3.1: 5.6 (Medium).
• Attack vector: Local; attacker must already be able to execute code on the host.

TOCTOU bugs are notoriously timing‑sensitive and often require an attacker to carefully orchestrate I/O to win the race window. In privileged services, such a race can make the service act on attacker‑controlled paths or handles and delete or corrupt files that it should never touch.

CVE‑2025‑42706 — Origin validation / logic error (CWE‑346)​

• Nature: Origin/logic validation error that causes the sensor to trust or accept input it should not, allowing a local attacker to induce deletion of arbitrary files.
• CVSS v3.1: 6.5 (Medium).
• Attack vector: Local; requires prior code execution on the host.

Logic/origin validation bugs typically occur when provenance checks are missing or incomplete; for endpoint agents that accept directives or content, incorrect validation can convert untrusted input into privileged actions.

---

Affected products and fixed builds​

The vulnerabilities affect the CrowdStrike Falcon sensor for Windows up to the pre‑hotfix builds in several active branches. CrowdStrike and multiple CVE aggregators list the fixed thresholds as follows:

• Fixed in the latest full release: Falcon sensor for Windows 7.29.
• Hotfix thresholds in previous branches (representative samples):
• 7.28 — fixed at or after build 7.28.20008
• 7.27 — fixed at or after build 7.27.19909
• 7.26 — fixed at or after build 7.26.19813
• 7.25 — fixed at or after build 7.25.19707
• 7.24 — fixed at or after build 7.24.19608
• Legacy OS: for Windows 7 / Windows Server 2008 R2, a special hotfix 7.16.18637 is provided for affected legacy systems.

Enterprises that pin sensor updates to release policies (e.g., N, N‑1) or block auto‑updates must verify installed build numbers against these hotfix thresholds rather than relying on generic version labels.

---

Technical analysis — how these bugs can be abused​

TOCTOU race (CVE‑2025‑42701)​

A TOCTOU vulnerability arises when code performs a security check (time‑of‑check) and later acts on that assumption (time‑of‑use) without preventing the underlying condition from changing between the two events. In a file‑handling path inside a privileged service, an attacker able to control filesystem state (for example, by creating or replacing symlinks or opening handles) can cause the service to act on a different file than it checked, resulting in deletion or modification of arbitrary targets. Exploitation complexity is non‑trivial but feasible for a local attacker who controls process scheduling and I/O patterns.

Origin validation / logic error (CVE‑2025‑42706)​

This class of bug occurs when the code trusts the origin or provenance of a request or artifact (for example, a temporary file path, an update directive, or an IPC message) and fails to validate that the origin is allowed to request destructive operations. In the Falcon sensor’s privileged code path, incorrect origin checks can allow an attacker’s local process to masquerade as a legitimate component, tricking the sensor into deleting files it should protect. Such logic errors are often easier to trigger once an attacker has code execution.

---

Realistic impact and operational risk​

These flaws do not enable remote code execution or initial access by themselves. Their primary operational impact is post‑compromise escalation:

• Evidence tampering: an attacker could delete logs, telemetry, or forensic artifacts to hinder detection and response.
• Service disruption: deletion of OS files, drivers, or security tooling could cause crashes, degraded service, or loss of monitoring.
• Sensor self‑sabotage: an attacker may delete sensor components to blind detection or force a sensor reboot/update race. CrowdStrike notes that affected files would surface in the Quarantined Files ledger and that detection telemetry should still generate alerts if exploitation occurs.

The attack surface is constrained to hosts where an adversary has already achieved local execution, but that still includes many high‑value targets in enterprise environments — RDP‑exposed servers, jump boxes, shared admin workstations, and Cloud PCs. Where endpoint fleets are large and centralized, a single post‑compromise bug can have outsized effects.

---

Detection, hunting and forensics — practical checklist​

CrowdStrike and community guidance provide a starting list for detection and triage. The following are practical, prioritized actions defenders should add to current playbooks:

• Inventory and identify affected hosts: query the Falcon console and endpoint inventories for installed sensor builds and compare against fixed build thresholds. Confirm which machines are pinned to older branches (N‑1, N‑2).
• Search for evidence of local exploitation: missing log segments, unusual deletion patterns, or suspicious process creation events where non‑privileged processes spawn actions against system directories.
• Hunt for suspicious installer activity: MSIInstaller runs or unexpected updates outside maintenance windows; attackers often mimic update chains to hide actions.
• Verify sensor integrity: compare on‑disk sensor binaries against expected checksums where feasible and check the Falcon Quarantined Files ledger and audit logs for unusual deletions.
• Forensic capture sequence if exploitation suspected: isolate host, capture memory image, collect process lists, open handles, loaded kernel modules, and EDR timelines. Assume compromise if a host is unpatched and shows suspicious deletion behavior.

Detection tuning and SIEM rules should prioritize post‑exploit behaviors (log deletions, unexpected restarts, new driver/service installs) rather than attempting to detect the race itself, which is timing‑sensitive and may not leave obvious signals.

---

Remediation and operational guidance — prioritized steps​

• Inventory: immediately query all Falcon‑managed Windows endpoints for installed sensor build numbers and identify hosts running affected builds (pre‑hotfix).
• Patch: deploy the hotfix or upgrade to Falcon sensor for Windows 7.29 (or the branch hotfix build appropriate to your update policy). Apply the 7.16.18637 hotfix where Windows 7/2008 R2 support is required.
• Staged rollout: use a canary/staging ring first, validate business workflows and telemetry, then push broadly — do not rely solely on background auto‑update status without verification.
• Monitor: after rollout, validate that hotfix builds applied and hunt for indicators described above; escalate any endpoints failing to update.
• Compensating controls: where immediate patching is impossible, harden against initial access — disable RDP where possible, enforce least privilege, strong application allow‑listing, and increase monitoring of exposed management interfaces.

Administrators should plan for a quick forced rollout if policy‑pinned fleets lag; many enterprises pin to N‑1 and may not receive hotfixes automatically unless policy updated or manual deployment is performed.

---

Strengths, mitigations and the vendor response​

There are notable positive elements in how this was handled:

• Responsible disclosure and patch availability: CrowdStrike released hotfixes and an updated full release (7.29), and the vulnerabilities were triaged through their bug bounty program — a sign of mature vulnerability lifecycle management.
• Active monitoring: the vendor reports that threat hunting and intelligence teams are watching for exploitation activity and that no in‑the‑wild exploitation has been detected so far. That statement reduces immediate panic, but must be treated as time‑sensitive.

Built‑in EDR telemetry and quarantined file ledgers can help defenders detect manifestations of abuse and reduce the chance of silent, undetected deletion of telemetry. Nevertheless, the presence of privileged local code paths in endpoint agents makes rigorous validation and staged rollouts essential operational controls.

---

Risks, open questions and caveats​

• Reports from community threads indicate some organizations experienced endpoints that temporarily hung, lost certain management channels, or required reboots during hotfix application; these are community observations and should be validated against vendor support channels before assuming a widespread regression. Treat such reports as operational anecdotes that underscore the importance of staged rollouts and fallback plans.
• The statement “no evidence of exploitation in the wild” is accurate at disclosure time but ephemeral. Defenders must continue logging and active hunting — absence of evidence today does not guarantee absence tomorrow. Maintain high‑fidelity logging and preserve historical telemetry to enable retrospective analysis if exploitation indicators surface.
• Some technical specifics of the exploitability (exact required privileges, timing windows, and specific target file classes) have not been published in full technical detail. That’s intentional to avoid creating a reliable recipe for attackers; it also means defenders must operate on conservative assumptions. Flag any vendor‑provided internal telemetry numbers (counts of impacted endpoints, etc.) as vendor‑reported until independently verifiable.

---

Why privileged agents demand operational maturity​

The class of incidents where endpoint protection updates or privileged content interact unexpectedly with OS internals is not hypothetical — CrowdStrike’s own July 2024 content‑update incident demonstrated how a narrow content update could cause widespread operational disruption on Windows endpoints. That event and its post‑incident review illustrate the real operational consequences when privileged components behave unexpectedly; customers must therefore treat agent updates as operational events with staging, canaries, rollback capability, and monitoring.
Key operational controls to institutionalize:

• Staged updates with canaries and rollback plans.
• Tight change management for agent update policies (especially for rapid “content” updates versus full sensor upgrades).
• Strong telemetry retention and immutable logging for post‑incident forensics.
• Clear playbooks for forced updates and emergency reboots if an update fails to apply.

---

Short, actionable checklist for IT teams (next 72 hours)​

• Query Falcon console for sensor builds and produce a prioritized list of hosts on pre‑hotfix builds.
• Validate patches/hotfix availability for each pinned branch and schedule a staged rollout to reach full coverage.
• Increase hunting posture: look for log deletions, unexplained MSIInstaller activity, and sudden service restarts.
• If any host cannot be updated immediately, isolate or severely limit remote management exposure and apply stricter local execution controls.
• Open vendor support tickets for any hosts that report update failures, hangs, or unexpected behavior; do not ignore outliers.

---

Conclusion — what defenders should take away​

CVE‑2025‑42701 and CVE‑2025‑42706 are not remote takeover bugs, but they materially increase the damage an attacker who already has local code execution can inflict. The combination of privileged access and implementation flaws in endpoint agents makes timely remediation and vigilant hunting essential. Organizations running CrowdStrike Falcon on Windows must inventory their fleets, apply the 7.29 release or the appropriate hotfix builds (including 7.16.18637 for legacy OSes), and verify that updates applied successfully across cloud and on‑prem hosts. Treat the vendor’s “no evidence of exploitation” statement as provisional: keep hunting, retain telemetry, and be prepared to respond if indicators emerge.
The incident is also a broader operational reminder: privileged agents are powerful defenders, and their updates should be governed with the same discipline applied to other critical infrastructure changes — test, stage, monitor, and be ready to roll back.

---

CrowdStrike customers should consult their Falcon console and official vendor advisory to map specific builds to their environment and proceed with the remediation steps above as soon as operationally feasible.

---

Source: SecNews.gr Vulnerabilities in CrowdStrike Falcon for Windows: File Deletion and Code Execution