CrowdStrike Falcon Windows Sensor fixes CVE-2025-42701 and CVE-2025-42706

  • Thread Author
CrowdStrike has published fixes for two medium‑severity vulnerabilities in the Falcon Windows Sensor that could allow an attacker who already has local code execution to delete arbitrary files on Windows hosts — the issues are tracked as CVE‑2025‑42701 (a TOCTOU race condition) and CVE‑2025‑42706 (a logic/origin‑validation bug).

Neon holographic cyber shield surrounds a server rack, displaying CVE-2025-42701 and CVE-2025-42706.Overview​

These two flaws affect the Falcon sensor for Windows and were responsibly reported through CrowdStrike’s bug bounty program. Both vulnerabilities are classified as Medium under CVSS 3.1: CVE‑2025‑42701 is scored 5.6 and CVE‑2025‑42706 is scored 6.5. In every public advisory and aggregated CVE feed the attack vector is listed as local — an attacker must already be able to execute code on the host before these issues become useful for further impact. CrowdStrike has released fixes and hotfixes for multiple sensor branches; affected customers are strongly advised to update to a patched sensor build as soon as possible.

Background and context​

Why this matters for Windows endpoints​

Endpoint sensors like CrowdStrike Falcon operate with privileged access by design to provide deep process, file, kernel and network visibility. That access delivers security value — but it also raises the blast radius for implementation bugs. A defective path in a sensor that runs as a privileged service or driver can be used by an attacker who already has a foothold to inflict additional damage or to impede detection. CrowdStrike’s own operational history — including the high‑profile July 2024 content‑update incident that caused wide‑scale instability on some Windows fleets — makes any new Falcon sensor vulnerability particularly salient for enterprise risk teams.

The two CVEs at a glance​

  • CVE‑2025‑42701 — TOCTOU (Time‑of‑check / Time‑of‑use) race condition (CWE‑367). A timing/synchronization weakness that an attacker could exploit to cause deletion of arbitrary files under certain conditions. Rated CVSS 3.1 = 5.6 (Medium).
  • CVE‑2025‑42706 — Logic bug / origin validation (CWE‑346). A validation error that can be abused, again only after code execution on the host, to delete arbitrary files. Rated CVSS 3.1 = 6.5 (Medium).
Both issues are explicitly not remote code execution vulnerabilities and cannot by themselves provide initial access. Instead, they materially increase the impact an already‑present attacker can achieve on a compromised host — for example by removing forensic evidence, sabotaging critical data, or destabilizing the host and other security tooling. Public CVE feeds and the vendor responses note there is no current evidence of exploitation in the wild, but monitoring is ongoing.

Affected products and patched builds​

Versions named in public feeds​

Aggregated CVE trackers indicate the issues affect Falcon Windows Sensor builds up to specific pre‑hotfix numbers. The fixed threshold across the affected branches is represented in the feeds as builds at or above:
  • 7.29 (latest full release), and hotfixed builds for previous branches, e.g.:
  • 7.28 — fixed at or after 7.28.20008
  • 7.27 — fixed at or after 7.27.19909
  • 7.26 — fixed at or after 7.26.19813
  • 7.25 — fixed at or after 7.25.19707
  • 7.24 — fixed at or after 7.24.19608
  • For older Windows 7 / Windows Server 2008 R2 hosts there’s a dedicated hotfix (for example 7.16.18637 was called out as the corrected build for legacy OS support by some trackers).
These build identifiers are important because many enterprises pin sensor updates to a specific update policy (N, N‑1, N‑2) or block automated updates. Administrators must verify the currently installed sensor builds in their fleet and ensure updates or hotfixes propagate to all Windows hosts that run the affected sensors.

Technical analysis — how the vulnerabilities work​

TOCTOU race conditions (CVE‑2025‑42701)​

A TOCTOU issue arises when code checks a condition (time‑of‑check) and later acts based on that check (time‑of‑use) without locking or otherwise guaranteeing the condition remains true. In kernel or privileged services, an attacker who can race the check and use windows can cause the software to operate on unexpected or attacker‑controlled objects. In this case, the race allows deletion of arbitrary files when the attacker times operations to exploit a window in the sensor’s file‑handling code path. TOCTOU weaknesses are notoriously tricky to reproduce reliably but can be exploited by a local actor who controls timing and filesystem operations. Public CVE summaries classify this as CWE‑367.

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

