Common Weakness Enumeration

CWE-1325

Allowed

Improperly Controlled Sequential Memory Allocation

Abstraction: Base · Status: Incomplete

API response cwe.mitre.org

The product manages a group of objects or resources and performs a separate memory allocation for each object, but it does not properly limit the total amount of memory that is consumed by all of the combined objects.

38 vulnerabilities reference this CWE, most recent first.

GHSA-444M-PX7R-QPVV

Vulnerability from github – Published: 2026-01-27 09:30 – Updated: 2026-01-28 16:01
VLAI
Summary
weixin4j has Improperly Controlled Sequential Memory Allocation
Details

Improperly Controlled Sequential Memory Allocation vulnerability in foxinmy weixin4j (weixin4j-base/src/main/java/com/foxinmy/weixin4j/util modules). This vulnerability is associated with program files CharArrayBuffer.Java, ClassUtil.Java.

This issue affects all versions of weixin4j. A path is available: d1c8258

Severity
6.3 (Medium)
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:L/SI:N/SA:N/AU:Y/R:A/V:D/RE:M/U:Amber
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "com.foxinmy:weixin4j-base"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "1.10.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-24819"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1325"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-01-28T16:01:17Z",
    "nvd_published_at": "2026-01-27T09:15:52Z",
    "severity": "MODERATE"
  },
  "details": "Improperly Controlled Sequential Memory Allocation vulnerability in foxinmy weixin4j (weixin4j-base/src/main/java/com/foxinmy/weixin4j/util modules). This vulnerability is associated with program files CharArrayBuffer.Java, ClassUtil.Java.\n\nThis issue affects all versions of weixin4j. A path is available:  [d1c8258](https://github.com/foxinmy/weixin4j/commit/4b7ad14df6567064b468b4c9cb7a8bfeff48c8bd)",
  "id": "GHSA-444m-px7r-qpvv",
  "modified": "2026-01-28T16:01:17Z",
  "published": "2026-01-27T09:30:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-24819"
    },
    {
      "type": "WEB",
      "url": "https://github.com/foxinmy/weixin4j/pull/229"
    },
    {
      "type": "WEB",
      "url": "https://github.com/foxinmy/weixin4j/commit/d1c825835802cd3a0c04772be1220ff4476ea27c"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/foxinmy/weixin4j"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:L/SI:N/SA:N/AU:Y/R:A/V:D/RE:M/U:Amber",
      "type": "CVSS_V4"
    }
  ],
  "summary": "weixin4j has Improperly Controlled Sequential Memory Allocation "
}

GHSA-4MRG-698Q-FXMG

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

