CWE-789

{
  "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"
}

{
  "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"
    }
  ]
}

{
  "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"
    }
  ]
}

{
  "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)"
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "SixLabors.ImageSharp"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.1.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "SixLabors.ImageSharp"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0"
            },
            {
              "fixed": "3.1.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-32035"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-770",
      "CWE-789"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-04-15T20:22:54Z",
    "nvd_published_at": "2024-04-15T20:15:11Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nA vulnerability discovered in the ImageSharp library, where the processing of specially crafted files can lead to excessive memory usage in image decoders. The vulnerability is triggered when ImageSharp attempts to process image files that are designed to exploit this flaw. \n\nThis flaw can be exploited to cause a denial of service (DoS) by depleting process memory, thereby affecting applications and services that rely on ImageSharp for image processing tasks. Users and administrators are advised to update to the latest version of ImageSharp that addresses this vulnerability to mitigate the risk of exploitation.\n\n### Patches\n\nThe problem has been patched. All users are advised to upgrade to v3.1.4 or v2.1.8.\n\n### Workarounds\n\nBefore calling `Image.Decode(Async)`, use `Image.Identify` to determine the image dimensions in order to enforce a limit.\n\n### References\n\n- ImageSharp: [Security Considerations](https://docs.sixlabors.com/articles/imagesharp/security.html)\n- ImageSharp.Web: [Securing Processing Commands](https://docs.sixlabors.com/articles/imagesharp.web/processingcommands.html#securing-processing-commands)",
  "id": "GHSA-g85r-6x2q-45w7",
  "modified": "2025-01-09T22:04:41Z",
  "published": "2024-04-15T20:22:54Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/SixLabors/ImageSharp/security/advisories/GHSA-g85r-6x2q-45w7"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-32035"
    },
    {
      "type": "WEB",
      "url": "https://github.com/SixLabors/ImageSharp/commit/b6b08ac3e7cea8da5ac1e90f7c0b67dd254535c3"
    },
    {
      "type": "WEB",
      "url": "https://github.com/SixLabors/ImageSharp/commit/f21d64188e59ae9464ff462056a5e29d8e618b27"
    },
    {
      "type": "WEB",
      "url": "https://docs.sixlabors.com/articles/imagesharp.web/processingcommands.html#securing-processing-commands"
    },
    {
      "type": "WEB",
      "url": "https://docs.sixlabors.com/articles/imagesharp/security.html"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/SixLabors/ImageSharp"
    }
  ],
  "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:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "SixLabors.ImageSharp vulnerable to Memory Allocation with Excessive Size Value"
}

