Vulnerability-Lookup

GHSA-G2PG-6438-JWPF

Vulnerability from github – Published: 2026-01-15 22:15 – Updated: 2026-01-15 22:15

Summary

devalue vulnerable to denial of service due to memory/CPU exhaustion in devalue.parse

Details

Summary

Certain inputs can cause devalue.parse to consume excessive CPU time and/or memory, potentially leading to denial of service in systems that parse input from untrusted sources. This affects applications using devalue.parse on externally-supplied data. The root cause is the ArrayBuffer hydration expecting base64 encoded strings as input, but not checking the assumption before decoding the input.

Details

The parser's ArrayBuffer hydration logic does not properly validate input before processing. Specially crafted inputs can cause disproportionate memory allocation or CPU usage on the receiving system.

Impact

This is a denial of service vulnerability affecting systems that use devalue.parse to handle data from potentially untrusted sources.

Affected systems should upgrade to patched versions immediately.

Severity

7.5 (High)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "devalue"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.1.0"
            },
            {
              "fixed": "5.6.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-22775"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-405"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-01-15T22:15:18Z",
    "nvd_published_at": "2026-01-15T19:16:05Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\nCertain inputs can cause `devalue.parse` to consume excessive CPU time and/or memory, potentially leading to denial of service in systems that parse input from untrusted sources. This affects applications using `devalue.parse` on externally-supplied data. The root cause is the `ArrayBuffer` hydration expecting base64 encoded strings as input, but not checking the assumption before decoding the input.\n\n## Details\n\nThe parser\u0027s `ArrayBuffer` hydration logic does not properly validate input before processing. Specially crafted inputs can cause disproportionate memory allocation or CPU usage on the receiving system.\n\n## Impact\n\nThis is a denial of service vulnerability affecting systems that use `devalue.parse` to handle data from potentially untrusted sources.\n\nAffected systems should upgrade to patched versions immediately.",
  "id": "GHSA-g2pg-6438-jwpf",
  "modified": "2026-01-15T22:15:18Z",
  "published": "2026-01-15T22:15:18Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/sveltejs/devalue/security/advisories/GHSA-g2pg-6438-jwpf"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-22775"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sveltejs/devalue/commit/11755849fa0634ae294a15ec0aef2f43efcad7c4"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/sveltejs/devalue"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sveltejs/devalue/releases/tag/v5.6.2"
    }
  ],
  "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": "devalue vulnerable to denial of service due to memory/CPU exhaustion in devalue.parse"
}

GHSA-GQHX-WXJR-RPHX

Vulnerability from github – Published: 2023-06-26 21:30 – Updated: 2024-09-16 15:32

Details

An unauthenticated denial of service vulnerability exists in the SMM v1, SMM v2, and FPC management web server which can be triggered under crafted conditions. Rebooting SMM or FPC will restore access to the management web server.

Severity

7.5 (High)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2023-2992"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-405"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-06-26T20:15:09Z",
    "severity": "HIGH"
  },
  "details": "An unauthenticated \u00a0denial of service vulnerability exists in the SMM v1, SMM v2, and FPC management web server which can be triggered under crafted conditions.  Rebooting SMM or FPC will restore access to the management web server.",
  "id": "GHSA-gqhx-wxjr-rphx",
  "modified": "2024-09-16T15:32:44Z",
  "published": "2023-06-26T21:30:59Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-2992"
    },
    {
      "type": "WEB",
      "url": "https://support.lenovo.com/us/en/product_security/LEN-127357"
    }
  ],
  "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-J3G3-5QV5-52MJ

Vulnerability from github – Published: 2025-04-28 14:17 – Updated: 2025-11-21 22:18

Summary

net-imap rubygem vulnerable to possible DoS by memory exhaustion

Details

Summary

There is a possibility for denial of service by memory exhaustion when net-imap reads server responses. At any time while the client is connected, a malicious server can send can send a "literal" byte count, which is automatically read by the client's receiver thread. The response reader immediately allocates memory for the number of bytes indicated by the server response.

This should not be an issue when securely connecting to trusted IMAP servers that are well-behaved. It can affect insecure connections and buggy, untrusted, or compromised servers (for example, connecting to a user supplied hostname).

Details

The IMAP protocol allows "literal" strings to be sent in responses, prefixed with their size in curly braces (e.g. {1234567890}\r\n). When Net::IMAP receives a response containing a literal string, it calls IO#read with that size. When called with a size, IO#read immediately allocates memory to buffer the entire string before processing continues. The server does not need to send any more data. There is no limit on the size of literals that will be accepted.

Fix

Upgrade

Users should upgrade to net-imap 0.5.7 or later. A configurable max_response_size limit has been added to Net::IMAP's response reader. The max_response_size limit has also been backported to net-imap 0.2.5, 0.3.9, and 0.4.20.

To set a global value for max_response_size, users must upgrade to net-imap ~> 0.4.20, or > 0.5.7.

Configuration

To avoid backward compatibility issues for secure connections to trusted well-behaved servers, the default max_response_size for net-imap 0.5.7 is very high (512MiB), and the default max_response_size for net-imap ~> 0.4.20, ~> 0.3.9, and 0.2.5 is nil (unlimited).

When connecting to untrusted servers or using insecure connections, a much lower max_response_size should be used.

# Set the global max_response_size (only ~> v0.4.20, > 0.5.7)
Net::IMAP.config.max_response_size = 256 << 10 # 256 KiB

# Set when creating the connection
imap = Net::IMAP.new(hostname, ssl: true,
                     max_response_size: 16 << 10) # 16 KiB

# Set after creating the connection
imap.max_response_size = 256 << 20 # 256 KiB
# flush currently waiting read, to ensure the new setting is loaded
imap.noop

Please Note: max_response_size only limits the size per response. It does not prevent a flood of individual responses and it does not limit how many unhandled responses may be stored on the responses hash. Users are responsible for adding response handlers to prune excessive unhandled responses.

Compatibility with lower `max_response_size`

A lower max_response_size may cause a few commands which legitimately return very large responses to raise an exception and close the connection. The max_response_size could be temporarily set to a higher value, but paginated or limited versions of commands should be used whenever possible. For example, to fetch message bodies:

imap.max_response_size = 256 << 20 # 256 KiB
imap.noop # flush currently waiting read

