Common Weakness Enumeration

CWE-789

Allowed

Memory Allocation with Excessive Size Value

Abstraction: Variant · Status: Draft

API response cwe.mitre.org

The product allocates memory based on an untrusted, large size value, but it does not ensure that the size is within expected limits, allowing arbitrary amounts of memory to be allocated.

531 vulnerabilities reference this CWE, most recent first.

GHSA-F9QC-QG88-7PQ5

Vulnerability from github – Published: 2026-08-28 18:34 – Updated: 2026-08-28 18:34
VLAI
Summary
Buffa Vulnerable to Memory Exhaustion Denial of Service in decode_unknown_field via Unbounded Allocation
Details

The decode_unknown_field function in buffa's protobuf decoder allocated heap memory in proportion to untrusted input (unknown fields in the serialized protobuf) without enforcing an allocation budget. Any message decoded from untrusted input using code generated with preserve_unknown_fields=true (the default) was affected. A small, well-formed payload of nested unknown fields inside a StartGroup could trigger roughly 22× memory amplification (e.g., a 64 MiB input forcing ~1.4 GB of heap allocation), and length-delimited unknown fields could be sized arbitrarily, enabling an unauthenticated attacker to crash a process via memory exhaustion. This was reachable from the default decode APIs, since the top-level message size cap did not account for in-decode amplification.

For users of connectrpc - the DEFAULT_MAX_MESSAGE_SIZE for connectrpc is 4MiB, which limits amplification in the worst case to ~88 MiB of memory. A flood of concurrent requests with this pattern could still be used to exhaust available memory, however.

Users are advised to either set preserve_unknown_fields=false on their current generated code, or upgrade to 0.8.0, which enforces per-message unknown field count limits - this is configurable, with a default of 1 million unknown fields, or ~40MiB of allocation overhead per message. Users are advised to update to the latest version, which enforces per-message unknown field count limits.

Thank you to @p80n-sec for reporting this issue.

Severity
6.3 (Medium)
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "buffa"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.8.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-55407"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-770",
      "CWE-789"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-28T18:34:22Z",
    "nvd_published_at": "2026-07-16T17:16:57Z",
    "severity": "MODERATE"
  },
  "details": "The `decode_unknown_field` function in buffa\u0027s protobuf decoder allocated heap memory in proportion to untrusted input (unknown fields in the serialized protobuf) without enforcing an allocation budget. Any message decoded from untrusted input using code generated with `preserve_unknown_fields=true` (the default) was affected. A small, well-formed payload of nested unknown fields inside a StartGroup could trigger roughly 22\u00d7 memory amplification (e.g., a 64 MiB input forcing ~1.4 GB of heap allocation), and length-delimited unknown fields could be sized arbitrarily, enabling an unauthenticated attacker to crash a process via memory exhaustion. This was reachable from the default decode APIs, since the top-level message size cap did not account for in-decode amplification. \n\nFor users of connectrpc - the DEFAULT_MAX_MESSAGE_SIZE for connectrpc is 4MiB, which limits amplification in the worst case to ~88 MiB of memory. A flood of concurrent requests with this pattern could still be used to exhaust available memory, however.\n\nUsers are advised to either set `preserve_unknown_fields=false` on their current generated code, or upgrade to 0.8.0, which enforces per-message unknown field count limits - this is configurable, with a default of 1 million unknown fields, or ~40MiB of allocation overhead per message.\nUsers are advised to update to the latest version, which enforces per-message unknown field count limits.\n\nThank you to @p80n-sec for reporting this issue.",
  "id": "GHSA-f9qc-qg88-7pq5",
  "modified": "2026-08-28T18:34:22Z",
  "published": "2026-08-28T18:34:22Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/anthropics/buffa/security/advisories/GHSA-f9qc-qg88-7pq5"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-55407"
    },
    {
      "type": "WEB",
      "url": "https://github.com/anthropics/buffa/pull/184"
    },
    {
      "type": "WEB",
      "url": "https://github.com/anthropics/buffa/commit/278fa43fcff661d4ee6bd83b75955a153d4281fc"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/anthropics/buffa"
    },
    {
      "type": "WEB",
      "url": "https://github.com/anthropics/buffa/releases/tag/v0.8.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Buffa Vulnerable to Memory Exhaustion Denial of Service in decode_unknown_field via Unbounded Allocation"
}

GHSA-FG3J-Q579-V8X4

Vulnerability from github – Published: 2021-06-15 15:54 – Updated: 2022-02-08 21:22
VLAI
Summary
Uncontrolled memory consumption
Details

In Apache PDFBox, a carefully crafted PDF file can trigger an OutOfMemory-Exception while loading the file. This issue affects Apache PDFBox version 2.0.23 and prior 2.0.x versions.

