Vulnerability-Lookup

GHSA-W8RR-5GCM-PP58

Vulnerability from github – Published: 2026-04-08 19:22 – Updated: 2026-04-09 14:29

Summary

opentelemetry-go: OTLP HTTP exporters read unbounded HTTP response bodies

Details

overview: this report shows that the otlp HTTP exporters (traces/metrics/logs) read the full HTTP response body into an in-memory bytes.Buffer without a size cap.

this is exploitable for memory exhaustion when the configured collector endpoint is attacker-controlled (or a network attacker can mitm the exporter connection).

severity

HIGH

not claiming: this is a remote dos against every default deployment. claiming: if the exporter sends traces to an untrusted collector endpoint (or over a network segment where mitm is realistic), that endpoint can crash the process via a large response body.

callsite (pinned): - exporters/otlp/otlptrace/otlptracehttp/client.go:199 - exporters/otlp/otlptrace/otlptracehttp/client.go:230 - exporters/otlp/otlpmetric/otlpmetrichttp/client.go:170 - exporters/otlp/otlpmetric/otlpmetrichttp/client.go:201 - exporters/otlp/otlplog/otlploghttp/client.go:190 - exporters/otlp/otlplog/otlploghttp/client.go:221

permalinks (pinned): - https://github.com/open-telemetry/opentelemetry-go/blob/248da958375e4dfb4a1105645107be3ef04b1c59/exporters/otlp/otlptrace/otlptracehttp/client.go#L199 - https://github.com/open-telemetry/opentelemetry-go/blob/248da958375e4dfb4a1105645107be3ef04b1c59/exporters/otlp/otlptrace/otlptracehttp/client.go#L230 - https://github.com/open-telemetry/opentelemetry-go/blob/248da958375e4dfb4a1105645107be3ef04b1c59/exporters/otlp/otlpmetric/otlpmetrichttp/client.go#L170 - https://github.com/open-telemetry/opentelemetry-go/blob/248da958375e4dfb4a1105645107be3ef04b1c59/exporters/otlp/otlpmetric/otlpmetrichttp/client.go#L201 - https://github.com/open-telemetry/opentelemetry-go/blob/248da958375e4dfb4a1105645107be3ef04b1c59/exporters/otlp/otlplog/otlploghttp/client.go#L190 - https://github.com/open-telemetry/opentelemetry-go/blob/248da958375e4dfb4a1105645107be3ef04b1c59/exporters/otlp/otlplog/otlploghttp/client.go#L221

root cause: each exporter client reads resp.Body using io.Copy(&respData, resp.Body) into a bytes.Buffer on both success and error paths, with no upper bound.

impact: a malicious collector can force large transient heap allocations during export (peak memory scales with attacker-chosen response size) and can potentially crash the instrumented process (oom).

affected component: - go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracehttp - go.opentelemetry.io/otel/exporters/otlp/otlpmetric/otlpmetrichttp - go.opentelemetry.io/otel/exporters/otlp/otlplog/otlploghttp

repro (local-only):

unzip poc.zip -d poc
cd poc
make canonical resp_bytes=33554432 chunk_delay_ms=0

expected output contains:

[CALLSITE_HIT]: otlptracehttp.UploadTraces::io.Copy(resp.Body)
[PROOF_MARKER]: resp_bytes=33554432 peak_alloc_bytes=118050512

control (same env, patched target):

unzip poc.zip -d poc
cd poc
make control resp_bytes=33554432 chunk_delay_ms=0

expected control output contains:

[CALLSITE_HIT]: otlptracehttp.UploadTraces::io.Copy(resp.Body)
[NC_MARKER]: resp_bytes=33554432 peak_alloc_bytes=512232

attachments: poc.zip (attached)

PR_DESCRIPTION.md

attack_scenario.md

poc.zip

Fixed in: https://github.com/open-telemetry/opentelemetry-go/pull/8108

Severity