{
  "affected": [],
  "aliases": [
    "CVE-2022-20717"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-770",
      "CWE-789"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-04-15T15:15:00Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability in the NETCONF process of Cisco SD-WAN vEdge Routers could allow an authenticated, local attacker to cause an affected device to run out of memory, resulting in a denial of service (DoS) condition. This vulnerability is due to insufficient memory management when an affected device receives large amounts of traffic. An attacker could exploit this vulnerability by sending malicious traffic to an affected device. A successful exploit could allow the attacker to cause the device to crash, resulting in a DoS condition.",
  "id": "GHSA-g8c4-6cm2-mvxv",
  "modified": "2022-05-17T00:01:43Z",
  "published": "2022-04-16T00:00:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-20717"
    },
    {
      "type": "WEB",
      "url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-sdwan-vedge-dos-jerVm4bB"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "OpenTelemetry.Api"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.5.0-beta.2"
            },
            {
              "fixed": "1.15.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "OpenTelemetry.Extensions.Propagators"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.3.1"
            },
            {
              "fixed": "1.15.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-40894"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-789"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-23T21:43:53Z",
    "nvd_published_at": "2026-04-23T19:17:28Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nThe implementation details of the baggage, B3 and Jaeger processing code in the `OpenTelemetry.Api` and `OpenTelemetry.Extensions.Propagators` NuGet packages can allocate excessive memory when parsing which could create a potential denial of service (DoS) in the consuming application.\n\n### Details\n\n#### Exceeding Limits\n\n[`BaggagePropagator.Inject\u003cT\u003e()`](https://github.com/open-telemetry/opentelemetry-dotnet/blob/fc1a2864d1665bda857089e11fe9247e3c75637a/src/OpenTelemetry.Api/Context/Propagation/BaggagePropagator.cs#L93-L112) does not enforce the length limit of `8192` characters if the injected baggage contains only one item.\n\nThis change was introduced by #1048.\n\n#### Excessive allocation\n\nThe following methods eagerly allocate intermediate arrays before applying size limits.\n\n- [`BaggagePropagator.Extract\u003cT\u003e()`](https://github.com/open-telemetry/opentelemetry-dotnet/blob/888d1bf2489fb7408d3c5e8758a5bbffa89a8fb2/src/OpenTelemetry.Api/Context/Propagation/BaggagePropagator.cs#L52-L55) - this change was introduced by #1048.\n- [`BaggagePropagator.Inject\u003cT\u003e()`](https://github.com/open-telemetry/opentelemetry-dotnet/blob/888d1bf2489fb7408d3c5e8758a5bbffa89a8fb2/src/OpenTelemetry.Api/Context/Propagation/BaggagePropagator.cs#L138-L157) - this change was introduced by #1048.\n- [`B3Propagator.Extract\u003cT\u003e()`](https://github.com/open-telemetry/opentelemetry-dotnet/blob/888d1bf2489fb7408d3c5e8758a5bbffa89a8fb2/src/OpenTelemetry.Extensions.Propagators/B3Propagator.cs#L203-L207) - this change was introduced by #533.\n- [`B3Propagator.Extract\u003cT\u003e()`](https://github.com/open-telemetry/opentelemetry-dotnet/blob/888d1bf2489fb7408d3c5e8758a5bbffa89a8fb2/src/OpenTelemetry.Api/Context/Propagation/B3Propagator.cs#L204-L214) - this change was introduced by #3244.\n- [`JaegerPropagator.Extract\u003cT\u003e()`](https://github.com/open-telemetry/opentelemetry-dotnet/blob/888d1bf2489fb7408d3c5e8758a5bbffa89a8fb2/src/OpenTelemetry.Extensions.Propagators/JaegerPropagator.cs#L150-L154) - this change was introduced by #3309.\n\n### Impact\n\nExcessively large propagation headers, particularly in degenerate/malformed cases that consist or large numbers of delimiter characters, can allocate excessive amounts of memory for intermediate storage of parsed content relative to the size of the original input.\n\n### Mitigation\n\nHTTP servers often set maximum limits on the length of HTTP request headers, such as [Internet Information Services (IIS)](https://learn.microsoft.com/iis/configuration/system.webserver/security/requestfiltering/requestlimits/headerlimits/) which sets a default limit of 16KB and [nginx](https://nginx.org/docs/http/ngx_http_core_module.html#large_client_header_buffers) which sets a default limit of 8KB.\n\n### Workarounds\n\nPossible workarounds include:\n\n- Configuring appropriate HTTP request header limits.\n- Disabling baggage and/or trace propagation.\n\n### Remediation\n\n[#7061](https://github.com/open-telemetry/opentelemetry-dotnet/pull/7061) refactors the handling of baggage, B3 and Jaeger propagation headers to stop parsing eagerly when limits are exceeded and avoid allocating intermediate arrays.",
  "id": "GHSA-g94r-2vxg-569j",
  "modified": "2026-04-23T21:43:54Z",
  "published": "2026-04-23T21:43:53Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/open-telemetry/opentelemetry-dotnet/security/advisories/GHSA-g94r-2vxg-569j"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-40894"
    },
    {
      "type": "WEB",
      "url": "https://github.com/open-telemetry/opentelemetry-dotnet/pull/1048"
    },
    {
      "type": "WEB",
      "url": "https://github.com/open-telemetry/opentelemetry-dotnet/pull/3244"
    },
    {
      "type": "WEB",
      "url": "https://github.com/open-telemetry/opentelemetry-dotnet/pull/3309"
    },
    {
      "type": "WEB",
      "url": "https://github.com/open-telemetry/opentelemetry-dotnet/pull/3533"
    },
    {
      "type": "WEB",
      "url": "https://github.com/open-telemetry/opentelemetry-dotnet/pull/533"
    },
    {
      "type": "WEB",
      "url": "https://github.com/open-telemetry/opentelemetry-dotnet/pull/7061"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/open-telemetry/opentelemetry-dotnet"
    },
    {
      "type": "WEB",
      "url": "https://github.com/open-telemetry/opentelemetry-dotnet/releases/tag/core-1.15.3"
    }
  ],
  "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:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "OpenTelemetry dotnet: Excessive memory allocation when parsing OpenTelemetry propagation headers"
}