# fetch a message in 252KiB chunks
size = imap.uid_fetch(uid, "RFC822.SIZE").first.rfc822_size
limit = 252 << 10
message = ((0..size) % limit).each_with_object("") {|offset, str|
  str << imap.uid_fetch(uid, "BODY.PEEK[]<#{offset}.#{limit}>").first.message(offset:)
}

imap.max_response_size = 16 << 20 # 16 KiB
imap.noop # flush currently waiting read

References

PR to introduce max_response_size: https://github.com/ruby/net-imap/pull/444
Specific commit: 0ae8576c1 - lib/net/imap/response_reader.rb
Backport to 0.4: https://github.com/ruby/net-imap/pull/445
Backport to 0.3: https://github.com/ruby/net-imap/pull/446
Backport to 0.2: https://github.com/ruby/net-imap/pull/447

Severity

6.0 (Medium)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.5.6"
      },
      "package": {
        "ecosystem": "RubyGems",
        "name": "net-imap"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.5.0"
            },
            {
              "fixed": "0.5.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.4.19"
      },
      "package": {
        "ecosystem": "RubyGems",
        "name": "net-imap"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.4.0"
            },
            {
              "fixed": "0.4.20"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.3.8"
      },
      "package": {
        "ecosystem": "RubyGems",
        "name": "net-imap"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.3.0"
            },
            {
              "fixed": "0.3.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.2.4"
      },
      "package": {
        "ecosystem": "RubyGems",
        "name": "net-imap"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.2.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-43857"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-405",
      "CWE-770",
      "CWE-789"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-04-28T14:17:32Z",
    "nvd_published_at": "2025-04-28T16:15:33Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nThere is a possibility for denial of service by memory exhaustion when `net-imap` reads server responses.  At any time while the client is connected, a malicious server can send can send a \"literal\" byte count, which is automatically read by the client\u0027s receiver thread.  The response reader immediately allocates memory for the number of bytes indicated by the server response.\n\nThis should not be an issue when securely connecting to trusted IMAP servers that are well-behaved.  It can affect insecure connections and buggy, untrusted, or compromised servers (for example, connecting to a user supplied hostname).\n\n### Details\n\nThe IMAP protocol allows \"literal\" strings to be sent in responses, prefixed with their size in curly braces (e.g. `{1234567890}\\r\\n`).  When `Net::IMAP` receives a response containing a literal string, it calls `IO#read` with that size.  When called with a size, `IO#read` immediately allocates memory to buffer the entire string before processing continues.  The server does not need to send any more data.  There is no limit on the size of literals that will be accepted.\n\n### Fix\n#### Upgrade\nUsers should upgrade to `net-imap` 0.5.7 or later.  A configurable `max_response_size` limit has been added to `Net::IMAP`\u0027s response reader.  The `max_response_size` limit has also been backported to `net-imap` 0.2.5, 0.3.9, and 0.4.20.\n\nTo set a global value for `max_response_size`, users must upgrade to `net-imap` ~\u003e 0.4.20, or \u003e 0.5.7.\n\n#### Configuration\n\nTo avoid backward compatibility issues for secure connections to trusted well-behaved servers, the default `max_response_size` for `net-imap` 0.5.7 is _very high_ (512MiB), and the default `max_response_size` for `net-imap` ~\u003e 0.4.20, ~\u003e 0.3.9, and 0.2.5 is `nil` (unlimited).\n\nWhen connecting to untrusted servers or using insecure connections, a much lower `max_response_size` should be used.\n```ruby\n# Set the global max_response_size (only ~\u003e v0.4.20, \u003e 0.5.7)\nNet::IMAP.config.max_response_size = 256 \u003c\u003c 10 # 256 KiB\n\n# Set when creating the connection\nimap = Net::IMAP.new(hostname, ssl: true,\n                     max_response_size: 16 \u003c\u003c 10) # 16 KiB\n\n# Set after creating the connection\nimap.max_response_size = 256 \u003c\u003c 20 # 256 KiB\n# flush currently waiting read, to ensure the new setting is loaded\nimap.noop\n```\n\n_**Please Note:**_ `max_response_size` only limits the size _per response_.  It does not prevent a flood of individual responses and it does not limit how many unhandled responses may be stored on the responses hash.  Users are responsible for adding response handlers to prune excessive unhandled responses.\n\n#### Compatibility with lower `max_response_size`\n\nA lower `max_response_size` may cause a few commands which legitimately return very large responses to raise an exception and close the connection.  The `max_response_size` could be temporarily set to a higher value, but paginated or limited versions of commands should be used whenever possible.  For example, to fetch message bodies:\n\n```ruby\nimap.max_response_size = 256 \u003c\u003c 20 # 256 KiB\nimap.noop # flush currently waiting read\n\n# fetch a message in 252KiB chunks\nsize = imap.uid_fetch(uid, \"RFC822.SIZE\").first.rfc822_size\nlimit = 252 \u003c\u003c 10\nmessage = ((0..size) % limit).each_with_object(\"\") {|offset, str|\n  str \u003c\u003c imap.uid_fetch(uid, \"BODY.PEEK[]\u003c#{offset}.#{limit}\u003e\").first.message(offset:)\n}\n\nimap.max_response_size = 16 \u003c\u003c 20 # 16 KiB\nimap.noop # flush currently waiting read\n```\n\n### References\n\n* PR to introduce max_response_size: https://github.com/ruby/net-imap/pull/444\n  * Specific commit: [0ae8576c1 - lib/net/imap/response_reader.rb](https://github.com/ruby/net-imap/pull/444/commits/0ae8576c1a90bcd9573f81bdad4b4b824642d105#diff-53721cb4d9c3fb86b95cc8476ca2df90968ad8c481645220c607034399151462)\n* Backport to 0.4: https://github.com/ruby/net-imap/pull/445\n* Backport to 0.3: https://github.com/ruby/net-imap/pull/446\n* Backport to 0.2: https://github.com/ruby/net-imap/pull/447",
  "id": "GHSA-j3g3-5qv5-52mj",
  "modified": "2025-11-21T22:18:03Z",
  "published": "2025-04-28T14:17:32Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/ruby/net-imap/security/advisories/GHSA-j3g3-5qv5-52mj"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-43857"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ruby/net-imap/pull/442"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ruby/net-imap/pull/444"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ruby/net-imap/pull/444/commits/0ae8576c1a90bcd9573f81bdad4b4b824642d105#diff-53721cb4d9c3fb86b95cc8476ca2df90968ad8c481645220c607034399151462"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ruby/net-imap/pull/445"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ruby/net-imap/pull/446"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ruby/net-imap/pull/447"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ruby/net-imap"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/net-imap/CVE-2025-43857.yml"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "net-imap rubygem vulnerable to possible DoS by memory exhaustion"
}

