Common Weakness Enumeration

CWE-789

Allowed

Memory Allocation with Excessive Size Value

Abstraction: Variant · Status: Draft

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.

321 vulnerabilities reference this CWE, most recent first.

GHSA-W8RR-5GCM-PP58

Vulnerability from github – Published: 2026-04-08 19:22 – Updated: 2026-04-09 14:29
VLAI
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

Show details on source website

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

Show details on source website

{
  "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-WHXR-3P84-RF3C

Vulnerability from github – Published: 2025-05-07 09:31 – Updated: 2025-11-03 21:33
VLAI
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.

Show details on source website

{
  "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-X284-J5P8-9C5P

Vulnerability from github – Published: 2026-04-16 21:30 – Updated: 2026-05-05 15:44
VLAI
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.

Show details on source website

{
  "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-X4HH-VJM7-G2JV

Vulnerability from github – Published: 2023-09-20 22:51 – Updated: 2023-09-20 22:51
VLAI
Summary
Faktory Web Dashboard can lead to denial of service(DOS) via malicious user input
Details

Summary

Faktory web dashboard can suffer from denial of service by a crafted malicious url query param days.

Details

The vulnerability is related to how the backend reads the days URL query parameter in the Faktory web dashboard. The value is used directly without any checks to create a string slice. If a very large value is provided, the backend server ends up using a significant amount of memory and causing it to crash.

PoC

To reproduce this vulnerability, please follow these steps:

Start the Faktory Docker and limit memory usage to 512 megabytes for better demonstration:

$ docker run --rm -it -m 512m \
  -p 127.0.0.1:7419:7419 \
  -p 127.0.0.1:7420:7420 \
  contribsys/faktory:latest

Send the following request. The Faktory server will exit after a few seconds due to out of memory:

$ curl 'http://localhost:7420/?days=922337'

Impact

Server Availability: The vulnerability can crash the Faktory server, affecting its availability. Denial of Service Risk: Given that the Faktory web dashboard does not require authorization, any entity with internet access to the dashboard could potentially exploit this vulnerability. This unchecked access opens up the potential for a Denial of Service (DoS) attack, which could disrupt service availability without any conditional barriers to the attacker.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/contribsys/faktory"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.8.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-37279"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-770",
      "CWE-789"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-09-20T22:51:09Z",
    "nvd_published_at": "2023-09-20T22:15:13Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nFaktory web dashboard can suffer from denial of service by a crafted malicious url query param `days`.\n\n### Details\nThe vulnerability is related to how the backend reads the `days` URL query parameter in the Faktory web dashboard. The value is used directly without any checks to create a string slice. If a very large value is provided, the backend server ends up using a significant amount of memory and causing it to crash.\n\n### PoC\nTo reproduce this vulnerability, please follow these steps:\n\nStart the Faktory Docker and limit memory usage to 512 megabytes for better demonstration:\n```\n$ docker run --rm -it -m 512m \\\n  -p 127.0.0.1:7419:7419 \\\n  -p 127.0.0.1:7420:7420 \\\n  contribsys/faktory:latest\n``` \n\nSend the following request. The Faktory server will exit after a few seconds due to out of memory:\n\n```\n$ curl \u0027http://localhost:7420/?days=922337\u0027\n```\n\n### Impact\n**Server Availability**: The vulnerability can crash the Faktory server, affecting its availability.\n**Denial of Service Risk**: Given that the Faktory web dashboard does not require authorization, any entity with internet access to the dashboard could potentially exploit this vulnerability. This unchecked access opens up the potential for a Denial of Service (DoS) attack, which could disrupt service availability without any conditional barriers to the attacker. \n",
  "id": "GHSA-x4hh-vjm7-g2jv",
  "modified": "2023-09-20T22:51:09Z",
  "published": "2023-09-20T22:51:09Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/contribsys/faktory/security/advisories/GHSA-x4hh-vjm7-g2jv"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-37279"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/contribsys/faktory"
    }
  ],
  "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": "Faktory Web Dashboard can lead to denial of service(DOS) via malicious user input"
}

GHSA-X8WM-PQ66-9PP3

Vulnerability from github – Published: 2025-06-11 15:30 – Updated: 2025-08-19 15:31
VLAI
Details

