CWE-400
DiscouragedUncontrolled Resource Consumption
Abstraction: Class · Status: Draft
The product does not properly control the allocation and maintenance of a limited resource.
6465 vulnerabilities reference this CWE, most recent first.
GHSA-GP9C-PM5M-5CXR
Vulnerability from github – Published: 2026-06-26 21:53 – Updated: 2026-06-26 21:53Summary
The SOCKS5 transport in src/hackney_socks5.erl correctly applies the caller-supplied timeout to the SOCKS5 negotiation phase, but then upgrades the tunnel to TLS using ssl:connect/2 (the two-argument form), which defaults to infinity. The Timeout value is in scope at that call site but is never forwarded. A hostile or man-in-the-middled SOCKS5 proxy that completes the SOCKS5 handshake normally and then stalls the TLS exchange will pin the connecting Erlang process and socket indefinitely, regardless of any connect_timeout or recv_timeout options the caller set.
Details
In src/hackney_socks5.erl, line 65, after the SOCKS5 negotiation succeeds, the code calls:
ssl:connect(Socket, SSLOpts)
The three-argument form ssl:connect/3 takes a timeout; the two-argument form used here defaults to infinity. The variable Timeout (already used for SOCKS5 recv calls earlier in the same function) is simply not passed. The bytes that drive the TLS handshake on the upstream side of the tunnel come from whatever endpoint the proxy connects to. A hostile proxy can complete SOCKS5 normally, then either stay silent or send a partial ServerHello and stop, keeping ssl:connect/2 blocked forever. No certificate forgery is needed.
PoC
- Stand up a SOCKS5 proxy that completes the SOCKS5 greeting and CONNECT reply normally, then goes silent (never sends a TLS ServerHello).
- Issue an HTTPS request through it via hackney with
connect_timeoutandrecv_timeoutset to a short value (e.g. 2000 ms). - Observe the calling process remains blocked well past the configured timeout, consuming a process and socket until killed externally.
Impact
Denial of service via unbounded process and socket consumption. Affects hackney 0.10.0 through 4.0.0 for any HTTPS request routed through a SOCKS5 proxy. The connect_timeout and recv_timeout options give a false sense of safety since they are not honored during the TLS upgrade. CVSS v4.0: 8.2 (HIGH).
Resources
- Introduction commit: https://github.com/benoitc/hackney/commit/34cdbd1d20a282aacc286a89327465a3925b4c5d
- Patch commit: https://github.com/benoitc/hackney/commit/5ccdab725c561a6f03d05a51f2d0664f98236dae
{
"affected": [
{
"package": {
"ecosystem": "Hex",
"name": "hackney"
},
"ranges": [
{
"events": [
{
"introduced": "0.10.0"
},
{
"fixed": "4.0.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-47071"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-26T21:53:50Z",
"nvd_published_at": "2026-05-25T15:16:22Z",
"severity": "HIGH"
},
"details": "### Summary\n\nThe SOCKS5 transport in `src/hackney_socks5.erl` correctly applies the caller-supplied timeout to the SOCKS5 negotiation phase, but then upgrades the tunnel to TLS using `ssl:connect/2` (the two-argument form), which defaults to `infinity`. The `Timeout` value is in scope at that call site but is never forwarded. A hostile or man-in-the-middled SOCKS5 proxy that completes the SOCKS5 handshake normally and then stalls the TLS exchange will pin the connecting Erlang process and socket indefinitely, regardless of any `connect_timeout` or `recv_timeout` options the caller set.\n\n### Details\n\nIn `src/hackney_socks5.erl`, line 65, after the SOCKS5 negotiation succeeds, the code calls:\n\n```erlang\nssl:connect(Socket, SSLOpts)\n```\n\nThe three-argument form `ssl:connect/3` takes a timeout; the two-argument form used here defaults to `infinity`. The variable `Timeout` (already used for SOCKS5 recv calls earlier in the same function) is simply not passed. The bytes that drive the TLS handshake on the upstream side of the tunnel come from whatever endpoint the proxy connects to. A hostile proxy can complete SOCKS5 normally, then either stay silent or send a partial `ServerHello` and stop, keeping `ssl:connect/2` blocked forever. No certificate forgery is needed.\n\n### PoC\n\n1. Stand up a SOCKS5 proxy that completes the SOCKS5 greeting and CONNECT reply normally, then goes silent (never sends a TLS ServerHello).\n2. Issue an HTTPS request through it via hackney with `connect_timeout` and `recv_timeout` set to a short value (e.g. 2000 ms).\n3. Observe the calling process remains blocked well past the configured timeout, consuming a process and socket until killed externally.\n\n### Impact\n\nDenial of service via unbounded process and socket consumption. Affects hackney 0.10.0 through 4.0.0 for any HTTPS request routed through a SOCKS5 proxy. The `connect_timeout` and `recv_timeout` options give a false sense of safety since they are not honored during the TLS upgrade. CVSS v4.0: **8.2 (HIGH)**.\n\n## Resources\n\n* Introduction commit: https://github.com/benoitc/hackney/commit/34cdbd1d20a282aacc286a89327465a3925b4c5d\n* Patch commit: https://github.com/benoitc/hackney/commit/5ccdab725c561a6f03d05a51f2d0664f98236dae",
"id": "GHSA-gp9c-pm5m-5cxr",
"modified": "2026-06-26T21:53:50Z",
"published": "2026-06-26T21:53:50Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/benoitc/hackney/security/advisories/GHSA-gp9c-pm5m-5cxr"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-47071"
},
{
"type": "WEB",
"url": "https://github.com/benoitc/hackney/commit/5ccdab725c561a6f03d05a51f2d0664f98236dae"
},
{
"type": "WEB",
"url": "https://cna.erlef.org/cves/CVE-2026-47071.html"
},
{
"type": "PACKAGE",
"url": "https://github.com/benoitc/hackney"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/EEF-CVE-2026-47071"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Hackney: `ssl:connect/2` post-handshake upgrade has no timeout"
}
GHSA-GPGJ-87V4-MJ9R
Vulnerability from github – Published: 2024-05-17 15:31 – Updated: 2024-07-03 18:42In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Prevent crash when disable stream
[Why] Disabling stream encoder invokes a function that no longer exists.
[How] Check if the function declaration is NULL in disable stream encoder.
{
"affected": [],
"aliases": [
"CVE-2024-35799"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-17T14:15:12Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Prevent crash when disable stream\n\n[Why]\nDisabling stream encoder invokes a function that no longer exists.\n\n[How]\nCheck if the function declaration is NULL in disable stream encoder.",
"id": "GHSA-gpgj-87v4-mj9r",
"modified": "2024-07-03T18:42:25Z",
"published": "2024-05-17T15:31:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35799"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2b17133a0a2e0e111803124dad09e803718d4a48"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4356a2c3f296503c8b420ae8adece053960a9f06"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/59772327d439874095516673b4b30c48bd83ca38"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/72d72e8fddbcd6c98e1b02d32cf6f2b04e10bd1c"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-GPJV-6R8H-VP58
Vulnerability from github – Published: 2026-05-27 15:33 – Updated: 2026-05-27 15:33IBM Db2 11.5.0 through 11.5.9, and 12.1.0 through 12.1.4 is vulnerable to running out of memory when executing certain queries with MDC tables.
{
"affected": [],
"aliases": [
"CVE-2026-6052"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-27T14:17:34Z",
"severity": "MODERATE"
},
"details": "IBM Db2 11.5.0 through 11.5.9, and 12.1.0 through 12.1.4 is vulnerable to running out of memory when executing certain queries with MDC tables.",
"id": "GHSA-gpjv-6r8h-vp58",
"modified": "2026-05-27T15:33:24Z",
"published": "2026-05-27T15:33:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-6052"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/pages/node/7273557"
}
],
"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-GQ56-J6HH-XR2P
Vulnerability from github – Published: 2022-05-06 00:00 – Updated: 2022-05-13 00:00On F5 BIG-IP 16.1.x versions prior to 16.1.2.2, 15.1.x versions prior to 15.1.5, 14.1.x versions prior to 14.1.4.6, and 13.1.x versions prior to 13.1.5, when a Real Time Streaming Protocol (RTSP) profile is configured on a virtual server, undisclosed traffic can cause an increase in Traffic Management Microkernel (TMM) resource utilization. Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated
{
"affected": [],
"aliases": [
"CVE-2022-28691"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-05-05T17:15:00Z",
"severity": "HIGH"
},
"details": "On F5 BIG-IP 16.1.x versions prior to 16.1.2.2, 15.1.x versions prior to 15.1.5, 14.1.x versions prior to 14.1.4.6, and 13.1.x versions prior to 13.1.5, when a Real Time Streaming Protocol (RTSP) profile is configured on a virtual server, undisclosed traffic can cause an increase in Traffic Management Microkernel (TMM) resource utilization. Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated",
"id": "GHSA-gq56-j6hh-xr2p",
"modified": "2022-05-13T00:00:55Z",
"published": "2022-05-06T00:00:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-28691"
},
{
"type": "WEB",
"url": "https://support.f5.com/csp/article/K37155600"
}
],
"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-GQ97-QJ3M-VHJH
Vulnerability from github – Published: 2024-03-22 21:30 – Updated: 2024-03-22 21:30Uncontrolled resource consumption for some Intel(R) SPS firmware before version SPS_E5_06.01.04.002.0 may allow a privileged user to potentially enable denial of service via network access.
{
"affected": [],
"aliases": [
"CVE-2023-29153"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-02-14T14:15:49Z",
"severity": "MODERATE"
},
"details": "Uncontrolled resource consumption for some Intel(R) SPS firmware before version SPS_E5_06.01.04.002.0 may allow a privileged user to potentially enable denial of service via network access.",
"id": "GHSA-gq97-qj3m-vhjh",
"modified": "2024-03-22T21:30:56Z",
"published": "2024-03-22T21:30:56Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-29153"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20240322-0005"
},
{
"type": "WEB",
"url": "https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-01003.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-GQ9C-WMRM-5HVR
Vulnerability from github – Published: 2026-09-17 20:32 – Updated: 2026-09-17 20:32Summary
A malformed Smart Health Card (SHC) JWT with zip: "DEF" and an empty or truncated DEFLATE payload causes SHCParser.inflate() to loop forever. This allows an attacker who can submit SHC content for validation to pin a JVM worker thread indefinitely, causing denial of service.
Details
The vulnerable code is in org.hl7.fhir.r5/src/main/java/org/hl7/fhir/r5/elementmodel/SHCParser.java.
decodeJWT() inflates the JWT payload when the header contains "zip":"DEF":
// SHCParser.java:300-302
if ("DEF".equals(res.header.asString("zip"))) {
payloadJson = inflate(payloadJson);
}
inflate() loops only on !inflater.finished() and does not check inflater.needsInput(), inflater.needsDictionary(), or zero-progress output:
// SHCParser.java:455-468
while (!inflater.finished()) {
final int count = inflater.inflate(buffer);
outputStream.write(buffer, 0, count);
}
For empty or truncated raw DEFLATE input, Inflater.inflate() returns 0, finished() remains false, and needsInput() becomes true, producing an infinite tight loop. The same unsafe loop pattern also exists in decompress() at SHCParser.java:410-423.
The validator reaches this path during SHC validation and during file-format detection for SHC-looking input (ResourceChecker.java:115-118).
PoC
Compile the project, then run a minimal local harness that calls:
SHCParser.inflate(new byte[0]);
This never returns. Local verification:
timeout 3s java -cp ... VerifyDoSFindings shcHang
echo $?
# 124 = timeout killed the hung process
A JWT PoC uses:
- header: Base64URL(
{"zip":"DEF"}) - payload: empty or truncated raw DEFLATE bytes
- signature: arbitrary
Submit the resulting token as SHC content, for example via a .shc file or content beginning with shc:/ that reaches the validator's SHC detection path.
Impact
This is a denial-of-service vulnerability. A single malformed SHC validation request can consume a worker thread indefinitely. In services that validate uploaded SHC content, a small number of concurrent malformed requests can exhaust all validation workers.
Credits
- Thai Son Dinh from VinSOC Labs (R&D)
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 6.9.11"
},
"package": {
"ecosystem": "Maven",
"name": "ca.uhn.hapi.fhir:org.hl7.fhir.r5"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.9.12"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 6.9.11"
},
"package": {
"ecosystem": "Maven",
"name": "ca.uhn.hapi.fhir:org.hl7.fhir.validation"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.9.12"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 6.9.11"
},
"package": {
"ecosystem": "Maven",
"name": "ca.uhn.hapi.fhir:org.hl7.fhir.validation.cli"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.9.12"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-81876"
],
"database_specific": {
"cwe_ids": [
"CWE-20",
"CWE-400",
"CWE-835"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-17T20:32:21Z",
"nvd_published_at": "2026-09-16T19:17:44Z",
"severity": "HIGH"
},
"details": "### Summary\nA malformed Smart Health Card (SHC) JWT with `zip: \"DEF\"` and an empty or truncated DEFLATE payload causes `SHCParser.inflate()` to loop forever. This allows an attacker who can submit SHC content for validation to pin a JVM worker thread indefinitely, causing denial of service.\n\n### Details\nThe vulnerable code is in `org.hl7.fhir.r5/src/main/java/org/hl7/fhir/r5/elementmodel/SHCParser.java`.\n\n`decodeJWT()` inflates the JWT payload when the header contains `\"zip\":\"DEF\"`:\n\n```java\n// SHCParser.java:300-302\nif (\"DEF\".equals(res.header.asString(\"zip\"))) {\n payloadJson = inflate(payloadJson);\n}\n```\n\n`inflate()` loops only on `!inflater.finished()` and does not check `inflater.needsInput()`, `inflater.needsDictionary()`, or zero-progress output:\n\n```java\n// SHCParser.java:455-468\nwhile (!inflater.finished()) {\n final int count = inflater.inflate(buffer);\n outputStream.write(buffer, 0, count);\n}\n```\n\nFor empty or truncated raw DEFLATE input, `Inflater.inflate()` returns `0`, `finished()` remains `false`, and `needsInput()` becomes `true`, producing an infinite tight loop. The same unsafe loop pattern also exists in `decompress()` at `SHCParser.java:410-423`.\n\nThe validator reaches this path during SHC validation and during file-format detection for SHC-looking input (`ResourceChecker.java:115-118`).\n\n### PoC\nCompile the project, then run a minimal local harness that calls:\n\n```java\nSHCParser.inflate(new byte[0]);\n```\n\nThis never returns. Local verification:\n\n```bash\ntimeout 3s java -cp ... VerifyDoSFindings shcHang\necho $?\n# 124 = timeout killed the hung process\n```\n\nA JWT PoC uses:\n\n- header: Base64URL(`{\"zip\":\"DEF\"}`)\n- payload: empty or truncated raw DEFLATE bytes\n- signature: arbitrary\n\nSubmit the resulting token as SHC content, for example via a `.shc` file or content beginning with `shc:/` that reaches the validator\u0027s SHC detection path.\n\n### Impact\nThis is a denial-of-service vulnerability. A single malformed SHC validation request can consume a worker thread indefinitely. In services that validate uploaded SHC content, a small number of concurrent malformed requests can exhaust all validation workers.\n\n### Credits\n- Thai Son Dinh from VinSOC Labs (R\u0026D)",
"id": "GHSA-gq9c-wmrm-5hvr",
"modified": "2026-09-17T20:32:21Z",
"published": "2026-09-17T20:32:21Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/hapifhir/org.hl7.fhir.core/security/advisories/GHSA-gq9c-wmrm-5hvr"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-81876"
},
{
"type": "WEB",
"url": "https://github.com/hapifhir/org.hl7.fhir.core/pull/2493"
},
{
"type": "WEB",
"url": "https://github.com/hapifhir/org.hl7.fhir.core/commit/d804558bd77372b1629e55a5b901cad3f5134cdc"
},
{
"type": "WEB",
"url": "https://github.com/hapifhir/org.hl7.fhir.core/commit/edd5d8c139e669e39270785f08be7b63aefef24c"
},
{
"type": "PACKAGE",
"url": "https://github.com/hapifhir/org.hl7.fhir.core"
}
],
"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": "HAPI FHIR: SHCParser DEFLATE infinite loop causes denial of service"
}
GHSA-GQ9P-F254-H286
Vulnerability from github – Published: 2026-09-15 20:01 – Updated: 2026-09-15 20:01Summary
An unauthenticated peer can make Ember's HTTP/2 read loop hold 16 MiB of a single frame in memory on a connection where Ember advertised a 16 KiB limit. The declared length is readable from the frame's first 9 bytes, but it is not compared against SETTINGS_MAX_FRAME_SIZE until the whole payload has been read into a contiguous buffer. That is 1024x amplification per connection, bounded by the protocol's 24-bit length field rather than by any setting, and at the default maxConnections of 1024 it puts about 16 GiB of heap in reach.
Details
H2Frame.RawFrame.fromByteVector (ember-core/.../h2/H2Frame.scala:66-69) reads the length, then refuses to produce a frame until 9 + length bytes are present:
val length = (bv(2) & 0xff) | ((bv(1) & 0xff) << 8) | ((bv(0) & 0xff) << 16)
if (bv.length >= 9 + length) {
readNextFrame in H2Connection.readLoop (H2Connection.scala:246-266) reads that None as "need more" and concatenates further socket reads into one accumulator until it is satisfied.
The only check of an inbound frame against the connection's own SETTINGS_MAX_FRAME_SIZE is in processFrame at H2Connection.scala:534, which cannot run until the frame is assembled. So the value that condemns the frame sits in the accumulator from byte 9 onward and is never consulted. A peer that declares 16777215 and dribbles the payload without finishing gets the same buffering with no reaction at all, since an incomplete frame never reaches processFrame.
RFC 9113 4.2 requires treating an oversized frame as a connection error and explicitly permits responding without reading the rest of the payload.
Impact
Uncontrolled resource consumption leading to unauthenticated remote denial of service by memory exhaustion.
- ember-server built .withHttp2: any peer able to open an HTTP/2 connection can trigger it. No authentication and no valid request, since the frame is rejected before it is associated with a stream, and the incomplete variant is never rejected.
- ember-client built .withHttp2 against a hostile origin: readLoop is shared, so the client side is symmetric. Reasoned from the shared code path, not reproduced.
- Not affected: HTTP/2 off, which is the default on both builders.
The overshoot is not configurable. It comes from the protocol's length field, not from Ember's limit, so tuning SETTINGS_MAX_FRAME_SIZE down does not reduce exposure, and withIdleTimeout does not apply because the read loop is making steady progress. Workarounds: leave HTTP/2 off, or terminate it at a proxy that enforces frame size and speak HTTP/1.1 to Ember.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.23.36"
},
"package": {
"ecosystem": "Maven",
"name": "org.http4s:http4s-ember-core_2.13"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.23.37"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.23.36"
},
"package": {
"ecosystem": "Maven",
"name": "org.http4s:http4s-ember-core_2.12"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.23.37"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.23.36"
},
"package": {
"ecosystem": "Maven",
"name": "org.http4s:http4s-ember-core_3"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.23.37"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.0.0-M47"
},
"package": {
"ecosystem": "Maven",
"name": "org.http4s:http4s-ember-core_2.13"
},
"ranges": [
{
"events": [
{
"introduced": "1.0.0-M1"
},
{
"fixed": "1.0.0-M48"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.0.0-M47"
},
"package": {
"ecosystem": "Maven",
"name": "org.http4s:http4s-ember-core_3"
},
"ranges": [
{
"events": [
{
"introduced": "1.0.0-M1"
},
{
"fixed": "1.0.0-M48"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-88975"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-15T20:01:22Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Summary\nAn unauthenticated peer can make Ember\u0027s HTTP/2 read loop hold 16 MiB of a single frame in memory on a connection where Ember advertised a 16 KiB limit. The declared length is readable from the frame\u0027s first 9 bytes, but it is not compared against SETTINGS_MAX_FRAME_SIZE until the whole payload has been read into a contiguous buffer. That is 1024x amplification per connection, bounded by the protocol\u0027s 24-bit length field rather than by any setting, and at the default maxConnections of 1024 it puts about 16 GiB of heap in reach.\n\n### Details\nH2Frame.RawFrame.fromByteVector (ember-core/.../h2/H2Frame.scala:66-69) reads the length, then refuses to produce a frame until 9 + length bytes are present:\n\n```\nval length = (bv(2) \u0026 0xff) | ((bv(1) \u0026 0xff) \u003c\u003c 8) | ((bv(0) \u0026 0xff) \u003c\u003c 16)\nif (bv.length \u003e= 9 + length) {\n```\n\nreadNextFrame in H2Connection.readLoop (H2Connection.scala:246-266) reads that None as \"need more\" and concatenates further socket reads into one accumulator until it is satisfied.\n\nThe only check of an inbound frame against the connection\u0027s own SETTINGS_MAX_FRAME_SIZE is in processFrame at H2Connection.scala:534, which cannot run until the frame is assembled. So the value that condemns the frame sits in the accumulator from byte 9 onward and is never consulted. A peer that declares 16777215 and dribbles the payload without finishing gets the same buffering with no reaction at all, since an incomplete frame never reaches processFrame.\n\nRFC 9113 4.2 requires treating an oversized frame as a connection error and explicitly permits responding without reading the rest of the payload.\n\n### Impact\nUncontrolled resource consumption leading to unauthenticated remote denial of service by memory exhaustion.\n\n- ember-server built .withHttp2: any peer able to open an HTTP/2 connection can trigger it. No authentication and no valid request, since the frame is rejected before it is associated with a stream, and the incomplete variant is never rejected.\n- ember-client built .withHttp2 against a hostile origin: readLoop is shared, so the client side is symmetric. Reasoned from the shared code path, not reproduced.\n- Not affected: HTTP/2 off, which is the default on both builders.\n\nThe overshoot is not configurable. It comes from the protocol\u0027s length field, not from Ember\u0027s limit, so tuning SETTINGS_MAX_FRAME_SIZE down does not reduce exposure, and withIdleTimeout does not apply because the read loop is making steady progress. Workarounds: leave HTTP/2 off, or terminate it at a proxy that enforces frame size and speak HTTP/1.1 to Ember.",
"id": "GHSA-gq9p-f254-h286",
"modified": "2026-09-15T20:01:22Z",
"published": "2026-09-15T20:01:22Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/http4s/http4s/security/advisories/GHSA-gq9p-f254-h286"
},
{
"type": "WEB",
"url": "https://github.com/http4s/http4s/commit/87cf334fa3f608ef7d3eb359e71e037ba3336d29"
},
{
"type": "PACKAGE",
"url": "https://github.com/http4s/http4s"
},
{
"type": "WEB",
"url": "https://github.com/http4s/http4s/releases/tag/v0.23.37"
},
{
"type": "WEB",
"url": "https://github.com/http4s/http4s/releases/tag/v1.0.0-M48"
}
],
"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": "Http4s: Ember HTTP/2 buffers a frame\u0027s declared payload before checking SETTINGS_MAX_FRAME_SIZE"
}
GHSA-GQC7-GJGF-XVMG
Vulnerability from github – Published: 2025-01-14 18:32 – Updated: 2025-01-14 18:32Microsoft Message Queuing (MSMQ) Denial of Service Vulnerability
{
"affected": [],
"aliases": [
"CVE-2025-21251"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-14T18:15:42Z",
"severity": "HIGH"
},
"details": "Microsoft Message Queuing (MSMQ) Denial of Service Vulnerability",
"id": "GHSA-gqc7-gjgf-xvmg",
"modified": "2025-01-14T18:32:03Z",
"published": "2025-01-14T18:32:03Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21251"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-21251"
}
],
"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-GQC9-9F54-XC45
Vulnerability from github – Published: 2022-06-07 00:00 – Updated: 2022-06-14 00:00An issue has been discovered in GitLab CE/EE affecting all versions starting from 14.3 before 14.9.5, all versions starting from 14.10 before 14.10.4, all versions starting from 15.0 before 15.0.1. It may be possible for malicious group maintainers to add new members to a project within their group, through the REST API, even after their group owner enabled a setting to prevent members from being added to projects within that group.
{
"affected": [],
"aliases": [
"CVE-2022-1783"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-06-06T17:15:00Z",
"severity": "MODERATE"
},
"details": "An issue has been discovered in GitLab CE/EE affecting all versions starting from 14.3 before 14.9.5, all versions starting from 14.10 before 14.10.4, all versions starting from 15.0 before 15.0.1. It may be possible for malicious group maintainers to add new members to a project within their group, through the REST API, even after their group owner enabled a setting to prevent members from being added to projects within that group.",
"id": "GHSA-gqc9-9f54-xc45",
"modified": "2022-06-14T00:00:28Z",
"published": "2022-06-07T00:00:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-1783"
},
{
"type": "WEB",
"url": "https://hackerone.com/reports/1472109"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/cves/-/blob/master/2022/CVE-2022-1783.json"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/gitlab/-/issues/353121"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-GQHX-WXJR-RPHX
Vulnerability from github – Published: 2023-06-26 21:30 – Updated: 2024-09-16 15:32An unauthenticated denial of service vulnerability exists in the SMM v1, SMM v2, and FPC management web server which can be triggered under crafted conditions. Rebooting SMM or FPC will restore access to the management web server.
{
"affected": [],
"aliases": [
"CVE-2023-2992"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-405"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-06-26T20:15:09Z",
"severity": "HIGH"
},
"details": "An unauthenticated \u00a0denial of service vulnerability exists in the SMM v1, SMM v2, and FPC management web server which can be triggered under crafted conditions. Rebooting SMM or FPC will restore access to the management web server.",
"id": "GHSA-gqhx-wxjr-rphx",
"modified": "2024-09-16T15:32:44Z",
"published": "2023-06-26T21:30:59Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-2992"
},
{
"type": "WEB",
"url": "https://support.lenovo.com/us/en/product_security/LEN-127357"
}
],
"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
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.