Dissection engine zlib decompression crash in Wireshark 4.6.0 to 4.6.4 and 4.4.0 to 4.4.14 allows denial of service

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-6535"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1325"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-30T07:16:40Z",
    "severity": "MODERATE"
  },
  "details": "Dissection engine zlib decompression crash in Wireshark 4.6.0 to 4.6.4 and 4.4.0 to 4.4.14 allows denial of service",
  "id": "GHSA-4mrg-698q-fxmg",
  "modified": "2026-04-30T09:30:25Z",
  "published": "2026-04-30T09:30:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-6535"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/wireshark/wireshark/-/issues/21097"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/wireshark/wireshark/-/issues/21098"
    },
    {
      "type": "WEB",
      "url": "https://www.wireshark.org/security/wnpa-sec-2026-26.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-56RM-3MR5-JFRM

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

WebSocket protocol dissector crash in Wireshark 4.6.0 to 4.6.4 and 4.4.0 to 4.4.14 allows denial of service

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-6869"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1325"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-30T07:16:41Z",
    "severity": "MODERATE"
  },
  "details": "WebSocket protocol dissector crash in Wireshark 4.6.0 to 4.6.4 and 4.4.0 to 4.4.14 allows denial of service",
  "id": "GHSA-56rm-3mr5-jfrm",
  "modified": "2026-04-30T09:30:25Z",
  "published": "2026-04-30T09:30:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-6869"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/wireshark/wireshark/-/work_items/21190"
    },
    {
      "type": "WEB",
      "url": "https://www.wireshark.org/security/wnpa-sec-2026-44.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-7C26-995W-6F47

Vulnerability from github – Published: 2026-07-29 15:19 – Updated: 2026-07-29 15:19
VLAI
Summary
veraPDF Parser DoS via PostScript Type 1 Font Programs
Details

Summary

Description

A PostScript-interpreter-driven Denial of Service (CWE-1325) vulnerability in veraPDF allows a remote attacker to exhaust validator memory or CPU by submitting a PDF whose Type 1 font /FontFile is a font program containing attacker-supplied PostScript. veraPDF's Type 1 font program parser dispatches every cleartext token through a hardcoded operator allow-list whose members include the unbounded array N allocation operator and the for control operator with no zero-increment guard. This affects all current versions of veraPDF-parser.

Details

The vulnerability resides in veraPDF-parser. Type 1 font program streams referenced from any Type 1 font's /FontDescriptor /FontFile are parsed by Type1FontProgram (veraPDF-parser/src/main/java/org/verapdf/pd/font/type1/Type1FontProgram.java), which extends PSParser. parseFont reads cleartext PostScript tokens until it encounters eexec (which switches into the encrypted private dictionary parser) or end-of-stream. Each non-eexec token is dispatched via toExecute, which gates execution behind a hardcoded allow-list.

The allow-list explicitly admits both ARRAY (Type1FontProgram.java:98) and FOR (Type1FontProgram.java:100). When either keyword passes the gate, operator.execute delegates straight into the generic PSOperator implementation (org.verapdf.parser.postscript.PSOperator, methods array() at PSOperator.java:536-547 and opFor() at PSOperator.java:571-592), which apply no validation:

  1. array N calls COSArray.construct(N) followed by new ArrayList<>(N) (COSArray.java:102), so the underlying Object[] is allocated up-front. Passing 2147483647 (Integer.MAX_VALUE) requests a 16 GB backing array on a 64-bit JVM.
  2. for runs for (long i = initial; i <= limit; i += increment) with no validation of increment. With increment == 0, the loop never exits.

In addition to the two shared primitives, toExecute introduces a third primitive specific to this code path: when an unknown operator is encountered, it looks the name up in userDict and recursively re-executes the value. There is no visited-set, no recursion-depth cap, and no detection of a cycle. A Type 1 font program that defines a name to itself, such as /loop { loop } def loop, recurses indefinitely on the JVM stack and throws StackOverflowError after ~16,000 frames.

The interpreter is reachable on every Type 1 font validation. GFPDType1Font's constructor unconditionally calls program.parseFont().

Type1FontProgram.parseFont only catches PostScriptException and rewraps it as IOException; it does not catch OutOfMemoryError, StackOverflowError, or wall-clock budget, so any of the three failure modes propagates out of font model construction and aborts the validation worker.

A single payload byte sequence is sufficient. The conventional %!PS-AdobeFont-1.0 header line is treated as a comment and skipped; the parser then begins consuming PostScript tokens, the very first for invocation enters the infinite loop, and the parser never reaches the eexec boundary that would normally end the cleartext section.

Impact

This impacts all current releases of the veraPDF-parser. Successful exploitation requires only that the target validate an attacker-supplied PDF; a single Type 1 font with a malicious /FontFile stream is sufficient.

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.30.1"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.verapdf:parser"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.30.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.31.22"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.verapdf:parser"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.31.1"
            },
            {
              "fixed": "1.31.23"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-54081"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1325"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-29T15:19:04Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\n**Description**\n\nA PostScript-interpreter-driven Denial of Service (CWE-1325) vulnerability in veraPDF allows a remote attacker to exhaust validator memory or CPU by submitting a PDF whose Type 1 font `/FontFile` is a font program containing attacker-supplied PostScript. veraPDF\u0027s Type 1 font program parser dispatches every cleartext token through a hardcoded operator allow-list whose members include the unbounded `array N` allocation operator and the `for` control operator with no zero-increment guard. This affects all current versions of veraPDF-parser.\n\n## Details\n\nThe vulnerability resides in veraPDF-parser. Type 1 font program streams referenced from any Type 1 font\u0027s `/FontDescriptor /FontFile` are parsed by `Type1FontProgram` (veraPDF-parser/src/main/java/org/verapdf/pd/font/type1/Type1FontProgram.java), which extends `PSParser`. `parseFont` reads cleartext PostScript tokens until it encounters `eexec` (which switches into the encrypted private dictionary parser) or end-of-stream. Each non-`eexec` token is dispatched via `toExecute`, which gates execution behind a hardcoded allow-list.\n\nThe allow-list explicitly admits both `ARRAY` (Type1FontProgram.java:98) and `FOR` (Type1FontProgram.java:100). When either keyword passes the gate, `operator.execute` delegates straight into the generic `PSOperator` implementation (`org.verapdf.parser.postscript.PSOperator`, methods `array()` at PSOperator.java:536-547 and `opFor()` at PSOperator.java:571-592), which apply no validation:\n\n1. `array N` calls `COSArray.construct(N)` followed by `new ArrayList\u003c\u003e(N)` (COSArray.java:102), so the underlying `Object[]` is allocated up-front. Passing `2147483647` (`Integer.MAX_VALUE`) requests a 16 GB backing array on a 64-bit JVM.\n2. `for` runs `for (long i = initial; i \u003c= limit; i += increment)` with no validation of `increment`. With `increment == 0`, the loop never exits.\n\nIn addition to the two shared primitives, `toExecute` introduces a third primitive specific to this code path: when an unknown operator is encountered, it looks the name up in `userDict` and recursively re-executes the value. There is no visited-set, no recursion-depth cap, and no detection of a cycle. A Type 1 font program that defines a name to itself, such as `/loop { loop } def loop`, recurses indefinitely on the JVM stack and throws `StackOverflowError` after ~16,000 frames.\n\nThe interpreter is reachable on every Type 1 font validation. `GFPDType1Font`\u0027s constructor unconditionally calls `program.parseFont()`.\n\n`Type1FontProgram.parseFont` only catches `PostScriptException` and rewraps it as `IOException`; it does not catch `OutOfMemoryError`, `StackOverflowError`, or wall-clock budget, so any of the three failure modes propagates out of font model construction and aborts the validation worker.\n\nA single payload byte sequence is sufficient. The conventional `%!PS-AdobeFont-1.0` header line is treated as a comment and skipped; the parser then begins consuming PostScript tokens, the very first `for` invocation enters the infinite loop, and the parser never reaches the `eexec` boundary that would normally end the cleartext section.\n\n## Impact\n\nThis impacts all current releases of the veraPDF-parser. Successful exploitation requires only that the target validate an attacker-supplied PDF; a single Type 1 font with a malicious `/FontFile` stream is sufficient.",
  "id": "GHSA-7c26-995w-6f47",
  "modified": "2026-07-29T15:19:04Z",
  "published": "2026-07-29T15:19:04Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/veraPDF/veraPDF-parser/security/advisories/GHSA-7c26-995w-6f47"
    },
    {
      "type": "WEB",
      "url": "https://github.com/veraPDF/veraPDF-parser/pull/703"
    },
    {
      "type": "WEB",
      "url": "https://github.com/veraPDF/veraPDF-parser/commit/73d6ec002b98ce1f3f68640442f8e5d5613c80ce"
    },
    {
      "type": "WEB",
      "url": "https://github.com/veraPDF/veraPDF-parser/commit/cb3538607a549d63504299be1088c85ae48605f4"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/veraPDF/veraPDF-parser"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "veraPDF Parser DoS via PostScript Type 1 Font Programs"
}