5.3 (Medium)


                  
                    CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracehttp"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.43.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "go.opentelemetry.io/otel/exporters/otlp/otlpmetric/otlpmetrichttp"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.43.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "go.opentelemetry.io/otel/exporters/otlp/otlplog/otlploghttp"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.19.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-39882"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-789"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-08T19:22:01Z",
    "nvd_published_at": "2026-04-08T21:17:00Z",
    "severity": "MODERATE"
  },
  "details": "overview:\nthis report shows that the otlp HTTP exporters (traces/metrics/logs) read the full HTTP response body into an in-memory `bytes.Buffer` without a size cap.\n\nthis is exploitable for memory exhaustion when the configured collector endpoint is attacker-controlled (or a network attacker can mitm the exporter connection).\n\nseverity\n\nHIGH\n\nnot claiming: this is a remote dos against every default deployment.\nclaiming: if the exporter sends traces to an untrusted collector endpoint (or over a network segment where mitm is realistic), that endpoint can crash the process via a large response body.\n\ncallsite (pinned):\n- exporters/otlp/otlptrace/otlptracehttp/client.go:199\n- exporters/otlp/otlptrace/otlptracehttp/client.go:230\n- exporters/otlp/otlpmetric/otlpmetrichttp/client.go:170\n- exporters/otlp/otlpmetric/otlpmetrichttp/client.go:201\n- exporters/otlp/otlplog/otlploghttp/client.go:190\n- exporters/otlp/otlplog/otlploghttp/client.go:221\n\npermalinks (pinned):\n- https://github.com/open-telemetry/opentelemetry-go/blob/248da958375e4dfb4a1105645107be3ef04b1c59/exporters/otlp/otlptrace/otlptracehttp/client.go#L199\n- https://github.com/open-telemetry/opentelemetry-go/blob/248da958375e4dfb4a1105645107be3ef04b1c59/exporters/otlp/otlptrace/otlptracehttp/client.go#L230\n- https://github.com/open-telemetry/opentelemetry-go/blob/248da958375e4dfb4a1105645107be3ef04b1c59/exporters/otlp/otlpmetric/otlpmetrichttp/client.go#L170\n- https://github.com/open-telemetry/opentelemetry-go/blob/248da958375e4dfb4a1105645107be3ef04b1c59/exporters/otlp/otlpmetric/otlpmetrichttp/client.go#L201\n- https://github.com/open-telemetry/opentelemetry-go/blob/248da958375e4dfb4a1105645107be3ef04b1c59/exporters/otlp/otlplog/otlploghttp/client.go#L190\n- https://github.com/open-telemetry/opentelemetry-go/blob/248da958375e4dfb4a1105645107be3ef04b1c59/exporters/otlp/otlplog/otlploghttp/client.go#L221\n\nroot cause:\neach exporter client reads `resp.Body` using `io.Copy(\u0026respData, resp.Body)` into a `bytes.Buffer` on both success and error paths, with no upper bound.\n\nimpact:\na malicious collector can force large transient heap allocations during export (peak memory scales with attacker-chosen response size) and can potentially crash the instrumented process (oom).\n\naffected component:\n- go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracehttp\n- go.opentelemetry.io/otel/exporters/otlp/otlpmetric/otlpmetrichttp\n- go.opentelemetry.io/otel/exporters/otlp/otlplog/otlploghttp\n\nrepro (local-only):\n\n```bash\nunzip poc.zip -d poc\ncd poc\nmake canonical resp_bytes=33554432 chunk_delay_ms=0\n```\n\nexpected output contains:\n\n```\n[CALLSITE_HIT]: otlptracehttp.UploadTraces::io.Copy(resp.Body)\n[PROOF_MARKER]: resp_bytes=33554432 peak_alloc_bytes=118050512\n```\n\ncontrol (same env, patched target):\n\n```bash\nunzip poc.zip -d poc\ncd poc\nmake control resp_bytes=33554432 chunk_delay_ms=0\n```\n\nexpected control output contains:\n\n```\n[CALLSITE_HIT]: otlptracehttp.UploadTraces::io.Copy(resp.Body)\n[NC_MARKER]: resp_bytes=33554432 peak_alloc_bytes=512232\n```\n\nattachments: poc.zip (attached)\n\n[PR_DESCRIPTION.md](https://github.com/user-attachments/files/25564272/PR_DESCRIPTION.md)\n\n[attack_scenario.md](https://github.com/user-attachments/files/25564273/attack_scenario.md)\n\n[poc.zip](https://github.com/user-attachments/files/25564271/poc.zip)\n\n\nFixed in: https://github.com/open-telemetry/opentelemetry-go/pull/8108",
  "id": "GHSA-w8rr-5gcm-pp58",
  "modified": "2026-04-09T14:29:37Z",
  "published": "2026-04-08T19:22:01Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/open-telemetry/opentelemetry-go/security/advisories/GHSA-w8rr-5gcm-pp58"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-39882"
    },
    {
      "type": "WEB",
      "url": "https://github.com/open-telemetry/opentelemetry-go/pull/8108"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/open-telemetry/opentelemetry-go"
    },
    {
      "type": "WEB",
      "url": "http://github.com/open-telemetry/opentelemetry-go/releases/tag/v1.43.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "opentelemetry-go: OTLP HTTP exporters read unbounded HTTP response bodies"
}

