CVE-2026-42968

What it actually does

CVE-2026-42968 is a local information disclosure vulnerability caused by an out-of-bounds read in the Windows Telephony Service. An attacker who already has local, low-privileged authorized access can trigger the vulnerable code path and cause the service to read memory outside the intended bounds. The primary impact is confidentiality loss: data from process or adjacent memory may be exposed to the attacker. The CVSS vector indicates local access, low attack complexity, low privileges required, no user interaction, unchanged scope, high confidentiality impact, and no direct integrity or availability impact.

Why it matters to the business

Successful exploitation could allow a local user or malware already running on a Windows workstation or server to obtain sensitive information that should not be accessible to that user. While this is not a remote entry-point vulnerability and is not currently listed in CISA KEV, it affects a broad range of supported Windows client and server versions, including Windows 10, Windows 11, and Windows Server releases. The main business risk is that leaked memory data could help an attacker gather credentials, tokens, configuration details, or other sensitive information to support follow-on activity such as privilege escalation, lateral movement, or data theft. The current EPSS score is low and stable, and no public exploit maturity is reported, so remediation should be handled through normal but timely Windows patch management rather than emergency response unless sensitive multi-user systems are exposed.

How an attack unfolds

An attacker must first obtain local execution on an affected Windows system, such as through valid credentials, malware execution, abuse of an exposed interactive session, or compromise through a separate vulnerability. After gaining low-privileged local access, the attacker interacts with Windows Telephony Service functionality in a way that reaches the vulnerable memory-handling path. Because of an out-of-bounds read, the service may return or otherwise expose memory contents beyond the intended buffer boundary. The attacker then analyzes the disclosed data for useful secrets or process state, such as credentials, access tokens, memory pointers, configuration values, or other information that can assist additional attacks. This vulnerability is most useful as a post-compromise aid rather than an initial access vector.

How to fix it

Apply the Microsoft security update that addresses CVE-2026-42968 for all affected Windows versions, including Windows 10 1607, 1809, 21H2, and 22H2; Windows 11 23H2, 24H2, 25H2, and 26H1; and Windows Server 2012, 2016, 2019, 2022, and 2025. No exact fixed build numbers were provided in the input, so use Microsoft Update, Windows Server Update Services, Microsoft Configuration Manager, or the Microsoft Update Catalog to deploy the applicable cumulative update for the installed OS version. Prioritize shared servers, remote desktop hosts, VDI, developer workstations, jump hosts, and systems where untrusted or many low-privileged users can log on locally. If immediate patching is not possible, reduce exposure by limiting local logon rights, restricting interactive access to trusted administrators, disabling or restricting unnecessary telephony-related functionality where operationally feasible, and monitoring for unusual local access to Telephony Service interfaces. Mitigation should not be considered a substitute for applying the vendor fix.

How to confirm the fix worked

Confirm exposure by inventorying Windows endpoints and servers and identifying affected OS versions that have not received the applicable Microsoft security update released for this vulnerability. Validate remediation by checking Windows Update compliance, installed cumulative update history, and OS build numbers against Microsoft’s official fixed build guidance for the relevant Windows release. On individual systems, review Settings > Windows Update > Update history, Control Panel installed updates, or command-line sources such as Get-HotFix, wmic qfe, DISM package inventory, or enterprise patch-management reporting. Confirm that the Telephony Service is not unnecessarily exposed to broad local user populations and that local logon rights are appropriately restricted. Because the vulnerability is an information disclosure bug, successful exploitation may not leave a clear crash or service-failure artifact; patch state is the most reliable validation method.

Typical attack path

1. Gain local low-privileged access to an affected Windows workstation or server.
2. Identify that the Windows Telephony Service is present and the system has not received the relevant security update.
3. Invoke or interact with Telephony Service functionality that reaches the vulnerable out-of-bounds read condition.
4. Capture the disclosed memory data returned or exposed through the vulnerable path.
5. Analyze the leaked data for credentials, tokens, memory layout details, or sensitive configuration information.
6. Use any recovered information to support follow-on actions such as privilege escalation, lateral movement, or data access.

How to detect it

There are no public, vulnerability-specific exploitation indicators provided for this issue, and information disclosure through an out-of-bounds read may not generate distinctive logs. To assess possible prior exploitation, focus on post-compromise telemetry and unusual local interaction with Telephony Service components. Review Windows Security logs for suspicious local logons, new process creation if command-line logging is enabled, unusual service interaction, and activity by low-privileged accounts on systems where they normally do not operate. Relevant sources include Windows Security Event Logs, Sysmon logs, EDR process and module telemetry, service control activity, PowerShell logs, Windows Error Reporting, and application crash logs. Look for non-standard processes interacting with telephony-related services or libraries, repeated local execution by low-privileged users followed by credential access behavior, memory-dumping tools, abnormal access to LSASS, token impersonation attempts, or lateral movement shortly after suspicious local activity. Because EPSS is low, no KEV listing exists, and no exploit maturity is reported, detection should be risk-based and correlated with broader endpoint compromise indicators rather than relying on a single signature.

• Service name: TapiSrv
• Display name: Telephony
• Process name: svchost.exe
• Command line contains: -k NetworkService
• Command line contains: TapiSrv
• File path: C:\Windows\System32\tapisrv.dll
• File path: C:\Windows\System32\tapi32.dll
• Registry key: HKLM\SYSTEM\CurrentControlSet\Services\TapiSrv
• Windows Event ID 4624 with Logon Type 2 or 10 by an unusual low-privileged account
• Windows Event ID 4688 where a non-standard executable launches telephony-related tooling or loads tapi32.dll
• Sysmon Event ID 1 with command line containing TapiSrv
• Sysmon Event ID 7 with ImageLoaded ending in \tapi32.dll
• Sysmon Event ID 7 with ImageLoaded ending in \tapisrv.dll

What your security team should do

• Deploy the applicable Microsoft cumulative security updates to affected Windows clients and servers through standard patch-management workflows.
• Prioritize patching on multi-user systems, RDS/VDI hosts, jump boxes, domain administration workstations, and servers where low-privileged users or service accounts have local execution rights.
• Verify patch compliance using centralized endpoint management, vulnerability scanning, and OS build validation rather than relying only on service state.
• Review and minimize local interactive logon rights, especially on servers and privileged administration systems.
• Harden endpoints to prevent initial local code execution, including application control, least privilege, EDR coverage, and credential theft protections.
• Monitor for suspicious local process activity involving telephony-related components, especially when launched by non-administrative users or unusual parent processes.
• Treat any evidence of exploitation as a post-compromise signal and investigate for the initial access method and follow-on credential or token abuse.