GHSA-7WP7-648J-J534

Vulnerability from github – Published: 2026-07-22 21:32 – Updated: 2026-07-22 21:32
VLAI
Details

Using expressions that generate large arrays it is possible to craft a query that creates very large intermediate objects in memory, causing the server to crash with OOM error.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-13056"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1325"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-22T20:16:43Z",
    "severity": "HIGH"
  },
  "details": "Using expressions that generate large arrays it is possible to craft a query that creates very large intermediate objects in memory, causing the server to crash with OOM error.",
  "id": "GHSA-7wp7-648j-j534",
  "modified": "2026-07-22T21:32:06Z",
  "published": "2026-07-22T21:32:06Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-13056"
    },
    {
      "type": "WEB",
      "url": "https://jira.mongodb.org/browse/SERVER-124355"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/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-CH76-JRMH-QM2H

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

An authenticated user can cause excess memory usage via bitwise match expression AST processing of $bitsAllSet, $bitsAnySet, $bitsAllClear, and $bitsAnyClear. This contributes to memory pressure and may lead to availability loss by OOM.

This issue impacts MongoDB Server v7.0 versions prior to 7.0.34, v8.0 versions prior to 8.0.23, v8.2 versions prior to 8.2.9 and v8.3 versions prior to 8.3.2.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-8199"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1325"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-13T04:17:41Z",
    "severity": "HIGH"
  },
  "details": "An authenticated user can cause excess memory usage via bitwise match expression AST processing of $bitsAllSet, $bitsAnySet, $bitsAllClear, and $bitsAnyClear. This contributes to memory pressure and may lead to availability loss by OOM.\n\nThis issue impacts MongoDB Server v7.0 versions prior to 7.0.34, v8.0 versions prior to 8.0.23, v8.2 versions prior to 8.2.9 and v8.3 versions prior to 8.3.2.",
  "id": "GHSA-ch76-jrmh-qm2h",
  "modified": "2026-05-13T18:30:51Z",
  "published": "2026-05-13T18:30:51Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-8199"
    },
    {
      "type": "WEB",
      "url": "https://jira.mongodb.org/browse/SERVER-122449"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/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-F283-GHQC-FG79

Vulnerability from github – Published: 2026-07-20 23:27 – Updated: 2026-07-20 23:27
VLAI
Summary
Guzzle: Unbounded response cookies risk denial of service
Details

Impact

In affected versions, Guzzle's built-in CookieJar accepts any number of Set-Cookie header fields from one response, with no limit on the size of each field. When a later request matches the stored cookies, Guzzle places every match into one generated Cookie header without limiting the number of cookies or the total header length.

A malicious or compromised server can therefore return many large cookies, causing Guzzle to store attacker-controlled data in memory and copy it into later request headers. This can increase memory use and processing time. It can also make later requests fail when the generated header exceeds a limit in a handler, HTTP implementation, proxy, or destination server. A server on one sibling host, such as attacker.example.com, can also set parent-domain cookies that are later selected for another sibling, such as service.example.com. The denial can therefore affect a different service that uses the same jar.

An application is affected when it enables the built-in cookie support, receives an attacker-controlled response, and retains or reuses the jar. The issue affects both built-in handlers because Guzzle manages these cookies itself instead of using libcurl's native cookie engine. cURL addressed a similar denial-of-service issue in CVE-2022-32205 by limiting the cookies it accepts and sends, but those native limits do not protect Guzzle's separate jar. Applications that do not use cookies, use separate jars for untrusted origins, or use a third-party CookieJarInterface with suitable limits are not affected by this behavior. The demonstrated direct impact is limited to availability. The patch does not impose a lifetime limit on a jar built up over an unlimited number of responses or populated directly by application code.

Patches

The issue is patched in 7.15.1 and later. Starting in that release, the built-in CookieJar ignores a Set-Cookie field value longer than 8,190 bytes and applies at most 50 successful cookie insertions or replacements from one response. When generating a request, it emits at most 150 matching name=value pairs and limits the complete Cookie: header line to 8,190 bytes, including the field name and following space.

These limits follow the same practical shape as cURL's response to CVE-2022-32205. Both bound cookies accepted from one response, cookies added to one request, and generated header size. Guzzle's 8,190-byte incoming field limit is more generous than cURL's current 5,000-byte cookie-line limit. Neither approach adds a global jar quota or an eviction policy. The 8,190-byte incoming boundary is inclusive. Invalid, unrelated, identical, oversized, and deletion fields do not consume the 50-cookie limit. For outgoing requests, Guzzle preserves its existing matching and iteration order. It stops after 150 pairs or before the first matching cookie that would exceed the line limit. The output limits also apply to directly imported cookie state, but that state is not limited when it is added to the jar. Explicit caller-supplied Cookie headers and third-party jar implementations remain the caller's responsibility. Versions before 7.15.1 are affected.

Workarounds

If you cannot upgrade immediately, do not enable a shared built-in cookie jar for requests to untrusted origins. Use separate jars per host or trust boundary, disable cookie handling for untrusted requests, and discard or clear a jar after receiving an untrusted response before it is reused. Applications that must accept cookies from untrusted peers can provide a custom CookieJarInterface implementation that enforces suitable limits.

Guzzle does not use libcurl's cookie engine for cookies stored in a CookieJar. The cURL handler sends the Cookie header that Guzzle's cookie middleware has already built, so libcurl's cookie limits do not apply. Upgrading libcurl therefore does not fix this issue.

References

  • https://curl.se/docs/CVE-2022-32205.html
  • https://www.rfc-editor.org/rfc/rfc10025.html#section-5.7
  • https://www.rfc-editor.org/rfc/rfc10025.html#section-5.8.3
  • https://www.rfc-editor.org/rfc/rfc10025.html#section-6.1
Severity
5.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "guzzlehttp/guzzle"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "7.15.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-1325",
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-20T23:27:02Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nIn affected versions, Guzzle\u0027s built-in `CookieJar` accepts any number of `Set-Cookie` header fields from one response, with no limit on the size of each field. When a later request matches the stored cookies, Guzzle places every match into one generated `Cookie` header without limiting the number of cookies or the total header length.\n\nA malicious or compromised server can therefore return many large cookies, causing Guzzle to store attacker-controlled data in memory and copy it into later request headers. This can increase memory use and processing time. It can also make later requests fail when the generated header exceeds a limit in a handler, HTTP implementation, proxy, or destination server. A server on one sibling host, such as `attacker.example.com`, can also set parent-domain cookies that are later selected for another sibling, such as `service.example.com`. The denial can therefore affect a different service that uses the same jar.\n\nAn application is affected when it enables the built-in cookie support, receives an attacker-controlled response, and retains or reuses the jar. The issue affects both built-in handlers because Guzzle manages these cookies itself instead of using libcurl\u0027s native cookie engine. cURL addressed a similar denial-of-service issue in CVE-2022-32205 by limiting the cookies it accepts and sends, but those native limits do not protect Guzzle\u0027s separate jar. Applications that do not use cookies, use separate jars for untrusted origins, or use a third-party `CookieJarInterface` with suitable limits are not affected by this behavior. The demonstrated direct impact is limited to availability. The patch does not impose a lifetime limit on a jar built up over an unlimited number of responses or populated directly by application code.\n\n### Patches\n\nThe issue is patched in `7.15.1` and later. Starting in that release, the built-in `CookieJar` ignores a `Set-Cookie` field value longer than 8,190 bytes and applies at most 50 successful cookie insertions or replacements from one response. When generating a request, it emits at most 150 matching `name=value` pairs and limits the complete `Cookie: ` header line to 8,190 bytes, including the field name and following space.\n\nThese limits follow the same practical shape as cURL\u0027s response to CVE-2022-32205. Both bound cookies accepted from one response, cookies added to one request, and generated header size. Guzzle\u0027s 8,190-byte incoming field limit is more generous than cURL\u0027s current 5,000-byte cookie-line limit. Neither approach adds a global jar quota or an eviction policy. The 8,190-byte incoming boundary is inclusive. Invalid, unrelated, identical, oversized, and deletion fields do not consume the 50-cookie limit. For outgoing requests, Guzzle preserves its existing matching and iteration order. It stops after 150 pairs or before the first matching cookie that would exceed the line limit. The output limits also apply to directly imported cookie state, but that state is not limited when it is added to the jar. Explicit caller-supplied `Cookie` headers and third-party jar implementations remain the caller\u0027s responsibility. Versions before `7.15.1` are affected.\n\n### Workarounds\n\nIf you cannot upgrade immediately, do not enable a shared built-in cookie jar for requests to untrusted origins. Use separate jars per host or trust boundary, disable cookie handling for untrusted requests, and discard or clear a jar after receiving an untrusted response before it is reused. Applications that must accept cookies from untrusted peers can provide a custom `CookieJarInterface` implementation that enforces suitable limits.\n\nGuzzle does not use libcurl\u0027s cookie engine for cookies stored in a `CookieJar`. The cURL handler sends the `Cookie` header that Guzzle\u0027s cookie middleware has already built, so libcurl\u0027s cookie limits do not apply. Upgrading libcurl therefore does not fix this issue.\n\n### References\n\n* https://curl.se/docs/CVE-2022-32205.html\n* https://www.rfc-editor.org/rfc/rfc10025.html#section-5.7\n* https://www.rfc-editor.org/rfc/rfc10025.html#section-5.8.3\n* https://www.rfc-editor.org/rfc/rfc10025.html#section-6.1",
  "id": "GHSA-f283-ghqc-fg79",
  "modified": "2026-07-20T23:27:02Z",
  "published": "2026-07-20T23:27:02Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/guzzle/guzzle/security/advisories/GHSA-f283-ghqc-fg79"
    },
    {
      "type": "WEB",
      "url": "https://github.com/guzzle/guzzle/pull/3901"
    },
    {
      "type": "WEB",
      "url": "https://github.com/guzzle/guzzle/commit/7b68220d6543f6f80fe62e633361fc9d4ead14d4"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/guzzle/guzzle"
    },
    {
      "type": "WEB",
      "url": "https://github.com/guzzle/guzzle/releases/tag/7.15.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:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Guzzle: Unbounded response cookies risk denial of service"
}