GHSA-J6GV-XG9Q-8H4P

Vulnerability from github – Published: 2026-08-18 15:31 – Updated: 2026-08-18 15:31

Details

An authenticated user is able to cause disproportionate CPU load on the Frontend webserver by sending specifically crafted requests to the Frontend validate.api.exists action, leading to potential denial of service.

Severity

5.1 (Medium)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-23934"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-405"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-18T13:17:21Z",
    "severity": "MODERATE"
  },
  "details": "An authenticated user is able to cause disproportionate CPU load on the Frontend webserver by sending specifically crafted requests to the Frontend validate.api.exists action, leading to potential denial of service.",
  "id": "GHSA-j6gv-xg9q-8h4p",
  "modified": "2026-08-18T15:31:37Z",
  "published": "2026-08-18T15:31:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23934"
    },
    {
      "type": "WEB",
      "url": "https://support.zabbix.com/browse/ZBX-28072"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:A/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-JJ6M-R8JC-2GP7

Vulnerability from github – Published: 2021-06-23 18:03 – Updated: 2022-10-25 20:24

Summary

Asymmetric Resource Consumption (Amplification) in Docker containers created by Wings

Details

Impact

All versions of Pterodactyl Wings preior to 1.4.4 are vulnerable to system resource exhaustion due to improper container process limits being defined. A malicious user can consume more resources than intended and cause downstream impacts to other clients on the same hardware, eventually causing the physical server to stop responding.

Patches

Users should upgrade to 1.4.4.

Workarounds

There is no non-code based workaround for impacted versions of the software. Users running customized versions of this software can manually set a PID limit for containers created.

For more information

If you have any questions or comments about this advisory: * Contact us on Discord * Email us at dane ät pterodactyl dot io

Severity

6.5 (Medium)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/pterodactyl/wings"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.4.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-32699"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-405",
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-06-22T15:43:57Z",
    "nvd_published_at": "2021-06-22T20:15:00Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\nAll versions of Pterodactyl Wings preior to `1.4.4` are vulnerable to system resource exhaustion due to improper container process limits being defined. A malicious user can consume more resources than intended and cause downstream impacts to other clients on the same hardware, eventually causing the physical server to stop responding.\n\n### Patches\nUsers should upgrade to `1.4.4`.\n\n### Workarounds\nThere is no non-code based workaround for impacted versions of the software. Users running customized versions of this software can manually set a PID limit for containers created.\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Contact us on [Discord](https://discord.gg/pterodactyl)\n* Email us at `dane \u00e4t pterodactyl dot io`",
  "id": "GHSA-jj6m-r8jc-2gp7",
  "modified": "2022-10-25T20:24:52Z",
  "published": "2021-06-23T18:03:18Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/pterodactyl/wings/security/advisories/GHSA-jj6m-r8jc-2gp7"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-32699"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pterodactyl/wings/commit/e0078eee0a71d61573a94c75e6efcad069d78de3"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/pterodactyl/wings"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Asymmetric Resource Consumption (Amplification) in Docker containers created by Wings "
}

GHSA-JM46-725R-HH9V

Vulnerability from github – Published: 2024-03-19 18:31 – Updated: 2024-03-25 00:30

Details

An issue was found in the CPython zipfile module affecting versions 3.12.2, 3.11.8, 3.10.13, 3.9.18, and 3.8.18 and prior.

The zipfile module is vulnerable to “quoted-overlap” zip-bombs which exploit the zip format to create a zip-bomb with a high compression ratio. The fixed versions of CPython makes the zipfile module reject zip archives which overlap entries in the archive.

Severity