Logic or origin validation bugs (CWE‑346) occur when code trusts the origin of input or fails to validate the provenance of a request or file. In privileged services that accept directives or content updates, improperly validated input can be misinterpreted as trusted data. In this situation the logic bug permits abuse by a local actor to cause the sensor to delete files it should not. Aggregators indicate the root cause is validation/logic, not an unauthenticated remote API.

Practical exploitation conditions​

  • An attacker needs an existing capability to execute code on the host (local code execution). These flaws are post‑compromise issues: they elevate the damage an attacker can do after gaining a foothold, rather than providing that initial foothold.
  • Exploitation can have operational side effects beyond file deletion — for example, deleting files used by the OS or other software could create instability or inhibit monitoring, potentially hindering incident response. Public advisories explicitly warn these bugs could impact stability or functionality of the OS or the Falcon software itself.

What CrowdStrike and trackers say (verification)​

Multiple independent CVE aggregators and security feeds publish matching summaries (CVE descriptions, CVSS values, affected‑build thresholds and mitigation recommendations). The NVD entry for CVE‑2025‑42701 is present and awaiting full enrichment, while other trackers list the complete CVSS and affected build numbers. CrowdStrike’s public communications reiterate the discovery via its bug bounty program and the release of hotfix builds for affected sensor branches. The vendor’s prior transparency efforts — including the published post‑incident analysis for the July 2024 content update event — provide useful context for how the company handles sensor stability and rapid mitigation. These cross‑references were used to confirm the facts reported in public advisories. Flag: where precise timelines or internal telemetries are reported only by one party (for example exact counts of endpoints that failed during previous incidents), treat those numbers as vendor‑provided and conditional on later verification. The CVE feeds and NVD notes are consistent on the technical classification and the presence of hotfix builds.

Operational impact and risk assessment​

Immediate risks​

  • Post‑compromise amplification — an attacker who already has code execution can use these flaws to delete logs, detection artifacts or system files, making forensic triage harder and potentially helping persistence or cleanup.
  • Stability and availability — file deletion of critical components or race‑condition side effects could crash processes, degrade services or destabilize endpoints and monitoring. Public advisories warn these vulnerabilities could affect system stability and Falcon’s ability to monitor or protect a host.

What these flaws are not​

  • They are not remote code execution vectors and cannot be used by a remote unauthenticated attacker to gain initial access. The attack requires local code execution first, which constrains the attack surface to scenarios where an attacker already controls or can run code on the machine. That limits, but does not eliminate, the operational severity — especially in high‑value or shared environments (file servers, jump boxes, Cloud PCs).

Where the real risk accumulates​

Risks escalate in environments that combine:
  • Widely‑deployed sensor fleets with centralized auto‑update or rapid mass rollouts, and
  • High exposure services (RDP‑exposed hosts, multitenant VMs, Windows Cloud PCs) where initial code execution is more likely to appear from either external exploit chains or insider threats.
Enterprises that rely on a single vendor for endpoint protection should also consider the operational coupling risk: a single flawed update or an exploited post‑compromise bug may have broad operational impact across many critical systems. Historical incidents involving Falcon sensor content updates illustrate real world consequences when privileged agent behavior interacts unexpectedly with OS internals.

Clear, practical guidance for administrators​

The following steps are prioritized and practical for IT and security teams managing Windows endpoints with Falcon deployed.
  • Inventory sensor versions: query the Falcon console and endpoint inventories to identify all Windows hosts running affected sensor builds (7.24–7.28 range, older 7.16 for legacy OSes). Verify actual build numbers against the hotfix thresholds.
  • Apply the hotfixes or update to 7.29 (or the hotfixed builds in your supported branch) as soon as testing windows allow. If auto‑update is enabled and set to a policy that will receive hotfixes, confirm the policy propagated successfully.
  • For pinned update policies (N, N‑1), plan forced or staged deployments to reach 100% coverage quickly — don’t rely on a slow, uncontrolled stagger. Use canaries and validate in the staging ring before a full push.
  • Monitor Falcon alerts and quarantined file ledgers for indicators of local exploitation — the vendor notes exploit attempts would surface in the endpoint UI and audit logs. Hunt for suspicious local process launches, unexpected deletes of log or telemetry files, and unusual MSI or installer activity.
  • If immediate patching isn’t possible, harden hosts against initial code execution: limit exposed management interfaces (RDP), enforce least privilege, apply application allowlists, and elevate monitoring on internet‑facing or high‑value devices.
