CWE-400
DiscouragedUncontrolled Resource Consumption
Abstraction: Class · Status: Draft
The product does not properly control the allocation and maintenance of a limited resource.
5448 vulnerabilities reference this CWE, most recent first.
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"
}
]
}
GHSA-39FP-MC5W-P8HH
Vulnerability from github – Published: 2026-06-30 12:31 – Updated: 2026-07-20 09:31Net::BitTorrent versions through 2.0.1 for Perl allow remote memory exhaustion via deeply nested bencoded input.
bdecode recurses once per nested list or dictionary level with no depth cap, and each recursive call receives the remaining buffer by value while the list and dictionary branches capture the whole remainder, so every live recursion frame keeps its own copy of the shrinking buffer (O(N^2) bytes for an N-deep input). The decoder runs on every untrusted bencode source: .torrent files, BEP09 metadata fetched from peers, DHT messages, and tracker responses.
A bencoded input of roughly 150,000 nested lists (about 150 KB on the wire) drives multi-gigabyte peak memory, so one short message from any peer, or one crafted .torrent file or magnet link, terminates the client.
{
"affected": [],
"aliases": [
"CVE-2026-57081"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-30T12:16:25Z",
"severity": "HIGH"
},
"details": "Net::BitTorrent versions through 2.0.1 for Perl allow remote memory exhaustion via deeply nested bencoded input.\n\nbdecode recurses once per nested list or dictionary level with no depth cap, and each recursive call receives the remaining buffer by value while the list and dictionary branches capture the whole remainder, so every live recursion frame keeps its own copy of the shrinking buffer (O(N^2) bytes for an N-deep input). The decoder runs on every untrusted bencode source: .torrent files, BEP09 metadata fetched from peers, DHT messages, and tracker responses.\n\nA bencoded input of roughly 150,000 nested lists (about 150 KB on the wire) drives multi-gigabyte peak memory, so one short message from any peer, or one crafted .torrent file or magnet link, terminates the client.",
"id": "GHSA-39fp-mc5w-p8hh",
"modified": "2026-07-20T09:31:05Z",
"published": "2026-06-30T12:31:53Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/sanko/Net-BitTorrent.pm/security/advisories/GHSA-mv44-v82p-89xv"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-57081"
},
{
"type": "WEB",
"url": "https://metacpan.org/release/SANKO/Net-BitTorrent-v2.1.0/changes"
}
],
"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-39JM-FM9J-JG9P
Vulnerability from github – Published: 2022-05-13 01:46 – Updated: 2024-03-21 03:33** DISPUTED ** BackBox Linux 4.6 allows remote attackers to cause a denial of service (ksoftirqd CPU consumption) via a flood of packets with Martian source IP addresses (as defined in RFC 1812 section 5.3.7). This product enables net.ipv4.conf.all.log_martians by default. NOTE: the vendor reports "It has been proved that this vulnerability has no foundation and it is totally fake and based on false assumptions."
{
"affected": [],
"aliases": [
"CVE-2017-7397"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-04-03T20:59:00Z",
"severity": "HIGH"
},
"details": "** DISPUTED ** BackBox Linux 4.6 allows remote attackers to cause a denial of service (ksoftirqd CPU consumption) via a flood of packets with Martian source IP addresses (as defined in RFC 1812 section 5.3.7). This product enables net.ipv4.conf.all.log_martians by default. NOTE: the vendor reports \"It has been proved that this vulnerability has no foundation and it is totally fake and based on false assumptions.\"",
"id": "GHSA-39jm-fm9j-jg9p",
"modified": "2024-03-21T03:33:13Z",
"published": "2022-05-13T01:46:58Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-7397"
},
{
"type": "WEB",
"url": "https://backbox.org/portal/blog/false-cve-backbox-46-unmasked"
},
{
"type": "WEB",
"url": "https://cxsecurity.com/issue/WLB-2017040001"
},
{
"type": "WEB",
"url": "https://forum.backbox.org/security-advisories/waiting-verification-backbox-os-denial-of-service/msg10218"
},
{
"type": "WEB",
"url": "https://www.exploit-db.com/exploits/41781"
},
{
"type": "WEB",
"url": "http://www.exploitalert.com/view-details.html?id=26361"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-39Q4-P535-C852
Vulnerability from github – Published: 2021-06-10 17:25 – Updated: 2023-09-07 21:45The package locutus before 2.0.15 is vulnerable to Regular Expression Denial of Service (ReDoS) via the gopher_parsedir function.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "locutus"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.0.15"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-23392"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2021-06-09T20:22:09Z",
"nvd_published_at": "2021-06-08T08:15:00Z",
"severity": "HIGH"
},
"details": "The package locutus before 2.0.15 is vulnerable to Regular Expression Denial of Service (ReDoS) via the gopher_parsedir function.",
"id": "GHSA-39q4-p535-c852",
"modified": "2023-09-07T21:45:40Z",
"published": "2021-06-10T17:25:05Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-23392"
},
{
"type": "WEB",
"url": "https://github.com/locutusjs/locutus/pull/446"
},
{
"type": "WEB",
"url": "https://github.com/locutusjs/locutus/commit/eb863321990e7e5514aa14f68b8d9978ece9e65e"
},
{
"type": "WEB",
"url": "https://snyk.io/vuln/SNYK-JS-LOCUTUS-1090597"
}
],
"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": "Uncontrolled Resource Consumption in locutus"
}
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.