PuTTY 0.84 Released: Patching ECDSA Verification, RSA KEX Double-Free, and Telnet State Flaws

The PuTTY project has officially rolled out version 0.84, a maintenance release designed to patch three distinct security vulnerabilities. While these flaws are currently classified as low severity, they target fundamental aspects of the client’s communication stack—specifically SSH key exchange mechanisms and Telnet session state management. For administrators and power users who rely on PuTTY as a primary gateway for secure remote management, these updates provide critical stability and integrity safeguards.

Addressing Elliptic Curve Cryptography (ECC) Integrity

The most significant fix in this release targets a vulnerability within the Elliptic Curve Digital Signature Algorithm (ECDSA) verification process used during SSH key exchanges. As documented in recent security advisories, a specific mathematical edge case in the signature verification logic could trigger an assertion failure, leading to an immediate application crash.

From a threat modeling perspective, this is a Denial-of-Service (DoS) vector. A Man-in-the-Middle (MitM) attacker could intercept a connection and present a specially crafted host key and signature. Because PuTTY executes the signature verification routine prior to validating the host key against the local cache, the crash occurs before the user receives any visual warning of a potential interception. While this vulnerability does not facilitate remote code execution (RCE) or data exfiltration, it can lead to the loss of unsaved session configurations and interrupted workflows. Notably, this affects NIST-standard curves (P-256, P-384, and P-521), whereas modern Edwards-curve signatures like Ed25519 remain resilient.

Mitigating Memory Corruption in RSA Key Exchange

The second patch addresses a memory management flaw specifically within the RSA Key Exchange (RSA KEX) implementation. This issue, present in versions 0.72 through 0.83, involves a “double-free” vulnerability. This occurs when a malicious or malformed server sends an invalid short RSA key during the initial handshake, triggering an error-handling path that attempts to release the same memory address twice.

While double-free errors are traditionally high-risk because they can occasionally be leveraged to achieve memory corruption or arbitrary code execution, there is currently no evidence of such exploitation in the wild for PuTTY. At present, the primary impact remains a controlled application crash. However, given the inherent risks of heap-based memory corruption, patching this legacy component is a vital step in hardening the client’s attack surface.

Fixing the Telnet “Trust Sigil” Spoofing Risk

The third vulnerability targets the “trust sigil”—a visual security feature designed to provide users with a psychological “anchor” to distinguish between legitimate client prompts and spoofed server responses.

In affected versions, a logic error exists in how session state is handled during Telnet proxy authentication. If a user authenticates through a proxy, the “trusted” status of the session is not properly cleared upon completion. Consequently, the trust indicator remains active for the remainder of the session. An attacker could exploit this by injecting fake password prompts or sensitive data requests that appear to be part of a “trusted” stream, potentially tricking users into entering credentials for the proxy or other services. While Telnet is an inherently insecure, unencrypted protocol, this flaw undermines the very visual safeguards PuTTY provides to mitigate user error.

Conclusion and Hardening Recommendations

In addition to these fixes, version 0.84 addresses CVE-2026-4115 regarding EdDSA signature handling, though the maintainers suggest this poses a negligible real-world risk.

Recommended Actions:

  • Immediate Upgrade: Transition all workstations to PuTTY 0.84 to mitigate the discussed DoS and spoofing vectors.
  • Protocol Hygiene: Deprecate the use of Telnet in favor of SSH whenever possible.
  • Configuration Hardening: Disable unused or legacy key exchange methods, such as RSA KEX, within your PuTTY configuration to reduce the available attack surface.
  • Monitoring: Keep an eye on unexpected SSH client crashes, as these may be early indicators of attempted exploitation attempts.

Related Articles

Back to top button