GHSA-W9M8-P4CC-4QJ9

Vulnerability from github – Published: 2026-05-26 13:30 – Updated: 2026-06-29 22:52

Summary

Mattermost doesn't properly validate msgpack-encoded WebSocket frames before memory allocation

Details

Mattermost versions 11.6.x <= 11.6.0, 11.5.x <= 11.5.3, 11.4.x <= 11.4.4, 10.11.x <= 10.11.14 fail to properly validate msgpack-encoded WebSocket frames before memory allocation which allows an unauthenticated remote attacker to crash the server process and cause a full service outage for all users via a crafted binary WebSocket message sent to the public WebSocket endpoint.. Mattermost Advisory ID: MMSA-2026-00647

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

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "11.6.0"
            },
            {
              "fixed": "11.6.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "11.6.0"
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "11.5.0"
            },
            {
              "fixed": "11.5.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "11.4.0"
            },
            {
              "fixed": "11.4.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "10.11.0"
            },
            {
              "fixed": "10.11.15"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost/server/v8"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "8.0.0-20260410202636-17939826efa2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-5740"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-789"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-29T22:52:00Z",
    "nvd_published_at": "2026-05-22T11:16:23Z",
    "severity": "HIGH"
  },
  "details": "Mattermost versions 11.6.x \u003c= 11.6.0, 11.5.x \u003c= 11.5.3, 11.4.x \u003c= 11.4.4, 10.11.x \u003c= 10.11.14 fail to properly validate msgpack-encoded WebSocket frames before memory allocation which allows an unauthenticated remote attacker to crash the server process and cause a full service outage for all users via a crafted binary WebSocket message sent to the public WebSocket endpoint.. Mattermost Advisory ID: MMSA-2026-00647",
  "id": "GHSA-w9m8-p4cc-4qj9",
  "modified": "2026-06-29T22:52:00Z",
  "published": "2026-05-26T13:30:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-5740"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mattermost/mattermost/commit/17939826efa20a97f087b3d390ec5136df350bae"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/mattermost/mattermost"
    },
    {
      "type": "WEB",
      "url": "https://mattermost.com/security-updates"
    }
  ],
  "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": "Mattermost doesn\u0027t properly validate msgpack-encoded WebSocket frames before memory allocation"
}

GHSA-WF3X-273G-MVXV

Vulnerability from github – Published: 2026-10-01 15:17 – Updated: 2026-10-01 15:17

Summary

devalue: Sparse arrays emitted by uneval cause eager allocation when evaluated

Details

Evaluating legitimate uneval output for a sparse array can allocate memory proportional to its declared length. A tiny serialized value can therefore cause large memory allocation in a consuming browser/runtime. This occurs during evaluation of generated code, not in default parse sparse-array construction.

You would only be affected by this if you were serializing very large sparse arrays and then evaluating the results. In the general use case for uneval of sending data to the client, the worst that could happen is the browser tab running out of memory.

Severity

2.3 (Low)


                  
                    CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:P/VC:N/VI:N/VA:N/SC:N/SI:N/SA:L

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 5.9.2"
      },
      "package": {
        "ecosystem": "npm",
        "name": "devalue"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.0.0"
            },
            {
              "fixed": "5.9.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-789"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-01T15:17:13Z",
    "nvd_published_at": null,
    "severity": "LOW"
  },
  "details": "Evaluating legitimate `uneval` output for a sparse array can allocate memory proportional to its declared length. A tiny serialized value can therefore cause large memory allocation in a consuming browser/runtime. This occurs during evaluation of generated code, not in default `parse` sparse-array construction.\n\nYou would only be affected by this if you were serializing very large sparse arrays and then evaluating the results. In the general use case for `uneval` of sending data to the client, the worst that could happen is the browser tab running out of memory.",
  "id": "GHSA-wf3x-273g-mvxv",
  "modified": "2026-10-01T15:17:13Z",
  "published": "2026-10-01T15:17:13Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/sveltejs/devalue/security/advisories/GHSA-wf3x-273g-mvxv"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sveltejs/devalue/commit/6861dbbb7e548849e48bce718e88747a298f7250"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/sveltejs/devalue"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sveltejs/devalue/releases/tag/v5.9.3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:P/VC:N/VI:N/VA:N/SC:N/SI:N/SA:L",
      "type": "CVSS_V4"
    }
  ],
  "summary": "devalue: Sparse arrays emitted by uneval cause eager allocation when evaluated"
}