GHSA-F5V8-V6Q3-Q4H6

Vulnerability from github – Published: 2026-04-16 22:50 – Updated: 2026-04-16 22:50
VLAI
Summary
Meridian: Multiple defense-in-depth gaps (collection/depth caps, telemetry, retry, fan-out)
Details

Summary

Meridian v2.1.0 (Meridian.Mapping and Meridian.Mediator) shipped with nine defense-in-depth gaps reachable through its public APIs. Two are HIGH severity — the advertised DefaultMaxCollectionItems and DefaultMaxDepth safety caps are silently bypassed on the IMapper.Map(source, destination) overload and anywhere .UseDestinationValue() is configured on a collection-typed property. Four are MEDIUM (constructor invariant bypass, OpenTelemetry stack-trace info disclosure, retry amplification, notification fan-out amplification). Three are LOW (exception message disclosure, dictionary duplicate-key echo, static mediator cache growth under closed-generic types).

All nine are patched in v2.1.1. Upgrade is a drop-in NuGet bump; see the v2.1.1 CHANGELOG for the four behavioural changes (constructor selection, OTel default, publisher fan-out cap, retry caps).

Severity Matrix

# Severity CWE Finding Fix
1 HIGH CWE-770 MappingEngine.TryMapCollectionOntoExisting enumerated the source without enforcing DefaultMaxCollectionItems. Reachable via Mapper.Map<TSrc,TDst>(src, dst) and any .ForMember(..., o => o.UseDestinationValue()) on a collection member through a plain Map(src) call. Shared cap enforcement helper between MapCollection and TryMapCollectionOntoExisting.
2 HIGH CWE-674 Collection-item recursion in the existing-destination path did not increment ResolutionContext.Depth, so self-referential collection graphs could reach stack overflow before DefaultMaxDepth fired. Depth increments at every collection-item boundary.
3 MEDIUM CWE-665 ObjectCreator.CreateWithConstructorMapping always invoked the widest public constructor, silently filling unresolved parameters with default(T) and bypassing narrower-ctor invariants. Widest-ctor selection now requires every parameter to be bound via explicit ctor mapping, source-name match, or a C# optional default.
4 MEDIUM CWE-532 Mediator.MarkActivityFailure emitted the full ex.ToString() (stack + inner chain) to the OpenTelemetry exception.stacktrace activity tag by default, leaking context to any shared trace sink. Gated on MediatorTelemetryOptions.RecordExceptionStackTrace — opt-in, default false.
5 MEDIUM CWE-400 RetryBehavior retried every exception type with unbounded MaxRetries; the exponential-backoff delay overflowed TimeSpan at ~30 attempts. No cancellation exclusion. Server-side MaxRetriesCap = 10, MaxBackoff = 5 min, OperationCanceledException short-circuit, recommended RetryPolicy.TransientOnly helper.
6 MEDIUM CWE-400 TaskWhenAllPublisher started every registered handler concurrently with no bound on fan-out. New constructor parameter maxDegreeOfParallelism (default 16; -1 restores legacy unbounded).
7 LOW CWE-209 Public mapping exceptions leaked FullName of source/destination types and concatenated inner exception messages into top-level property-mapping errors. Scrubbed to type Name; inner details only via InnerException chain.
8 LOW CWE-209 Dictionary materialization threw ArgumentException on duplicate keys, echoing the attacker-supplied key's .ToString(). Last-write-wins indexer semantics.
9 LOW CWE-1325 Static mediator handler caches grow monotonically under closed-generic request types. Doc-only mitigation; no code change — consumers must not allow attacker-controlled runtime type materialization to reach Send, Publish, or CreateStream. Documented in docs/security-model.md.