6.2 (Medium)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2024-0450"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-405"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-03-19T16:15:09Z",
    "severity": "MODERATE"
  },
  "details": "An issue was found in the CPython `zipfile` module affecting versions 3.12.2, 3.11.8, 3.10.13, 3.9.18, and 3.8.18 and prior.\n\nThe zipfile module is vulnerable to \u201cquoted-overlap\u201d zip-bombs which exploit the zip format to create a zip-bomb with a high compression ratio. The fixed versions of CPython makes the zipfile module reject zip archives which overlap entries in the archive.\n\n",
  "id": "GHSA-jm46-725r-hh9v",
  "modified": "2024-03-25T00:30:30Z",
  "published": "2024-03-19T18:31:59Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-0450"
    },
    {
      "type": "WEB",
      "url": "https://github.com/python/cpython/issues/109858"
    },
    {
      "type": "WEB",
      "url": "https://github.com/python/cpython/commit/30fe5d853b56138dbec62432d370a1f99409fc85"
    },
    {
      "type": "WEB",
      "url": "https://github.com/python/cpython/commit/66363b9a7b9fe7c99eba3a185b74c5fdbf842eba"
    },
    {
      "type": "WEB",
      "url": "https://github.com/python/cpython/commit/a2c59992e9e8d35baba9695eb186ad6c6ff85c51"
    },
    {
      "type": "WEB",
      "url": "https://github.com/python/cpython/commit/a956e510f6336d5ae111ba429a61c3ade30a7549"
    },
    {
      "type": "WEB",
      "url": "https://github.com/python/cpython/commit/d05bac0b74153beb541b88b4fca33bf053990183"
    },
    {
      "type": "WEB",
      "url": "https://github.com/python/cpython/commit/fa181fcf2156f703347b03a3b1966ce47be8ab3b"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2024/03/msg00024.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2024/03/msg00025.html"
    },
    {
      "type": "WEB",
      "url": "https://mail.python.org/archives/list/security-announce@python.org/thread/XELNUX2L3IOHBTFU7RQHCY6OUVEWZ2FG"
    },
    {
      "type": "WEB",
      "url": "https://www.bamsoftware.com/hacks/zipbomb"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-JXH8-WPM5-QP9X

Vulnerability from github – Published: 2025-08-15 00:31 – Updated: 2025-08-15 00:31

Details

HCL Connections Docs may mishandle validation of certain uploaded documents leading to denial of service due to resource exhaustion.

Severity

4.8 (Medium)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2025-31987"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-405"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-08-14T23:15:33Z",
    "severity": "MODERATE"
  },
  "details": "HCL Connections Docs may mishandle validation of certain uploaded documents leading to denial of service due to resource exhaustion.",
  "id": "GHSA-jxh8-wpm5-qp9x",
  "modified": "2025-08-15T00:31:48Z",
  "published": "2025-08-15T00:31:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-31987"
    },
    {
      "type": "WEB",
      "url": "https://support.hcl-software.com/csm?id=kb_article\u0026sysparm_article=KB0123272"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-MH63-6H87-95CP

Vulnerability from github – Published: 2025-03-21 22:04 – Updated: 2025-04-10 13:02

Summary

jwt-go allows excessive memory allocation during header parsing

Details

Summary

Function parse.ParseUnverified currently splits (via a call to strings.Split) its argument (which is untrusted data) on periods.

As a result, in the face of a malicious request whose Authorization header consists of Bearer followed by many period characters, a call to that function incurs allocations to the tune of O(n) bytes (where n stands for the length of the function's argument), with a constant factor of about 16. Relevant weakness: CWE-405: Asymmetric Resource Consumption (Amplification)

Details

See parse.ParseUnverified

Impact

Excessive memory allocation

Severity

7.5 (High)


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

8.7 (High)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/golang-jwt/jwt/v5"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.0.0-rc.1"
            },
            {
              "fixed": "5.2.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/golang-jwt/jwt/v4"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.5.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/golang-jwt/jwt"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.2.0"
            },
            {
              "last_affected": "3.2.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-30204"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-405"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-03-21T22:04:00Z",
    "nvd_published_at": "2025-03-21T22:15:26Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nFunction [`parse.ParseUnverified`](https://github.com/golang-jwt/jwt/blob/c035977d9e11c351f4c05dfeae193923cbab49ee/parser.go#L138-L139) currently splits (via a call to [strings.Split](https://pkg.go.dev/strings#Split)) its argument (which is untrusted data) on periods.\n\nAs a result, in the face of a malicious request whose _Authorization_ header consists of `Bearer ` followed by many period characters, a call to that function incurs allocations to the tune of O(n) bytes (where n stands for the length of the function\u0027s argument), with a constant factor of about 16. Relevant weakness: [CWE-405: Asymmetric Resource Consumption (Amplification)](https://cwe.mitre.org/data/definitions/405.html)\n\n### Details\n\nSee [`parse.ParseUnverified`](https://github.com/golang-jwt/jwt/blob/c035977d9e11c351f4c05dfeae193923cbab49ee/parser.go#L138-L139) \n\n### Impact\n\nExcessive memory allocation",
  "id": "GHSA-mh63-6h87-95cp",
  "modified": "2025-04-10T13:02:34Z",
  "published": "2025-03-21T22:04:00Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/golang-jwt/jwt/security/advisories/GHSA-mh63-6h87-95cp"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-30204"
    },
    {
      "type": "WEB",
      "url": "https://github.com/golang-jwt/jwt/commit/0951d184286dece21f73c85673fd308786ffe9c3"
    },
    {
      "type": "WEB",
      "url": "https://github.com/golang-jwt/jwt/commit/bf316c48137a1212f8d0af9288cc9ce8e59f1afb"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/golang-jwt/jwt"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20250404-0002"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "jwt-go allows excessive memory allocation during header parsing"
}

GHSA-MJ63-M3RC-8PPR

Vulnerability from github – Published: 2026-08-06 20:42 – Updated: 2026-08-06 20:42

Summary

league/commonmark: Denial of service via deeply nested XML output

Details

Impact

XmlRenderer pretty-prints XML by emitting depth-proportional indentation whitespace for every opening and closing tag. For a tree of depth n, the indentation alone sums to O(n²) bytes of output (and corresponding memory), reachable through MarkdownToXmlConverter — e.g. str_repeat('> ', $depth) . "x\n", a single line of nested blockquotes — or through a direct XmlRenderer::renderDocument() call on an attacker-influenced AST.

This affects applications that convert untrusted Markdown to XML, which is an opt-in output path. The parser's max_nesting_level bounds the depth of parser-created trees, but its default is high enough to reach damaging sizes, can be raised by the host application, and does not constrain custom or programmatically built ASTs handed straight to the renderer. The result is a memory / output-size amplification rather than a hard crash, which is why this issue is rated Medium rather than High. No confidentiality or integrity impact. XML rendering was introduced in 2.0.0 (first shipped in 2.0.0-beta1, June 2021) and has emitted depth-proportional indentation ever since, so all 2.x releases are affected (verified against 2.8.x, clean upstream 1902f60f). 1.x has no XML renderer and is not affected.

Workarounds

Applications converting untrusted Markdown to XML should:

Lower max_nesting_level to a conservative value appropriate to expected content, so the parser refuses to build extremely deep trees. This is the most direct lever for parser-produced ASTs, but does not protect trees built programmatically and passed straight to XmlRenderer.
Cap input size before conversion, since the amplification is driven by input-proportional depth.
Constrain XML consumers with memory / output-size limits (and streaming or size caps on any downstream XML parser or storage) so one request cannot allocate unbounded output.
Prefer HTML rendering for untrusted content where XML is not strictly required — the HTML renderer does not emit depth-proportional indentation and is not subject to this amplification.

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

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "league/commonmark"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0"
            },
            {
              "fixed": "2.9.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-405"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-06T20:42:54Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Impact\n\n`XmlRenderer` pretty-prints XML by emitting depth-proportional indentation whitespace for **every** opening and closing tag. For a tree of depth n, the indentation alone sums to **O(n\u00b2)** bytes of output (and corresponding memory), reachable through `MarkdownToXmlConverter` \u2014 e.g. `str_repeat(\u0027\u003e \u0027, $depth) . \"x\\n\"`, a single line of nested blockquotes \u2014 or through a direct `XmlRenderer::renderDocument()` call on an attacker-influenced AST.\n\nThis affects applications that convert untrusted Markdown to XML, which is an **opt-in** output path. The parser\u0027s `max_nesting_level` bounds the depth of *parser-created* trees, but its default is high enough to reach damaging sizes, can be raised by the host application, and does not constrain custom or programmatically built ASTs handed straight to the renderer. The result is a memory / output-size amplification rather than a hard crash, which is why this issue is rated **Medium** rather than High. No confidentiality or integrity impact. XML rendering was introduced in 2.0.0 (first shipped in 2.0.0-beta1, June 2021) and has emitted depth-proportional indentation ever since, so all 2.x releases are affected (verified against 2.8.x, clean upstream `1902f60f`). 1.x has no XML renderer and is not affected.\n\n### Workarounds\n\nApplications converting untrusted Markdown to XML should:\n\n- **Lower `max_nesting_level`** to a conservative value appropriate to expected content, so the parser refuses to build extremely deep trees. This is the most direct lever for parser-produced ASTs, but does not protect trees built programmatically and passed straight to `XmlRenderer`.\n- **Cap input size before conversion**, since the amplification is driven by input-proportional depth.\n- **Constrain XML consumers** with memory / output-size limits (and streaming or size caps on any downstream XML parser or storage) so one request cannot allocate unbounded output.\n- **Prefer HTML rendering** for untrusted content where XML is not strictly required \u2014 the HTML renderer does not emit depth-proportional indentation and is not subject to this amplification.",
  "id": "GHSA-mj63-m3rc-8ppr",
  "modified": "2026-08-06T20:42:55Z",
  "published": "2026-08-06T20:42:54Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/thephpleague/commonmark/security/advisories/GHSA-mj63-m3rc-8ppr"
    },
    {
      "type": "WEB",
      "url": "https://github.com/thephpleague/commonmark/commit/b5ac8c3947ca81844e85a09c7e0a5b4148bde2e1"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/thephpleague/commonmark"
    },
    {
      "type": "WEB",
      "url": "https://github.com/thephpleague/commonmark/releases/tag/2.9.0"
    }
  ],
  "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": "league/commonmark: Denial of service via deeply nested XML output"
}

