CWE-400
DiscouragedUncontrolled Resource Consumption
Abstraction: Class · Status: Draft
The product does not properly control the allocation and maintenance of a limited resource.
5412 vulnerabilities reference this CWE, most recent first.
GHSA-V4P3-MV8C-JVGX
Vulnerability from github – Published: 2024-04-09 18:30 – Updated: 2024-04-09 18:30DHCP Server Service Denial of Service Vulnerability
{
"affected": [],
"aliases": [
"CVE-2024-26215"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-09T17:15:40Z",
"severity": "HIGH"
},
"details": "DHCP Server Service Denial of Service Vulnerability",
"id": "GHSA-v4p3-mv8c-jvgx",
"modified": "2024-04-09T18:30:25Z",
"published": "2024-04-09T18:30:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26215"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-26215"
}
],
"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-V4RH-8P82-6H5W
Vulnerability from github – Published: 2020-06-22 14:39 – Updated: 2021-09-22 18:35all versions of url-regex are vulnerable to Regular Expression Denial of Service. An attacker providing a very long string in String.test can cause a Denial of Service.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "url-regex"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "5.0.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2020-7661"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2020-06-18T14:26:22Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "all versions of url-regex are vulnerable to Regular Expression Denial of Service. An attacker providing a very long string in String.test can cause a Denial of Service.",
"id": "GHSA-v4rh-8p82-6h5w",
"modified": "2021-09-22T18:35:57Z",
"published": "2020-06-22T14:39:03Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-7661"
},
{
"type": "WEB",
"url": "https://github.com/kevva/url-regex/issues/70"
},
{
"type": "PACKAGE",
"url": "https://github.com/kevva/url-regex"
},
{
"type": "WEB",
"url": "https://snyk.io/vuln/SNYK-JS-URLREGEX-569472"
}
],
"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": "Regular expression denial of service in url-regex"
}
GHSA-V4V5-73P4-RG59
Vulnerability from github – Published: 2025-04-08 18:34 – Updated: 2025-04-08 18:34Uncontrolled resource consumption in Windows Standards-Based Storage Management Service allows an unauthorized attacker to deny service over a network.
{
"affected": [],
"aliases": [
"CVE-2025-26652"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-08T18:15:49Z",
"severity": "HIGH"
},
"details": "Uncontrolled resource consumption in Windows Standards-Based Storage Management Service allows an unauthorized attacker to deny service over a network.",
"id": "GHSA-v4v5-73p4-rg59",
"modified": "2025-04-08T18:34:46Z",
"published": "2025-04-08T18:34:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-26652"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-26652"
}
],
"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-V4W8-49PV-MF72
Vulnerability from github – Published: 2026-01-20 18:36 – Updated: 2026-01-20 18:36Summary
ChatterBot versions up to 1.2.10 are vulnerable to a denial-of-service condition caused by improper database session and connection pool management. Concurrent invocations of the get_response() method can exhaust the underlying SQLAlchemy connection pool, resulting in persistent service unavailability and requiring a manual restart to recover.
Details
ChatterBot relies on SQLAlchemy for database access and uses a connection pool with default limits. The get_response() method does not enforce concurrency limits, rate limiting, or explicit session lifecycle controls.
When multiple threads concurrently invoke get_response(), database connections are rapidly consumed and not released in a timely manner. This leads to exhaustion of the SQLAlchemy QueuePool, causing subsequent requests to block and eventually fail with a TimeoutError.
This issue can be triggered without authentication in deployments where ChatterBot is exposed as a chatbot service, making it exploitable by remote attackers to cause denial of service.
PoC Video: https://github.com/user-attachments/assets/4ee845c4-b847-4854-84ec-4b2fb2f7090f
PoC
- Install ChatterBot version 1.2.10.
- Use the default database configuration (SQLite / SQLAlchemy).
- Run the following Python script to invoke concurrent requests:
from chatterbot import ChatBot import threading
bot = ChatBot("dos-test")
def attack(): bot.get_response("hello")
threads = [] for _ in range(30): t = threading.Thread(target=attack) t.start() threads.append(t)
for t in threads: t.join()
- Observe that the application becomes unresponsive and raises SQLAlchemy TimeoutError exceptions indicating exhaustion of the connection pool.
Impact
This vulnerability allows an attacker to trigger a denial-of-service condition by exhausting the database connection pool. Once triggered, the chatbot becomes unresponsive to legitimate users and requires a manual restart to restore functionality.
All deployments of ChatterBot version 1.2.10 or earlier that allow concurrent access to the get_response() method are impacted.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.2.10"
},
"package": {
"ecosystem": "PyPI",
"name": "chatterbot"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.2.11"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-23842"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2026-01-20T18:36:17Z",
"nvd_published_at": "2026-01-19T19:16:04Z",
"severity": "HIGH"
},
"details": "### Summary\nChatterBot versions up to 1.2.10 are vulnerable to a denial-of-service condition caused by improper database session and connection pool management. Concurrent invocations of the get_response() method can exhaust the underlying SQLAlchemy connection pool, resulting in persistent service unavailability and requiring a manual restart to recover.\n\n### Details\nChatterBot relies on SQLAlchemy for database access and uses a connection pool with default limits. The get_response() method does not enforce concurrency limits, rate limiting, or explicit session lifecycle controls.\n\nWhen multiple threads concurrently invoke get_response(), database connections are rapidly consumed and not released in a timely manner. This leads to exhaustion of the SQLAlchemy QueuePool, causing subsequent requests to block and eventually fail with a TimeoutError.\n\nThis issue can be triggered without authentication in deployments where ChatterBot is exposed as a chatbot service, making it exploitable by remote attackers to cause denial of service.\n\nPoC Video: \nhttps://github.com/user-attachments/assets/4ee845c4-b847-4854-84ec-4b2fb2f7090f\n\n### PoC\n1. Install ChatterBot version 1.2.10.\n2. Use the default database configuration (SQLite / SQLAlchemy).\n3. Run the following Python script to invoke concurrent requests:\n\nfrom chatterbot import ChatBot\nimport threading\n\nbot = ChatBot(\"dos-test\")\n\ndef attack():\n bot.get_response(\"hello\")\n\nthreads = []\nfor _ in range(30):\n t = threading.Thread(target=attack)\n t.start()\n threads.append(t)\n\nfor t in threads:\n t.join()\n\n4. Observe that the application becomes unresponsive and raises SQLAlchemy TimeoutError exceptions indicating exhaustion of the connection pool.\n\n### Impact\nThis vulnerability allows an attacker to trigger a denial-of-service condition by exhausting the database connection pool. Once triggered, the chatbot becomes unresponsive to legitimate users and requires a manual restart to restore functionality.\n\nAll deployments of ChatterBot version 1.2.10 or earlier that allow concurrent access to the get_response() method are impacted.",
"id": "GHSA-v4w8-49pv-mf72",
"modified": "2026-01-20T18:36:17Z",
"published": "2026-01-20T18:36:17Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/gunthercox/ChatterBot/security/advisories/GHSA-v4w8-49pv-mf72"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23842"
},
{
"type": "WEB",
"url": "https://github.com/gunthercox/ChatterBot/pull/2432"
},
{
"type": "WEB",
"url": "https://github.com/gunthercox/ChatterBot/commit/de89fe648139f8eeacc998ad4524fab291a378cf"
},
{
"type": "PACKAGE",
"url": "https://github.com/gunthercox/ChatterBot"
},
{
"type": "WEB",
"url": "https://github.com/gunthercox/ChatterBot/releases/tag/1.2.11"
},
{
"type": "WEB",
"url": "https://github.com/user-attachments/assets/4ee845c4-b847-4854-84ec-4b2fb2f7090f"
}
],
"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": "ChatterBot Vulnerable to Denial of Service via Database Connection Pool Exhaustion"
}
GHSA-V533-M73V-H37V
Vulnerability from github – Published: 2022-01-11 00:01 – Updated: 2022-09-21 00:00Z-Wave devices based on Silicon Labs 500 series chipsets using S0 authentication are susceptible to uncontrolled resource consumption leading to battery exhaustion. As an example, the Schlage BE468 version 3.42 door lock is vulnerable and fails open at a low battery level.
{
"affected": [],
"aliases": [
"CVE-2020-9059"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-770"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-01-10T14:10:00Z",
"severity": "MODERATE"
},
"details": "Z-Wave devices based on Silicon Labs 500 series chipsets using S0 authentication are susceptible to uncontrolled resource consumption leading to battery exhaustion. As an example, the Schlage BE468 version 3.42 door lock is vulnerable and fails open at a low battery level.",
"id": "GHSA-v533-m73v-h37v",
"modified": "2022-09-21T00:00:40Z",
"published": "2022-01-11T00:01:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-9059"
},
{
"type": "WEB",
"url": "https://doi.org/10.1109/ACCESS.2021.3138768"
},
{
"type": "WEB",
"url": "https://github.com/CNK2100/VFuzz-public"
},
{
"type": "WEB",
"url": "https://ieeexplore.ieee.org/document/9663293"
},
{
"type": "WEB",
"url": "https://kb.cert.org/vuls/id/142629"
},
{
"type": "WEB",
"url": "https://www.kb.cert.org/vuls/id/142629"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-V55M-3W98-233J
Vulnerability from github – Published: 2025-02-06 06:31 – Updated: 2025-02-06 15:32A prototype pollution in the lib.fromQuery function of underscore-contrib v0.3.0 allows attackers to cause a Denial of Service (DoS) via supplying a crafted payload.
{
"affected": [],
"aliases": [
"CVE-2024-57081"
],
"database_specific": {
"cwe_ids": [
"CWE-1321",
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-05T22:15:32Z",
"severity": "HIGH"
},
"details": "A prototype pollution in the lib.fromQuery function of underscore-contrib v0.3.0 allows attackers to cause a Denial of Service (DoS) via supplying a crafted payload.",
"id": "GHSA-v55m-3w98-233j",
"modified": "2025-02-06T15:32:52Z",
"published": "2025-02-06T06:31:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57081"
},
{
"type": "WEB",
"url": "https://gist.github.com/tariqhawis/4b2c7273054f0d70ef162aa5b6daec01"
}
],
"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-V569-HP3G-36WR
Vulnerability from github – Published: 2026-04-02 20:32 – Updated: 2026-05-13 16:18Summary
Rack::Utils.select_best_encoding processes Accept-Encoding values with quadratic time complexity when the header contains many wildcard (*) entries. Because this method is used by Rack::Deflater to choose a response encoding, an unauthenticated attacker can send a single request with a crafted Accept-Encoding header and cause disproportionate CPU consumption on the compression middleware path.
This results in a denial of service condition for applications using Rack::Deflater.
Details
Rack::Utils.select_best_encoding expands parsed Accept-Encoding values into a list of candidate encodings. When an entry is *, the method computes the set of concrete encodings by subtracting the encodings already present in the request:
if m == "*"
(available_encodings - accept_encoding.map(&:first)).each do |m2|
expanded_accept_encoding << [m2, q, preference]
end
else
expanded_accept_encoding << [m, q, preference]
end
Because accept_encoding.map(&:first) is evaluated inside the loop, it is recomputed for each wildcard entry. If the request contains N wildcard entries, this produces repeated scans over the full parsed header and causes quadratic behavior.
After expansion, the method also performs additional work over expanded_accept_encoding, including per-entry deletion, which further increases the cost for large inputs.
Rack::Deflater invokes this method for each request when the middleware is enabled:
Utils.select_best_encoding(ENCODINGS, Utils.parse_encodings(accept_encoding))
As a result, a client can trigger this expensive code path simply by sending a large Accept-Encoding header containing many repeated wildcard values.
For example, a request with an approximately 8 KB Accept-Encoding header containing about 1,000 *;q=0.5 entries can cause roughly 170 ms of CPU time in a single request on the Rack::Deflater path, compared to a negligible baseline for a normal header.
This issue is distinct from CVE-2024-26146. That issue concerned regular expression denial of service during Accept header parsing, whereas this issue arises later during encoding selection after the header has already been parsed.
Impact
Any Rack application using Rack::Deflater may be affected.
An unauthenticated attacker can send requests with crafted Accept-Encoding headers to trigger excessive CPU usage in the encoding selection logic. Repeated requests can consume worker time disproportionately and reduce application availability.
The attack does not require invalid HTTP syntax or large payload bodies. A single header-sized request is sufficient to reach the vulnerable code path.
Mitigation
- Update to a patched version of Rack in which encoding selection does not repeatedly rescan the parsed header for wildcard entries.
- Avoid enabling
Rack::Deflateron untrusted traffic. - Apply request filtering or header size / format restrictions at the reverse proxy or application boundary to limit abusive
Accept-Encodingvalues.
{
"affected": [
{
"package": {
"ecosystem": "RubyGems",
"name": "rack"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.2.23"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "RubyGems",
"name": "rack"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.0.beta1"
},
{
"fixed": "3.1.21"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "RubyGems",
"name": "rack"
},
"ranges": [
{
"events": [
{
"introduced": "3.2.0"
},
{
"fixed": "3.2.6"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-34230"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-407"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-02T20:32:19Z",
"nvd_published_at": "2026-04-02T17:16:23Z",
"severity": "HIGH"
},
"details": "## Summary\n\n`Rack::Utils.select_best_encoding` processes `Accept-Encoding` values with quadratic time complexity when the header contains many wildcard (`*`) entries. Because this method is used by `Rack::Deflater` to choose a response encoding, an unauthenticated attacker can send a single request with a crafted `Accept-Encoding` header and cause disproportionate CPU consumption on the compression middleware path.\n\nThis results in a denial of service condition for applications using `Rack::Deflater`.\n\n## Details\n\n`Rack::Utils.select_best_encoding` expands parsed `Accept-Encoding` values into a list of candidate encodings. When an entry is `*`, the method computes the set of concrete encodings by subtracting the encodings already present in the request:\n\n```ruby\nif m == \"*\"\n (available_encodings - accept_encoding.map(\u0026:first)).each do |m2|\n expanded_accept_encoding \u003c\u003c [m2, q, preference]\n end\nelse\n expanded_accept_encoding \u003c\u003c [m, q, preference]\nend\n```\n\nBecause `accept_encoding.map(\u0026:first)` is evaluated inside the loop, it is recomputed for each wildcard entry. If the request contains `N` wildcard entries, this produces repeated scans over the full parsed header and causes quadratic behavior.\n\nAfter expansion, the method also performs additional work over `expanded_accept_encoding`, including per-entry deletion, which further increases the cost for large inputs.\n\n`Rack::Deflater` invokes this method for each request when the middleware is enabled:\n\n```ruby\nUtils.select_best_encoding(ENCODINGS, Utils.parse_encodings(accept_encoding))\n```\n\nAs a result, a client can trigger this expensive code path simply by sending a large `Accept-Encoding` header containing many repeated wildcard values.\n\nFor example, a request with an approximately 8 KB `Accept-Encoding` header containing about 1,000 `*;q=0.5` entries can cause roughly 170 ms of CPU time in a single request on the `Rack::Deflater` path, compared to a negligible baseline for a normal header.\n\nThis issue is distinct from CVE-2024-26146. That issue concerned regular expression denial of service during `Accept` header parsing, whereas this issue arises later during encoding selection after the header has already been parsed.\n\n## Impact\n\nAny Rack application using `Rack::Deflater` may be affected.\n\nAn unauthenticated attacker can send requests with crafted `Accept-Encoding` headers to trigger excessive CPU usage in the encoding selection logic. Repeated requests can consume worker time disproportionately and reduce application availability.\n\nThe attack does not require invalid HTTP syntax or large payload bodies. A single header-sized request is sufficient to reach the vulnerable code path.\n\n## Mitigation\n\n* Update to a patched version of Rack in which encoding selection does not repeatedly rescan the parsed header for wildcard entries.\n* Avoid enabling `Rack::Deflater` on untrusted traffic.\n* Apply request filtering or header size / format restrictions at the reverse proxy or application boundary to limit abusive `Accept-Encoding` values.",
"id": "GHSA-v569-hp3g-36wr",
"modified": "2026-05-13T16:18:11Z",
"published": "2026-04-02T20:32:19Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/rack/rack/security/advisories/GHSA-v569-hp3g-36wr"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34230"
},
{
"type": "PACKAGE",
"url": "https://github.com/rack/rack"
},
{
"type": "WEB",
"url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/rack/CVE-2026-34230.yml"
}
],
"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": "Rack has quadratic complexity in Rack::Utils.select_best_encoding via wildcard Accept-Encoding header"
}
GHSA-V57X-GXFJ-484Q
Vulnerability from github – Published: 2022-01-21 23:25 – Updated: 2022-01-19 16:11Impact
A highly critical 0-day exploit (CVE-2021-44228) is found in Apache log4j 2 library on December 9, 2021.
This affects Apache log4j versions from 2.0-beta9 to 2.14.1 (inclusive).
This vulnerability allows a remote attacker to execute code on the server if the system logs an attacker-controlled string value with the attacker's JNDI LDAP server lookup.
Another vulnerability related to the same library, which was discovered on 12/14/2021 (CVE-2021-45046) and revealed another Remote Code Execution vulnerability, has been investigated by Hazelcast team as well and it is found that it does not affect Hazelcast Products under default configurations.
The finding of CVE-2021-45105 on 12/14/2021, which can cause a Denial of Service attack, was investigated by Hazelcast team and it is confirmed that it does not affect Hazelcast Products under default configurations.
The finding of CVE-2021-44832 on 12/28/2021, which is a medium vulnerability, is investigated by our security team as well, and not considered to be as critical. It requires attacker to be able to modify logging configuration, which means attacker can modify the filesystem and/or can already execute arbitrary code which is more of a general security breach rather than something log4j specific.
Note that Hazelcast IMDG and IMDG Enterprise itself is not affected.
However, given version distributions are considered to be vulnerable since related ZIP and TGZ distributions contain a vulnerable Hazelcast Management Center version.
Patches
CVE-2021-44228 is fixed in log4j 2.15.0. CVE-2021-45046 is fixed in log4j 2.16.0. CVE-2021-45105 is fixed in log4j 2.17.0. CVE-2021-44832 is fixed in log4j 2.17.1.
As of 12/21/2021, Hazelcast team has released a new version of all affected products that upgrades log4j to 2.17.0 as listed below: Hazelcast Management Center 4.2021.12-1, Hazelcast Management Center 5.0.4. Hazelcast IMDG and IMDG Enterprise 4.0.5, 4.1.8 and 4.2.4. Hazelcast Jet 4.5.3. Hazelcast Platform 5.0.2.
As of 01/06/2022, Hazelcast Management Center 4.2022.01 with the updated log4j 2.17.1 is released. log4j2.17.1 will be included in Management Center 5.1 that is expected to be released in February.
Hazelcast recommends upgrading to the latest versions available.
Workarounds
For users that an upgrade is not an option, below mitigations can be applied.
Disabling lookups via Environment Variable
Setting the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS=true . This option is the easiest to apply for containerized environments.
Disabling lookups in log4j2 configuration
Another good option since there is no need to replace JARs or no need to modify logging configuration file, users who cannot upgrade to 2.17.0 can mitigate the exposure by:
Users of Log4j 2.10 or greater may add -Dlog4j2.formatMsgNoLookups=trueas a command line option or add -Dlog4j2.formatMsgNoLookups=true in a log4j2.component.properties file on the classpath to prevent lookups in log event messages.
Users since Log4j 2.7 may specify %m{nolookups} in the PatternLayout configuration to prevent lookups in log event messages.
As an example; users deploying Hazelcast Management Center via helm charts can do the following to disable lookups and restart in one command:
helm upgrade <release-name> hazelcast/hazelcast --set mancenter.javaOpts="<javaOpts> -Dlog4j2.formatMsgNoLookups=true"
Where is the release name and is existing java options user has added previously.
Removing the JndiLookup from classpath
Remove the JndiLookup and JndiManager classes from the log4j-core jar. Note that removal of the JndiManager will cause the JndiContextSelector and JMSAppender to no longer function.
References
https://nvd.nist.gov/vuln/detail/CVE-2021-44228 https://nvd.nist.gov/vuln/detail/CVE-2021-45046 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45105 https://nvd.nist.gov/vuln/detail/CVE-2021-44832 https://logging.apache.org/log4j/2.x/index.html
For more information
If you have any questions or comments about this advisory: * Open an issue in our repo * Slack us at Hazelcast Community Slack
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "com.hazelcast.jet:hazelcast-jet"
},
"ranges": [
{
"events": [
{
"introduced": "4.1"
},
{
"fixed": "4.5.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.hazelcast:hazelcast"
},
"ranges": [
{
"events": [
{
"introduced": "5.0"
},
{
"fixed": "5.0.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.hazelcast:hazelcast"
},
"ranges": [
{
"events": [
{
"introduced": "4.0.0"
},
{
"fixed": "4.0.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.hazelcast:hazelcast"
},
"ranges": [
{
"events": [
{
"introduced": "4.1.1"
},
{
"fixed": "4.1.8"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.hazelcast:hazelcast"
},
"ranges": [
{
"events": [
{
"introduced": "4.2"
},
{
"fixed": "4.2.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-20",
"CWE-400",
"CWE-502"
],
"github_reviewed": true,
"github_reviewed_at": "2022-01-19T16:11:28Z",
"nvd_published_at": null,
"severity": "CRITICAL"
},
"details": "### Impact\nA highly critical 0-day exploit (CVE-2021-44228) is found in Apache log4j 2 library on December 9, 2021.\n\nThis affects Apache log4j versions from 2.0-beta9 to 2.14.1 (inclusive). \n\nThis vulnerability allows a remote attacker to execute code on the server if the system logs an attacker-controlled string value with the attacker\u0027s JNDI LDAP server lookup.\n\nAnother vulnerability related to the same library, which was discovered on 12/14/2021 (CVE-2021-45046) and revealed another Remote Code Execution vulnerability, has been investigated by Hazelcast team as well and it is found that it does not affect Hazelcast Products under default configurations. \n\nThe finding of CVE-2021-45105 on 12/14/2021, which can cause a Denial of Service attack, was investigated by Hazelcast team and it is confirmed that it does not affect Hazelcast Products under default configurations. \n\nThe finding of CVE-2021-44832 on 12/28/2021, which is a medium vulnerability, is investigated by our security team as well, and not considered to be as critical. It requires attacker to be able to modify logging configuration, which means attacker can modify the filesystem and/or can already execute arbitrary code which is more of a general security breach rather than something log4j specific.\n\nNote that Hazelcast IMDG and IMDG Enterprise itself is not affected.\n\nHowever, given version distributions are considered to be vulnerable since related ZIP and TGZ distributions contain a vulnerable Hazelcast Management Center version.\n\n### Patches\nCVE-2021-44228 is fixed in log4j 2.15.0.\nCVE-2021-45046 is fixed in log4j 2.16.0.\nCVE-2021-45105 is fixed in log4j 2.17.0.\nCVE-2021-44832 is fixed in log4j 2.17.1.\n\nAs of 12/21/2021, Hazelcast team has released a new version of all affected products that upgrades log4j to 2.17.0 as listed below: \nHazelcast Management Center 4.2021.12-1, Hazelcast Management Center 5.0.4.\nHazelcast IMDG and IMDG Enterprise 4.0.5, 4.1.8 and 4.2.4.\nHazelcast Jet 4.5.3.\nHazelcast Platform 5.0.2.\n\nAs of 01/06/2022, Hazelcast Management Center 4.2022.01 with the updated log4j 2.17.1 is released. log4j2.17.1 will be included in Management Center 5.1 that is expected to be released in February. \n\nHazelcast recommends upgrading to the latest versions available.\n\n### Workarounds\nFor users that an upgrade is not an option, below mitigations can be applied.\n\n#### Disabling lookups via Environment Variable \nSetting the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS=true .\nThis option is the easiest to apply for containerized environments.\n\n#### Disabling lookups in log4j2 configuration\nAnother good option since there is no need to replace JARs or no need to modify logging configuration file, users who cannot upgrade to 2.17.0 can mitigate the exposure by:\n\nUsers of Log4j 2.10 or greater may add `-Dlog4j2.formatMsgNoLookups=true `as a command line option or add `-Dlog4j2.formatMsgNoLookups=true` in a `log4j2.component.properties` file on the classpath to prevent lookups in log event messages.\nUsers since Log4j 2.7 may specify `%m{nolookups}` in the PatternLayout configuration to prevent lookups in log event messages.\nAs an example; users deploying Hazelcast Management Center via helm charts can do the following to disable lookups and restart in one command:\n\n`helm upgrade \u003crelease-name\u003e hazelcast/hazelcast --set mancenter.javaOpts=\"\u003cjavaOpts\u003e -Dlog4j2.formatMsgNoLookups=true\"`\n\nWhere \u003crelease-name\u003e is the release name and \u003cjavaOpts\u003e is existing java options user has added previously.\n\n#### Removing the JndiLookup from classpath\nRemove the JndiLookup and JndiManager classes from the log4j-core jar. Note that removal of the JndiManager will cause the JndiContextSelector and JMSAppender to no longer function.\n\n### References\nhttps://nvd.nist.gov/vuln/detail/CVE-2021-44228\nhttps://nvd.nist.gov/vuln/detail/CVE-2021-45046\nhttps://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45105\nhttps://nvd.nist.gov/vuln/detail/CVE-2021-44832\nhttps://logging.apache.org/log4j/2.x/index.html\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Open an issue in [our repo](https://github.com/hazelcast/hazelcast)\n* Slack us at [Hazelcast Community Slack](https://slack.hazelcast.com/)\n",
"id": "GHSA-v57x-gxfj-484q",
"modified": "2022-01-19T16:11:28Z",
"published": "2022-01-21T23:25:04Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/hazelcast/hazelcast/security/advisories/GHSA-v57x-gxfj-484q"
},
{
"type": "WEB",
"url": "https://github.com/hazelcast/hazelcast"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Security Advisory for \"Log4Shell\""
}
GHSA-V58W-6XC2-W799
Vulnerability from github – Published: 2022-05-14 00:56 – Updated: 2024-01-12 16:39A vulnerability in Puppet 2.6.x before 2.6.15 and 2.7.x before 2.7.13, and Puppet Enterprise (PE) Users 1.0, 1.1, 1.2.x, 2.0.x, and 2.5.x before 2.5.1 allows remote authenticated users with agent SSL keys to (1) cause a denial of service (memory consumption) via a REST request to a stream that triggers a thread block, as demonstrated using CVE-2012-1986 and /dev/random; or (2) cause a denial of service (filesystem consumption) via crafted REST requests that use "a marshaled form of a Puppet::FileBucket::File object" to write to arbitrary file locations.
{
"affected": [
{
"package": {
"ecosystem": "RubyGems",
"name": "puppet"
},
"ranges": [
{
"events": [
{
"introduced": "2.6.0"
},
{
"fixed": "2.6.15"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "RubyGems",
"name": "puppet"
},
"ranges": [
{
"events": [
{
"introduced": "2.7.0"
},
{
"fixed": "2.7.13"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2012-1987"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2024-01-12T16:39:38Z",
"nvd_published_at": "2012-05-29T20:55:00Z",
"severity": "LOW"
},
"details": "A vulnerability in Puppet 2.6.x before 2.6.15 and 2.7.x before 2.7.13, and Puppet Enterprise (PE) Users 1.0, 1.1, 1.2.x, 2.0.x, and 2.5.x before 2.5.1 allows remote authenticated users with agent SSL keys to **(1)** cause a denial of service (memory consumption) via a REST request to a stream that triggers a thread block, as demonstrated using CVE-2012-1986 and `/dev/random`; or **(2)** cause a denial of service (filesystem consumption) via crafted REST requests that use \"a marshaled form of a `Puppet::FileBucket::File object`\" to write to arbitrary file locations.",
"id": "GHSA-v58w-6xc2-w799",
"modified": "2024-01-12T16:39:38Z",
"published": "2022-05-14T00:56:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2012-1987"
},
{
"type": "WEB",
"url": "https://github.com/puppetlabs/puppet/commit/0d6d29933e613fe177e9235415919a5428db67bc"
},
{
"type": "WEB",
"url": "https://github.com/puppetlabs/puppet/commit/568ded50ec6cc498ad32ff7f086d9f73b5d24c14"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/74794"
},
{
"type": "ADVISORY",
"url": "https://github.com/advisories/GHSA-v58w-6xc2-w799"
},
{
"type": "PACKAGE",
"url": "https://github.com/puppetlabs/puppet"
},
{
"type": "WEB",
"url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/puppet/CVE-2012-1987.yml"
},
{
"type": "WEB",
"url": "https://hermes.opensuse.org/messages/14523305"
},
{
"type": "WEB",
"url": "https://hermes.opensuse.org/messages/15087408"
},
{
"type": "WEB",
"url": "https://web.archive.org/web/20120415105345/http://www.securityfocus.com/bid/52975"
},
{
"type": "WEB",
"url": "https://web.archive.org/web/20120513213318/http://projects.puppetlabs.com/issues/13553"
},
{
"type": "WEB",
"url": "https://web.archive.org/web/20120513224202/http://projects.puppetlabs.com/issues/13552"
},
{
"type": "WEB",
"url": "https://web.archive.org/web/20121005145241/http://projects.puppetlabs.com/projects/1/wiki/Release_Notes#2.6.15"
},
{
"type": "WEB",
"url": "https://web.archive.org/web/20160808163232/https://puppet.com/security/cve/cve-2012-1987"
},
{
"type": "WEB",
"url": "http://lists.fedoraproject.org/pipermail/package-announce/2012-April/079227.html"
},
{
"type": "WEB",
"url": "http://lists.fedoraproject.org/pipermail/package-announce/2012-April/079289.html"
},
{
"type": "WEB",
"url": "http://lists.fedoraproject.org/pipermail/package-announce/2012-May/080003.html"
},
{
"type": "WEB",
"url": "http://ubuntu.com/usn/usn-1419-1"
},
{
"type": "WEB",
"url": "http://www.debian.org/security/2012/dsa-2451"
}
],
"schema_version": "1.4.0",
"severity": [],
"summary": "Puppet Denial of Service and Arbitrary File Write"
}
GHSA-V5C5-M6WP-9RF7
Vulnerability from github – Published: 2024-07-17 00:32 – Updated: 2025-11-04 18:31Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB). Supported versions that are affected are 8.0.37 and prior and 8.4.0 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).
{
"affected": [],
"aliases": [
"CVE-2024-20996"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-16T23:15:11Z",
"severity": "MODERATE"
},
"details": "Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB). Supported versions that are affected are 8.0.37 and prior and 8.4.0 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).",
"id": "GHSA-v5c5-m6wp-9rf7",
"modified": "2025-11-04T18:31:07Z",
"published": "2024-07-17T00:32:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-20996"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20240801-0001"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpujul2024.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"
}
]
}
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.