Exploitation

Finding 1 / 2 (headline): A consumer that maps user-supplied collection payloads onto an existing destination list via mapper.Map(userCollection, existingList) — a documented and commonly used AutoMapper-style idiom — processes the full attacker-supplied collection with no size cap and no depth cap. An attacker sending a single request with a large (or self-referential) collection payload can block the worker thread for seconds and exhaust the managed heap or the call stack. Equivalent exposure through .UseDestinationValue() on a collection-typed destination member, reachable via a plain Map(src) call whose destination type default-initializes that member.

Finding 3: A destination type with multiple public constructors that differ only in their parameter-binding invariants (e.g., new UserAccount(string name, Email email) enforcing a non-default Email) could be instantiated with the narrower ctor's invariants silently bypassed if any source field was absent — the widest ctor was always picked, with unbound parameters replaced by default(T).

Findings 4 / 5 / 6: Amplification / information-disclosure vectors described in the matrix above. Each requires moderate integration context (telemetry sink trust, handler count, retry policy) to weaponize, but each is reachable through public APIs without authentication.

Patches

  • Meridian.Mapping 2.1.1 (published 2026-04-16)
  • Meridian.Mediator 2.1.1 (published 2026-04-16)

Verified via: - GitHub Release assets at https://github.com/UmutKorkmaz/meridian/releases/tag/v2.1.1 - Sigstore attestation (actions/attest-build-provenance@v2 → gh attestation verify green on both .nupkg from the GitHub Release) - NuGet.org indexed both packages within the release workflow run