GHSA-QJVR-435C-5FJH

Vulnerability from github – Published: 2026-05-29 19:55 – Updated: 2026-05-29 19:55

Summary

Nerdbank.MessagePack has a memory amplification DoS in collection deserialization

Details

Nerdbank.MessagePack deserializers for many collection-shaped types trusted the element count declared in MessagePack array and map headers when allocating destination storage. A crafted payload could therefore force large arrays, pooled buffers, dictionaries, or collection instances to be allocated before the deserializer had consumed the corresponding elements.

The same allocation pattern existed across strongly typed arrays, primitive arrays, mutable and immutable dictionaries, mutable enumerables, span-backed enumerable construction, JsonNode, MessagePackValue, and the object/dynamic primitive converters.

Because MessagePack array and map headers carry an attacker-controlled element count, any converter that immediately allocates count elements or constructs a collection with capacity count can turn a payload that is merely large into a much larger managed heap allocation. The reader's residency checks reduce the most extreme header-only attack shape, but they do not remove the memory amplification: minimal MessagePack elements can be one or two bytes on the wire while the managed representation may require object references, dictionary buckets, entries, array headers, or over-allocated collection internals.

Vulnerability Pattern

Affected converters followed one or both of these patterns:

int count = reader.ReadArrayHeader();
TElement[] array = new TElement[count];

int count = reader.ReadMapHeader();
Dictionary<TKey, TValue> map = new(count);

or, for streaming and span-backed construction:

TElement[] elements = ArrayPool<TElement>.Shared.Rent(count);
TCollection collection = getCollection(state, count);

In all affected cases, the allocation size was derived from the untrusted header count before the converter had read the elements. This made deserialization vulnerable to memory amplification and process availability attacks.

Affected Scope

The vulnerable logic was present in multiple converter families:

Converter surface	Risk
`ArrayConverter<TElement>`	Allocated `new TElement[count]` for typed arrays and rented large buffers in async paths.
`ArraysOfPrimitivesConverters`	Allocated or rented `TElement[count]` for primitive array and span-constructor paths.
`MutableEnumerableConverter<TEnumerable, TElement>`	Passed the untrusted count directly to collection construction.
`SpanEnumerableConverter<TEnumerable, TElement>`	Rented buffers sized to the declared element count.
`MutableDictionaryConverter<TDictionary, TKey, TValue>`	Passed the untrusted map count directly to dictionary construction.
`ImmutableDictionaryConverter<TDictionary, TKey, TValue>`	Rented `KeyValuePair<TKey, TValue>[count]` before reading entries.
`PrimitivesAsObjectConverter` and `PrimitivesAsDynamicConverter`	Allocated object arrays and dictionaries from attacker-controlled counts.
`JsonNodeConverter`	Allocated `JsonNode?[]` from the declared array length.
`MessagePackValueConverter`	Allocated arrays and dictionaries from declared array/map counts.

This means the issue affects normal typed deserialization as well as object/dynamic APIs. Any endpoint or protocol surface that accepts untrusted MessagePack and deserializes collection-shaped contracts can be affected.

Attack Mechanics

MessagePack encodes array and map lengths up front. For array32 and map32, the declared count can be very large. The reader checks that enough bytes remain to plausibly contain the declared number of elements, so an attacker must provide real payload bytes. However, the managed allocation can still be much larger than the payload.

Examples:

Attack shape	Input cost	Managed allocation pressure
`array32` of `nil` values into `object?[]`	1 byte per element	8 bytes per reference on 64-bit runtimes, plus array overhead.
`map32` of small keys and `nil` values into `Dictionary<object, object?>`	2 bytes per entry	Buckets, entries, key/value references, and dictionary overhead.
`array32` into typed reference arrays	1 byte per `nil` element when element type allows null	8 bytes per reference, plus array overhead.
`array32` into immutable dictionary staging buffers	2+ bytes per entry	`KeyValuePair<TKey, TValue>[]` staging allocation before construction.
`map32` into typed dictionaries	2+ bytes per entry for small keys/values	Dictionary capacity is allocated from the declared map count.

At larger counts, the attack can trigger OutOfMemoryException, force full blocking garbage collections, or degrade service through repeated moderate allocations. The impact is availability loss rather than confidentiality or integrity compromise.

Impact

An attacker who can deliver crafted MessagePack data to an endpoint that deserializes collections can:

Crash the target process via OutOfMemoryException from a single large payload.
Exhaust available memory through repeated moderate payloads.
Induce severe GC pressure, increasing latency and reducing throughput.
Affect typed DTO and framework integration paths, not only dynamic or untyped deserialization paths.