Recommended forensic checks (short list):
  • Search for unusual file deletion patterns or missing log segments.
  • Review recent process creation events around sensitive services.
  • Scan for suspicious child processes spawned by system‑level services.
  • Verify the integrity of sensor files and compare with expected checksums where supported.

Detection and hunting: useful starting queries​

  • Look for local process creations that executed code in user folders followed by deletions in system or log directories.
  • Search Falcon (or SIEM) logs for quarantined items and correlate timestamps with any unexpected service restarts or kernel exceptions.
  • Monitor for MSIInstaller activity launched outside maintenance windows — many sensor updates use MSI semantics and an attacker might mimic the same process chain.

Why vendors’ update discipline and deployment mechanics matter​

The past year’s incidents underscore that even small content updates — templates, configuration packages, detection content — can interact with privileged components in unexpected ways. The operational model for endpoint protection (fast content updates, cloud‑driven rules, privileged local agents) delivers security efficacy but depends on rigorous validation, staged rollouts and robust rollback tools. CrowdStrike’s public remediation work and the company’s bug bounty disclosures show a mature vulnerability program, but they also highlight the need for customers to treat agent updates as operational events: test, stage, monitor, and have playbooks ready.

Strengths and mitigations built into modern endpoint platforms​

  • Modern EDR/XDR platforms provide immediate detection telemetry and quarantine mechanisms that can help contain an exploited post‑compromise path. CrowdStrike’s telemetry signals and quarantined file ledger were specifically referenced as ways customers would detect manifestations of these CVEs. That capability reduces the chance that an attacker could silently delete critical telemetry without triggering alerts.
  • Bug bounty programs and rapid disclosure pipelines accelerate the time between discovery and patching; these CVEs were disclosed via HackerOne and remediated with hotfixes — a positive indicator of vulnerability lifecycle management.

Risks and open questions to watch​

  • One remaining operational risk is partial update coverage. Several community reports indicate some environments observed hung or partially unresponsive endpoints until a forced reboot allowed the hotfix to apply. Customers should validate that updates applied successfully across cloud‑hosted and on‑prem hosts and be prepared for outliers (e.g., cloud‑based Cloud PCs, VDI images, or devices that are offline during rollouts).
  • Public feeds state “no evidence of in‑the‑wild exploitation” at the time of disclosure; while reassuring, this is a time‑sensitive statement. Monitoring for suspicious artifacts and reviewing endpoint telemetry remains essential — the absence of evidence is not proof of absence. Flag: treat “no evidence” as temporary and continue logging and hunting.

Conclusion — practical takeaway for Windows administrators​

The dual disclosures CVE‑2025‑42701 and CVE‑2025‑42706 are important operational‑security reminders: privileged endpoint agents are powerful defenders and — when imperfect — can also amplify damage in post‑compromise scenarios. These two vulnerabilities do not enable remote takeover but do allow an attacker who already controls a host to delete files and potentially disrupt security monitoring and system stability. Enterprises should act now: inventory affected builds, deploy the hotfixes or upgrade to the patched sensor release, and beef up detection for suspicious local activity while the rollout completes. Maintain staged update discipline, verify successful application of hotfix builds on cloud and on‑prem hosts, and keep hunting for any signs of post‑compromise activity. Aggregated CVE trackers and vendor notices confirm the technical details and hotfix availability; treat those advisories as the operational baseline for patch planning.

Quick checklist (actionable)​

  • Verify current Falcon Windows Sensor builds across the estate.
  • Update to a patched build (7.29 or the hotfixed builds in your branch) or apply vendor hotfixes immediately.
  • Confirm update success on cloud‑hosted and offline hosts; reboot if necessary to let installers complete.
  • Hunt for suspicious local code execution, file deletions, or gaps in telemetry.
  • If exposure is suspected, escalate to forensic triage and coordinate with incident response; open a vendor support case for targeted assistance.
These steps will materially reduce operational risk and preserve detection integrity while the hotfix rollout completes.

Source: Red Hot Cyber CrowdStrike risolve due bug su Falcon Windows Sensor per Windows
 

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.

A futuristic security dashboard displays Falcon Sensor for Windows 7.29 with patch status and a world map.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
 

Back
Top