Workarounds

Users who cannot upgrade immediately may: 1. Avoid mapper.Map(src, dst) and .UseDestinationValue() on collection-typed destination members. 2. Wrap input collection deserialization with an explicit size limit before handing the payload to Meridian. 3. Register TaskWhenAllPublisher with maxDegreeOfParallelism ≤ 16 manually (v2.1.1+ only). 4. Disable OpenTelemetry exception.stacktrace tag emission at the trace exporter level if your trace sink is less trusted than your application.

These are defense-in-depth; the only complete mitigation is upgrading to 2.1.1.

Supported Versions

As of this advisory the supported security branch is 2.1.x. The 2.0.x line (published 2026-04-15) is not receiving the Phase 1 safety-defaults infrastructure needed to carry the HIGH-severity fixes, so 2.0.x is deprecated in favor of 2.1.x. See SECURITY.md for the updated supported-versions table.

Credits

  • UmutKorkmaz (reporter and maintainer)

References

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Meridian.Mapping"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0"
            },
            {
              "fixed": "2.1.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Meridian.Mediator"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0"
            },
            {
              "fixed": "2.1.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-1325",
      "CWE-209",
      "CWE-400",
      "CWE-532",
      "CWE-665",
      "CWE-674",
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-16T22:50:37Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\n\nMeridian v2.1.0 (`Meridian.Mapping` and `Meridian.Mediator`) shipped with nine defense-in-depth gaps reachable through its public APIs. Two are HIGH severity \u2014 the advertised `DefaultMaxCollectionItems` and `DefaultMaxDepth` safety caps are silently bypassed on the `IMapper.Map(source, destination)` overload and anywhere `.UseDestinationValue()` is configured on a collection-typed property. Four are MEDIUM (constructor invariant bypass, OpenTelemetry stack-trace info disclosure, retry amplification, notification fan-out amplification). Three are LOW (exception message disclosure, dictionary duplicate-key echo, static mediator cache growth under closed-generic types).\n\nAll nine are patched in **v2.1.1**. Upgrade is a drop-in NuGet bump; see the v2.1.1 CHANGELOG for the four behavioural changes (constructor selection, OTel default, publisher fan-out cap, retry caps).\n\n## Severity Matrix\n\n| # | Severity | CWE | Finding | Fix |\n|---|---|---|---|---|\n| 1 | **HIGH** | CWE-770 | `MappingEngine.TryMapCollectionOntoExisting` enumerated the source without enforcing `DefaultMaxCollectionItems`. Reachable via `Mapper.Map\u003cTSrc,TDst\u003e(src, dst)` and any `.ForMember(..., o =\u003e o.UseDestinationValue())` on a collection member through a plain `Map(src)` call. | Shared cap enforcement helper between `MapCollection` and `TryMapCollectionOntoExisting`. |\n| 2 | **HIGH** | CWE-674 | Collection-item recursion in the existing-destination path did not increment `ResolutionContext.Depth`, so self-referential collection graphs could reach stack overflow before `DefaultMaxDepth` fired. | Depth increments at every collection-item boundary. |\n| 3 | MEDIUM | CWE-665 | `ObjectCreator.CreateWithConstructorMapping` always invoked the widest public constructor, silently filling unresolved parameters with `default(T)` and bypassing narrower-ctor invariants. | Widest-ctor selection now requires every parameter to be bound via explicit ctor mapping, source-name match, or a C# optional default. |\n| 4 | MEDIUM | CWE-532 | `Mediator.MarkActivityFailure` emitted the full `ex.ToString()` (stack + inner chain) to the OpenTelemetry `exception.stacktrace` activity tag by default, leaking context to any shared trace sink. | Gated on `MediatorTelemetryOptions.RecordExceptionStackTrace` \u2014 opt-in, default `false`. |\n| 5 | MEDIUM | CWE-400 | `RetryBehavior` retried every exception type with unbounded `MaxRetries`; the exponential-backoff delay overflowed `TimeSpan` at ~30 attempts. No cancellation exclusion. | Server-side `MaxRetriesCap = 10`, `MaxBackoff = 5 min`, `OperationCanceledException` short-circuit, recommended `RetryPolicy.TransientOnly` helper. |\n| 6 | MEDIUM | CWE-400 | `TaskWhenAllPublisher` started every registered handler concurrently with no bound on fan-out. | New constructor parameter `maxDegreeOfParallelism` (default 16; `-1` restores legacy unbounded). |\n| 7 | LOW | CWE-209 | Public mapping exceptions leaked `FullName` of source/destination types and concatenated inner exception messages into top-level property-mapping errors. | Scrubbed to type `Name`; inner details only via `InnerException` chain. |\n| 8 | LOW | CWE-209 | Dictionary materialization threw `ArgumentException` on duplicate keys, echoing the attacker-supplied key\u0027s `.ToString()`. | Last-write-wins indexer semantics. |\n| 9 | LOW | CWE-1325 | Static mediator handler caches grow monotonically under closed-generic request types. **Doc-only mitigation**; no code change \u2014 consumers must not allow attacker-controlled runtime type materialization to reach `Send`, `Publish`, or `CreateStream`. | Documented in `docs/security-model.md`. |\n\n## Exploitation\n\n**Finding 1 / 2 (headline):** A consumer that maps user-supplied collection payloads onto an existing destination list via `mapper.Map(userCollection, existingList)` \u2014 a documented and commonly used AutoMapper-style idiom \u2014 processes the full attacker-supplied collection with no size cap and no depth cap. An attacker sending a single request with a large (or self-referential) collection payload can block the worker thread for seconds and exhaust the managed heap or the call stack. Equivalent exposure through `.UseDestinationValue()` on a collection-typed destination member, reachable via a plain `Map(src)` call whose destination type default-initializes that member.\n\n**Finding 3:** A destination type with multiple public constructors that differ only in their parameter-binding invariants (e.g., `new UserAccount(string name, Email email)` enforcing a non-default `Email`) could be instantiated with the narrower ctor\u0027s invariants silently bypassed if any source field was absent \u2014 the widest ctor was always picked, with unbound parameters replaced by `default(T)`.\n\n**Findings 4 / 5 / 6:** Amplification / information-disclosure vectors described in the matrix above. Each requires moderate integration context (telemetry sink trust, handler count, retry policy) to weaponize, but each is reachable through public APIs without authentication.\n\n## Patches\n\n- `Meridian.Mapping` **2.1.1** (published 2026-04-16)\n- `Meridian.Mediator` **2.1.1** (published 2026-04-16)\n\nVerified via:\n- GitHub Release assets at \u003chttps://github.com/UmutKorkmaz/meridian/releases/tag/v2.1.1\u003e\n- Sigstore attestation (`actions/attest-build-provenance@v2` \u2192 `gh attestation verify` green on both `.nupkg` from the GitHub Release)\n- NuGet.org indexed both packages within the release workflow run\n\n## Workarounds\n\nUsers who cannot upgrade immediately may:\n1. Avoid `mapper.Map(src, dst)` and `.UseDestinationValue()` on collection-typed destination members.\n2. Wrap input collection deserialization with an explicit size limit before handing the payload to Meridian.\n3. Register `TaskWhenAllPublisher` with `maxDegreeOfParallelism` \u2264 16 manually (v2.1.1+ only).\n4. Disable OpenTelemetry `exception.stacktrace` tag emission at the trace exporter level if your trace sink is less trusted than your application.\n\nThese are defense-in-depth; the only complete mitigation is upgrading to 2.1.1.\n\n## Supported Versions\n\nAs of this advisory the supported security branch is **2.1.x**. The 2.0.x line (published 2026-04-15) is not receiving the Phase 1 safety-defaults infrastructure needed to carry the HIGH-severity fixes, so 2.0.x is deprecated in favor of 2.1.x. See `SECURITY.md` for the updated supported-versions table.\n\n## Credits\n\n- UmutKorkmaz (reporter and maintainer)\n\n## References\n\n- v2.1.1 CHANGELOG section: \u003chttps://github.com/UmutKorkmaz/meridian/blob/main/CHANGELOG.md#211---2026-04-16\u003e\n- `docs/security-model.md` threat model: \u003chttps://github.com/UmutKorkmaz/meridian/blob/main/docs/security-model.md\u003e\n- `SECURITY.md` disclosure policy: \u003chttps://github.com/UmutKorkmaz/meridian/blob/main/SECURITY.md\u003e\n- AutoMapper CVE-2026-32933 (motivating precedent for Meridian\u0027s safety-defaults)",
  "id": "GHSA-f5v8-v6q3-q4h6",
  "modified": "2026-04-16T22:50:37Z",
  "published": "2026-04-16T22:50:37Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/UmutKorkmaz/meridian/security/advisories/GHSA-f5v8-v6q3-q4h6"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/UmutKorkmaz/meridian"
    },
    {
      "type": "WEB",
      "url": "https://github.com/UmutKorkmaz/meridian/blob/main/CHANGELOG.md#211---2026-04-16"
    },
    {
      "type": "WEB",
      "url": "https://github.com/UmutKorkmaz/meridian/releases/tag/v2.1.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": "Meridian: Multiple defense-in-depth gaps (collection/depth caps, telemetry, retry, fan-out)"
}

