CWE-400
DiscouragedUncontrolled Resource Consumption
Abstraction: Class · Status: Draft
The product does not properly control the allocation and maintenance of a limited resource.
5567 vulnerabilities reference this CWE, most recent first.
GHSA-38FC-WPQX-33J7
Vulnerability from github – Published: 2021-09-02 17:15 – Updated: 2021-08-26 14:52All versions of package trim-off-newlines are vulnerable to Regular Expression Denial of Service (ReDoS) via string processing.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "trim-off-newlines"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.0.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-23425"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2021-08-26T14:52:19Z",
"nvd_published_at": "2021-08-18T17:15:00Z",
"severity": "MODERATE"
},
"details": "All versions of package trim-off-newlines are vulnerable to Regular Expression Denial of Service (ReDoS) via string processing.",
"id": "GHSA-38fc-wpqx-33j7",
"modified": "2021-08-26T14:52:19Z",
"published": "2021-09-02T17:15:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-23425"
},
{
"type": "WEB",
"url": "https://github.com/stevemao/trim-off-newlines/pull/3"
},
{
"type": "PACKAGE",
"url": "https://github.com/stevemao/trim-off-newlines"
},
{
"type": "WEB",
"url": "https://github.com/stevemao/trim-off-newlines/blob/master/index.js%23L6"
},
{
"type": "WEB",
"url": "https://snyk.io/vuln/SNYK-JAVA-ORGWEBJARSNPM-1567197"
},
{
"type": "WEB",
"url": "https://snyk.io/vuln/SNYK-JS-TRIMOFFNEWLINES-1296850"
}
],
"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": "Uncontrolled Resource Consumption in trim-off-newlines"
}
GHSA-38H3-2333-QX47
Vulnerability from github – Published: 2026-04-18 01:05 – Updated: 2026-04-27 16:15Summary
[!IMPORTANT]
There is no plan to fix this issue asOpenTelemetry.Exporter.Jaegerwas deprecated in 2023. It is for informational purposes only.
OpenTelemetry.Exporter.Jaeger may allow sustained memory pressure when the internal pooled-list sizing grows based on a large observed span/tag set and that enlarged size is reused for subsequent allocations. Under high-cardinality or attacker-influenced telemetry input, this can increase memory consumption and potentially cause denial of service.
Details
The Jaeger exporter conversion path can append tag/event data into pooled list structures. In affected versions, pooled allocation sizing may be influenced by large observed payloads and reused globally across later allocations, resulting in persistent oversized rentals and elevated memory pressure. In environments where telemetry attributes/events can be influenced by untrusted input and limits are increased from defaults, this may lead to process instability or denial of service.
Impact
Availability impact only. Confidentiality and integrity impacts are not expected.
Workarounds / Mitigations
- Prefer maintained exporters (for example OpenTelemetry Protocol format (OTLP)) instead of the Jaeger exporter.
{
"affected": [
{
"package": {
"ecosystem": "NuGet",
"name": "OpenTelemetry.Exporter.Jaeger"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "1.6.0-rc.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-41078"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-18T01:05:12Z",
"nvd_published_at": "2026-04-23T19:17:28Z",
"severity": "MODERATE"
},
"details": "### Summary\n\n\u003e [!IMPORTANT] \n\u003e There is no plan to fix this issue as `OpenTelemetry.Exporter.Jaeger` was deprecated in 2023. It is for informational purposes only.\n\n`OpenTelemetry.Exporter.Jaeger` may allow sustained memory pressure when the internal pooled-list sizing grows based on a large observed span/tag set and that enlarged size is reused for subsequent allocations. Under high-cardinality or attacker-influenced telemetry input, this can increase memory consumption and potentially cause denial of service.\n\n### Details\n\nThe Jaeger exporter conversion path can append tag/event data into pooled list structures. In affected versions, pooled allocation sizing may be influenced by large observed payloads and reused globally across later allocations, resulting in persistent oversized rentals and elevated memory pressure. In environments where telemetry attributes/events can be influenced by untrusted input and limits are increased from defaults, this may lead to process instability or denial of service.\n\n### Impact\n\nAvailability impact only. Confidentiality and integrity impacts are not expected.\n\n### Workarounds / Mitigations\n\n* Prefer maintained exporters (for example OpenTelemetry Protocol format (OTLP)) instead of the Jaeger exporter.",
"id": "GHSA-38h3-2333-qx47",
"modified": "2026-04-27T16:15:48Z",
"published": "2026-04-18T01:05:12Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/open-telemetry/opentelemetry-dotnet/security/advisories/GHSA-38h3-2333-qx47"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41078"
},
{
"type": "PACKAGE",
"url": "https://github.com/open-telemetry/opentelemetry-dotnet"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "OpenTelemetry .NET has potential memory exhaustion via unbounded pooled-list sizing in Jaeger exporter conversion path"
}
GHSA-38H7-7925-FVWV
Vulnerability from github – Published: 2024-09-25 12:30 – Updated: 2026-01-05 21:30Certain PCI devices in a system might be assigned Reserved Memory Regions (specified via Reserved Memory Region Reporting, "RMRR") for Intel VT-d or Unity Mapping ranges for AMD-Vi. These are typically used for platform tasks such as legacy USB emulation.
Since the precise purpose of these regions is unknown, once a device associated with such a region is active, the mappings of these regions need to remain continuouly accessible by the device. In the logic establishing these mappings, error handling was flawed, resulting in such mappings to potentially remain in place when they should have been removed again. Respective guests would then gain access to memory regions which they aren't supposed to have access to.
{
"affected": [],
"aliases": [
"CVE-2024-31145"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-09-25T11:15:12Z",
"severity": "HIGH"
},
"details": "Certain PCI devices in a system might be assigned Reserved Memory\nRegions (specified via Reserved Memory Region Reporting, \"RMRR\") for\nIntel VT-d or Unity Mapping ranges for AMD-Vi. These are typically used\nfor platform tasks such as legacy USB emulation.\n\nSince the precise purpose of these regions is unknown, once a device\nassociated with such a region is active, the mappings of these regions\nneed to remain continuouly accessible by the device. In the logic\nestablishing these mappings, error handling was flawed, resulting in\nsuch mappings to potentially remain in place when they should have been\nremoved again. Respective guests would then gain access to memory\nregions which they aren\u0027t supposed to have access to.",
"id": "GHSA-38h7-7925-fvwv",
"modified": "2026-01-05T21:30:26Z",
"published": "2024-09-25T12:30:40Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-31145"
},
{
"type": "WEB",
"url": "https://xenbits.xenproject.org/xsa/advisory-460.html"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2024/08/14/2"
},
{
"type": "WEB",
"url": "http://xenbits.xen.org/xsa/advisory-460.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-38M8-39F8-GQ75
Vulnerability from github – Published: 2026-01-20 21:31 – Updated: 2026-01-30 21:30A memory leak in Node.js’s OpenSSL integration occurs when converting X.509 certificate fields to UTF-8 without freeing the allocated buffer. When applications call socket.getPeerCertificate(true), each certificate field leaks memory, allowing remote clients to trigger steady memory growth through repeated TLS connections. Over time this can lead to resource exhaustion and denial of service.
{
"affected": [],
"aliases": [
"CVE-2025-59464"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-01-20T21:16:03Z",
"severity": "MODERATE"
},
"details": "A memory leak in Node.js\u2019s OpenSSL integration occurs when converting `X.509` certificate fields to UTF-8 without freeing the allocated buffer. When applications call `socket.getPeerCertificate(true)`, each certificate field leaks memory, allowing remote clients to trigger steady memory growth through repeated TLS connections. Over time this can lead to resource exhaustion and denial of service.",
"id": "GHSA-38m8-39f8-gq75",
"modified": "2026-01-30T21:30:21Z",
"published": "2026-01-20T21:31:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-59464"
},
{
"type": "WEB",
"url": "https://nodejs.org/en/blog/vulnerability/december-2025-security-releases"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-38RV-X7PX-6HHQ
Vulnerability from github – Published: 2026-06-18 14:28 – Updated: 2026-06-18 14:28Impact
The undici WebSocket client enforces maxPayloadSize per-frame but does not enforce the cumulative size of fragmented uncompressed messages. A malicious WebSocket server can stream many small fragments that each pass per-frame validation but collectively exceed the configured limit, causing unbounded memory growth in the client process. The result is memory exhaustion and a denial of service.
Affected applications are those using the undici WebSocket client (new WebSocket(...)) that can be induced to connect to an attacker-controlled or compromised WebSocket endpoint.
This is a regression specific to undici 8.1.0. The 6.25.0 line shipped the equivalent cumulative check from the start and is unaffected. The 7.x line never had the maxPayloadSize feature and is also unaffected.
Patches
Upgrade to undici >= 8.5.0.
Workarounds
No workaround is available. The fix must be applied through an upgrade.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "undici"
},
"ranges": [
{
"events": [
{
"introduced": "8.0.0"
},
{
"fixed": "8.5.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-9675"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-18T14:28:10Z",
"nvd_published_at": "2026-06-17T17:17:28Z",
"severity": "HIGH"
},
"details": "## Impact\n\nThe undici WebSocket client enforces `maxPayloadSize` per-frame but does not enforce the cumulative size of fragmented uncompressed messages. A malicious WebSocket server can stream many small fragments that each pass per-frame validation but collectively exceed the configured limit, causing unbounded memory growth in the client process. The result is memory exhaustion and a denial of service.\n\nAffected applications are those using the undici WebSocket client (`new WebSocket(...)`) that can be induced to connect to an attacker-controlled or compromised WebSocket endpoint.\n\nThis is a regression specific to undici 8.1.0. The 6.25.0 line shipped the equivalent cumulative check from the start and is unaffected. The 7.x line never had the `maxPayloadSize` feature and is also unaffected.\n\n## Patches\n\nUpgrade to undici \u003e= 8.5.0.\n\n## Workarounds\n\nNo workaround is available. The fix must be applied through an upgrade.",
"id": "GHSA-38rv-x7px-6hhq",
"modified": "2026-06-18T14:28:10Z",
"published": "2026-06-18T14:28:10Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/nodejs/undici/security/advisories/GHSA-38rv-x7px-6hhq"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-9675"
},
{
"type": "WEB",
"url": "https://cna.openjsf.org/security-advisories.html"
},
{
"type": "PACKAGE",
"url": "https://github.com/nodejs/undici"
}
],
"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": "undici WebSocket client vulnerable to denial of service via cumulative fragment bypass"
}
GHSA-38WR-VPC7-2MP4
Vulnerability from github – Published: 2026-07-15 22:59 – Updated: 2026-07-15 22:59Impact
Datadog tracing libraries that implement W3C baggage propagation parse incoming baggage HTTP headers without enforcing item-count or byte-size limits on the extract path. The DD_TRACE_BAGGAGE_MAX_ITEMS (default 64) and DD_TRACE_BAGGAGE_MAX_BYTES (default 8192) limits were applied only to baggage injection, not extraction. A remote, unauthenticated attacker can send a request whose baggage header contains an arbitrarily large number of comma-separated key-value pairs (or a single very large value). The tracer allocates a hash-map entry for each pair on every request, causing unbounded CPU and memory consumption and enabling a remote Denial of Service against any HTTP service that has the baggage propagation style enabled. The baggage propagation style is enabled by default in most affected tracers, so any internet-facing service that has been instrumented with an affected tracer version is exposed unless the propagation style has been explicitly narrowed.
Patches
This is resolved in version 3.43.0 and later of the dd-trace-dotnet library.
Workarounds
If users cannot upgrade immediately:
1. Disable baggage extraction by removing baggage from DD_TRACE_PROPAGATION_STYLE (or DD_TRACE_PROPAGATION_STYLE_EXTRACT if set independently).
2. Cap the maximum HTTP request header size at an upstream proxy or web server (for example, Apache LimitRequestFieldSize, Nginx large_client_header_buffers, Envoy max_request_headers_kb).
Resources
Related upstream advisories: opentelemetry-go GHSA-mh2q-q3fh-2475 opentelemetry-dotnet GHSA-g94r-2vxg-569j
{
"affected": [
{
"package": {
"ecosystem": "NuGet",
"name": "Datadog.Trace"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.43.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Datadog.Trace.OpenTracing"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.43.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-50273"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-15T22:59:30Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Impact\nDatadog tracing libraries that implement W3C baggage propagation parse incoming baggage HTTP headers without enforcing item-count or byte-size limits on the extract path. The DD_TRACE_BAGGAGE_MAX_ITEMS (default 64) and DD_TRACE_BAGGAGE_MAX_BYTES (default 8192) limits were applied only to baggage injection, not extraction. A remote, unauthenticated attacker can send a request whose baggage header contains an arbitrarily large number of comma-separated key-value pairs (or a single very large value). The tracer allocates a hash-map entry for each pair on every request, causing unbounded CPU and memory consumption and enabling a remote Denial of Service against any HTTP service that has the baggage propagation style enabled.\nThe baggage propagation style is enabled by default in most affected tracers, so any internet-facing service that has been instrumented with an affected tracer version is exposed unless the propagation style has been explicitly narrowed.\n\n\n### Patches\nThis is resolved in version 3.43.0 and later of the `dd-trace-dotnet` library.\n\n### Workarounds\nIf users cannot upgrade immediately:\n1. Disable `baggage` extraction by removing `baggage` from `DD_TRACE_PROPAGATION_STYLE` (or `DD_TRACE_PROPAGATION_STYLE_EXTRACT` if set independently).\n2. Cap the maximum HTTP request header size at an upstream proxy or web server (for example, Apache `LimitRequestFieldSize`, Nginx `large_client_header_buffers`, Envoy `max_request_headers_kb`).\n\n### Resources\nRelated upstream advisories:\n[opentelemetry-go GHSA-mh2q-q3fh-2475](https://github.com/open-telemetry/opentelemetry-go/security/advisories/GHSA-mh2q-q3fh-2475)\n[opentelemetry-dotnet GHSA-g94r-2vxg-569j](https://github.com/open-telemetry/opentelemetry-dotnet/security/advisories/GHSA-g94r-2vxg-569j)",
"id": "GHSA-38wr-vpc7-2mp4",
"modified": "2026-07-15T22:59:30Z",
"published": "2026-07-15T22:59:30Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/DataDog/dd-trace-dotnet/security/advisories/GHSA-38wr-vpc7-2mp4"
},
{
"type": "PACKAGE",
"url": "https://github.com/DataDog/dd-trace-dotnet"
}
],
"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": "dd-trace-dotnet: Improper parsing of W3C baggage headers may lead to DoS"
}
GHSA-3936-5CXX-GXGF
Vulnerability from github – Published: 2022-05-14 01:10 – Updated: 2025-04-20 03:39When GraphicsMagick 1.3.25 processes a DPX image (with metadata indicating a large width) in coders/dpx.c, a denial of service (OOM) can occur in ReadDPXImage().
{
"affected": [],
"aliases": [
"CVE-2017-10799"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-07-03T01:29:00Z",
"severity": "MODERATE"
},
"details": "When GraphicsMagick 1.3.25 processes a DPX image (with metadata indicating a large width) in coders/dpx.c, a denial of service (OOM) can occur in ReadDPXImage().",
"id": "GHSA-3936-5cxx-gxgf",
"modified": "2025-04-20T03:39:45Z",
"published": "2022-05-14T01:10:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-10799"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2019/04/msg00015.html"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/4206-1"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2018/dsa-4321"
},
{
"type": "WEB",
"url": "http://hg.code.sf.net/p/graphicsmagick/code/rev/f10b9bb3ca62"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/99358"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-394C-5J6W-4XMX
Vulnerability from github – Published: 2022-02-09 22:46 – Updated: 2022-09-14 20:38The package ua-parser-js before 0.7.23 are vulnerable to Regular Expression Denial of Service (ReDoS) in multiple regexes (see linked commit for more info).
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "ua-parser-js"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.7.23"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2020-7793"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2021-04-08T21:32:22Z",
"nvd_published_at": "2020-12-11T14:15:00Z",
"severity": "HIGH"
},
"details": "The package ua-parser-js before 0.7.23 are vulnerable to Regular Expression Denial of Service (ReDoS) in multiple regexes (see linked commit for more info).",
"id": "GHSA-394c-5j6w-4xmx",
"modified": "2022-09-14T20:38:16Z",
"published": "2022-02-09T22:46:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-7793"
},
{
"type": "WEB",
"url": "https://github.com/faisalman/ua-parser-js/commit/6d1f26df051ba681463ef109d36c9cf0f7e32b18"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/pdf/ssa-637483.pdf"
},
{
"type": "WEB",
"url": "https://snyk.io/vuln/SNYK-JAVA-ORGWEBJARSBOWERGITHUBFAISALMAN-1050388"
},
{
"type": "WEB",
"url": "https://snyk.io/vuln/SNYK-JAVA-ORGWEBJARSNPM-1050387"
},
{
"type": "WEB",
"url": "https://snyk.io/vuln/SNYK-JS-UAPARSERJS-1023599"
}
],
"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": "ua-parser-js Regular Expression Denial of Service vulnerability"
}
GHSA-3999-5FFV-WP2R
Vulnerability from github – Published: 2024-05-01 16:40 – Updated: 2024-05-01 16:40Summary
Attack scenario The Rust implementation of the Yamux stream multiplexer uses a vector for pending frames. This vector is not bounded in length. Every time the Yamux protocol requires sending of a new frame, this frame gets appended to this vector. This can be remotely triggered in a number of ways, for example by:
- Opening a new libp2p Identify stream. This causes the node to send its Identify message. Of course, every other protocol that causes the sending of data also works. The larger the response, the more data is enqueued.
- Sending a Yamux Ping frame. This causes a Pong frame to be enqueued.
Under normal circumstances, this queue of pending frames would be drained once they’re sent out over the network. However, the attacker can use TCP’s receive window mechanism to prevent the victim from sending out any data: By not reading from the TCP connection, the receive window will never be increased, and the victim won’t be able to send out any new data (this is how TCP implements backpressure). Once this happens, Yamux’s queue of pending frames will start growing indefinitely. The queue will only be drained once the underlying TCP connection is closed.
Components https://github.com/libp2p/rust-yamux/blob/yamux-v0.13.1/yamux/src/connection.rs#L289
Details
This attack is inspired by the HTTP/2 Rapid Reset Attack (CVE 2023-44487), HTTP/2 Ping Flood (CVE-2019-9512), and the QUIC Path Validation attack (see my blog post: https://seemann.io/posts/2023-12-18-exploiting-quics-path-validation/).
Impact
An attacker can cause a remote node to run out of memory, which will result in the corresponding process getting terminated by the operating system.
Depending on the application protocols running on top of rust-libp2p, higher amplification factors are possible. For example, image a protocol that sends out 10 MB of data as a result of an incoming request. By issuing that request and sending a Yamux stream window update (together ~100-200 bytes), the victim would now enqueue the entire 10 MB into its frame buffer. Any block transfer / sync protocols might be good candidates.
In addition to consuming huge amounts of memory, this attack also drives up the victim's CPU load, such that the allocation of memory at some point becomes CPU-limited.
This was originally submitted by @marteen-seemann to the Ethereum Foundation bug bounty program.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "yamux"
},
"ranges": [
{
"events": [
{
"introduced": "0.13.0"
},
{
"fixed": "0.13.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-32984"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2024-05-01T16:40:49Z",
"nvd_published_at": "2024-05-01T11:15:47Z",
"severity": "HIGH"
},
"details": "### Summary\n\nAttack scenario\nThe Rust implementation of the Yamux stream multiplexer uses a vector for pending frames. This vector is not bounded in length. Every time the Yamux protocol requires sending of a new frame, this frame gets appended to this vector. This can be remotely triggered in a number of ways, for example by:\n\n1. Opening a new libp2p Identify stream. This causes the node to send its Identify message. Of course, every other protocol that causes the sending of data also works. The larger the response, the more data is enqueued.\n2. Sending a Yamux Ping frame. This causes a Pong frame to be enqueued.\n\nUnder normal circumstances, this queue of pending frames would be drained once they\u2019re sent out over the network. However, the attacker can use TCP\u2019s receive window mechanism to prevent the victim from sending out any data: By not reading from the TCP connection, the receive window will never be increased, and the victim won\u2019t be able to send out any new data (this is how TCP implements backpressure). Once this happens, Yamux\u2019s queue of pending frames will start growing indefinitely. The queue will only be drained once the underlying TCP connection is closed.\n\nComponents\nhttps://github.com/libp2p/rust-yamux/blob/yamux-v0.13.1/yamux/src/connection.rs#L289\n\n### Details\nThis attack is inspired by the HTTP/2 Rapid Reset Attack (CVE 2023-44487), HTTP/2 Ping Flood (CVE-2019-9512), and the QUIC Path Validation attack (see my blog post: https://seemann.io/posts/2023-12-18-exploiting-quics-path-validation/).\n\n### Impact\nAn attacker can cause a remote node to run out of memory, which will result in the corresponding process getting terminated by the operating system.\n\nDepending on the application protocols running on top of rust-libp2p, higher amplification factors are possible. For example, image a protocol that sends out 10 MB of data as a result of an incoming request. By issuing that request and sending a Yamux stream window update (together ~100-200 bytes), the victim would now enqueue the entire 10 MB into its frame buffer. Any block transfer / sync protocols might be good candidates.\n\nIn addition to consuming huge amounts of memory, this attack also drives up the victim\u0027s CPU load, such that the allocation of memory at some point becomes CPU-limited.\n\nThis was originally submitted by @marteen-seemann to the Ethereum Foundation bug bounty program.",
"id": "GHSA-3999-5ffv-wp2r",
"modified": "2024-05-01T16:40:49Z",
"published": "2024-05-01T16:40:49Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/libp2p/rust-yamux/security/advisories/GHSA-3999-5ffv-wp2r"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-32984"
},
{
"type": "WEB",
"url": "https://github.com/libp2p/rust-yamux/commit/460baf2ccb7d5982b266cb3cb9c0bdf75b4fb779"
},
{
"type": "WEB",
"url": "https://github.com/sigp/rust-yamux/commit/6689e227a48258a52347cd1d984adfc94afc6f7a"
},
{
"type": "PACKAGE",
"url": "https://github.com/libp2p/rust-yamux"
},
{
"type": "WEB",
"url": "https://github.com/libp2p/rust-yamux/blob/yamux-v0.13.1/yamux/src/connection.rs#L289"
}
],
"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": "Yamux Memory Exhaustion Vulnerability via Active::pending_frames property "
}
GHSA-399H-RRQC-RPGV
Vulnerability from github – Published: 2025-12-01 18:30 – Updated: 2026-01-26 15:30When reading an HTTP response from a server, if no read amount is specified, the default behavior will be to use Content-Length. This allows a malicious server to cause the client to read large amounts of data into memory, potentially causing OOM or other DoS.
{
"affected": [],
"aliases": [
"CVE-2025-13836"
],
"database_specific": {
"cwe_ids": [
"CWE-125",
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-01T18:16:04Z",
"severity": "MODERATE"
},
"details": "When reading an HTTP response from a server, if no read amount is specified, the default behavior will be to use Content-Length. This allows a malicious server to cause the client to read large amounts of data into memory, potentially causing OOM or other DoS.",
"id": "GHSA-399h-rrqc-rpgv",
"modified": "2026-01-26T15:30:30Z",
"published": "2025-12-01T18:30:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-13836"
},
{
"type": "WEB",
"url": "https://github.com/python/cpython/issues/119451"
},
{
"type": "WEB",
"url": "https://github.com/python/cpython/pull/119454"
},
{
"type": "WEB",
"url": "https://github.com/python/cpython/commit/14b1fdb0a94b96f86fc7b86671ea9582b8676628"
},
{
"type": "WEB",
"url": "https://github.com/python/cpython/commit/289f29b0fe38baf2d7cb5854f4bb573cc34a6a15"
},
{
"type": "WEB",
"url": "https://github.com/python/cpython/commit/4ce27904b597c77d74dd93f2c912676021a99155"
},
{
"type": "WEB",
"url": "https://github.com/python/cpython/commit/5a4c4a033a4a54481be6870aa1896fad732555b5"
},
{
"type": "WEB",
"url": "https://github.com/python/cpython/commit/5dc101675fd22918facbbe0fecdc821502beaaf0"
},
{
"type": "WEB",
"url": "https://github.com/python/cpython/commit/afc40bdd3dd71f343fd9016f6d8eebbacbd6587c"
},
{
"type": "WEB",
"url": "https://mail.python.org/archives/list/security-announce@python.org/thread/OQ6G7MKRQIS3OAREC3HNG3D2DPOU34XO"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:L/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
Mitigation
Design throttling mechanisms into the system architecture. The best protection is to limit the amount of resources that an unauthorized user can cause to be expended. A strong authentication and access control model will help prevent such attacks from occurring in the first place. The login application should be protected against DoS attacks as much as possible. Limiting the database access, perhaps by caching result sets, can help minimize the resources expended. To further limit the potential for a DoS attack, consider tracking the rate of requests received from users and blocking requests that exceed a defined rate threshold.
Mitigation
- Mitigation of resource exhaustion attacks requires that the target system either:
- The first of these solutions is an issue in itself though, since it may allow attackers to prevent the use of the system by a particular valid user. If the attacker impersonates the valid user, they may be able to prevent the user from accessing the server in question.
- The second solution is simply difficult to effectively institute -- and even when properly done, it does not provide a full solution. It simply makes the attack require more resources on the part of the attacker.
- recognizes the attack and denies that user further access for a given amount of time, or
- uniformly throttles all requests in order to make it more difficult to consume resources more quickly than they can again be freed.
Mitigation
Ensure that protocols have specific limits of scale placed on them.
Mitigation
Ensure that all failures in resource allocation place the system into a safe posture.
CAPEC-147: XML Ping of the Death
An attacker initiates a resource depletion attack where a large number of small XML messages are delivered at a sufficiently rapid rate to cause a denial of service or crash of the target. Transactions such as repetitive SOAP transactions can deplete resources faster than a simple flooding attack because of the additional resources used by the SOAP protocol and the resources necessary to process SOAP messages. The transactions used are immaterial as long as they cause resource utilization on the target. In other words, this is a normal flooding attack augmented by using messages that will require extra processing on the target.
CAPEC-227: Sustained Client Engagement
An adversary attempts to deny legitimate users access to a resource by continually engaging a specific resource in an attempt to keep the resource tied up as long as possible. The adversary's primary goal is not to crash or flood the target, which would alert defenders; rather it is to repeatedly perform actions or abuse algorithmic flaws such that a given resource is tied up and not available to a legitimate user. By carefully crafting a requests that keep the resource engaged through what is seemingly benign requests, legitimate users are limited or completely denied access to the resource.
CAPEC-492: Regular Expression Exponential Blowup
An adversary may execute an attack on a program that uses a poor Regular Expression(Regex) implementation by choosing input that results in an extreme situation for the Regex. A typical extreme situation operates at exponential time compared to the input size. This is due to most implementations using a Nondeterministic Finite Automaton(NFA) state machine to be built by the Regex algorithm since NFA allows backtracking and thus more complex regular expressions.