GHSA-WHMM-QJ9R-WVR2

Vulnerability from github – Published: 2026-07-28 22:15 – Updated: 2026-07-28 22:15

Summary

td has pre-auth denial of service via unbounded memory allocation in proto.UnencryptedMessage.Decode

Details

Impact

A remote, unauthenticated attacker can cause excessive memory allocation (and resulting CPU / GC pressure, potentially OOM termination) by sending a crafted unencrypted MTProto packet.

(*proto.UnencryptedMessage).Decode read an attacker-controlled 32-bit dataLen field and immediately allocated a buffer of that size via make([]byte, dataLen) before validating that the underlying buffer actually contained that many bytes. A 20-byte packet declaring a ~1.75 GB payload (e.g. dataLen = 0x70000000) forces the runtime to provision and zero-initialize a multi-gigabyte heap allocation before the length is rejected.

Unencrypted messages are part of the unauthenticated MTProto handshake path, so no credentials or established session are required to reach the vulnerable code.

Impact is limited to availability; there is no evidence of memory corruption, out-of-bounds access, or code execution.

Patches

Fixed in v0.145.1 by validating dataLen against the remaining buffer length before allocation (commit 9d5d1f31e).

Workarounds

Upgrade to v0.145.1 or later. There is no in-process workaround for affected versions short of avoiding exposure of the unauthenticated MTProto parsing path to untrusted peers.

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

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/gotd/td"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.145.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-54638"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-770",
      "CWE-789"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-28T22:15:28Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Impact\n\nA remote, unauthenticated attacker can cause excessive memory allocation (and resulting CPU / GC pressure, potentially OOM termination) by sending a crafted unencrypted MTProto packet.\n\n`(*proto.UnencryptedMessage).Decode` read an attacker-controlled 32-bit `dataLen` field and immediately allocated a buffer of that size via `make([]byte, dataLen)` **before** validating that the underlying buffer actually contained that many bytes. A 20-byte packet declaring a ~1.75 GB payload (e.g. `dataLen = 0x70000000`) forces the runtime to provision and zero-initialize a multi-gigabyte heap allocation before the length is rejected.\n\nUnencrypted messages are part of the unauthenticated MTProto handshake path, so no credentials or established session are required to reach the vulnerable code.\n\nImpact is limited to availability; there is no evidence of memory corruption, out-of-bounds access, or code execution.\n\n### Patches\n\nFixed in **v0.145.1** by validating `dataLen` against the remaining buffer length before allocation (commit `9d5d1f31e`).\n\n### Workarounds\n\nUpgrade to v0.145.1 or later. There is no in-process workaround for affected versions short of avoiding exposure of the unauthenticated MTProto parsing path to untrusted peers.",
  "id": "GHSA-whmm-qj9r-wvr2",
  "modified": "2026-07-28T22:15:28Z",
  "published": "2026-07-28T22:15:28Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/gotd/td/security/advisories/GHSA-whmm-qj9r-wvr2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/gotd/td/issues/1711"
    },
    {
      "type": "WEB",
      "url": "https://github.com/gotd/td/commit/9d5d1f31ea5022d9798d84ccce15de2e91ba6baa"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/gotd/td"
    },
    {
      "type": "WEB",
      "url": "https://github.com/gotd/td/releases/tag/v0.145.1"
    }
  ],
  "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": "td has pre-auth denial of service via unbounded memory allocation in proto.UnencryptedMessage.Decode"
}

GHSA-WHXR-3P84-RF3C

Vulnerability from github – Published: 2025-05-07 09:31 – Updated: 2025-11-03 21:33

Summary

Apache ActiveMQ: Unchecked buffer length can cause excessive memory allocation

Details

Memory Allocation with Excessive Size Value vulnerability in Apache ActiveMQ.