Severity
5.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.pdfbox:pdfbox"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0"
            },
            {
              "fixed": "2.0.24"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.pdfbox:pdfbox-parent"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0"
            },
            {
              "fixed": "2.0.24"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-31811"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-770",
      "CWE-789"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-06-14T19:39:19Z",
    "nvd_published_at": "2021-06-12T10:15:00Z",
    "severity": "MODERATE"
  },
  "details": "In Apache PDFBox, a carefully crafted PDF file can trigger an OutOfMemory-Exception while loading the file. This issue affects Apache PDFBox version 2.0.23 and prior 2.0.x versions.",
  "id": "GHSA-fg3j-q579-v8x4",
  "modified": "2022-02-08T21:22:40Z",
  "published": "2021-06-15T15:54:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-31811"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpuoct2021.html"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpujul2022.html"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpujan2022.html"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpuapr2022.html"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com//security-alerts/cpujul2021.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/MDJKJQOMVFDFIDS27OQJXNOYHV2O273D"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/7HHWJRFXZ3PTKLJCOM7WJEYZFKFWMNSV"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rfe26bcaba564deb505c32711ba68df7ec589797dcd96ff3389a8aaba@%3Cnotifications.ofbiz.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rf937c2236e6c79cdb99f76a70690dd345e53dbe0707cb506a202e43e@%3Cannounce.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/re3bd16f0cc8f1fbda46b06a4b8241cd417f71402809baa81548fc20e@%3Cusers.pdfbox.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/re3bd16f0cc8f1fbda46b06a4b8241cd417f71402809baa81548fc20e%40%3Cusers.pdfbox.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/re0cacd3fb337cdf8469853913ed2b4ddd8f8bfc52ff0ddbe61c1dfba@%3Ccommits.ofbiz.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rd4b6db6c3b8ab3c70f1c3bbd725a40920896453ffc2744ade6afd9fb@%3Cnotifications.ofbiz.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r2090789e4dcc2c87aacbd87d5f18e2d64dcb9f6eb7c47f5cf7d293cb@%3Cnotifications.ofbiz.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r179cc3b6822c167702ab35fe36093d5da4c99af44238c8a754c6860f@%3Ccommits.ofbiz.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r143fd8445e0e778f4a85187bd79438630b96b8040e9401751fdb8aea@%3Ccommits.ofbiz.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r132e9dbbe0ebdc08b39583d8be0a575fdba573d60a42d940228bceff@%3Cnotifications.ofbiz.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2021/06/12/2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Uncontrolled memory consumption"
}

GHSA-FM65-XRRR-C358

Vulnerability from github – Published: 2026-05-13 18:30 – Updated: 2026-06-16 21:31
VLAI
Details

A vulnerability exists in the ngx_http_scgi_module and ngx_http_uwsgi_module modules that may result in excessive memory allocation or an over-read of data. When scgi_pass or uwsgi_pass is configured, an unauthenticated attacker with man-in-the-middle (MITM) ability to control responses from an upstream server may be able to read the memory of the NGINX worker process or restart it.  Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:L
8.3 (High)
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:L/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-42946"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-789"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-13T16:16:50Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability exists in the ngx_http_scgi_module\u00a0and ngx_http_uwsgi_module\u00a0modules that may result in excessive memory allocation or an over-read of data. When scgi_pass\u00a0or uwsgi_pass\u00a0is configured, an unauthenticated attacker with man-in-the-middle (MITM) ability to control responses from an upstream server may be able to read the memory of the NGINX worker process or restart it.\u00a0 Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.",
  "id": "GHSA-fm65-xrrr-c358",
  "modified": "2026-06-16T21:31:53Z",
  "published": "2026-05-13T18:30:56Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42946"
    },
    {
      "type": "WEB",
      "url": "https://my.f5.com/manage/s/article/K000161027"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/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",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-FPF5-4JW8-67X8

Vulnerability from github – Published: 2026-05-07 01:54 – Updated: 2026-05-07 01:54
VLAI
Summary
rust-zserio has Unbounded Memory Allocation
Details

Impact

When deserializing arrays, strings or bytes (blob) types zserio first reads the size of the variable, and then allocates sufficient memory to load data. Since the size is always trusted this can be abused by creating a data file with a large size value, causing the zserio runtime to allocate large amounts of memory.

Patches

Please cherry-pick 57f5fb.

Workarounds

  • Do not accept zserio-encoded messages from non-trusted sources.
  • Allocate a maximum heap amount to rust-zerio to avoid impacting other applications.
Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.5.3"
      },
      "package": {
        "ecosystem": "crates.io",
        "name": "rust-zserio"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.5.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-789"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-07T01:54:57Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Impact\n\nWhen deserializing arrays, strings or bytes (blob) types zserio first reads the size of the variable, and then allocates sufficient memory to load data. Since the size is always trusted this can be abused by creating a data file with a large size value, causing the zserio runtime to allocate large amounts of memory.\n\n### Patches\n\nPlease cherry-pick [57f5fb](https://github.com/Danaozhong/rust-zserio/commit/57f5fb4a2a8611d58dbcc1a9221349206dd99c3c).\n\n### Workarounds\n\n- Do not accept `zserio`-encoded messages from non-trusted sources.\n- Allocate a maximum heap amount to `rust-zerio` to avoid impacting other applications.",
  "id": "GHSA-fpf5-4jw8-67x8",
  "modified": "2026-05-07T01:54:57Z",
  "published": "2026-05-07T01:54:57Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Danaozhong/rust-zserio/security/advisories/GHSA-fpf5-4jw8-67x8"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ndsev/zserio/security/advisories/GHSA-cwq5-8pvq-j65j"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Danaozhong/rust-zserio/commit/57f5fb4a2a8611d58dbcc1a9221349206dd99c3c"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Danaozhong/rust-zserio"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "rust-zserio has Unbounded Memory Allocation"
}