A maliciously crafted .usdc file, when loaded through Autodesk Maya, can force an uncontrolled memory allocation vulnerability. A malicious actor may leverage this vulnerability to cause a denial-of-service (DoS), or cause data corruption.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-4605"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-770",
      "CWE-789"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-06-11T14:15:36Z",
    "severity": "MODERATE"
  },
  "details": "A maliciously crafted .usdc file, when loaded through Autodesk Maya, can force an uncontrolled memory allocation vulnerability. A malicious actor may leverage this vulnerability to cause a denial-of-service (DoS), or cause data corruption.",
  "id": "GHSA-x8wm-pq66-9pp3",
  "modified": "2025-08-19T15:31:24Z",
  "published": "2025-06-11T15:30:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-4605"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Autodesk/3dsmax-usd"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Autodesk/maya-usd"
    },
    {
      "type": "WEB",
      "url": "https://www.autodesk.com/products/autodesk-access/overview"
    },
    {
      "type": "WEB",
      "url": "https://www.autodesk.com/trust/security-advisories/adsk-sa-2025-0011"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:U/C:L/I:L/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-X9HX-HWFF-3M7W

Vulnerability from github – Published: 2026-05-26 13:30 – Updated: 2026-05-26 13:30
VLAI
Details

Nord VPN 6.14.31 contains a denial of service vulnerability that allows unauthenticated attackers to crash the application by submitting an excessively long string in the password field. Attackers can paste a buffer of repeated characters into the password input field to trigger an application crash when attempting to authenticate.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2018-25368"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-789"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-25T15:16:19Z",
    "severity": "HIGH"
  },
  "details": "Nord VPN 6.14.31 contains a denial of service vulnerability that allows unauthenticated attackers to crash the application by submitting an excessively long string in the password field. Attackers can paste a buffer of repeated characters into the password input field to trigger an application crash when attempting to authenticate.",
  "id": "GHSA-x9hx-hwff-3m7w",
  "modified": "2026-05-26T13:30:44Z",
  "published": "2026-05-26T13:30:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-25368"
    },
    {
      "type": "WEB",
      "url": "https://nordvpn.com/download"
    },
    {
      "type": "WEB",
      "url": "https://www.exploit-db.com/exploits/45304"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/nord-vpn-denial-of-service-via-password-field"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/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-XHJ4-G6W8-2XJW

Vulnerability from github – Published: 2026-04-24 16:25 – Updated: 2026-04-24 16:25
VLAI
Summary
go-zserio has Unbounded Memory Allocation for All Platforms
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 apply this commit.

Workarounds

  • Do not accept zserio data from non-trusted sources.
  • Use secure transportation protocols (like TLS).
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/woven-planet/go-zserio"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.9.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-789"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-24T16:25:54Z",
    "nvd_published_at": null,
    "severity": "CRITICAL"
  },
  "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 apply [this commit](https://github.com/woven-by-toyota/go-zserio/commit/39ef1decde7e9766207794d396018776b33c6e45).\n\n### Workarounds\n\n- Do not accept zserio data from non-trusted sources.\n- Use secure transportation protocols (like TLS).",
  "id": "GHSA-xhj4-g6w8-2xjw",
  "modified": "2026-04-24T16:25:54Z",
  "published": "2026-04-24T16:25:54Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/woven-by-toyota/go-zserio/security/advisories/GHSA-xhj4-g6w8-2xjw"
    },
    {
      "type": "WEB",
      "url": "https://github.com/woven-by-toyota/go-zserio/commit/39ef1decde7e9766207794d396018776b33c6e45"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/woven-by-toyota/go-zserio"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "go-zserio has Unbounded Memory Allocation for All Platforms"
}

GHSA-XR5H-RXWF-6Q73

Vulnerability from github – Published: 2022-01-26 00:01 – Updated: 2022-02-01 00:00
VLAI
Details