During unmarshalling of OpenWire commands the size value of buffers was not properly validated which could lead to excessive memory allocation and be exploited to cause a denial of service (DoS) by depleting process memory, thereby affecting applications and services that rely on the availability of the ActiveMQ broker when not using mutual TLS connections. This issue affects Apache ActiveMQ: from 6.0.0 before 6.1.6, from 5.18.0 before 5.18.7, from 5.17.0 before 5.17.7, before 5.16.8. ActiveMQ 5.19.0 is not affected.

Users are recommended to upgrade to version 6.1.6+, 5.19.0+, 5.18.7+, 5.17.7, or 5.16.8 or which fixes the issue.

Existing users may implement mutual TLS to mitigate the risk on affected brokers.

Severity

7.5 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

6.9 (Medium)


                  
                    CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:H/AU:Y/R:A/V:D/RE:M/U:Red

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.activemq:activemq-openwire-legacy"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.16.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.activemq:activemq-client"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.16.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.activemq:activemq-openwire-legacy"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.17.0"
            },
            {
              "fixed": "5.17.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.activemq:activemq-openwire-legacy"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.18.0"
            },
            {
              "fixed": "5.18.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.activemq:activemq-openwire-legacy"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.0.0"
            },
            {
              "fixed": "6.1.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.activemq:activemq-client"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.17.0"
            },
            {
              "fixed": "5.17.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.activemq:activemq-client"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.18.0"
            },
            {
              "fixed": "5.18.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.activemq:activemq-client"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.0.0"
            },
            {
              "fixed": "6.1.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-27533"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-789"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-05-07T15:25:41Z",
    "nvd_published_at": "2025-05-07T09:15:18Z",
    "severity": "MODERATE"
  },
  "details": "Memory Allocation with Excessive Size Value vulnerability in Apache ActiveMQ.\n\nDuring unmarshalling of OpenWire commands the size value of buffers was not properly validated which could lead to excessive memory allocation and be exploited to cause a denial of service (DoS) by depleting process memory, thereby affecting applications and services that rely on the availability of the ActiveMQ broker when not using mutual TLS connections.\nThis issue affects Apache ActiveMQ: from 6.0.0 before 6.1.6, from 5.18.0 before 5.18.7, from 5.17.0 before 5.17.7, before 5.16.8. ActiveMQ 5.19.0 is not affected.\n\nUsers are recommended to upgrade to version 6.1.6+, 5.19.0+,  5.18.7+, 5.17.7, or 5.16.8 or which fixes the issue.\n\nExisting users may implement mutual TLS to mitigate the risk on affected brokers.",
  "id": "GHSA-whxr-3p84-rf3c",
  "modified": "2025-11-03T21:33:47Z",
  "published": "2025-05-07T09:31:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-27533"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/activemq/commit/fc4372b9f0f72b8b5eed917f0019c5cea45c5d06"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/apache/activemq"
    },
    {
      "type": "WEB",
      "url": "https://issues.apache.org/jira/browse/AMQ-6596"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/8hcm25vf7mchg4zbbhnlx2lc5bs705hg"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/06/msg00020.html"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2025/05/06/1"
    }
  ],
  "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:P/PR:H/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:H/AU:Y/R:A/V:D/RE:M/U:Red",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Apache ActiveMQ: Unchecked buffer length can cause excessive memory allocation"
}

GHSA-WPJJ-864Q-GGC9

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

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 Vert.x MySQL client (vertx-mysql-client) pre-allocates an array for column definitions based on a server-declared column count with no upper-bound validation. A malicious or compromised MySQL server, or an attacker with man-in-the-middle positioning, can send a crafted result set packet with an extremely large column count, causing the client to attempt a massive heap allocation. The resulting OutOfMemoryError crashes the Netty event loop thread, causing a complete denial of service for all connections and verticles in the Vert.x application.

The impacted component is io.vertx:vertx-mysql-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

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-102466"
  ],
  "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 Vert.x MySQL client (vertx-mysql-client) pre-allocates an array for column definitions based on a server-declared column count with no upper-bound validation. A malicious or compromised MySQL server, or an attacker with man-in-the-middle positioning, can send a crafted result set packet with an extremely large column count, causing the client to attempt a massive heap allocation. The resulting OutOfMemoryError crashes the Netty event loop thread, causing a complete denial of service for all connections and verticles in the Vert.x application.\n\n\n\nThe impacted component is io.vertx:vertx-mysql-client.",
  "id": "GHSA-wpjj-864q-ggc9",
  "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-9jxp-x3fr-ffqh"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-102466"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.eclipse.org/security/cve-assignment/-/work_items/342"
    }
  ],
  "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-WR2R-M36X-734X

