Windows Telnet Client EUVD-2026-72976

Exploitation requires the optional Windows Telnet Client feature to be installed/enabled (it is NOT present by default on modern Windows) and requires the victim to initiate a Telnet connection from telnet.exe to an attacker-controlled or malicious server - the network path is client-to-server, so despite the vendor's UI:N rating, practical exploitation depends on user-initiated connection to a hostile endpoint. It is limited by these factors: the feature must be enabled, the user must connect to attacker-controlled infrastructure, and code executes in the connecting user's security context (no evidence of automatic privilege elevation).

The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H = 9.8) implies fully remote, unauthenticated, no-interaction exploitation with total system impact - but this is a CLIENT-side flaw: an attacker realistically must lure or coerce a victim into connecting telnet.exe to an attacker-controlled server, which is user interaction (UI:R) that Microsoft's vector does not reflect. This discrepancy materially lowers real-world risk versus the raw 9.8; treat the effective severity closer to CVSS ~8.8. No EPSS score, KEV listing, or POC is present in the provided data, so there is no evidence of active or imminent exploitation. Critically, the Telnet Client is not installed by default on modern Windows, further constraining the exposed population. Net: a serious memory-corruption bug worth patching in the normal cycle, but the headline 9.8 overstates practical priority for environments that do not run the Telnet Client.

An attacker stands up a malicious Telnet server and, via phishing, a rogue link/command, or a compromised internal host, induces a victim to run 'telnet <attacker>' from a vulnerable Windows machine. The server returns crafted Telnet negotiation/response data that overflows a heap buffer in telnet.exe, executing attacker-supplied code in the user's context. No public exploit is identified at time of analysis.