This vulnerability allows local attackers to escalate privileges on affected installations of Parallels Desktop 16.1.3-49160. An attacker must first obtain the ability to execute low-privileged code on the target guest system in order to exploit this vulnerability. The specific flaw exists within the Toolgate component. The issue results from the lack of proper validation of user-supplied data, which can result in an uncontrolled memory allocation. An attacker can leverage this vulnerability to escalate privileges and execute arbitrary code in the context of the hypervisor. Was ZDI-CAN-13712.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-34868"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-789"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-01-25T16:15:00Z",
    "severity": "HIGH"
  },
  "details": "This vulnerability allows local attackers to escalate privileges on affected installations of Parallels Desktop 16.1.3-49160. An attacker must first obtain the ability to execute low-privileged code on the target guest system in order to exploit this vulnerability. The specific flaw exists within the Toolgate component. The issue results from the lack of proper validation of user-supplied data, which can result in an uncontrolled memory allocation. An attacker can leverage this vulnerability to escalate privileges and execute arbitrary code in the context of the hypervisor. Was ZDI-CAN-13712.",
  "id": "GHSA-xr5h-rxwf-6q73",
  "modified": "2022-02-01T00:00:49Z",
  "published": "2022-01-26T00:01:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-34868"
    },
    {
      "type": "WEB",
      "url": "https://kb.parallels.com/125013"
    },
    {
      "type": "WEB",
      "url": "https://www.zerodayinitiative.com/advisories/ZDI-21-1056"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-XRVJ-V92F-53GJ

Vulnerability from github – Published: 2026-06-08 23:43 – Updated: 2026-06-11 14:07
VLAI
Summary
Dulwich has unbounded memory allocation in receive-pack from crafted thin packs
Details

Impact

An uncontrolled-resource-consumption (memory exhaustion) denial-of-service vulnerability (CWE-400 / CWE-789).

A client with push access could push a tiny crafted thin pack (~174 bytes) whose delta header declares a huge dest_size. When dulwich ingested it via add_thin_pack / apply_delta, it would allocate hundreds of MB of memory based on that attacker-controlled size, with no relationship to the actual bytes received.

Who is impacted: Operators running a Dulwich-based Git server that exposes git-receive-pack (i.e. accepts pushes) - for example via dulwich.server functionality, the HTTP smart server, or anything built on ReceivePackHandler.

Patches

Patched in 1.2.5.

add_thin_pack now accepts a max_input_size keyword (bytes; 0/None = unlimited, matching git's semantics), and ReceivePackHandler reads receive.maxInputSize from the repository config and passes it through. Wire reads are counted and a PackInputTooLarge exception is raised once the cap is exceeded - equivalent to git index-pack --max-input-size.

Users should upgrade to Dulwich 1.2.5 or later and set receive.maxInputSize in their server's repository config to a sane bound for their environment.

Workarounds

On unpatched versions, receive.maxInputSize has no effect, so it cannot be used as a workaround. Until upgrading, operators should:

  • Restrict dulwich-receive-pack (push) access to trusted, authenticated clients only, or disable it entirely on servers that only need to serve fetches.
  • Run the server under an OS-level memory limit (e.g. ulimit, cgroups/MemoryMax, or a container memory limit) so a malicious push is killed rather than taking down the host.

Resources

  • git's receive.maxInputSize / git index-pack --max-input-size documentation
  • Reported by Liyi, Ziyue, Strick, Maurice and Chenchen @ University of Sydney
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "dulwich"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.1.0"
            },
            {
              "fixed": "1.2.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-47734"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-789"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-08T23:43:42Z",
    "nvd_published_at": "2026-06-10T23:16:48Z",
    "severity": "MODERATE"
  },
  "details": "## Impact\n\nAn uncontrolled-resource-consumption (memory exhaustion) denial-of-service vulnerability (CWE-400 / CWE-789).\n\nA client with push access could push a tiny crafted thin pack (~174 bytes)  whose delta header declares a huge   dest_size. When dulwich ingested it via  add_thin_pack / apply_delta, it would  allocate hundreds of MB of memory based on that attacker-controlled size, with no relationship to the actual bytes received.\n\nWho is impacted: Operators running a Dulwich-based Git server that exposes git-receive-pack (i.e. accepts pushes) -\nfor example via dulwich.server functionality, the HTTP  smart server, or anything built on ReceivePackHandler. \n\n## Patches\n\nPatched in 1.2.5.\n\nadd_thin_pack now accepts a max_input_size keyword (bytes; 0/None = unlimited, matching git\u0027s semantics), and ReceivePackHandler reads receive.maxInputSize from the repository config and passes it through. Wire reads are counted and a PackInputTooLarge exception is raised once the cap is exceeded - equivalent to git index-pack --max-input-size.\n\nUsers should upgrade to Dulwich 1.2.5 or later and set receive.maxInputSize in their server\u0027s repository config to a sane bound for their environment.\n\n## Workarounds\n\nOn unpatched versions, receive.maxInputSize has no effect, so it cannot be used as a workaround. Until upgrading, operators should:\n\n- Restrict dulwich-receive-pack (push) access to trusted, authenticated clients only, or disable it entirely on servers that only need to serve fetches.\n- Run the server under an OS-level memory limit (e.g. ulimit, cgroups/MemoryMax, or a container memory limit) so a malicious push is killed rather than taking down the host.\n\n##  Resources\n\n- git\u0027s receive.maxInputSize / git index-pack --max-input-size documentation \n- Reported by Liyi, Ziyue, Strick, Maurice and Chenchen @ University of Sydney",
  "id": "GHSA-xrvj-v92f-53gj",
  "modified": "2026-06-11T14:07:18Z",
  "published": "2026-06-08T23:43:42Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/jelmer/dulwich/security/advisories/GHSA-xrvj-v92f-53gj"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-47734"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/jelmer/dulwich"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jelmer/dulwich/releases/tag/dulwich-1.2.5"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Dulwich has unbounded memory allocation in receive-pack from crafted thin packs"
}

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.