Vulnerability from github – Published: 2026-08-05 06:30 – Updated: 2026-08-06 15:32

Details

A pre-authentication attacker could leverage type size/count handling to cause excessive allocation leading to potential denial of service.

This issue affects Apache Qpid Proton-J: through 0.34.1.

Users are recommended to upgrade to version 0.35.0, which fixes the issue.

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

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-66273"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-789"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-05T06:16:38Z",
    "severity": "HIGH"
  },
  "details": "A pre-authentication attacker could leverage type size/count handling to cause excessive allocation leading to potential denial of service.\n\nThis issue affects Apache Qpid Proton-J: through 0.34.1.\n\nUsers are recommended to upgrade to version 0.35.0, which fixes the issue.",
  "id": "GHSA-wr2r-m36x-734x",
  "modified": "2026-08-06T15:32:32Z",
  "published": "2026-08-05T06:30:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-66273"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/z34s9v5w05qk4qqtz5fs3v9wpxz6fnbh"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2026/08/04/9"
    }
  ],
  "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"
    }
  ]
}

GHSA-WV4V-8JH9-247V

Vulnerability from github – Published: 2026-08-13 21:36 – Updated: 2026-08-13 21:36

Details

Elasticsearch does not validate a size value taken from a user-supplied input before that value is used to reserve memory for an internal data structure. An authenticated user holding only read privileges can submit a single small crafted request to a product API endpoint that causes the node to attempt an excessively large allocation. The resulting memory exhaustion raises a fatal error that terminates the Elasticsearch node process, causing a denial of service for the affected node and degrading cluster health. The defect is not volumetric, so a single request is sufficient regardless of the heap size configured on the target node.

Severity

6.5 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-72678"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-789"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-13T20:17:28Z",
    "severity": "MODERATE"
  },
  "details": "Elasticsearch does not validate a size value taken from a user-supplied input before that value is used to reserve memory for an internal data structure. An authenticated user holding only read privileges can submit a single small crafted request to a product API endpoint that causes the node to attempt an excessively large allocation. The resulting memory exhaustion raises a fatal error that terminates the Elasticsearch node process, causing a denial of service for the affected node and degrading cluster health. The defect is not volumetric, so a single request is sufficient regardless of the heap size configured on the target node.",
  "id": "GHSA-wv4v-8jh9-247v",
  "modified": "2026-08-13T21:36:10Z",
  "published": "2026-08-13T21:36:10Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72678"
    },
    {
      "type": "WEB",
      "url": "https://discuss.elastic.co/t/elasticsearch-8-19-20-9-4-5-9-5-1-security-update-esa-2026-80/389507"
    }
  ],
  "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"
    }
  ]
}

GHSA-X284-J5P8-9C5P

Vulnerability from github – Published: 2026-04-16 21:30 – Updated: 2026-05-05 15:44

Summary

pypdf: Manipulated FlateDecode image dimensions can exhaust RAM

Details

Impact

An attacker who uses this vulnerability can craft a PDF which leads to the RAM being exhausted. This requires accessing an image using /FlateDecode with large size values.

Patches

This has been fixed in pypdf==6.10.2.

Workarounds

If you cannot upgrade yet, consider applying the changes from PR #3734.

Severity

6.5 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H

6.8 (Medium)


                  
                    CVSS:4.0/AV:L/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

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "pypdf"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.10.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-41314"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-789"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-16T21:30:25Z",
    "nvd_published_at": "2026-04-22T22:16:32Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\nAn attacker who uses this vulnerability can craft a PDF which leads to the RAM being exhausted. This requires accessing an image using `/FlateDecode` with large size values.\n\n### Patches\nThis has been fixed in [pypdf==6.10.2](https://github.com/py-pdf/pypdf/releases/tag/6.10.2).\n\n### Workarounds\nIf you cannot upgrade yet, consider applying the changes from PR [#3734](https://github.com/py-pdf/pypdf/pull/3734).",
  "id": "GHSA-x284-j5p8-9c5p",
  "modified": "2026-05-05T15:44:27Z",
  "published": "2026-04-16T21:30:25Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/py-pdf/pypdf/security/advisories/GHSA-x284-j5p8-9c5p"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41314"
    },
    {
      "type": "WEB",
      "url": "https://github.com/py-pdf/pypdf/pull/3734"
    },
    {
      "type": "WEB",
      "url": "https://github.com/py-pdf/pypdf/commit/ac734dab4eef92bcce50d503949b4d9887d89f11"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/py-pdf/pypdf"
    },
    {
      "type": "WEB",
      "url": "https://github.com/py-pdf/pypdf/releases/tag/6.10.2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "pypdf: Manipulated FlateDecode image dimensions can exhaust RAM"
}

