A newly logged elevation‑of‑privilege flaw in the Host Process for Windows Tasks (taskhostw.exe / taskhostex.exe) gives local authenticated users a path to SYSTEM‑level effects by abusing improper link resolution (commonly called “link following”) in scheduled‑task/hosted‑task file operations — administrators must map the CVE to the correct KB, patch quickly, and apply targeted mitigations while vendor detail and exploit mechanics remain carefully circumscribed.
The Host Process for Windows Tasks is a generic Windows host used to load DLL‑based services and per‑task components on behalf of the OS and user sessions. Because instances of taskhostw.exe can run on behalf of system‑level scheduled tasks and — in some configurations — with elevated tokens or access to privileged file paths, a filesystem‑handling weakness in this component can convert routine, local file operations into a potent privilege‑escalation primitive. Community trackers and vendor pages classify the vulnerability as improper link resolution before file access (link following), which is a canonical route to local elevation when privileged code later acts on attacker‑controlled targets. Microsoft has registered the CVE in its Security Update Guide and distributes remediations as part of its monthly/patch cadence; the Security Update Guide entry is the authoritative confirmation that the problem is real and that vendor fixes are available. However, Microsoft’s public advisory text is intentionally concise in many inbox‑component advisories, so defenders must rely on the KB→SKU mapping in Microsoft’s update pages to ensure correct deployment.
Source: MSRC Security Update Guide - Microsoft Security Response Center
Background / Overview
The Host Process for Windows Tasks is a generic Windows host used to load DLL‑based services and per‑task components on behalf of the OS and user sessions. Because instances of taskhostw.exe can run on behalf of system‑level scheduled tasks and — in some configurations — with elevated tokens or access to privileged file paths, a filesystem‑handling weakness in this component can convert routine, local file operations into a potent privilege‑escalation primitive. Community trackers and vendor pages classify the vulnerability as improper link resolution before file access (link following), which is a canonical route to local elevation when privileged code later acts on attacker‑controlled targets. Microsoft has registered the CVE in its Security Update Guide and distributes remediations as part of its monthly/patch cadence; the Security Update Guide entry is the authoritative confirmation that the problem is real and that vendor fixes are available. However, Microsoft’s public advisory text is intentionally concise in many inbox‑component advisories, so defenders must rely on the KB→SKU mapping in Microsoft’s update pages to ensure correct deployment. What the record currently says
- Vulnerability class: Improper link resolution before file access (link‑following). This is sometimes written as CWE‑59.
- Impact: Local elevation of privilege — an authorized (local) attacker with the ability to manipulate filesystem reparse points or links can cause the privileged host process to act on attacker‑controlled files or directories.
- Attack vector: Local / authenticated — exploitation requires local code execution or the ability to create and switch symbolic links/junctions in locations the scheduled task or host touches.
- Reported severity: CVSS v3.1 ≈ 7.8 (High) as reflected in multiple vulnerability aggregators.
- Vendor remediation: Microsoft has published updates in the normal servicing channels (cumulative/LCU and, where applicable, hotpatches/OOB packages); administrators must confirm the specific KB for each affected build before deployment. Example KBs tied to the update wave include December 9, 2025 packages such as KB5072033 and hotpatch KB5072014.
How link‑following in a privileged host becomes dangerous
The technical pattern (high level)
Link‑following bugs occur when privileged code performs a path check or enumeration and later opens, deletes, or writes the same path without re‑validating that the target is unchanged. An attacker who can create NTFS reparse points (symbolic links, junctions) in the locations the privileged host consults can redirect privileged I/O to attacker‑controlled paths. That redirection may allow a non‑privileged user to:- cause privileged deletion or replacement of files and folders,
- induce privileged writes into attacker locations (leading to DLL hijack or binary replacement), or
- cause a privileged process to load attacker‑controlled code via search‑path or current‑directory resolution.
Attacker model and preconditions
- The attacker must have a local authenticated account or be able to run code in a user context on the host.
- The attacker must be able to create or manipulate filesystem reparse points or directory structures under locations observed by the privileged Host Process task. On many Windows systems this is feasible from a standard user account if the vulnerable task touches per‑user locations such as %LOCALAPPDATA% or other writable folders.
Confirmed and plausible specifics — what’s verified, what’s inferred
- Verified: Microsoft lists the entry in its Security Update Guide; vendor updates that fix the issue are published in normal servicing channels. Confirm the CVE→KB mappings before deploying updates.
- Reported by multiple independent vulnerability trackers (CVE mirrors, cvedetails, cvefeed): a high‑level classification of link‑following and a CVSS v3.1 base score near 7.8. Use those external trackers for triage, but rely on Microsoft’s KB mapping for remediation.
- Plausible details reported by some vendor/third‑party writeups: researchers and vendors (including Positive Technologies / PT Security summaries) have reported that the weakness can be triggered via artifacts under a per‑user CoreAIPlatform path and that the affected scheduled task includes Windows AI Recall or WindowsAIRecallPolicyConfiguration components. Those vendor reports provide concrete exploitation narratives but are not verbatim Microsoft statements — treat them as useful researcher guidance that should be validated against the KB diffs or Microsoft CSRF/CSAF advisory before baking into production detection logic. Flag: these specifics are currently corroborated by multiple trackers but are not the canonical Microsoft technical disclosure.
Operational risk: what this means for organizations
This vulnerability targets a privileged host that routinely runs on client and server systems and can act with elevated rights when executing scheduled tasks. Operational consequences include:- Rapid privilege escalation after an initial compromise: attackers who obtain low‑privilege local access can often convert that foothold into SYSTEM rights.
- Potential supply‑chain or persistence opportunities: replacing files or injecting into scheduled‑task payloads can persist attacker control or seed downstream compromise if privileged processes load attacker artifacts.
- High priority for management hosts and multi‑user systems: jump boxes, admin workstations, RDS/VDI hosts and servers that run taskhost‑backed scheduled tasks must be triaged first.
Immediate mitigation and remediation checklist (ranked, tactical)
- Inventory and identify affected hosts by build and SKU using your patch‑management tooling. Confirm the exact KB from Microsoft’s update pages before deploying updates. If your environment uses WSUS, SCCM, or an enterprise patch system, ensure MSRC→KB mapping is resolved accurately.
- Patch high‑value and high‑exposure hosts first: admin workstations, jump boxes, remote desktop/VDI servers, build servers, developer workstations, and any host that runs scheduled tasks with elevated context. Apply the vendor updates and reboot where required.
- If immediate patching is impossible, consider short‑term mitigations:
- Disable or pause the specific scheduled task(s) that run Windows AI Recall / WindowsAIRecallPolicyConfiguration if and only if your environment does not depend on them for critical operations. Confirm the exact task name in your environment before taking action.
- Restrict symbolic‑link creation where feasible: enforce developer‑mode restrictions (avoid enabling Developer Mode on production assets), and review SeCreateSymbolicLinkPrivilege assignments in privileged groups. (Caveat: this control can be operationally sensitive and must be evaluated per environment.
- Increase segmentation and reduce local administrator footprints on workstations and endpoints to reduce the number of accounts that can create reparse points in user‑writable locations.
- Enable focused detection and hunting:
- Watch for unexpected deletes / renames / writes performed by taskhostw.exe or related host processes. Look for SYSTEM ownership on deleted or replaced files that should be inaccessible to standard users.
- Monitor creation and manipulation of NTFS reparse points, symbolic links, and junctions under %LOCALAPPDATA% and other per‑user locations accessed by scheduled tasks.
- Track process ancestry for any privileged process that spawns cmd.exe, PowerShell, or unexpected binaries after scheduled‑task execution. These sequences are common telltales of post‑exploit activities.
- Validate remediation: after patching, confirm the KB is installed and the host rebooted where required. Conduct post‑patch detection sweeps to find exploitation artifacts that may predate remediation.
Technical detection signatures and hunting queries (practical)
- EDR rule: alert on taskhostw.exe or taskhostex.exe performing filesystem operations (CreateFile / DeleteFile / ReplaceFile) under paths outside expected system locations, especially writes that result in SYSTEM‑owned files appearing in user‑writable directories.
- SIEM query: file system audit events (Windows Audit: "Deleted" / "Created") where SubjectAccount is SYSTEM and the prior owner or caller context resolves to a standard user process or a taskhost instance.
- Reparse point monitor: audit calls to CreateSymbolicLink/CreateMountPoint and new reparse point entries in %LOCALAPPDATA% and temp directories. Search for directory names that match GUID patterns
{????????-????-????-????-????????????}if vendor writeups indicate such filters are used (validate before deploying signatures). Treat pattern specifics from third‑party writeups as provisional until verified.
Risk analysis: strengths, weaknesses, and unknowns
Strengths (what defenders can rely on)
- Vendor confirmation via Microsoft’s Security Update Guide establishes high confidence that a real issue exists and that Microsoft has shipped fixes; use the MSRC entry and KB mapping as the canonical source for remediation.
- The vulnerability is local only, so network‑only exposures (unless combined with another foothold) are not directly implicated; this gives defenders time to triage and prioritize host patching rather than panic‑mode emergency network containment.
Weaknesses and attacker advantages
- Link‑following is a low‑complexity exploit class in many environments: once an attacker has local code execution or an ability to drop/juggle reparse points, exploitation can be automated and reliable. This reduces the attacker cost for post‑compromise escalation.
- Scheduled tasks run frequently on both desktops and servers; the privileged nature of system tasks amplifies the impact of local exploits. Jump boxes and admin workstations are particularly high‑value targets.
Unknowns and cautionary flags
- Microsoft’s public advisory for the CVE is intentionally brief and may omit low‑level exploit mechanics; any precise implementation details (exact file paths, task names, internal function names) reported outside Microsoft should be treated as reported by researchers and verified against KB diffs or the vendor’s CSAF/patch notes before embedding into automated remediation or detection logic. Several third‑party writeups name concrete paths and task names — useful leads, but unverified by Microsoft’s advisory copy.
Recommended remediation playbook (concrete, prioritized steps)
- Within 24 hours: inventory affected systems by build and SKU. Use your patch inventory to identify hosts missing the December 9, 2025 fixes (example KBs: KB5072033, KB5072014) and map the CVE→KB correctly.
- Within 72 hours: patch and reboot high‑value hosts (domain controllers are not implicated by this local vector unless a domain compromise yields local code on a DC — still, prioritize management hosts first). If patching is blocked, disable the specific scheduled task(s) after confirming their purpose and risk to business continuity.
- During rollout: enforce compensating controls — application allow‑listing (WDAC/AppLocker), reduce local admin counts, and block execution from user‑writable paths — to reduce the opportunity for follow‑on payload execution even if an attacker obtains SYSTEM via EoP.
- Post‑deployment (2 weeks): run behavioral hunts for indicators of pre‑patch exploitation, review EDR alerts for SYSTEM‑owned file changes, and perform a forensics sweep on high‑value hosts. Validate that the expected KBs are installed and recorded in change logs.
Why the MSRC “confidence / technical detail” signal matters
Microsoft sometimes publishes terse advisory entries for inbox or management‑plane components to prevent rapid exploitation while fixes are staged. That vendor posture means defenders must treat the MSRC entry as the canonical signal that a fix exists, but not as the complete technical disclosure. Prioritize vendor KB application and then use vendor KB diffs, CSAF advisories, or independent technical write‑ups for precise detection and remediation steps. Relying solely on third‑party CVE mirrors without validating KB mapping is a common operational failure mode during patch waves.Conclusion
CVE‑2026‑20941 (Host Process for Windows Tasks Elevation of Privilege) — reflected in earlier tracker aliases such as CVE‑2025‑60710 in some mirrors — is a vendor‑confirmed local elevation‑of‑privilege flaw rooted in improper link resolution. The practical risk is acute for environments where attackers can already obtain local execution, and the available fix path is unambiguous: confirm Microsoft’s KB→SKU mapping, prioritize patching of administrative and high‑exposure hosts, and implement short‑term mitigations where patching cannot be immediate. Use third‑party technical writeups as hunting leads but validate specific path/task claims against Microsoft KB diffs or the vendor’s advisory before embedding them into detection or change‑control logic. For Windows administrators running scheduled tasks or AI/recall‑style features that use the Host Process for Windows Tasks, the remediation sequence is straightforward and urgent: inventory, map CVE→KB, patch, validate, and hunt. This vulnerability is a textbook example of how privileged hosts and unsuspecting filesystem semantics can be converted into a reliable privilege escalation primitive — the technical details matter, but the operational response is clear and immediate.Source: MSRC Security Update Guide - Microsoft Security Response Center
