CVE-2026-102820 in pageant
Summary
by MITRE • 09/29/2026
pageant provides a [PageantStream] type that implements [AsyncRead] and [AsyncWrite] traits and can be used to talk to a running Pageant instance. Prior to pageant 0.2.3, the Windows pageant crate's pageant/src/wmmessage.rs MemoryMap::read function trusts a peer-controlled u32 response length supplied through the 8192-byte Pageant shared-memory mapping reached by AgentClient::connect_pageant. A local process that impersonates the Pageant window can make query_pageant_direct allocate up to approximately 4 GiB and copy beyond the mapped view, reliably crashing a russh client and conditionally exposing adjacent committed memory. This issue is fixed in pageant 0.2.3.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/29/2026
The vulnerability identified within the Pageant crate prior to version 0.2.3 represents a critical buffer over-read resulting from insufficient validation of peer-supplied input data during inter-process communication on Windows systems. The core technical flaw resides in the MemoryMap::read function, which is invoked when an AgentClient attempts to connect to a running Pageant instance via shared memory mappings. Specifically, the application trusts a u32 value representing the response length provided by the remote peer without verifying that this value remains within the bounds of the allocated 8192-byte shared-memory mapping. This lack of boundary checking allows a malicious local process impersonating the legitimate Pageant window to supply an excessively large length field, effectively bypassing standard memory safety protections inherent in Rust's typical abstractions when interacting with low-level system APIs.
From an operational perspective, this flaw enables a denial-of-service attack against applications utilizing russh or similar SSH clients that rely on Pageant for authentication agent communication. By triggering the allocation of up to approximately 4 GiB of virtual memory and forcing the copying operation beyond the mapped view, the vulnerability causes reliable crashes in the affected client software. Furthermore, because the read operation accesses memory regions adjacent to the shared mapping, there is a conditional risk of information disclosure where sensitive data from other processes or system structures may be exposed if those pages are committed and accessible within the process address space. This scenario highlights the dangers of trusting unvalidated metadata in IPC mechanisms, particularly when dealing with shared memory segments that facilitate communication between distinct security contexts on Windows platforms.
In terms of industry standard classifications, this vulnerability aligns closely with CWE-126 Buffer Over-read, as it involves reading data beyond the intended buffer boundary due to improper limit enforcement. Additionally, given its nature as a local privilege escalation vector through impersonation and memory corruption leading to service disruption or potential information leakage, it relates to CWE-787 Out-of-bounds Write/Read in broader contexts of integrity violation, though primarily manifesting here as an over-read. The attack technique mirrors aspects found in the MITRE ATT&CK framework under Local Privilege Escalation and potentially Data from Information Repository if adjacent memory contents are successfully exfiltrated, demonstrating how IPC flaws can be leveraged to compromise system stability and confidentiality.
The recommended mitigation is straightforward: upgrade the Pageant crate to version 0.2.3 or later, where this issue has been resolved by implementing proper bounds checking on the response length field before performing any memory copy operations. Developers integrating this library should ensure that their dependency management systems enforce this minimum version requirement. For organizations relying on russh or similar SSH clients, verifying that all components are updated to patched versions is essential to prevent exploitation of this shared-memory validation flaw. Until updates can be applied, monitoring for abnormal memory allocation spikes in Pageant-related processes may serve as a temporary detection mechanism for attempted exploits targeting this specific vulnerability vector.