GHSA-X2Q3-8CJH-766F

Vulnerability from github – Published: 2026-10-08 16:31 – Updated: 2026-10-08 16:31

Summary

Excelize: extractPart allocates attacker-controlled, unbounded and negative-sized buffers from CFB directory entries: remote panic / OOM DoS

Details

Summary

extractPart allocates directly from the mscfb directory-entry size with no clamping (crypt.go:198, same missing bound at crypt.go:204):

buf := make([]byte, entry.Size)

entry.Size is the raw streamSize field from the attacker-controlled CFB directory entry (mscfb v1.0.8 fixFile, file.go:109-120: full uint64 → int64 for major version 4, low uint32 for v3). mscfb only detects short sector chains later, inside File.Read (file.go:485-489 "emergency brake") — i.e. after the allocation. The zip path already enforces UnzipSizeLimit, and the KDF path bounds work with maxSpinCount; this path consults no limit at all.

Details

Two consequences, both execution-confirmed against pristine master (ecd99d761fe0, 2026-09-08):

Hard crash: a version-4 CFB declaring streamSize = 0xFFFFFFFFFFFFFFFF yields entry.Size == -1 → panic: runtime error: makeslice: len out of range, which escapes Decrypt (openReaderAt converts errors, not panics, excelize.go:210-214) and kills the process.
Memory exhaustion: any CFB (v3 suffices) declaring streamSize up to 0xFFFFFFFF forces up to 4 GiB of zeroed allocation from a ~12 KB file — an amplification factor of ~350,000×, trivially repeated per request in memory-limited deployments.

Call path: OpenFile/OpenReader/OpenBytes → openReaderAt (excelize.go:208-215, OLE magic sniff) → Decrypt (crypt.go:145-150) → extractPart (crypt.go:198).

PoC

A standalone program (public API only) was provided to the maintainer by email (2-extractpart-oom): it builds a valid-enough v4 (4096-byte sector) CFB — header (signature, sector shift 0x0C, DIFAT[0]=1), one directory sector with Root Entry (typeID 5, child=1) and a stream entry EncryptionInfo (objectType=2, startingSector=endOfChain, streamSize=0xFFFFFFFFFFFFFFFF). mscfb.New succeeds, doc.Next() returns the entry, and extractPart calls make([]byte, -1) before any chain validation. On master ecd99d761fe0 the program prints panic: runtime error: makeslice: len out of range; with the proposed patch it prints BLOCKED. An -oom flag demonstrates the 4 GiB allocation variant with streamSize = 0xFFFFFFFF.

Impact

An attacker uploads any file starting with the OLE signature D0 CF 11 E0 A1 B1 1A E1 (~12 KB is enough) to a service that calls excelize.OpenFile/OpenReader/OpenBytes on it (or calls Decrypt directly): remote, unauthenticated process crash (hard panic) or forced 4 GiB allocation per request (OOM) with a ~350,000× amplification factor.

Proposed fix