{
  "affected": [],
  "aliases": [
    "CVE-2026-72687"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-789"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-13T20:17:29Z",
    "severity": "MODERATE"
  },
  "details": "A flaw in Elasticsearch allows a low-privileged authenticated user to submit a single small request containing a forged opaque identifier. Elasticsearch decodes and deserializes the identifier before confirming that it was legitimately issued by the cluster, and a size value carried inside the identifier drives an allocation that is neither capped nor accounted for by the available memory-usage controls. The resulting out-of-memory condition is fatal and terminates the affected node process, resulting in a denial of service.",
  "id": "GHSA-gf23-7gr9-6992",
  "modified": "2026-08-13T21:36:11Z",
  "published": "2026-08-13T21:36:11Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72687"
    },
    {
      "type": "WEB",
      "url": "https://discuss.elastic.co/t/elasticsearch-8-19-20-9-4-5-9-5-1-security-update-esa-2026-79/389506"
    }
  ],
  "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:H",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/kubeedge/kubeedge"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.0.0"
            },
            {
              "fixed": "1.21.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/kubeedge/kubeedge"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.22.0"
            },
            {
              "fixed": "1.22.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/kubeedge/kubeedge"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.23.0"
            },
            {
              "fixed": "1.23.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-62370"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-789"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-22T20:37:01Z",
    "nvd_published_at": "2026-09-21T17:17:36Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nKubeEdge CloudHub uses the viaduct packer to decode messages received from connected peers. The packer reads a 32-bit payload length from the message header and previously allocated a buffer of that size without enforcing an upper bound.\n\nAn authenticated peer that can establish a viaduct connection to CloudHub can send a crafted message header containing an excessively large payload length. This may cause CloudHub to allocate a large amount of memory and can result in memory exhaustion, process termination, or denial of service.\n\n## Impact\n\nA successfully authenticated malicious or compromised edge node may repeatedly send crafted viaduct message headers to increase CloudHub memory consumption.\n\nDepending on available memory and deployment limits, exploitation may cause:\n\n* Increased CloudHub memory usage\n* Out-of-memory termination\n* CloudHub restart loops\n* Temporary disruption of cloud-edge communication\n\nAuthentication to the viaduct endpoint is required. This issue does not provide unauthenticated access or direct code execution.\n\n## Root cause\n\nThe viaduct packer trusted the payload length encoded in the message header and allocated the payload buffer before validating whether the declared length was within an acceptable range.\n\n## Fix\n\nThe fix introduces a maximum viaduct payload size of 32 MiB.\n\nThe updated implementation:\n\n* Rejects oversized payload lengths in the reader before memory allocation\n* Enforces the same maximum size in the writer\n* Adds regression tests covering oversized and valid payloads\n\nFixes have been prepared for the following patch releases:\n\n* KubeEdge v1.23.1\n* KubeEdge v1.22.2\n* KubeEdge v1.21.2\n\nThese versions should not be listed as released until the coordinated release process is complete.\n\n## Workarounds\n\nBefore patched versions are available, operators should:\n\n* Restrict access to the CloudHub endpoint to trusted edge nodes and networks\n* Protect and rotate edge-node credentials\n* Revoke credentials belonging to decommissioned or potentially compromised nodes\n* Apply memory limits and restart policies to the CloudHub workload\n* Monitor CloudHub memory consumption and unexpected connection activity\n\n## Affected component\n\n* `pkg/viaduct/pkg/packer`\n* CloudHub viaduct message-processing path\n\n## Credits\n\nKubeEdge thanks Sang-Hoon Choi ([KoreaSecurity](https://github.com/KoreaSecurity), Sejong University)\nfor responsibly reporting this issue and for coordinating with the KubeEdge\nmaintainers through the security disclosure process.",
  "id": "GHSA-gfw4-49f9-cp25",
  "modified": "2026-09-22T20:37:02Z",
  "published": "2026-09-22T20:37:01Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/kubeedge/kubeedge/security/advisories/GHSA-gfw4-49f9-cp25"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-62370"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kubeedge/kubeedge/pull/7028"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kubeedge/kubeedge/pull/7029"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kubeedge/kubeedge/pull/7030"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kubeedge/kubeedge/commit/0fe1ea18e5d7fde29633286ddf1c7e71cb39606f"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kubeedge/kubeedge/commit/725a73ca35a65d91aa6338e52b8faaab6058f528"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kubeedge/kubeedge/commit/cc79621943fff9d3f62638d9403ef0cfeda3d0e7"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/kubeedge/kubeedge"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kubeedge/kubeedge/blob/master/CHANGELOG/CHANGELOG-1.21.md"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kubeedge/kubeedge/blob/master/CHANGELOG/CHANGELOG-1.22.md"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kubeedge/kubeedge/blob/master/CHANGELOG/CHANGELOG-1.23.md"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kubeedge/kubeedge/releases/tag/v1.21.2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kubeedge/kubeedge/releases/tag/v1.22.2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kubeedge/kubeedge/releases/tag/v1.23.1"
    }
  ],
  "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:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "KubeEdge: Unbounded allocation in viaduct packer enables authenticated remote DoS against CloudHub"
}

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.3.7"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/t2bot/matrix-media-repo"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.3.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-52791"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-789"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-01-16T19:07:43Z",
    "nvd_published_at": "2025-01-16T20:15:32Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\nMMR makes requests to other servers as part of normal operation, and these resource owners can return large amounts of JSON back to MMR for parsing. In parsing, MMR can consume large amounts of memory and exhaust available memory.\n\n### Patches\nThis is fixed in [MMR v1.3.8](https://github.com/t2bot/matrix-media-repo/releases/tag/v1.3.8).\n\n### Workarounds\nForward proxies can be configured to block requests to unsafe hosts. Alternatively, MMR processes can be configured with memory limits and auto-restart. Running multiple MMR processes concurrently can help ensure a restart does not overly impact users.",
  "id": "GHSA-gp86-q8hg-fpxj",
  "modified": "2025-08-20T17:40:17Z",
  "published": "2025-01-16T19:07:43Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/t2bot/matrix-media-repo/security/advisories/GHSA-gp86-q8hg-fpxj"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-52791"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/t2bot/matrix-media-repo"
    },
    {
      "type": "WEB",
      "url": "https://github.com/t2bot/matrix-media-repo/releases/tag/v1.3.8"
    },
    {
      "type": "WEB",
      "url": "https://pkg.go.dev/vuln/GO-2025-3398"
    }
  ],
  "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:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "matrix-media-repo (MMR) allows a denial of service through memory exhaustion"
}