GHSA-FPG7-639F-4V49

Vulnerability from github – Published: 2026-10-12 21:31 – Updated: 2026-10-12 21:31
VLAI
Details

cbor-sync through 1.0.4 contains a resource exhaustion vulnerability in CBOR.decode that trusts declared array and map lengths without checking remaining input. Remote attackers can supply a tiny crafted CBOR payload declaring huge lengths to drive billions of iterations, exhausting CPU and process memory.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
8.7 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2020-37280"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-789"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-10-12T21:17:05Z",
    "severity": "HIGH"
  },
  "details": "cbor-sync through 1.0.4 contains a resource exhaustion vulnerability in CBOR.decode that trusts declared array and map lengths without checking remaining input. Remote attackers can supply a tiny crafted CBOR payload declaring huge lengths to drive billions of iterations, exhausting CPU and process memory.",
  "id": "GHSA-fpg7-639f-4v49",
  "modified": "2026-10-12T21:31:57Z",
  "published": "2026-10-12T21:31:57Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-37280"
    },
    {
      "type": "WEB",
      "url": "https://github.com/PelionIoT/cbor-sync/issues/6"
    },
    {
      "type": "WEB",
      "url": "https://github.com/PelionIoT/cbor-sync/pull/4"
    },
    {
      "type": "WEB",
      "url": "https://github.com/PelionIoT/cbor-sync"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/cbor-sync-through-1.0.4-memory-exhaustion-via-unchecked-cbor-array-lengths"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/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",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-FQ3V-74GV-27GM

Vulnerability from github – Published: 2026-10-07 20:22 – Updated: 2026-10-07 20:22
VLAI
Summary
Excelize: Unbounded <col max> attribute is loaded with no MaxColumns check and expanded per-column by flatCols(), so any column mutator hangs or OOMs the process
Details

Summary

The max attribute of a <col> element in xl/worksheets/sheetN.xml is read verbatim on open with no check against MaxColumns, and flatCols() then walks Min..Max doing a deepcopy.Copy and append per iteration. Executed: max="300000", only about 18x past the real 16384 limit, cost 46.2 s of CPU and 122 MB on a single SetColWidth call, and the growth is linear in max up to 2^31-1.

Confirmed at ae2113b (HEAD at the time of audit).

Details

col.go:547, flatCols(), with the two loops at :549 and :564:

for i := col.Min; i <= col.Max; i++ {
...
for i := column.Min; i <= column.Max; i++ { ... fc = append(fc, deepcopy.Copy(...)) }

column.Min and column.Max are plain int attributes on xmlWorksheet.go:279-280, bound straight from the file. MaxColumns is 16384 (templates.go:176) and nothing in the parse path compares against it.

The contrast that makes this an oversight rather than a design decision is inside the callers themselves. SetColWidth validates its own column argument through parseColRange, which clamps to MaxColumns. But flatCols iterates ws.Cols.Col, the file-loaded slice, so the caller's validated argument never constrains the loop. The crafted column expands no matter which column the caller touches.

The row axis has the guard this axis is missing: GHSA-h69g-9hx6-f3v4 capped checkSheet's row allocation at TotalRows, and GHSA-q5j5-6p94-4gwc capped streaming Rows.Next. There is no column-axis equivalent.

Public entry points that flatten the existing columns: SetColWidth (col.go:498 into :534), SetColStyle (col.go:431 into :477), SetColVisible (col.go:282 into :313), SetColOutlineLevel (col.go:376 into :407).

PoC

Executed in-package: crafted a real xlsx, rezipped with an injected <cols> block before <sheetData>, opened it with OpenReader, then called SetColWidth.

<cols><col min="1" max="2147483647" width="9"/></cols>

f.SetColWidth("Sheet1", "A", "A", 12)

Measured:

  • max="300000": 46.2 s CPU, 122 MB allocated, ws.Cols.Col grew to 300000 entries, from one call.
  • max="5000000": did not complete in 110 s, killed by the test timeout.

Growth is linear in max. At max=2147483647 that is roughly two billion xlsxCol allocations, which is hundreds of gigabytes and in practice a permanent hang ending in OOM.

Impact

Any service that opens an untrusted spreadsheet and calls a column mutator. The input is a few dozen bytes of XML inside an otherwise ordinary workbook, no authentication is involved beyond whatever gates the upload, and the process is either wedged for minutes or killed by the OOM reaper. Availability only; no read or write primitive here.

Suggested fix

Validate col.Min and col.Max against MinColumns/MaxColumns when parsing the <col> element, or at the top of flatCols, returning ErrColumnNumber for out-of-range values. That mirrors what checkRowNum already does on the row axis.

Why this is not GHSA-h69g-9hx6-f3v4 or GHSA-q5j5-6p94-4gwc

Both of those are row-axis allocation bounds, and both fixes cap at TotalRows. Neither touched <col> parsing or flatCols. This is the same weakness class on the column axis, and it is arguably worse than the two that were fixed, because those had a cap that was bypassed while this one has no cap at all.

Severity
7.1 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/xuri/excelize/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.1.0"
            },
            {
              "fixed": "2.11.1-0.20260807015645-a54c578af309"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-107223"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-789"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-07T20:22:49Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n\nThe `max` attribute of a `\u003ccol\u003e` element in `xl/worksheets/sheetN.xml` is read verbatim on open with no check against `MaxColumns`, and `flatCols()` then walks `Min..Max` doing a `deepcopy.Copy` and `append` per iteration. Executed: `max=\"300000\"`, only about 18x past the real 16384 limit, cost 46.2 s of CPU and 122 MB on a single `SetColWidth` call, and the growth is linear in `max` up to 2^31-1.\n\nConfirmed at `ae2113b` (HEAD at the time of audit).\n\n### Details\n\n`col.go:547`, `flatCols()`, with the two loops at `:549` and `:564`:\n\n```go\nfor i := col.Min; i \u003c= col.Max; i++ {\n...\nfor i := column.Min; i \u003c= column.Max; i++ { ... fc = append(fc, deepcopy.Copy(...)) }\n```\n\n`column.Min` and `column.Max` are plain int attributes on `xmlWorksheet.go:279-280`, bound straight from the file. `MaxColumns` is 16384 (`templates.go:176`) and nothing in the parse path compares against it.\n\nThe contrast that makes this an oversight rather than a design decision is inside the callers themselves. `SetColWidth` validates its own column argument through `parseColRange`, which clamps to `MaxColumns`. But `flatCols` iterates `ws.Cols.Col`, the file-loaded slice, so the caller\u0027s validated argument never constrains the loop. The crafted column expands no matter which column the caller touches.\n\nThe row axis has the guard this axis is missing: GHSA-h69g-9hx6-f3v4 capped `checkSheet`\u0027s row allocation at `TotalRows`, and GHSA-q5j5-6p94-4gwc capped streaming `Rows.Next`. There is no column-axis equivalent.\n\nPublic entry points that flatten the existing columns: `SetColWidth` (`col.go:498` into `:534`), `SetColStyle` (`col.go:431` into `:477`), `SetColVisible` (`col.go:282` into `:313`), `SetColOutlineLevel` (`col.go:376` into `:407`).\n\n### PoC\n\nExecuted in-package: crafted a real xlsx, rezipped with an injected `\u003ccols\u003e` block before `\u003csheetData\u003e`, opened it with `OpenReader`, then called `SetColWidth`.\n\n```xml\n\u003ccols\u003e\u003ccol min=\"1\" max=\"2147483647\" width=\"9\"/\u003e\u003c/cols\u003e\n```\n\n```go\nf.SetColWidth(\"Sheet1\", \"A\", \"A\", 12)\n```\n\nMeasured:\n\n- `max=\"300000\"`: 46.2 s CPU, 122 MB allocated, `ws.Cols.Col` grew to 300000 entries, from one call.\n- `max=\"5000000\"`: did not complete in 110 s, killed by the test timeout.\n\nGrowth is linear in `max`. At `max=2147483647` that is roughly two billion `xlsxCol` allocations, which is hundreds of gigabytes and in practice a permanent hang ending in OOM.\n\n### Impact\n\nAny service that opens an untrusted spreadsheet and calls a column mutator. The input is a few dozen bytes of XML inside an otherwise ordinary workbook, no authentication is involved beyond whatever gates the upload, and the process is either wedged for minutes or killed by the OOM reaper. Availability only; no read or write primitive here.\n\n### Suggested fix\n\nValidate `col.Min` and `col.Max` against `MinColumns`/`MaxColumns` when parsing the `\u003ccol\u003e` element, or at the top of `flatCols`, returning `ErrColumnNumber` for out-of-range values. That mirrors what `checkRowNum` already does on the row axis.\n\n### Why this is not GHSA-h69g-9hx6-f3v4 or GHSA-q5j5-6p94-4gwc\n\nBoth of those are row-axis allocation bounds, and both fixes cap at `TotalRows`. Neither touched `\u003ccol\u003e` parsing or `flatCols`. This is the same weakness class on the column axis, and it is arguably worse than the two that were fixed, because those had a cap that was bypassed while this one has no cap at all.",
  "id": "GHSA-fq3v-74gv-27gm",
  "modified": "2026-10-07T20:22:49Z",
  "published": "2026-10-07T20:22:49Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/qax-os/excelize/security/advisories/GHSA-fq3v-74gv-27gm"
    },
    {
      "type": "WEB",
      "url": "https://github.com/qax-os/excelize/pull/2370"
    },
    {
      "type": "WEB",
      "url": "https://github.com/qax-os/excelize/commit/a54c578af309fa81f448143ed2b7a91192cc58a7"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/qax-os/excelize"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Excelize: Unbounded \u003ccol max\u003e attribute is loaded with no MaxColumns check and expanded per-column by flatCols(), so any column mutator hangs or OOMs the process"
}

GHSA-FQMH-J4R4-HGMJ

Vulnerability from github – Published: 2026-10-15 09:30 – Updated: 2026-10-15 09:30
VLAI
Details

In Eclipse Vert.x versions [4.0.0, 4.5.34] or [5.0.0,5.0.12] or [5.1.0,5.1.9] or [5.2.0, 5.2.0], the binary array decoder in vertx-pg-client (DataTypeCodec.binaryDecodeArray) allocates a Java array sized by a server-declared 32-bit dimension count with no upper bound. A malicious or compromised PostgreSQL server, or an on-path attacker intercepting an unencrypted connection, can send a crafted DataRow message with an excessively large array dimension value, causing the client to attempt a multi-gigabyte heap allocation and crash with an OutOfMemoryError.

The impacted component is io.vertx:vertx-pg-client.

Severity
8.2 (High)
CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-102463"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-789"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-10-15T09:17:15Z",
    "severity": "HIGH"
  },
  "details": "In Eclipse Vert.x versions [4.0.0, 4.5.34] or [5.0.0,5.0.12] or [5.1.0,5.1.9] or [5.2.0, 5.2.0], the binary array decoder in vertx-pg-client (DataTypeCodec.binaryDecodeArray) allocates a Java array sized by a server-declared 32-bit dimension count with no upper bound. A malicious or compromised PostgreSQL server, or an on-path attacker intercepting an unencrypted connection, can send a crafted DataRow message with an excessively large array dimension value, causing the client to attempt a multi-gigabyte heap allocation and crash with an OutOfMemoryError.\n\n\n\nThe impacted component is io.vertx:vertx-pg-client.",
  "id": "GHSA-fqmh-j4r4-hgmj",
  "modified": "2026-10-15T09:30:34Z",
  "published": "2026-10-15T09:30:34Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/eclipse-vertx/vertx-sql-client/security/advisories/GHSA-xqmh-8fhj-48fp"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-102463"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.eclipse.org/security/cve-assignment/-/work_items/345"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/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",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-FVH8-PV2H-6XR6