Concrete affected configurations include:

ASP.NET Core, SignalR, RPC, queue, or storage endpoints that deserialize MessagePack request bodies or messages into DTOs with arrays, lists, sets, dictionaries, immutable dictionaries, JsonNode, MessagePackValue, object, or dynamic members.
Code calling typed Deserialize<T>() where T contains collection-shaped members.
Code calling DeserializePrimitives() or DeserializeDynamicPrimitives() on untrusted input.
Applications registering WithObjectConverter() or WithDynamicObjectConverter() for framework integration or ad hoc object graphs.

Severity Rationale

Attack complexity is low. Once an application accepts untrusted MessagePack for an affected collection type, exploitation only requires a crafted array or map payload with a large declared count and minimal encoded elements.

Privileges required depend on deployment. Public endpoints are exploitable without authentication. Internal or authenticated message-processing systems reduce exposure but remain vulnerable to any caller who can submit MessagePack data.

User interaction is not required. The attack is triggered during server-side or service-side deserialization.

Availability impact is low. The practical outcome is memory pressure which can slow down a process or machine, or cause a network request to fail.

Proof of Concept

The following sample demonstrates the original object/dynamic shape and a typed array shape. Both rely on the same underlying bug: allocation is derived from the MessagePack header count before the elements are consumed.

using System.Buffers;
using System.Buffers.Binary;
using Nerdbank.MessagePack;

Console.WriteLine("=== Memory Amplification DoS - Nerdbank.MessagePack ===");
Console.WriteLine();

var serializer = new MessagePackSerializer();

// 5-byte array32 header + 1 byte per nil element.
// Deserializing as object?[] allocates one managed reference per element.
const int ObjectArrayCount = 1_000_000;
byte[] objectArrayPayload = BuildArray32Payload(ObjectArrayCount, 0xC0);

Measure("object?[] array32 nil", objectArrayPayload, () =>
{
    var sequence = new ReadOnlySequence<byte>(objectArrayPayload);
    var reader = new MessagePackReader(sequence);
    return serializer.DeserializePrimitives(ref reader);
});

// 5-byte array32 header + 1 byte per integer element.
// A typed int[] target allocates four bytes per element plus array overhead.
const int IntArrayCount = 1_000_000;
byte[] intArrayPayload = BuildArray32Payload(IntArrayCount, 0x00);

Measure("int[] array32 fixint", intArrayPayload, () =>
{
    var sequence = new ReadOnlySequence<byte>(intArrayPayload);
    var reader = new MessagePackReader(sequence);
    return serializer.Deserialize<int[]>(ref reader);
});

// 5-byte map32 header + 2 bytes per entry: small fixint key, nil value.
// Duplicate keys are overwritten later, but the Dictionary capacity allocation fires first.
const int MapCount = 100_000;
byte[] mapPayload = BuildMap32Payload(MapCount);

Measure("object dictionary map32", mapPayload, () =>
{
    var sequence = new ReadOnlySequence<byte>(mapPayload);
    var reader = new MessagePackReader(sequence);
    return serializer.DeserializePrimitives(ref reader);
});

static void Measure(string name, byte[] payload, Func<object?> deserialize)
{
    GC.Collect();
    long before = GC.GetTotalMemory(true);

    try
    {
        object? result = deserialize();
        long after = GC.GetTotalMemory(false);
        long delta = after - before;
        Console.WriteLine($"[{name}] payload: {payload.Length / 1024.0:F1} KB");
        Console.WriteLine($"[{name}] memory delta: +{delta / 1024.0 / 1024.0:F1} MB");
        Console.WriteLine($"[{name}] amplification: {(double)delta / payload.Length:F1}x");
        GC.KeepAlive(result);
    }
    catch (OutOfMemoryException)
    {
        Console.WriteLine($"[{name}] OutOfMemoryException");
    }
    catch (MessagePackSerializationException ex)
    {
        Console.WriteLine($"[{name}] guarded: {ex.Message}");
    }

    Console.WriteLine();
}

static byte[] BuildArray32Payload(int count, byte element)
{
    byte[] payload = new byte[5 + count];
    payload[0] = 0xDD;
    BinaryPrimitives.WriteInt32BigEndian(payload.AsSpan(1), count);
    payload.AsSpan(5).Fill(element);
    return payload;
}

static byte[] BuildMap32Payload(int count)
{
    byte[] payload = new byte[5 + count * 2];
    payload[0] = 0xDF;
    BinaryPrimitives.WriteInt32BigEndian(payload.AsSpan(1), count);

    for (int i = 0; i < count; i++)
    {
        payload[5 + i * 2] = (byte)(i % 128);
        payload[5 + i * 2 + 1] = 0xC0;
    }

    return payload;
}

Confirmed output against the vulnerable implementation included object-array amplification around 8x and dictionary amplification above 20x for moderate payload sizes. Typed collection amplification varies by element type and target collection implementation, but the same attacker-controlled preallocation primitive is present.

Remediation

The deserializer honors input data's prefixed collection sizes up to a reasonable limit, after which the collections grow when the data is actually encountered, such that memory amplification is limited to only small amounts over the size of the data being deserialized.

Prior Art

CVE-2026-21452 / GHSA-cw39-r4h6-8j3x: MessagePack for Java. An EXT32 object with an attacker-controlled payload length caused ExtensionValue.getData() to allocate a byte array of that size with no upper bound. This is the same vulnerability class: header-declared size leading to attacker-controlled heap allocation. It was fixed in msgpack-java 0.9.11 by avoiding unbounded allocation.

