CVE-2026-116775 in russh
Summary
by MITRE • 10/27/2026
pageant provides a PageantStream type that implements AsyncRead and AsyncWrite traits and can be used to communicate with a running Pageant instance. From 0.2.0 until 0.2.5, PageantStream::new in pageant/src/wmmessage.rs trusts a peer-controlled four-byte length prefix and buffers until len + 4 bytes are available without checking the fixed _AGENT_MAX_MSGLEN transport capacity. An application that bridges an SSH forwarded-agent channel to the raw stream can allow a malicious server to force large allocations or retain a partially filled frame, causing client memory exhaustion. This issue is fixed in version 0.2.5.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/27/2026
The vulnerability identified within the pageant library stems from improper input validation regarding message length prefixes during inter-process communication with an SSH authentication agent. Specifically, the PageantStream type, which implements asynchronous read and write traits to facilitate interaction with a running Pageant instance, contains a critical flaw in its initialization logic found between versions 0.2.0 and 0.2.5. The core issue resides in the PageantStream::new function located within the wmmessage.rs source file. This component is responsible for establishing a communication channel that relies on a four-byte length prefix to determine the size of incoming messages from a peer, typically an SSH server or client bridging through an agent forwarding channel.
The technical flaw involves the library's failure to validate this peer-controlled length field against the defined maximum message capacity known as _AGENT_MAX_MSGLEN. When PageantStream::new is invoked, it trusts the four-byte integer provided by the remote party without performing any bounds checking or sanity verification. Consequently, if a malicious actor controls the input stream and supplies an excessively large value for this length prefix, the application will proceed to allocate memory buffers sized according to that untrusted value plus the four bytes of overhead. This behavior ignores the fixed transport capacity limits designed to prevent such scenarios in secure SSH agent implementations.
The operational impact of this vulnerability is significant, primarily manifesting as a denial-of-service condition through resource exhaustion on the client side. An attacker operating a malicious server can exploit this flaw by initiating an SSH connection with agent forwarding enabled and subsequently sending a crafted message header containing a massive length value. The victim application will then attempt to allocate memory for a buffer that is disproportionately large relative to available system resources. This action forces the allocation of potentially gigabytes of RAM, leading to rapid memory exhaustion on the client machine. Furthermore, even if full allocation fails or is delayed, the library may retain partially filled frames in memory while waiting for data that will never arrive, further contributing to resource leakage and potential application instability or crash.
This vulnerability aligns with CWE-400, which describes uncontrolled resource consumption, as well as CWE-1321, concerning improper validation of message length fields. In the context of attack tactics, this exploitation vector corresponds to ATT&CK technique T1496, Resource Hijacking, where an adversary consumes resources to degrade service availability for legitimate users. The risk is particularly acute in environments where SSH agent forwarding is commonly used across untrusted networks or when connecting to potentially compromised remote servers that might attempt to exploit client-side implementations of the SSH protocol.
To mitigate this vulnerability, organizations and developers must ensure they are using version 0.2.5 or later of the pageant library, which includes fixes for this input validation gap. For systems where upgrading is not immediately feasible, defensive coding practices should be implemented by manually validating any length prefixes received from untrusted sources against known maximum message sizes before initiating buffer allocations. Additionally, implementing strict timeouts and memory limits on network connections can help limit the blast radius of such attacks. It is also advisable to review SSH agent forwarding configurations to ensure they are only used in trusted environments where the remote server's integrity can be assured, thereby reducing the attack surface for this specific class of resource exhaustion exploits.