CWE-400
DiscouragedUncontrolled Resource Consumption
Abstraction: Class · Status: Draft
The product does not properly control the allocation and maintenance of a limited resource.
5474 vulnerabilities reference this CWE, most recent first.
GHSA-XXH7-FCF3-RJ7F
Vulnerability from github – Published: 2026-03-05 21:27 – Updated: 2026-03-05 21:27Description (as reported)
There is a memory leak when using GzipHandler in jetty-12.0.30 that can cause off-heap OOMs. This can be used for DoS attacks so I'm reporting this as a vulnerability.
The leak is created by requests where the request is inflated (Content-Encoding: gzip) and the response is not deflated (no Accept-Encoding: gzip). In these conditions, a new inflator will be created by GzipRequest and never released back into GzipRequest.__inflaterPool because gzipRequest.destory() is not called.
In heap dumps one can see thousands of java.util.zip.Inflator objects, which use both Java heaps and native memory. Leaking native memory causes of off-heap OOMs.
Code path in GzipHandler.handle():
1. Line 601: GzipRequest is created when request inflation is needed.
2. Lines 611-616: The callback is only wrapped in GzipResponseAndCallback when both inflation and deflation are needed.
3. Lines 619-625: If the handler accepts the request (returns true), gzipRequest.destroy() is only called in the "request not accepted" path (returns false)
When deflation is needed, GzipResponseAndCallback (lines 102 and 116) properly calls gzipRequest.destroy() in its succeeded() and failed() methods. But this wrapper is only created when deflation is needed.
Possible fix:
The callback should be wrapped whenever a GzipRequest is created, not just when deflation is needed. This ensures gzipRequest.destroy() is always called when the request completes.
Impact
The leak causes the JVM to crash with OOME.
Patches
No patches yet.
Workarounds
Disable GzipHandler.
References
https://github.com/jetty/jetty.project/issues/14260
https://gitlab.eclipse.org/security/cve-assignment/-/issues/79
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 12.1.5"
},
"package": {
"ecosystem": "Maven",
"name": "org.eclipse.jetty:jetty-server"
},
"ranges": [
{
"events": [
{
"introduced": "12.1.0"
},
{
"fixed": "12.1.6"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 12.0.31"
},
"package": {
"ecosystem": "Maven",
"name": "org.eclipse.jetty:jetty-server"
},
"ranges": [
{
"events": [
{
"introduced": "12.0.0"
},
{
"fixed": "12.0.32"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-1605"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-401"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-05T21:27:59Z",
"nvd_published_at": "2026-03-05T10:15:56Z",
"severity": "HIGH"
},
"details": "### Description (as reported)\n\nThere is a memory leak when using `GzipHandler` in jetty-12.0.30 that can cause off-heap OOMs. This can be used for DoS attacks so I\u0027m reporting this as a vulnerability.\n\nThe leak is created by requests where the request is inflated (`Content-Encoding: gzip`) and the response is not deflated (no `Accept-Encoding: gzip`). In these conditions, a new inflator will be created by `GzipRequest` and never released back into `GzipRequest.__inflaterPool` because `gzipRequest.destory()` is not called.\n\nIn heap dumps one can see thousands of `java.util.zip.Inflator` objects, which use both Java heaps and native memory. Leaking native memory causes of off-heap OOMs.\n\nCode path in `GzipHandler.handle()`:\n1. Line 601: `GzipRequest` is created when request inflation is needed.\n2. Lines 611-616: The callback is only wrapped in `GzipResponseAndCallback` when both inflation and deflation are needed.\n3. Lines 619-625: If the handler accepts the request (returns true), `gzipRequest.destroy()` is only called in the \"request not accepted\" path (returns false)\n\nWhen deflation is needed, `GzipResponseAndCallback` (lines 102 and 116) properly calls `gzipRequest.destroy()` in its `succeeded()` and `failed()` methods. But this wrapper is only created when deflation is needed.\n\nPossible fix:\nThe callback should be wrapped whenever a `GzipRequest` is created, not just when deflation is needed. This ensures `gzipRequest.destroy()` is always called when the request completes.\n\n\n### Impact\nThe leak causes the JVM to crash with OOME.\n\n### Patches\nNo patches yet.\n\n### Workarounds\nDisable `GzipHandler`.\n\n### References\nhttps://github.com/jetty/jetty.project/issues/14260\n\nhttps://gitlab.eclipse.org/security/cve-assignment/-/issues/79",
"id": "GHSA-xxh7-fcf3-rj7f",
"modified": "2026-03-05T21:27:59Z",
"published": "2026-03-05T21:27:59Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/jetty/jetty.project/security/advisories/GHSA-xxh7-fcf3-rj7f"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-1605"
},
{
"type": "WEB",
"url": "https://github.com/jetty/jetty.project/issues/14260"
},
{
"type": "PACKAGE",
"url": "https://github.com/jetty/jetty.project"
},
{
"type": "WEB",
"url": "https://gitlab.eclipse.org/security/cve-assignment/-/issues/79"
}
],
"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": "The Eclipse Jetty Server Artifact has a Gzip request memory leak "
}
GHSA-XXJ3-55P6-XG3H
Vulnerability from github – Published: 2022-07-25 00:00 – Updated: 2023-03-01 20:32A regular expression used in Apache MXNet (incubating) is vulnerable to a potential denial-of-service by excessive resource consumption. The bug could be exploited when loading a model in Apache MXNet that has a specially crafted operator name that would cause the regular expression evaluation to use excessive resources to attempt a match. This issue affects Apache MXNet versions prior to 1.9.1.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "mxnet"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.9.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-24294"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2023-03-01T20:32:45Z",
"nvd_published_at": "2022-07-24T18:15:00Z",
"severity": "HIGH"
},
"details": "A regular expression used in Apache MXNet (incubating) is vulnerable to a potential denial-of-service by excessive resource consumption. The bug could be exploited when loading a model in Apache MXNet that has a specially crafted operator name that would cause the regular expression evaluation to use excessive resources to attempt a match. This issue affects Apache MXNet versions prior to 1.9.1.",
"id": "GHSA-xxj3-55p6-xg3h",
"modified": "2023-03-01T20:32:45Z",
"published": "2022-07-25T00:00:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-24294"
},
{
"type": "PACKAGE",
"url": "https://github.com/apache/mxnet"
},
{
"type": "WEB",
"url": "https://github.com/apache/mxnet/releases/tag/1.9.1"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/b1fbfmvzlr2bbp95lqoh3mtovclfcl3o"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2022/07/24/2"
}
],
"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": "Apache MXNet vulnerable to potential denial-of-service by excessive resource consumption"
}
GHSA-XXQJ-X2PV-X5JJ
Vulnerability from github – Published: 2024-07-03 18:48 – Updated: 2024-07-05 18:34Uncontrolled Resource Consumption vulnerability in MESbook 20221021.03 version. An unauthenticated remote attacker can use the "message" parameter to inject a payload with dangerous JavaScript code, causing the application to loop requests on itself, which could lead to resource consumption and disable the application.
{
"affected": [],
"aliases": [
"CVE-2024-6427"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-770"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-03T12:15:03Z",
"severity": "HIGH"
},
"details": "Uncontrolled Resource Consumption vulnerability in MESbook\u00a020221021.03 version. An unauthenticated remote attacker can use the \"message\" parameter to inject a payload with dangerous JavaScript code, causing the application to loop requests on itself, which could lead to resource consumption and disable the application.",
"id": "GHSA-xxqj-x2pv-x5jj",
"modified": "2024-07-05T18:34:17Z",
"published": "2024-07-03T18:48:14Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-6427"
},
{
"type": "WEB",
"url": "https://www.incibe.es/en/incibe-cert/notices/aviso-sci/multiple-vulnerabilities-mesbook"
}
],
"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-XXR9-34QV-3673
Vulnerability from github – Published: 2022-05-24 19:09 – Updated: 2022-10-25 12:00Dell PowerScale OneFS versions 9.1.0.3 and earlier contain a denial of service vulnerability. SmartConnect had an error condition that may be triggered to loop, using CPU and potentially preventing other SmartConnect DNS responses.
{
"affected": [],
"aliases": [
"CVE-2021-21565"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-834"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-08-03T00:15:00Z",
"severity": "MODERATE"
},
"details": "Dell PowerScale OneFS versions 9.1.0.3 and earlier contain a denial of service vulnerability. SmartConnect had an error condition that may be triggered to loop, using CPU and potentially preventing other SmartConnect DNS responses.",
"id": "GHSA-xxr9-34qv-3673",
"modified": "2022-10-25T12:00:15Z",
"published": "2022-05-24T19:09:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-21565"
},
{
"type": "WEB",
"url": "https://www.dell.com/support/kbdoc/000188148"
}
],
"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"
}
]
}
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.