Windows Telephony Service CVE-2026-62729

Exploitation requires a locally authenticated account with at minimum standard user (low) privileges - remote unauthenticated exploitation is not possible given AV:L/PR:L in the CVSS vector. The Windows Telephony Service (TapiSrv) must be running, which is the default state on most Windows desktop and server installations. Exploitation further requires the attacker to win a race condition (AC:H), meaning repeated attempts or multi-threaded tooling is necessary; this is reliably achievable on multi-core systems but limits single-shot exploitation. No specific non-default configuration of TAPI is required - the flaw exists in core service logic. Limiting factors: no network-accessible attack path; no unauthenticated exploitation; race complexity reduces automated exploitation reliability; requires code execution in user context (e.g., via prior phishing, malware drop, or interactive session).

The CVSS 3.1 base score of 7.0 with vector AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H accurately characterizes the risk profile: local access and authenticated low-privilege user required, with high attack complexity reflecting the race condition's timing dependency. Full CIA impact (C:H/I:H/A:H) reflects that successful SYSTEM-level escalation yields complete control of the local machine. EPSS data was not provided in the intelligence, so exploitation probability cannot be quantified. The vulnerability is absent from CISA KEV and no POC is identified, which meaningfully reduces near-term mass exploitation risk. However, local privilege escalation flaws in Windows are routinely chained by post-exploitation frameworks (e.g., after phishing or initial access via another bug), making patching important even without active exploitation signals. The 'Information Disclosure' tag is inconsistent with the full C:H/I:H/A:H CVSS impact - the CVSS vector is the authoritative signal; the tag likely reflects a secondary data-exposure facet or is a tagging artifact. The AC:H metric correctly signals that reliably exploiting a race condition requires precision timing, limiting opportunistic or fully automated exploitation.

A low-privileged attacker with interactive or remote desktop access to a Windows system (or malware executing in a standard user context) spawns multiple concurrent threads that invoke Windows Telephony Service APIs, deliberately racing shared service state across synchronization gaps. By winning the race window at the critical moment of a privilege check or memory operation, the attacker corrupts telephony service state to redirect execution to attacker-controlled code running as SYSTEM. No public exploit code exists at time of analysis, but the reliability of this technique depends on consistently winning the race, which is achievable on modern multi-core hardware with sufficient iteration.