The 'authorized attacker' qualifier in CVE-2026-62726 tells you something critical: this use-after-free in Windows Telephony Service is not your initial access vector. It's the privilege escalation pivot — the second stage that takes you from a foothold to SYSTEM. That's the analytical frame you need to adopt, because treating this as a standalone local privilege escalation bug badly understates the actual threat.
Windows Telephony Service runs with elevated privileges and exposes complex COM interfaces that manage stateful telephony sessions. A use-after-free in that context is a high-value target precisely because it's a force multiplier. But those interfaces are only reachable if you already have local access. So your threat model needs to answer: what initial access vector are your adversaries using that would make this UAF the escalation step in their chain? Phishing, credential theft, a separate RCE — this CVE does nothing for those, but it dramatically amplifies any compromise that gets a user-level shell.
The EPSS score of 0.00252 should not comfort you. It reflects the absence of a public proof-of-concept, not difficulty of exploitation. UAFs in privileged Windows services get weaponized quickly once a PoC circulates. Treat this as 'watch closely' — not because the bug is theoretical, but because the exploitability chain is still being assembled in the wild.
Two questions demand answers in your environment. First, identify your likely initial access vectors and model whether this CVE fits into those attack paths. Second, determine whether Windows Telephony Service is actually in use — it ships disabled by default on many installations but remains present, creating exposure most defenders don't account for.
Beyond patching, there's a systemic pattern worth recognizing: use-after-free vulnerabilities in high-privilege Windows services cluster around codebases that have accumulated complexity through successive patch cycles without fundamental refactoring. TAPI has been in maintenance mode for roughly a decade with no public evidence of active security auditing for modern Windows versions. If this UAF exists in TAPI, similar lifetime management bugs almost certainly exist in other legacy privileged services that haven't received fresh security eyes. Your patch horizon shouldn't be 'just TAPI' — it should be 'which other defaulted Windows services with decades-old COM interfaces are in my environment, and when did they last get a security review rather than cumulative updates?'