CVE-2024-48924 / GHSA-4qm4-8hg2-g2xm: MessagePack-CSharp. Untrusted data could trigger denial of service during deserialization through a different mechanism. It demonstrates the same ecosystem-level risk: MessagePack deserializers are frequently reachable on network and message-processing boundaries, where availability defects are exploitable.

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

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Nerdbank.MessagePack"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.1.78"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-405"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-29T19:55:09Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "Nerdbank.MessagePack deserializers for many collection-shaped types trusted the element count declared in MessagePack array and map headers when allocating destination storage. A crafted payload could therefore force large arrays, pooled buffers, dictionaries, or collection instances to be allocated before the deserializer had consumed the corresponding elements.\n\nThe same allocation pattern existed across strongly typed arrays, primitive arrays, mutable and immutable dictionaries, mutable enumerables, span-backed enumerable construction, `JsonNode`, `MessagePackValue`, and the object/dynamic primitive converters.\n\nBecause MessagePack array and map headers carry an attacker-controlled element count, any converter that immediately allocates `count` elements or constructs a collection with capacity `count` can turn a payload that is merely large into a much larger managed heap allocation. The reader\u0027s residency checks reduce the most extreme header-only attack shape, but they do not remove the memory amplification: minimal MessagePack elements can be one or two bytes on the wire while the managed representation may require object references, dictionary buckets, entries, array headers, or over-allocated collection internals.\n\n## Vulnerability Pattern\n\nAffected converters followed one or both of these patterns:\n\n```csharp\nint count = reader.ReadArrayHeader();\nTElement[] array = new TElement[count];\n\nint count = reader.ReadMapHeader();\nDictionary\u003cTKey, TValue\u003e map = new(count);\n```\n\nor, for streaming and span-backed construction:\n\n```csharp\nTElement[] elements = ArrayPool\u003cTElement\u003e.Shared.Rent(count);\nTCollection collection = getCollection(state, count);\n```\n\nIn all affected cases, the allocation size was derived from the untrusted header count before the converter had read the elements. This made deserialization vulnerable to memory amplification and process availability attacks.\n\n## Affected Scope\n\nThe vulnerable logic was present in multiple converter families:\n\n| Converter surface | Risk |\n|-------------------|------|\n| `ArrayConverter\u003cTElement\u003e` | Allocated `new TElement[count]` for typed arrays and rented large buffers in async paths. |\n| `ArraysOfPrimitivesConverters` | Allocated or rented `TElement[count]` for primitive array and span-constructor paths. |\n| `MutableEnumerableConverter\u003cTEnumerable, TElement\u003e` | Passed the untrusted count directly to collection construction. |\n| `SpanEnumerableConverter\u003cTEnumerable, TElement\u003e` | Rented buffers sized to the declared element count. |\n| `MutableDictionaryConverter\u003cTDictionary, TKey, TValue\u003e` | Passed the untrusted map count directly to dictionary construction. |\n| `ImmutableDictionaryConverter\u003cTDictionary, TKey, TValue\u003e` | Rented `KeyValuePair\u003cTKey, TValue\u003e[count]` before reading entries. |\n| `PrimitivesAsObjectConverter` and `PrimitivesAsDynamicConverter` | Allocated object arrays and dictionaries from attacker-controlled counts. |\n| `JsonNodeConverter` | Allocated `JsonNode?[]` from the declared array length. |\n| `MessagePackValueConverter` | Allocated arrays and dictionaries from declared array/map counts. |\n\nThis means the issue affects normal typed deserialization as well as object/dynamic APIs.\nAny endpoint or protocol surface that accepts untrusted MessagePack and deserializes collection-shaped contracts can be affected.\n\n## Attack Mechanics\n\nMessagePack encodes array and map lengths up front. For `array32` and `map32`, the declared count can be very large. The reader checks that enough bytes remain to plausibly contain the declared number of elements, so an attacker must provide real payload bytes. However, the managed allocation can still be much larger than the payload.\n\nExamples:\n\n| Attack shape | Input cost | Managed allocation pressure |\n|--------------|------------|-----------------------------|\n| `array32` of `nil` values into `object?[]` | 1 byte per element | 8 bytes per reference on 64-bit runtimes, plus array overhead. |\n| `map32` of small keys and `nil` values into `Dictionary\u003cobject, object?\u003e` | 2 bytes per entry | Buckets, entries, key/value references, and dictionary overhead. |\n| `array32` into typed reference arrays | 1 byte per `nil` element when element type allows null | 8 bytes per reference, plus array overhead. |\n| `array32` into immutable dictionary staging buffers | 2+ bytes per entry | `KeyValuePair\u003cTKey, TValue\u003e[]` staging allocation before construction. |\n| `map32` into typed dictionaries | 2+ bytes per entry for small keys/values | Dictionary capacity is allocated from the declared map count. |\n\nAt larger counts, the attack can trigger `OutOfMemoryException`, force full blocking garbage collections, or degrade service through repeated moderate allocations. The impact is availability loss rather than confidentiality or integrity compromise.\n\n## Impact\n\nAn attacker who can deliver crafted MessagePack data to an endpoint that deserializes collections can:\n\n- Crash the target process via `OutOfMemoryException` from a single large payload.\n- Exhaust available memory through repeated moderate payloads.\n- Induce severe GC pressure, increasing latency and reducing throughput.\n- Affect typed DTO and framework integration paths, not only dynamic or untyped deserialization paths.\n\nConcrete affected configurations include:\n\n- ASP.NET Core, SignalR, RPC, queue, or storage endpoints that deserialize MessagePack request bodies or messages into DTOs with arrays, lists, sets, dictionaries, immutable dictionaries, `JsonNode`, `MessagePackValue`, `object`, or `dynamic` members.\n- Code calling typed `Deserialize\u003cT\u003e()` where `T` contains collection-shaped members.\n- Code calling `DeserializePrimitives()` or `DeserializeDynamicPrimitives()` on untrusted input.\n- Applications registering `WithObjectConverter()` or `WithDynamicObjectConverter()` for framework integration or ad hoc object graphs.\n\n## Severity Rationale\n\n**Attack complexity is low.** Once an application accepts untrusted MessagePack for an affected collection type, exploitation only requires a crafted array or map payload with a large declared count and minimal encoded elements.\n\n**Privileges required depend on deployment.** Public endpoints are exploitable without authentication. Internal or authenticated message-processing systems reduce exposure but remain vulnerable to any caller who can submit MessagePack data.\n\n**User interaction is not required.** The attack is triggered during server-side or service-side deserialization.\n\n**Availability impact is low.** The practical outcome is memory pressure which can slow down a process or machine, or cause a network request to fail.\n\n## Proof of Concept\n\nThe following sample demonstrates the original object/dynamic shape and a typed array shape. Both rely on the same underlying bug: allocation is derived from the MessagePack header count before the elements are consumed.\n\n```csharp\nusing System.Buffers;\nusing System.Buffers.Binary;\nusing Nerdbank.MessagePack;\n\nConsole.WriteLine(\"=== Memory Amplification DoS - Nerdbank.MessagePack ===\");\nConsole.WriteLine();\n\nvar serializer = new MessagePackSerializer();\n\n// 5-byte array32 header + 1 byte per nil element.\n// Deserializing as object?[] allocates one managed reference per element.\nconst int ObjectArrayCount = 1_000_000;\nbyte[] objectArrayPayload = BuildArray32Payload(ObjectArrayCount, 0xC0);\n\nMeasure(\"object?[] array32 nil\", objectArrayPayload, () =\u003e\n{\n    var sequence = new ReadOnlySequence\u003cbyte\u003e(objectArrayPayload);\n    var reader = new MessagePackReader(sequence);\n    return serializer.DeserializePrimitives(ref reader);\n});\n\n// 5-byte array32 header + 1 byte per integer element.\n// A typed int[] target allocates four bytes per element plus array overhead.\nconst int IntArrayCount = 1_000_000;\nbyte[] intArrayPayload = BuildArray32Payload(IntArrayCount, 0x00);\n\nMeasure(\"int[] array32 fixint\", intArrayPayload, () =\u003e\n{\n    var sequence = new ReadOnlySequence\u003cbyte\u003e(intArrayPayload);\n    var reader = new MessagePackReader(sequence);\n    return serializer.Deserialize\u003cint[]\u003e(ref reader);\n});\n\n// 5-byte map32 header + 2 bytes per entry: small fixint key, nil value.\n// Duplicate keys are overwritten later, but the Dictionary capacity allocation fires first.\nconst int MapCount = 100_000;\nbyte[] mapPayload = BuildMap32Payload(MapCount);\n\nMeasure(\"object dictionary map32\", mapPayload, () =\u003e\n{\n    var sequence = new ReadOnlySequence\u003cbyte\u003e(mapPayload);\n    var reader = new MessagePackReader(sequence);\n    return serializer.DeserializePrimitives(ref reader);\n});\n\nstatic void Measure(string name, byte[] payload, Func\u003cobject?\u003e deserialize)\n{\n    GC.Collect();\n    long before = GC.GetTotalMemory(true);\n\n    try\n    {\n        object? result = deserialize();\n        long after = GC.GetTotalMemory(false);\n        long delta = after - before;\n        Console.WriteLine($\"[{name}] payload: {payload.Length / 1024.0:F1} KB\");\n        Console.WriteLine($\"[{name}] memory delta: +{delta / 1024.0 / 1024.0:F1} MB\");\n        Console.WriteLine($\"[{name}] amplification: {(double)delta / payload.Length:F1}x\");\n        GC.KeepAlive(result);\n    }\n    catch (OutOfMemoryException)\n    {\n        Console.WriteLine($\"[{name}] OutOfMemoryException\");\n    }\n    catch (MessagePackSerializationException ex)\n    {\n        Console.WriteLine($\"[{name}] guarded: {ex.Message}\");\n    }\n\n    Console.WriteLine();\n}\n\nstatic byte[] BuildArray32Payload(int count, byte element)\n{\n    byte[] payload = new byte[5 + count];\n    payload[0] = 0xDD;\n    BinaryPrimitives.WriteInt32BigEndian(payload.AsSpan(1), count);\n    payload.AsSpan(5).Fill(element);\n    return payload;\n}\n\nstatic byte[] BuildMap32Payload(int count)\n{\n    byte[] payload = new byte[5 + count * 2];\n    payload[0] = 0xDF;\n    BinaryPrimitives.WriteInt32BigEndian(payload.AsSpan(1), count);\n\n    for (int i = 0; i \u003c count; i++)\n    {\n        payload[5 + i * 2] = (byte)(i % 128);\n        payload[5 + i * 2 + 1] = 0xC0;\n    }\n\n    return payload;\n}\n```\n\nConfirmed output against the vulnerable implementation included object-array amplification around 8x and dictionary amplification above 20x for moderate payload sizes. Typed collection amplification varies by element type and target collection implementation, but the same attacker-controlled preallocation primitive is present.\n\n## Remediation\n\nThe deserializer honors input data\u0027s prefixed collection sizes up to a reasonable limit, after which the collections grow when the data is actually encountered, such that memory amplification is limited to only small amounts over the size of the data being deserialized.\n\n## Prior Art\n\n**CVE-2026-21452 / [GHSA-cw39-r4h6-8j3x](https://github.com/advisories/GHSA-cw39-r4h6-8j3x)**: MessagePack for Java. An EXT32 object with an attacker-controlled payload length caused `ExtensionValue.getData()` to allocate a byte array of that size with no upper bound. This is the same vulnerability class: header-declared size leading to attacker-controlled heap allocation. It was fixed in `msgpack-java` 0.9.11 by avoiding unbounded allocation.\n\n**CVE-2024-48924 / [GHSA-4qm4-8hg2-g2xm](https://github.com/advisories/GHSA-4qm4-8hg2-g2xm)**: MessagePack-CSharp. Untrusted data could trigger denial of service during deserialization through a different mechanism. It demonstrates the same ecosystem-level risk: MessagePack deserializers are frequently reachable on network and message-processing boundaries, where availability defects are exploitable.",
  "id": "GHSA-qjvr-435c-5fjh",
  "modified": "2026-05-29T19:55:09Z",
  "published": "2026-05-29T19:55:09Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/AArnott/Nerdbank.MessagePack/security/advisories/GHSA-qjvr-435c-5fjh"
    },
    {
      "type": "WEB",
      "url": "https://github.com/AArnott/Nerdbank.MessagePack/commit/6f19387a3d1322aea880ce3f8db2cfd0de195e12"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/AArnott/Nerdbank.MessagePack"
    }
  ],
  "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": "Nerdbank.MessagePack has a memory amplification DoS in collection deserialization"
}

CWE-405

Asymmetric Resource Consumption (Amplification)

Summary

Details

Impact

Summary

Details

Fix

Upgrade

Configuration

Compatibility with lower max_response_size

References

Impact

Patches

Workarounds

For more information

Summary

Details

Impact

Impact

Workarounds

Vulnerability Pattern

Affected Scope

Attack Mechanics

Impact

Severity Rationale

Proof of Concept

Remediation

Prior Art

Mitigation

Mitigation

Mitigation

Compatibility with lower `max_response_size`