Bound the declared stream size before allocating in extractPart: reject negative sizes and sizes above a sane policy cap (1 GiB is far above any real encrypted-workbook part) with ErrWorkbookFileFormat, so malformed CFBs are rejected as errors instead of panicking or OOMing. A complete patch has been provided to the maintainer; verified that the patch blocks the PoC while legitimate Encrypt() output still opens.

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

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/xuri/excelize/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.3.1"
            },
            {
              "fixed": "2.11.1-0.20260912113515-5f636f9dcde5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-107215"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-789"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-08T16:31:26Z",
    "nvd_published_at": "2026-10-07T18:17:19Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\n`extractPart` allocates directly from the mscfb directory-entry size with no clamping (`crypt.go:198`, same missing bound at `crypt.go:204`):\n\n```go\nbuf := make([]byte, entry.Size)\n```\n\n`entry.Size` is the raw `streamSize` field from the attacker-controlled CFB directory entry (mscfb v1.0.8 `fixFile`, `file.go:109-120`: full uint64 \u2192 int64 for major version 4, low uint32 for v3). mscfb only detects short sector chains later, inside `File.Read` (`file.go:485-489` \"emergency brake\") \u2014 i.e. **after** the allocation. The zip path already enforces `UnzipSizeLimit`, and the KDF path bounds work with `maxSpinCount`; this path consults no limit at all.\n\n### Details\n\nTwo consequences, both execution-confirmed against pristine master (`ecd99d761fe0`, 2026-09-08):\n\n1. **Hard crash**: a version-4 CFB declaring `streamSize = 0xFFFFFFFFFFFFFFFF` yields `entry.Size == -1` \u2192 `panic: runtime error: makeslice: len out of range`, which escapes `Decrypt` (`openReaderAt` converts errors, not panics, `excelize.go:210-214`) and kills the process.\n2. **Memory exhaustion**: any CFB (v3 suffices) declaring `streamSize` up to `0xFFFFFFFF` forces up to 4 GiB of zeroed allocation from a ~12 KB file \u2014 an amplification factor of ~350,000\u00d7, trivially repeated per request in memory-limited deployments.\n\nCall path: `OpenFile`/`OpenReader`/`OpenBytes` \u2192 `openReaderAt` (`excelize.go:208-215`, OLE magic sniff) \u2192 `Decrypt` (`crypt.go:145-150`) \u2192 `extractPart` (`crypt.go:198`).\n\n### PoC\n\nA standalone program (public API only) was provided to the maintainer by email (`2-extractpart-oom`): it builds a valid-enough v4 (4096-byte sector) CFB \u2014 header (signature, sector shift `0x0C`, `DIFAT[0]=1`), one directory sector with Root Entry (typeID 5, child=1) and a stream entry `EncryptionInfo` (objectType=2, startingSector=endOfChain, `streamSize=0xFFFFFFFFFFFFFFFF`). `mscfb.New` succeeds, `doc.Next()` returns the entry, and `extractPart` calls `make([]byte, -1)` before any chain validation. On master `ecd99d761fe0` the program prints `panic: runtime error: makeslice: len out of range`; with the proposed patch it prints BLOCKED. An `-oom` flag demonstrates the 4 GiB allocation variant with `streamSize = 0xFFFFFFFF`.\n\n### Impact\n\nAn attacker uploads any file starting with the OLE signature `D0 CF 11 E0 A1 B1 1A E1` (~12 KB is enough) to a service that calls `excelize.OpenFile`/`OpenReader`/`OpenBytes` on it (or calls `Decrypt` directly): remote, unauthenticated process crash (hard panic) or forced 4 GiB allocation per request (OOM) with a ~350,000\u00d7 amplification factor.\n\n### Proposed fix\n\nBound the declared stream size before allocating in `extractPart`: reject negative sizes and sizes above a sane policy cap (1 GiB is far above any real encrypted-workbook part) with `ErrWorkbookFileFormat`, so malformed CFBs are rejected as errors instead of panicking or OOMing. A complete patch has been provided to the maintainer; verified that the patch blocks the PoC while legitimate `Encrypt()` output still opens.",
  "id": "GHSA-x2q3-8cjh-766f",
  "modified": "2026-10-08T16:31:26Z",
  "published": "2026-10-08T16:31:26Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/qax-os/excelize/security/advisories/GHSA-x2q3-8cjh-766f"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-107215"
    },
    {
      "type": "WEB",
      "url": "https://github.com/qax-os/excelize/pull/2396"
    },
    {
      "type": "WEB",
      "url": "https://github.com/qax-os/excelize/commit/5f636f9dcde55911f14290060b017f0cc88cd694"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/qax-os/excelize"
    }
  ],
  "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": "Excelize: extractPart allocates attacker-controlled, unbounded and negative-sized buffers from CFB directory entries: remote panic / OOM DoS"
}

CWE-789

Memory Allocation with Excessive Size Value

GHSA-W8RR-5GCM-PP58

GHSA-W9M8-P4CC-4QJ9

GHSA-WF3X-273G-MVXV

GHSA-WHMM-QJ9R-WVR2

Impact

Patches

Workarounds

GHSA-WHXR-3P84-RF3C

GHSA-WPJJ-864Q-GGC9

GHSA-WR2R-M36X-734X

GHSA-WV4V-8JH9-247V

GHSA-X284-J5P8-9C5P

Impact

Patches

Workarounds

GHSA-X2Q3-8CJH-766F

Summary

Details

PoC

Impact

Proposed fix

Mitigation

Mitigation