GHSA-F5VX-F6JP-89J6

Vulnerability from github – Published: 2026-06-09 18:30 – Updated: 2026-06-10 18:31
VLAI
Details

Issue summary: Remote peer may exhaust heap memory of the QUIC server or client by flooding it with packets containing PATH_CHALLENGE frames.

Impact summary: A malicious remote peer can cause an unbounded memory allocation which can lead to an abnormal termination of the application acting as a QUIC client or server and a Denial of Service.

A remote peer may exhaust heap memory by flooding the local QUIC stack with PATH_CHALLENGE frames. The local QUIC stack allocates a PATH_RESPONSE frame for every PATH_CHALLENGE it receives. The allocated PATH_RESPONSE frame gets freed only when the remote peer acknowledges reception of the PATH_RESPONSE frame which will not be done by a malicious peer.

The FIPS modules in 4.0, 3.6, 3.5, 3.4, and 3.0 are not affected by this issue. The QUIC stack is outside of OpenSSL FIPS module boundary.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-34183"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1325"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-09T17:17:05Z",
    "severity": "HIGH"
  },
  "details": "Issue summary: Remote peer may exhaust heap memory of the QUIC\nserver or client by flooding it with packets containing PATH_CHALLENGE\nframes.\n\nImpact summary: A malicious remote peer can cause an unbounded\nmemory allocation which can lead to an abnormal termination of the\napplication acting as a QUIC client or server and a Denial of Service.\n\nA remote peer may exhaust heap memory by flooding the local\nQUIC stack with PATH_CHALLENGE frames. The local QUIC stack\nallocates a PATH_RESPONSE frame for every PATH_CHALLENGE it receives.\nThe allocated PATH_RESPONSE frame gets freed only when the remote\npeer acknowledges reception of the PATH_RESPONSE frame which will\nnot be done by a malicious peer.\n\nThe FIPS modules in 4.0, 3.6, 3.5, 3.4, and 3.0 are not affected by\nthis issue. The QUIC stack is outside of OpenSSL FIPS module\nboundary.",
  "id": "GHSA-f5vx-f6jp-89j6",
  "modified": "2026-06-10T18:31:41Z",
  "published": "2026-06-09T18:30:41Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34183"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openssl/openssl/commit/5b306efb0b3779dfdd0803b4afc9d08c91f11517"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openssl/openssl/commit/7d06955ebe0ecf8adfd4c1e92018586da47ef9ac"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openssl/openssl/commit/d2e9efbe4900a373227deb136e8665401404ffac"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openssl/openssl/commit/fbaa83859c01ad64f497b757aaf51be7d05ed9eb"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openssl/security/commit/5b306efb0b3779dfdd0803b4afc9d08c91f11517"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openssl/security/commit/7d06955ebe0ecf8adfd4c1e92018586da47ef9ac"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openssl/security/commit/d2e9efbe4900a373227deb136e8665401404ffac"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openssl/security/commit/fbaa83859c01ad64f497b757aaf51be7d05ed9eb"
    },
    {
      "type": "WEB",
      "url": "https://openssl-library.org/news/secadv/20260609.txt"
    }
  ],
  "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-GCCJ-RGH5-5X96

