CVE-2026-35423

What it actually does

This is a network-reachable out-of-bounds read in the Microsoft Windows Telnet Client. An unauthenticated attacker can trigger unsafe memory reads when a vulnerable client processes malicious Telnet server responses or negotiation data. Because the vulnerable component is the client, exploitation requires user interaction: a user, administrator, script, or tool must initiate a Telnet connection to an attacker-controlled or compromised server. Successful exploitation can disclose limited process memory and may also cause the Telnet Client process to terminate unexpectedly; integrity impact is not indicated.

Why it matters to the business

Organizations that still have the Windows Telnet Client enabled may face limited information disclosure risk if users or administrators connect to untrusted Telnet services. The risk is lower than actively exploited remote-code-execution issues because the flaw requires interaction, has low EPSS, is not in CISA KEV, and has no known public exploit maturity, but Telnet is commonly used for legacy troubleshooting and administration, so exposure can persist on workstations, jump hosts, and servers. The operational consequence is potential leakage of sensitive data present in client memory and possible disruption of Telnet-based administrative workflows.

How an attack unfolds

An attacker prepares a malicious Telnet service or compromises an existing Telnet-accessible host. The attacker then persuades a user or administrator to connect with the Windows Telnet Client, or waits for routine troubleshooting activity to reach the malicious service. During the Telnet session setup or protocol negotiation, the server sends malformed data that causes the client to read beyond the intended memory boundary. The attacker may receive unintended memory contents over the network or cause the Telnet Client process to crash. Because exploitation depends on an outbound client connection, detection should focus on Telnet Client enablement, execution of telnet.exe, and outbound TCP/23 sessions to untrusted or unusual destinations.

How to fix it

Apply the relevant Microsoft security updates for all affected Windows versions as they become available through Windows Update, Microsoft Update Catalog, WSUS, Intune, or other enterprise patching tools. No exact fixed build numbers were provided in the input, so remediation should be validated against Microsoft’s authoritative advisory and monthly cumulative update guidance for the affected Windows releases. Where Telnet is not explicitly required, disable or remove the Windows Telnet Client optional feature. Restrict outbound Telnet traffic, especially TCP/23, to approved legacy destinations only. Prefer encrypted and supported alternatives such as SSH, PowerShell Remoting over HTTPS, or vendor-supported management channels. For systems that must retain Telnet temporarily, limit use to trusted networks, block access to Internet-facing Telnet services, and monitor execution and outbound connections closely.

How to confirm the fix worked

Confirm that the relevant Microsoft cumulative/security update is installed on each affected Windows release by checking patch inventory, Windows Update history, or enterprise endpoint management records. Verify whether the Telnet Client optional feature is disabled on systems where it is not required using Windows Features, DISM, PowerShell optional feature inventory, or configuration management baselines. Confirm that outbound TCP/23 is blocked or restricted by host firewall, network firewall, proxy, or egress filtering policy. Validate that telnet.exe is absent, disabled, or execution-controlled where Telnet is not approved. For systems where Telnet must remain available, test that connections are limited to approved destinations and that endpoint telemetry captures process creation and network connection events for telnet.exe.

Typical attack path

1. Identify organizations or users likely to use Windows Telnet Client for legacy access or troubleshooting.
2. Host or compromise a Telnet service reachable by the target.
3. Lure a user, administrator, or script to initiate a Telnet connection to the attacker-controlled service.
4. Send malformed Telnet negotiation or response data to trigger the out-of-bounds read in the client.
5. Capture any leaked memory content returned over the network and optionally repeat attempts to maximize disclosure.
6. Use any recovered information, such as fragments of session data or sensitive process memory, to support further intrusion activity.

How to detect it

Post-exploitation evidence may be limited because this is a client-side information disclosure issue and may not create durable artifacts beyond normal process and network telemetry. Hunt for Telnet Client enablement and use, especially around connections to untrusted or unusual destinations. Relevant log sources include Windows Security process creation events, Sysmon process creation and network connection events, EDR telemetry, Windows optional feature/change-management records, PowerShell logs, command-line auditing, DNS logs, firewall logs, proxy logs if applicable, NetFlow, and packet capture for outbound Telnet. Look for telnet.exe started by users, scripts, shells, browsers, office applications, chat clients, or unusual parent processes. Review outbound TCP/23 sessions, particularly to Internet IPs, recently registered domains, rare destinations, or hosts not on an approved legacy-access list. Investigate crashes or abnormal termination of telnet.exe near suspicious Telnet sessions. Search for commands that enable the TelnetClient feature shortly before use. If packet capture is available, inspect Telnet negotiation streams for malformed or unusual option negotiation followed by client instability or repeated reconnects. Since no named threat actors or public exploit campaigns were provided, treat findings as suspicious based on behavior and destination reputation rather than a known campaign signature.

• C:\Windows\System32\telnet.exe
• C:\Windows\SysWOW64\telnet.exe
• telnet.exe
• TelnetClient
• Enable-WindowsOptionalFeature -Online -FeatureName TelnetClient
• Disable-WindowsOptionalFeature -Online -FeatureName TelnetClient
• dism /online /Enable-Feature /FeatureName:TelnetClient
• dism.exe /online /Enable-Feature /FeatureName:TelnetClient
• pkgmgr /iu:TelnetClient
• DestinationPort=23
• dest_port=23
• tcp/23
• EventCode=4688 telnet.exe
• EventID=1 Image=*\telnet.exe
• EventID=3 Image=*\telnet.exe DestinationPort=23
• New-Object System.Net.Sockets.TcpClient
• telnet

What your security team should do

• Inventory endpoints and servers for the Windows Telnet Client optional feature and prioritize removal where there is no business requirement.
• Patch affected Windows 10, Windows 11, and Windows Server systems through the appropriate Microsoft cumulative/security update channel.
• Block or tightly restrict outbound TCP/23 traffic to approved legacy destinations only.
• Create detections for telnet.exe execution and outbound Telnet connections, especially to Internet destinations or newly observed internal hosts.
• Replace Telnet-based operational procedures with encrypted alternatives such as SSH or supported remote management protocols.
• Review scripts, runbooks, monitoring checks, and legacy administration tools that may invoke telnet.exe.
• Treat unexpected Telnet Client enablement or execution on administrator workstations, jump hosts, and servers as suspicious and investigate promptly.
• Because this issue is not currently KEV-listed, has low EPSS, and has no known exploit maturity, prioritize remediation according to exposure, Telnet usage, and asset criticality rather than emergency response.