Vulnerability from github – Published: 2026-10-01 18:32 – Updated: 2026-10-01 21:32
VLAI
Details

A memory calculation bug in mod_dav in Apache httpd 2.4.67 and earlier allows an attacker with permission to create WebDAV locks to crash server child processes.

Users are recommended to upgrade to version 2.4.69, which fixes this issue

Severity
4.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-42528"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-789"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-10-01T16:17:43Z",
    "severity": "MODERATE"
  },
  "details": "A memory calculation bug in mod_dav in Apache httpd 2.4.67 and earlier allows an attacker with permission to create WebDAV locks to crash server child processes.\n\nUsers are recommended to upgrade to version 2.4.69, which fixes this issue",
  "id": "GHSA-fvh8-pv2h-6xr6",
  "modified": "2026-10-01T21:32:49Z",
  "published": "2026-10-01T18:32:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42528"
    },
    {
      "type": "WEB",
      "url": "https://httpd.apache.org/security/vulnerabilities_24.html"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2026/10/01/12"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-FW7G-X8Q3-H9PR

Vulnerability from github – Published: 2024-11-15 18:30 – Updated: 2024-11-15 18:30
VLAI
Details

A vulnerability in the TL1 function of Cisco Network Convergence System (NCS) 4000 Series could allow an authenticated, local attacker to cause a memory leak in the TL1 process. This vulnerability is due to TL1 not freeing memory under some conditions. An attacker could exploit this vulnerability by connecting to the device and issuing TL1 commands after being authenticated. A successful exploit could allow the attacker to cause the TL1 process to consume large amounts of memory. When the memory reaches a threshold, the Resource Monitor (Resmon) process will begin to restart or shutdown the top five consumers of memory, resulting in a denial of service (DoS).Cisco has released software updates that address this vulnerability. There are no workarounds that address this vulnerability.This advisory is part of the September 2022 release of the Cisco IOS XR Software Security Advisory Bundled Publication. For a complete list of the advisories and links to them, see .

Severity
6.0 (Medium)
CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:C/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2022-20845"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-789"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-11-15T16:15:22Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability in the TL1 function of Cisco\u0026nbsp;Network Convergence System (NCS) 4000 Series could allow an authenticated, local attacker to cause a memory leak in the TL1 process.\nThis vulnerability is due to TL1 not freeing memory under some conditions. An attacker could exploit this vulnerability by connecting to the device and issuing TL1 commands after being authenticated. A successful exploit could allow the attacker to cause the TL1 process to consume large amounts of memory. When the memory reaches a threshold, the Resource Monitor (Resmon)\u0026nbsp;process will begin to restart or shutdown the top five consumers of memory, resulting in a denial of service (DoS).Cisco\u0026nbsp;has released software updates that address this vulnerability. There are no workarounds that address this vulnerability.This advisory is part of the September 2022 release of the Cisco\u0026nbsp;IOS XR Software Security Advisory Bundled Publication. For a complete list of the advisories and links to them, see .",
  "id": "GHSA-fw7g-x8q3-h9pr",
  "modified": "2024-11-15T18:30:49Z",
  "published": "2024-11-15T18:30:49Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-20845"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:C/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-G4MP-VGX3-XRVM

Vulnerability from github – Published: 2026-09-30 23:41 – Updated: 2026-09-30 23:41
VLAI
Summary
pageant: Out-of-bounds read / oversized allocation in `pageant` MemoryMap::read via a malicious Pageant agent (Windows)
Details

Summary

MemoryMap::read in the pageant crate (part of the russh workspace, used by russh's SSH-agent client on Windows via AgentClient::connect_pageant) copies a peer-controlled number of bytes out of an 8192-byte shared-memory view with no bounds check — unlike the sibling MemoryMap::write, which correctly rejects oversize access with Error::Overflow. The byte count comes straight from a u32 length prefix that the responding "Pageant" process writes into the shared mapping. A malicious local process that answers as the Pageant agent can therefore cause:

  • an out-of-bounds read past the 8 KiB view (access violation → process crash; or disclosure of adjacent process memory if the following page is committed)
  • an allocation of up to ~4 GiB from a single u32 (vec![0; n]).

This was reproduced end-to-end against the real, unmodified pageant crate (not a model) on x86_64-pc-windows-gnu under Wine; see "Proof of concept".

Impact

  • Availability / DoS (reliable). MemoryMap::read(size) walks off the end of the 8192-byte view and faults on the next, unmapped page — an EXCEPTION_ACCESS_VIOLATION that crashes the russh SSH client. Independently, a size near u32::MAX drives a ~4 GiB vec![0; n] before any copy.
  • Confidentiality (conditional). If memory immediately after the mapped view happens to be committed, read returns those adjacent bytes to russh as the "agent response", which russh then parses as agent identities/signatures. This arm depends on process memory layout, so it is opportunistic; the crash/alloc is the deterministic outcome.
  • Trust boundary. russh locates the agent with FindWindowW("Pageant", "Pageant") and passes the shared-mapping name inside the WM_COPYDATA COPYDATASTRUCT. Any local process can register a window of class + title "Pageant", receive that name, open the same mapping, and write a hostile size. So an unprivileged local process impersonating Pageant can attack every russh-based SSH client that uses the Pageant agent.

Affected component

  • pageant/src/wmmessage.rs
  • MemoryMap::read (:160-171) — no bound (contrast MemoryMap::write :139-158, which returns Error::Overflow when pos + len > length).
  • query_pageant_direct (:199-237) — reads a 4-byte u32 size from the shared mapping (:233) and calls map.read(size) (:234) with no check against _AGENT_MAX_MSGLEN (8192).
  • Reached from russh via AgentClient::connect_pageant → PageantStream → query_pageant_direct.

Platform: Windows only (cfg(windows)), local attacker. Verified against the pageant crate v0.2.2 as shipped in russh v0.63.1 (d3ae702, the latest release). read has never had a bound in any revision (git log -p -- pageant/src/wmmessage.rs).

Details

fn write(&mut self, data: &[u8]) -> Result<(), Error> {
    if self.pos + data.len() > self.length {      // :140  BOUND PRESENT
        return Err(Error::Overflow);
    }
    ... copy_nonoverlapping(&data[0], view+pos, data.len()) ...
}

fn read(&mut self, n: usize) -> Vec<u8> {         // :160  NO BOUND
    let out = vec![0; n];                         // n up to 0xFFFF_FFFF (CWE-789)
    unsafe {
        std::ptr::copy_nonoverlapping(
            self.view.Value.add(self.pos) as *const u8,   // view is length==8192
            out.as_ptr() as *mut u8,
            n,                                    // reads n bytes, may run past the view (CWE-125)
        );
    }
    self.pos += n;
    out
}

query_pageant_direct creates the mapping at _AGENT_MAX_MSGLEN = 8192, writes the request, sends the WM_COPYDATA, then reads the response the peer wrote:

map.seek(0);
let mut buf = map.read(4);
let size = u32::from_be_bytes([buf[0],buf[1],buf[2],buf[3]]) as usize; // :233 peer-controlled
buf.extend(map.read(size));                                            // :234 unbounded

Nothing checks 4 + size <= 8192, so map.read(size) runs past the 8 KiB view.

Proof of concept

Because the bug is Windows-only (WM_COPYDATA + MapViewOfFile), the PoC is a Windows cross-build (x86_64-pc-windows-gnu) driven under Wine, entirely inside a Linux container. It exercises the real, unmodified crate: the PoC takes a path dependency on pageant and calls pageant::wmmessage::query_pageant_direct, exactly what AgentClient::connect_pageant uses. A second thread impersonates Pageant (registers the window class + title "Pageant") and, on WM_COPYDATA, opens the shared mapping russh created and writes an attacker-chosen 4-byte big-endian length.

poc/run.sh builds and runs it. Full log in results/e2e-wine-run.log:

======== LEG 1 — ATTACK: fake agent reports length 0x00080000 (512 KiB) >> 8192-byte view ========
[attacker] impersonating Pageant window is up (class+title "Pageant")
[victim ] calling pageant::wmmessage::query_pageant_direct() over the 8192-byte view ...
[attacker] WM_COPYDATA received; shared mapping = "PageantRequestpoc"
[attacker] wrote hostile response length = 524288 (0x00080000) into the 8192-byte view
wine: Unhandled page fault on read access to 0000000002092000 at address 00000002282CFDC4 ...
WINE-EXIT=5

======== LEG 2 — CONTROL: fake agent reports length 0x00000010 (16 B), in-bounds ========
[victim ] returned 20 bytes — request+response fit inside the 8192-byte view (in-bounds control); no fault
WINE-EXIT=0
  • LEG 1 (attack): an oversized size makes MemoryMap::read read past the 8192-byte view; Wine reports an unhandled page fault at a page-aligned address (0x…2092000) — the out-of-bounds read as an access violation (crash). Exit code 5 = STATUS_ACCESS_VIOLATION.
  • LEG 2 (control): an in-bounds size returns cleanly. Same code path; the only difference is whether the peer's length exceeds the view — isolating the missing bound.

Fix validation. With patch/pageant-read-bound.patch applied and the PoC rebuilt against the patched crate, the identical attack input is rejected (results/patched-wine-run.log):

[attacker] wrote hostile response length = 524288 (0x00080000) into the 8192-byte view
[victim ] query_pageant_direct error: Overflow
WINE-EXIT=0

No fault; the read is refused at the bound, exactly as write already refuses oversize writes. (A pure-logic Linux model of the same control flow is also included as poc/pageant_read_oob_demo.rs / results/logic-demo-run.log.)

Remediation

Mirror write's guard in read and validate the response length before allocating/copying. patch/pageant-read-bound.patch:

  • MemoryMap::read(n) returns Result<Vec<u8>, Error> and returns Error::Overflow when self.pos + n > self.length;
  • query_pageant_direct propagates that Result and additionally rejects size > _AGENT_MAX_MSGLEN - 4 before map.read(size).
Severity
6.2 (Medium)
CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.2.2"
      },
      "package": {
        "ecosystem": "crates.io",
        "name": "pageant"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.2.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-102820"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-125",
      "CWE-789"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-30T23:41:02Z",
    "nvd_published_at": "2026-09-29T19:17:23Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\n`MemoryMap::read` in the `pageant` crate (part of the russh workspace, used by\nrussh\u0027s SSH-agent client on Windows via `AgentClient::connect_pageant`) copies a\n**peer-controlled** number of bytes out of an 8192-byte shared-memory view with\n**no bounds check** \u2014 unlike the sibling `MemoryMap::write`, which correctly\nrejects oversize access with `Error::Overflow`. The byte count comes straight\nfrom a `u32` length prefix that the responding \"Pageant\" process writes into the\nshared mapping. A malicious local process that answers as the Pageant agent can\ntherefore cause:\n\n- an **out-of-bounds read** past the 8 KiB view (access violation \u2192 process\n  crash; or disclosure of adjacent process memory if the following page is\n  committed)\n- an allocation of up to **~4 GiB** from a single `u32` (`vec![0; n]`).\n\nThis was reproduced **end-to-end against the real, unmodified `pageant` crate**\n(not a model) on `x86_64-pc-windows-gnu` under Wine; see \"Proof of concept\".\n\n## Impact\n\n- **Availability / DoS (reliable).** `MemoryMap::read(size)` walks off the end of\n  the 8192-byte view and faults on the next, unmapped page \u2014 an\n  `EXCEPTION_ACCESS_VIOLATION` that crashes the russh SSH client. Independently,\n  a `size` near `u32::MAX` drives a ~4 GiB `vec![0; n]` before any copy.\n- **Confidentiality (conditional).** If memory immediately after the mapped view\n  happens to be committed, `read` returns those adjacent bytes to russh as the\n  \"agent response\", which russh then parses as agent identities/signatures. This\n  arm depends on process memory layout, so it is opportunistic; the crash/alloc\n  is the deterministic outcome.\n- **Trust boundary.** russh locates the agent with\n  `FindWindowW(\"Pageant\", \"Pageant\")` and passes the shared-mapping name inside\n  the `WM_COPYDATA` `COPYDATASTRUCT`. **Any** local process can register a window\n  of class + title `\"Pageant\"`, receive that name, open the same mapping, and\n  write a hostile `size`. So an unprivileged local process impersonating Pageant\n  can attack every russh-based SSH client that uses the Pageant agent.\n\n## Affected component\n\n- `pageant/src/wmmessage.rs`\n  - `MemoryMap::read` (`:160-171`) \u2014 no bound (contrast `MemoryMap::write`\n    `:139-158`, which returns `Error::Overflow` when `pos + len \u003e length`).\n  - `query_pageant_direct` (`:199-237`) \u2014 reads a 4-byte `u32` size from the\n    shared mapping (`:233`) and calls `map.read(size)` (`:234`) with no check\n    against `_AGENT_MAX_MSGLEN` (8192).\n- Reached from russh via `AgentClient::connect_pageant` \u2192 `PageantStream` \u2192\n  `query_pageant_direct`.\n\nPlatform: **Windows only** (`cfg(windows)`), local attacker. Verified against\nthe `pageant` crate **v0.2.2** as shipped in russh **v0.63.1** (`d3ae702`, the\nlatest release). `read` has never had a bound in any revision\n(`git log -p -- pageant/src/wmmessage.rs`).\n\n## Details\n\n```rust\nfn write(\u0026mut self, data: \u0026[u8]) -\u003e Result\u003c(), Error\u003e {\n    if self.pos + data.len() \u003e self.length {      // :140  BOUND PRESENT\n        return Err(Error::Overflow);\n    }\n    ... copy_nonoverlapping(\u0026data[0], view+pos, data.len()) ...\n}\n\nfn read(\u0026mut self, n: usize) -\u003e Vec\u003cu8\u003e {         // :160  NO BOUND\n    let out = vec![0; n];                         // n up to 0xFFFF_FFFF (CWE-789)\n    unsafe {\n        std::ptr::copy_nonoverlapping(\n            self.view.Value.add(self.pos) as *const u8,   // view is length==8192\n            out.as_ptr() as *mut u8,\n            n,                                    // reads n bytes, may run past the view (CWE-125)\n        );\n    }\n    self.pos += n;\n    out\n}\n```\n\n`query_pageant_direct` creates the mapping at `_AGENT_MAX_MSGLEN = 8192`, writes\nthe request, sends the `WM_COPYDATA`, then reads the response the peer wrote:\n\n```rust\nmap.seek(0);\nlet mut buf = map.read(4);\nlet size = u32::from_be_bytes([buf[0],buf[1],buf[2],buf[3]]) as usize; // :233 peer-controlled\nbuf.extend(map.read(size));                                            // :234 unbounded\n```\n\nNothing checks `4 + size \u003c= 8192`, so `map.read(size)` runs past the 8 KiB view.\n\n## Proof of concept\n\nBecause the bug is Windows-only (`WM_COPYDATA` + `MapViewOfFile`), the PoC is a\nWindows cross-build (`x86_64-pc-windows-gnu`) driven under **Wine**, entirely\ninside a Linux container. It exercises the **real, unmodified** crate: the PoC\ntakes a path dependency on `pageant` and calls\n`pageant::wmmessage::query_pageant_direct`, exactly what\n`AgentClient::connect_pageant` uses. A second thread impersonates Pageant\n(registers the window class + title `\"Pageant\"`) and, on `WM_COPYDATA`, opens\nthe shared mapping russh created and writes an attacker-chosen 4-byte\nbig-endian length.\n\n`poc/run.sh` builds and runs it. Full log in `results/e2e-wine-run.log`:\n\n```\n======== LEG 1 \u2014 ATTACK: fake agent reports length 0x00080000 (512 KiB) \u003e\u003e 8192-byte view ========\n[attacker] impersonating Pageant window is up (class+title \"Pageant\")\n[victim ] calling pageant::wmmessage::query_pageant_direct() over the 8192-byte view ...\n[attacker] WM_COPYDATA received; shared mapping = \"PageantRequestpoc\"\n[attacker] wrote hostile response length = 524288 (0x00080000) into the 8192-byte view\nwine: Unhandled page fault on read access to 0000000002092000 at address 00000002282CFDC4 ...\nWINE-EXIT=5\n\n======== LEG 2 \u2014 CONTROL: fake agent reports length 0x00000010 (16 B), in-bounds ========\n[victim ] returned 20 bytes \u2014 request+response fit inside the 8192-byte view (in-bounds control); no fault\nWINE-EXIT=0\n```\n\n- **LEG 1 (attack)**: an oversized `size` makes `MemoryMap::read` read past the\n  8192-byte view; Wine reports an unhandled page fault at a page-aligned address\n  (`0x\u20262092000`) \u2014 the out-of-bounds read as an access violation (crash). Exit\n  code 5 = `STATUS_ACCESS_VIOLATION`.\n- **LEG 2 (control)**: an in-bounds `size` returns cleanly. Same code path; the\n  only difference is whether the peer\u0027s length exceeds the view \u2014 isolating the\n  missing bound.\n\n**Fix validation.** With `patch/pageant-read-bound.patch` applied and the PoC\nrebuilt against the patched crate, the identical attack input is rejected\n(`results/patched-wine-run.log`):\n\n```\n[attacker] wrote hostile response length = 524288 (0x00080000) into the 8192-byte view\n[victim ] query_pageant_direct error: Overflow\nWINE-EXIT=0\n```\n\nNo fault; the read is refused at the bound, exactly as `write` already refuses\noversize writes. (A pure-logic Linux model of the same control flow is also\nincluded as `poc/pageant_read_oob_demo.rs` / `results/logic-demo-run.log`.)\n\n## Remediation\n\nMirror `write`\u0027s guard in `read` and validate the response length before\nallocating/copying. `patch/pageant-read-bound.patch`:\n\n- `MemoryMap::read(n)` returns `Result\u003cVec\u003cu8\u003e, Error\u003e` and returns\n  `Error::Overflow` when `self.pos + n \u003e self.length`;\n- `query_pageant_direct` propagates that `Result` and additionally rejects\n  `size \u003e _AGENT_MAX_MSGLEN - 4` before `map.read(size)`.",
  "id": "GHSA-g4mp-vgx3-xrvm",
  "modified": "2026-09-30T23:41:03Z",
  "published": "2026-09-30T23:41:02Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Eugeny/russh/security/advisories/GHSA-g4mp-vgx3-xrvm"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-102820"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Eugeny/russh/commit/5d566989ebabfdebfe6b33243d31765a0812260b"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Eugeny/russh"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Eugeny/russh/releases/tag/v0.63.2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "pageant: Out-of-bounds read / oversized allocation in `pageant` MemoryMap::read via a malicious Pageant agent (Windows)"
}
Mitigation
Implementation Architecture and Design

Perform adequate input validation against any value that influences the amount of memory that is allocated. Define an appropriate strategy for handling requests that exceed the limit, and consider supporting a configuration option so that the administrator can extend the amount of memory to be used if necessary.

Mitigation
Operation

Run your program using system-provided resource limits for memory. This might still cause the program to crash or exit, but the impact to the rest of the system will be minimized.

No CAPEC attack patterns related to this CWE.

← Back to the CWE list