Vulnerability from github – Published: 2024-07-09 12:30 – Updated: 2024-07-09 12:30
VLAI
Details

A vulnerability has been identified in SIMATIC Energy Manager Basic (All versions < V7.5), SIMATIC Energy Manager PRO (All versions < V7.5), SIMATIC IPC DiagBase (All versions), SIMATIC IPC DiagMonitor (All versions), SIMIT V10 (All versions), SIMIT V11 (All versions < V11.1). Unified Automation .NET based OPC UA Server SDK before 3.2.2 used in Siemens products are affected by a similar vulnerability as documented in CVE-2023-27321 for the OPC Foundation UA .NET Standard implementation. A successful attack may lead to high load situation and memory exhaustion, and may block the server.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-52891"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1325"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-07-09T12:15:11Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability has been identified in SIMATIC Energy Manager Basic (All versions \u003c V7.5), SIMATIC Energy Manager PRO (All versions \u003c V7.5), SIMATIC IPC DiagBase (All versions), SIMATIC IPC DiagMonitor (All versions), SIMIT V10 (All versions), SIMIT V11 (All versions \u003c V11.1). Unified Automation .NET based OPC UA Server SDK before 3.2.2 used in Siemens products are affected by a similar vulnerability as documented in CVE-2023-27321 for the OPC Foundation UA .NET Standard implementation. A successful attack may lead to high load situation and memory exhaustion, and may block the server.",
  "id": "GHSA-gccj-rgh5-5x96",
  "modified": "2024-07-09T12:30:57Z",
  "published": "2024-07-09T12:30:57Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52891"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-088132.html"
    }
  ],
  "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"
    }
  ]
}
Mitigation
Implementation

Ensure multiple allocations of the same kind of object are properly tracked - possibly across multiple sessions, requests, or messages. 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 the 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.

CAPEC-130: Excessive Allocation

An adversary causes the target to allocate excessive resources to servicing the attackers' request, thereby reducing the resources available for legitimate services and degrading or denying services. Usually, this attack focuses on memory allocation, but any finite resource on the target could be the attacked, including bandwidth, processing cycles, or other resources. This attack does not attempt to force this allocation through a large number of requests (that would be Resource Depletion through Flooding) but instead uses one or a small number of requests that are carefully formatted to force the target to allocate excessive resources to service this request(s). Often this attack takes advantage of a bug in the target to cause the target to allocate resources vastly beyond what would be needed for a normal request.

← Back to the CWE list