CVE-2026-102820: Out-of-Bounds Read and Excessive Memory Allocation in russh pageant

The pageant crate functions as a workspace utility inside the russh SSH client library, facilitating communications with the PuTTY Pageant SSH agent on Windows systems.

This communication depends on local Inter-Process Communication (IPC) involving Windows Messaging (WM_COPYDATA) and Shared Memory Map Views. The client establishes a shared file mapping with a static capacity constraint of 8,192 bytes (8 KiB) and passes this file name to the Pageant agent, which then writes responses directly to the shared space.

The vulnerability is located in the MemoryMap::read parser within the pageant/src/wmmessage.rs file. By failing to validate the boundaries of incoming messages, the parser exposes the client program's runtime memory to crashes or local information leaks. This flaw represents a severe design oversight when handling boundaries inside shared memory mappings.

The root cause of the vulnerability lies in the implementation of the MemoryMap::read stream reader and its interaction with the query_pageant_direct handler. When reading raw responses, the client first reads a 4-byte length prefix directly from the shared memory view, parsing it as a big-endian u32 value assigned to the variable size.

Because the peer process (which can be impersonated by any standard user process on the same desktop environment) fully controls this shared memory view, the size variable can be manipulated to contain arbitrary values. The library then executes MemoryMap::read(size) without validating whether the requested index range (self.pos + size) exceeds the physical size of the memory map (self.length), which is typically bounded at 8,192 bytes.

This lack of validation triggers two primary failure modes: first, an Out-of-Memory (OOM) abort via CWE-789 due to an excessive vector allocation size request; and second, an Out-of-Bounds Read (CWE-125) during the execution of std::ptr::copy_nonoverlapping inside an unsafe block. If the copy operation points to adjacent unmapped system space, the OS terminates the process with an access violation.

The sequence of IPC messaging and the interception point where a malicious local process triggers the crash are represented in the flowchart below.

This architecture highlights that the security of this local communication depends entirely on verifying boundary limits during the parsing phase, since the Windows Messaging API does not inherently isolate client-to-agent channel registrations within standard interactive sessions.

An inspection of the vulnerable source code confirms that raw pointer operations were executed without bounds checking.

Below is the vulnerable implementation of the reader function:

// VULNERABLE: Prior to pageant version 0.2.3
impl MemoryMap {
    fn read(&mut self, n: usize) -> Vec<u8> {
        let out = vec![0; n]; // CWE-789: Excessive memory allocation if 'n' is massive
        unsafe {
            std::ptr::copy_nonoverlapping(
                self.ptr.add(self.pos),
                out.as_ptr() as *mut u8,
                n, // CWE-125: Out-of-bounds pointer copy if 'self.pos + n' > self.length
            );
        }
        self.pos += n;
        out
    } 
}

To address this vulnerability, the maintainers refactored the function's signature and introduced boundary validation checks:

// PATCHED: pageant version 0.2.3
impl MemoryMap {
    fn read(&mut self, n: usize) -> Result<Vec<u8>, Error> {
        // Validate bounds and prevent integer overflow using checked_add
        if self.pos.checked_add(n).is_none_or(|end| end > self.length) {
            return Err(Error::Overflow);
        }
        let out = vec![0; n];
        unsafe {
            std::ptr::copy_nonoverlapping(
                self.ptr.add(self.pos),
                out.as_ptr() as *mut u8,
                n,
            );
        }
        self.pos += n;
        Ok(out)
    }
}

This patch adds robust boundary checking. Using checked_add prevents integer wrapping attacks when calculating memory offsets, and checking end > self.length prevents reads from exceeding the size of the 8,192-byte file mapping. These modifications ensure that memory is only allocated if the request falls within the active map boundaries.

Exploiting this flaw requires local code execution within the victim's Windows session. This scenario is common in shared development server environments or terminal environments containing multi-user services.

An attacker can register a window class matching the standard name of the legitimate PuTTY Pageant program (Pageant). If the genuine Pageant agent is not running, the victim client's call to connect_pageant will target the malicious window handle. When the client transmits a request and waits for an answer, the attacker-controlled window receives the notification, writes a payload containing 0xFFFFFFFF into the first four bytes of the shared mapping, and signals the client to resume.

Upon parsing this length, the client allocates a 4 GiB buffer. Because standard 32-bit and some 64-bit user processes lack the memory allocation headroom for an immediate block allocation of this scale, the memory manager aborts the program. If the attacker specifies a size exceeding the remaining unread buffer but within system allocation limits, the copy_nonoverlapping function reads adjacent heap memory, exposing potential secrets if the application subsequently processes, logs, or transmits this data.

The CVSS vector is rated as CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, yielding a severity score of 6.2.

The attack vector is local (AV:L) because triggering the condition requires interacting with local Windows API messaging loops. Attack complexity is low (AC:L) because standard programmatic window registration and shared memory access do not require advanced administrative rights on Windows systems.

While the official classification rates Confidentiality Impact as None (C:N), the presence of an out-of-bounds pointer copy operation means that adjacent heap contents could be copied into the output vector. Depending on how the client application processes error buffers, this could lead to the exposure of other private SSH keys or session structures.