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-FPF5-4JW8-67X8
Vulnerability from github – Published: 2026-05-07 01:54 – Updated: 2026-05-07 01:54Impact
When deserializing arrays, strings or bytes (blob) types zserio first reads the size of the variable, and then allocates sufficient memory to load data. Since the size is always trusted this can be abused by creating a data file with a large size value, causing the zserio runtime to allocate large amounts of memory.
Patches
Please cherry-pick 57f5fb.
Workarounds
- Do not accept
zserio-encoded messages from non-trusted sources. - Allocate a maximum heap amount to
rust-zerioto avoid impacting other applications.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.5.3"
},
"package": {
"ecosystem": "crates.io",
"name": "rust-zserio"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.5.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-789"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-07T01:54:57Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Impact\n\nWhen deserializing arrays, strings or bytes (blob) types zserio first reads the size of the variable, and then allocates sufficient memory to load data. Since the size is always trusted this can be abused by creating a data file with a large size value, causing the zserio runtime to allocate large amounts of memory.\n\n### Patches\n\nPlease cherry-pick [57f5fb](https://github.com/Danaozhong/rust-zserio/commit/57f5fb4a2a8611d58dbcc1a9221349206dd99c3c).\n\n### Workarounds\n\n- Do not accept `zserio`-encoded messages from non-trusted sources.\n- Allocate a maximum heap amount to `rust-zerio` to avoid impacting other applications.",
"id": "GHSA-fpf5-4jw8-67x8",
"modified": "2026-05-07T01:54:57Z",
"published": "2026-05-07T01:54:57Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/Danaozhong/rust-zserio/security/advisories/GHSA-fpf5-4jw8-67x8"
},
{
"type": "WEB",
"url": "https://github.com/ndsev/zserio/security/advisories/GHSA-cwq5-8pvq-j65j"
},
{
"type": "WEB",
"url": "https://github.com/Danaozhong/rust-zserio/commit/57f5fb4a2a8611d58dbcc1a9221349206dd99c3c"
},
{
"type": "PACKAGE",
"url": "https://github.com/Danaozhong/rust-zserio"
}
],
"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": "rust-zserio has Unbounded Memory Allocation"
}
GHSA-FW7G-X8Q3-H9PR
Vulnerability from github – Published: 2024-11-15 18:30 – Updated: 2024-11-15 18:30A vulnerability in the TL1 function of Cisco Network Convergence System (NCS) 4000 Series could allow an authenticated, local attacker to cause a memory leak in the TL1 process. This vulnerability is due to TL1 not freeing memory under some conditions. An attacker could exploit this vulnerability by connecting to the device and issuing TL1 commands after being authenticated. A successful exploit could allow the attacker to cause the TL1 process to consume large amounts of memory. When the memory reaches a threshold, the Resource Monitor (Resmon) process will begin to restart or shutdown the top five consumers of memory, resulting in a denial of service (DoS).Cisco has released software updates that address this vulnerability. There are no workarounds that address this vulnerability.This advisory is part of the September 2022 release of the Cisco IOS XR Software Security Advisory Bundled Publication. For a complete list of the advisories and links to them, see .
{
"affected": [],
"aliases": [
"CVE-2022-20845"
],
"database_specific": {
"cwe_ids": [
"CWE-789"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-15T16:15:22Z",
"severity": "MODERATE"
},
"details": "A vulnerability in the TL1 function of Cisco\u0026nbsp;Network Convergence System (NCS) 4000 Series could allow an authenticated, local attacker to cause a memory leak in the TL1 process.\nThis vulnerability is due to TL1 not freeing memory under some conditions. An attacker could exploit this vulnerability by connecting to the device and issuing TL1 commands after being authenticated. A successful exploit could allow the attacker to cause the TL1 process to consume large amounts of memory. When the memory reaches a threshold, the Resource Monitor (Resmon)\u0026nbsp;process will begin to restart or shutdown the top five consumers of memory, resulting in a denial of service (DoS).Cisco\u0026nbsp;has released software updates that address this vulnerability. There are no workarounds that address this vulnerability.This advisory is part of the September 2022 release of the Cisco\u0026nbsp;IOS XR Software Security Advisory Bundled Publication. For a complete list of the advisories and links to them, see .",
"id": "GHSA-fw7g-x8q3-h9pr",
"modified": "2024-11-15T18:30:49Z",
"published": "2024-11-15T18:30:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-20845"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:C/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-G85R-6X2Q-45W7
Vulnerability from github – Published: 2024-04-15 20:22 – Updated: 2025-01-09 22:04Impact
A vulnerability discovered in the ImageSharp library, where the processing of specially crafted files can lead to excessive memory usage in image decoders. The vulnerability is triggered when ImageSharp attempts to process image files that are designed to exploit this flaw.
This flaw can be exploited to cause a denial of service (DoS) by depleting process memory, thereby affecting applications and services that rely on ImageSharp for image processing tasks. Users and administrators are advised to update to the latest version of ImageSharp that addresses this vulnerability to mitigate the risk of exploitation.
Patches
The problem has been patched. All users are advised to upgrade to v3.1.4 or v2.1.8.
Workarounds
Before calling Image.Decode(Async), use Image.Identify to determine the image dimensions in order to enforce a limit.
References
- ImageSharp: Security Considerations
- ImageSharp.Web: Securing Processing Commands
{
"affected": [
{
"package": {
"ecosystem": "NuGet",
"name": "SixLabors.ImageSharp"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.1.8"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "SixLabors.ImageSharp"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.0"
},
{
"fixed": "3.1.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-32035"
],
"database_specific": {
"cwe_ids": [
"CWE-770",
"CWE-789"
],
"github_reviewed": true,
"github_reviewed_at": "2024-04-15T20:22:54Z",
"nvd_published_at": "2024-04-15T20:15:11Z",
"severity": "MODERATE"
},
"details": "### Impact\n\nA vulnerability discovered in the ImageSharp library, where the processing of specially crafted files can lead to excessive memory usage in image decoders. The vulnerability is triggered when ImageSharp attempts to process image files that are designed to exploit this flaw. \n\nThis flaw can be exploited to cause a denial of service (DoS) by depleting process memory, thereby affecting applications and services that rely on ImageSharp for image processing tasks. Users and administrators are advised to update to the latest version of ImageSharp that addresses this vulnerability to mitigate the risk of exploitation.\n\n### Patches\n\nThe problem has been patched. All users are advised to upgrade to v3.1.4 or v2.1.8.\n\n### Workarounds\n\nBefore calling `Image.Decode(Async)`, use `Image.Identify` to determine the image dimensions in order to enforce a limit.\n\n### References\n\n- ImageSharp: [Security Considerations](https://docs.sixlabors.com/articles/imagesharp/security.html)\n- ImageSharp.Web: [Securing Processing Commands](https://docs.sixlabors.com/articles/imagesharp.web/processingcommands.html#securing-processing-commands)",
"id": "GHSA-g85r-6x2q-45w7",
"modified": "2025-01-09T22:04:41Z",
"published": "2024-04-15T20:22:54Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/SixLabors/ImageSharp/security/advisories/GHSA-g85r-6x2q-45w7"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-32035"
},
{
"type": "WEB",
"url": "https://github.com/SixLabors/ImageSharp/commit/b6b08ac3e7cea8da5ac1e90f7c0b67dd254535c3"
},
{
"type": "WEB",
"url": "https://github.com/SixLabors/ImageSharp/commit/f21d64188e59ae9464ff462056a5e29d8e618b27"
},
{
"type": "WEB",
"url": "https://docs.sixlabors.com/articles/imagesharp.web/processingcommands.html#securing-processing-commands"
},
{
"type": "WEB",
"url": "https://docs.sixlabors.com/articles/imagesharp/security.html"
},
{
"type": "PACKAGE",
"url": "https://github.com/SixLabors/ImageSharp"
}
],
"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": "SixLabors.ImageSharp vulnerable to Memory Allocation with Excessive Size Value"
}
GHSA-G8C4-6CM2-MVXV
Vulnerability from github – Published: 2022-04-16 00:00 – Updated: 2022-05-17 00:01A vulnerability in the NETCONF process of Cisco SD-WAN vEdge Routers could allow an authenticated, local attacker to cause an affected device to run out of memory, resulting in a denial of service (DoS) condition. This vulnerability is due to insufficient memory management when an affected device receives large amounts of traffic. An attacker could exploit this vulnerability by sending malicious traffic to an affected device. A successful exploit could allow the attacker to cause the device to crash, resulting in a DoS condition.
{
"affected": [],
"aliases": [
"CVE-2022-20717"
],
"database_specific": {
"cwe_ids": [
"CWE-770",
"CWE-789"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-04-15T15:15:00Z",
"severity": "MODERATE"
},
"details": "A vulnerability in the NETCONF process of Cisco SD-WAN vEdge Routers could allow an authenticated, local attacker to cause an affected device to run out of memory, resulting in a denial of service (DoS) condition. This vulnerability is due to insufficient memory management when an affected device receives large amounts of traffic. An attacker could exploit this vulnerability by sending malicious traffic to an affected device. A successful exploit could allow the attacker to cause the device to crash, resulting in a DoS condition.",
"id": "GHSA-g8c4-6cm2-mvxv",
"modified": "2022-05-17T00:01:43Z",
"published": "2022-04-16T00:00:50Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-20717"
},
{
"type": "WEB",
"url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-sdwan-vedge-dos-jerVm4bB"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-G94R-2VXG-569J
Vulnerability from github – Published: 2026-04-23 21:43 – Updated: 2026-04-23 21:43Summary
The implementation details of the baggage, B3 and Jaeger processing code in the OpenTelemetry.Api and OpenTelemetry.Extensions.Propagators NuGet packages can allocate excessive memory when parsing which could create a potential denial of service (DoS) in the consuming application.
Details
Exceeding Limits
BaggagePropagator.Inject<T>() does not enforce the length limit of 8192 characters if the injected baggage contains only one item.
This change was introduced by #1048.
Excessive allocation
The following methods eagerly allocate intermediate arrays before applying size limits.
BaggagePropagator.Extract<T>()- this change was introduced by #1048.BaggagePropagator.Inject<T>()- this change was introduced by #1048.B3Propagator.Extract<T>()- this change was introduced by #533.B3Propagator.Extract<T>()- this change was introduced by #3244.JaegerPropagator.Extract<T>()- this change was introduced by #3309.
Impact
Excessively large propagation headers, particularly in degenerate/malformed cases that consist or large numbers of delimiter characters, can allocate excessive amounts of memory for intermediate storage of parsed content relative to the size of the original input.
Mitigation
HTTP servers often set maximum limits on the length of HTTP request headers, such as Internet Information Services (IIS) which sets a default limit of 16KB and nginx which sets a default limit of 8KB.
Workarounds
Possible workarounds include:
- Configuring appropriate HTTP request header limits.
- Disabling baggage and/or trace propagation.
Remediation
#7061 refactors the handling of baggage, B3 and Jaeger propagation headers to stop parsing eagerly when limits are exceeded and avoid allocating intermediate arrays.
{
"affected": [
{
"package": {
"ecosystem": "NuGet",
"name": "OpenTelemetry.Api"
},
"ranges": [
{
"events": [
{
"introduced": "0.5.0-beta.2"
},
{
"fixed": "1.15.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "OpenTelemetry.Extensions.Propagators"
},
"ranges": [
{
"events": [
{
"introduced": "1.3.1"
},
{
"fixed": "1.15.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-40894"
],
"database_specific": {
"cwe_ids": [
"CWE-789"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-23T21:43:53Z",
"nvd_published_at": "2026-04-23T19:17:28Z",
"severity": "MODERATE"
},
"details": "### Summary\n\nThe implementation details of the baggage, B3 and Jaeger processing code in the `OpenTelemetry.Api` and `OpenTelemetry.Extensions.Propagators` NuGet packages can allocate excessive memory when parsing which could create a potential denial of service (DoS) in the consuming application.\n\n### Details\n\n#### Exceeding Limits\n\n[`BaggagePropagator.Inject\u003cT\u003e()`](https://github.com/open-telemetry/opentelemetry-dotnet/blob/fc1a2864d1665bda857089e11fe9247e3c75637a/src/OpenTelemetry.Api/Context/Propagation/BaggagePropagator.cs#L93-L112) does not enforce the length limit of `8192` characters if the injected baggage contains only one item.\n\nThis change was introduced by #1048.\n\n#### Excessive allocation\n\nThe following methods eagerly allocate intermediate arrays before applying size limits.\n\n- [`BaggagePropagator.Extract\u003cT\u003e()`](https://github.com/open-telemetry/opentelemetry-dotnet/blob/888d1bf2489fb7408d3c5e8758a5bbffa89a8fb2/src/OpenTelemetry.Api/Context/Propagation/BaggagePropagator.cs#L52-L55) - this change was introduced by #1048.\n- [`BaggagePropagator.Inject\u003cT\u003e()`](https://github.com/open-telemetry/opentelemetry-dotnet/blob/888d1bf2489fb7408d3c5e8758a5bbffa89a8fb2/src/OpenTelemetry.Api/Context/Propagation/BaggagePropagator.cs#L138-L157) - this change was introduced by #1048.\n- [`B3Propagator.Extract\u003cT\u003e()`](https://github.com/open-telemetry/opentelemetry-dotnet/blob/888d1bf2489fb7408d3c5e8758a5bbffa89a8fb2/src/OpenTelemetry.Extensions.Propagators/B3Propagator.cs#L203-L207) - this change was introduced by #533.\n- [`B3Propagator.Extract\u003cT\u003e()`](https://github.com/open-telemetry/opentelemetry-dotnet/blob/888d1bf2489fb7408d3c5e8758a5bbffa89a8fb2/src/OpenTelemetry.Api/Context/Propagation/B3Propagator.cs#L204-L214) - this change was introduced by #3244.\n- [`JaegerPropagator.Extract\u003cT\u003e()`](https://github.com/open-telemetry/opentelemetry-dotnet/blob/888d1bf2489fb7408d3c5e8758a5bbffa89a8fb2/src/OpenTelemetry.Extensions.Propagators/JaegerPropagator.cs#L150-L154) - this change was introduced by #3309.\n\n### Impact\n\nExcessively large propagation headers, particularly in degenerate/malformed cases that consist or large numbers of delimiter characters, can allocate excessive amounts of memory for intermediate storage of parsed content relative to the size of the original input.\n\n### Mitigation\n\nHTTP servers often set maximum limits on the length of HTTP request headers, such as [Internet Information Services (IIS)](https://learn.microsoft.com/iis/configuration/system.webserver/security/requestfiltering/requestlimits/headerlimits/) which sets a default limit of 16KB and [nginx](https://nginx.org/docs/http/ngx_http_core_module.html#large_client_header_buffers) which sets a default limit of 8KB.\n\n### Workarounds\n\nPossible workarounds include:\n\n- Configuring appropriate HTTP request header limits.\n- Disabling baggage and/or trace propagation.\n\n### Remediation\n\n[#7061](https://github.com/open-telemetry/opentelemetry-dotnet/pull/7061) refactors the handling of baggage, B3 and Jaeger propagation headers to stop parsing eagerly when limits are exceeded and avoid allocating intermediate arrays.",
"id": "GHSA-g94r-2vxg-569j",
"modified": "2026-04-23T21:43:54Z",
"published": "2026-04-23T21:43:53Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/open-telemetry/opentelemetry-dotnet/security/advisories/GHSA-g94r-2vxg-569j"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-40894"
},
{
"type": "WEB",
"url": "https://github.com/open-telemetry/opentelemetry-dotnet/pull/1048"
},
{
"type": "WEB",
"url": "https://github.com/open-telemetry/opentelemetry-dotnet/pull/3244"
},
{
"type": "WEB",
"url": "https://github.com/open-telemetry/opentelemetry-dotnet/pull/3309"
},
{
"type": "WEB",
"url": "https://github.com/open-telemetry/opentelemetry-dotnet/pull/3533"
},
{
"type": "WEB",
"url": "https://github.com/open-telemetry/opentelemetry-dotnet/pull/533"
},
{
"type": "WEB",
"url": "https://github.com/open-telemetry/opentelemetry-dotnet/pull/7061"
},
{
"type": "PACKAGE",
"url": "https://github.com/open-telemetry/opentelemetry-dotnet"
},
{
"type": "WEB",
"url": "https://github.com/open-telemetry/opentelemetry-dotnet/releases/tag/core-1.15.3"
}
],
"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": "OpenTelemetry dotnet: Excessive memory allocation when parsing OpenTelemetry propagation headers"
}
GHSA-GF23-7GR9-6992
Vulnerability from github – Published: 2026-08-13 21:36 – Updated: 2026-08-13 21:36A flaw in Elasticsearch allows a low-privileged authenticated user to submit a single small request containing a forged opaque identifier. Elasticsearch decodes and deserializes the identifier before confirming that it was legitimately issued by the cluster, and a size value carried inside the identifier drives an allocation that is neither capped nor accounted for by the available memory-usage controls. The resulting out-of-memory condition is fatal and terminates the affected node process, resulting in a denial of service.
{
"affected": [],
"aliases": [
"CVE-2026-72687"
],
"database_specific": {
"cwe_ids": [
"CWE-789"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-13T20:17:29Z",
"severity": "MODERATE"
},
"details": "A flaw in Elasticsearch allows a low-privileged authenticated user to submit a single small request containing a forged opaque identifier. Elasticsearch decodes and deserializes the identifier before confirming that it was legitimately issued by the cluster, and a size value carried inside the identifier drives an allocation that is neither capped nor accounted for by the available memory-usage controls. The resulting out-of-memory condition is fatal and terminates the affected node process, resulting in a denial of service.",
"id": "GHSA-gf23-7gr9-6992",
"modified": "2026-08-13T21:36:11Z",
"published": "2026-08-13T21:36:11Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72687"
},
{
"type": "WEB",
"url": "https://discuss.elastic.co/t/elasticsearch-8-19-20-9-4-5-9-5-1-security-update-esa-2026-79/389506"
}
],
"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-GP86-Q8HG-FPXJ
Vulnerability from github – Published: 2025-01-16 19:07 – Updated: 2025-08-20 17:40Impact
MMR makes requests to other servers as part of normal operation, and these resource owners can return large amounts of JSON back to MMR for parsing. In parsing, MMR can consume large amounts of memory and exhaust available memory.
Patches
This is fixed in MMR v1.3.8.
Workarounds
Forward proxies can be configured to block requests to unsafe hosts. Alternatively, MMR processes can be configured with memory limits and auto-restart. Running multiple MMR processes concurrently can help ensure a restart does not overly impact users.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.3.7"
},
"package": {
"ecosystem": "Go",
"name": "github.com/t2bot/matrix-media-repo"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.3.8"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-52791"
],
"database_specific": {
"cwe_ids": [
"CWE-789"
],
"github_reviewed": true,
"github_reviewed_at": "2025-01-16T19:07:43Z",
"nvd_published_at": "2025-01-16T20:15:32Z",
"severity": "MODERATE"
},
"details": "### Impact\nMMR makes requests to other servers as part of normal operation, and these resource owners can return large amounts of JSON back to MMR for parsing. In parsing, MMR can consume large amounts of memory and exhaust available memory.\n\n### Patches\nThis is fixed in [MMR v1.3.8](https://github.com/t2bot/matrix-media-repo/releases/tag/v1.3.8).\n\n### Workarounds\nForward proxies can be configured to block requests to unsafe hosts. Alternatively, MMR processes can be configured with memory limits and auto-restart. Running multiple MMR processes concurrently can help ensure a restart does not overly impact users.",
"id": "GHSA-gp86-q8hg-fpxj",
"modified": "2025-08-20T17:40:17Z",
"published": "2025-01-16T19:07:43Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/t2bot/matrix-media-repo/security/advisories/GHSA-gp86-q8hg-fpxj"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-52791"
},
{
"type": "PACKAGE",
"url": "https://github.com/t2bot/matrix-media-repo"
},
{
"type": "WEB",
"url": "https://github.com/t2bot/matrix-media-repo/releases/tag/v1.3.8"
},
{
"type": "WEB",
"url": "https://pkg.go.dev/vuln/GO-2025-3398"
}
],
"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": "matrix-media-repo (MMR) allows a denial of service through memory exhaustion"
}
GHSA-GPG2-7M3G-5QC5
Vulnerability from github – Published: 2026-08-13 21:36 – Updated: 2026-08-13 21:36Memory Allocation with Excessive Size Value (CWE-789) in the ES|QL query processing of Elasticsearch can lead to denial of service via Excessive Allocation (CAPEC-130). An authenticated user able to submit ES|QL queries could send a specially crafted query whose evaluation allocates an unbounded amount of heap memory, exhausting the available heap on the receiving node and causing the node to become unavailable.
{
"affected": [],
"aliases": [
"CVE-2026-72656"
],
"database_specific": {
"cwe_ids": [
"CWE-789"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-13T20:17:25Z",
"severity": "MODERATE"
},
"details": "Memory Allocation with Excessive Size Value (CWE-789) in the ES|QL query processing of Elasticsearch can lead to denial of service via Excessive Allocation (CAPEC-130). An authenticated user able to submit ES|QL queries could send a specially crafted query whose evaluation allocates an unbounded amount of heap memory, exhausting the available heap on the receiving node and causing the node to become unavailable.",
"id": "GHSA-gpg2-7m3g-5qc5",
"modified": "2026-08-13T21:36:08Z",
"published": "2026-08-13T21:36:08Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72656"
},
{
"type": "WEB",
"url": "https://discuss.elastic.co/t/elasticsearch-8-18-0-9-0-0-security-update-esa-2026-111/389495"
}
],
"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-GPGQ-5Q34-MH72
Vulnerability from github – Published: 2023-12-27 18:30 – Updated: 2023-12-27 18:30A flaw was found in EAP-7 during deserialization of certain classes, which permits instantiation of HashMap and HashTable with no checks on resources consumed. This issue could allow an attacker to submit malicious requests using these classes, which could eventually exhaust the heap and result in a Denial of Service.
{
"affected": [],
"aliases": [
"CVE-2023-3171"
],
"database_specific": {
"cwe_ids": [
"CWE-770",
"CWE-789"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-12-27T16:15:13Z",
"severity": "HIGH"
},
"details": "A flaw was found in EAP-7 during deserialization of certain classes, which permits instantiation of HashMap and HashTable with no checks on resources consumed. This issue could allow an attacker to submit malicious requests using these classes, which could eventually exhaust the heap and result in a Denial of Service.",
"id": "GHSA-gpgq-5q34-mh72",
"modified": "2023-12-27T18:30:20Z",
"published": "2023-12-27T18:30:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-3171"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2023:5484"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2023:5485"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2023:5486"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2023:5488"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2023-3171"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2213639"
}
],
"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-GPQH-X9H4-X2XH
Vulnerability from github – Published: 2025-08-06 15:31 – Updated: 2025-08-06 15:31NVIDIA Triton Inference Server for Windows and Linux contains a vulnerability where a user could cause a memory allocation with excessive size value, leading to a segmentation fault, by providing an invalid request. A successful exploit of this vulnerability might lead to denial of service.
{
"affected": [],
"aliases": [
"CVE-2025-23331"
],
"database_specific": {
"cwe_ids": [
"CWE-789"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-08-06T13:15:40Z",
"severity": "HIGH"
},
"details": "NVIDIA Triton Inference Server for Windows and Linux contains a vulnerability where a user could cause a memory allocation with excessive size value, leading to a segmentation fault, by providing an invalid request. A successful exploit of this vulnerability might lead to denial of service.",
"id": "GHSA-gpqh-x9h4-x2xh",
"modified": "2025-08-06T15:31:26Z",
"published": "2025-08-06T15:31:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23331"
},
{
"type": "WEB",
"url": "https://nvidia.custhelp.com/app/answers/detail/a_id/5687"
},
{
"type": "WEB",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23331"
}
],
"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"
}
]
}
Mitigation
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
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.