CWE-400
DiscouragedUncontrolled Resource Consumption
Abstraction: Class · Status: Draft
The product does not properly control the allocation and maintenance of a limited resource.
5570 vulnerabilities reference this CWE, most recent first.
GHSA-6FVQ-23CW-5628
Vulnerability from github – Published: 2025-10-07 21:35 – Updated: 2025-10-07 21:35Summary
A resource-exhaustion (denial-of-service) vulnerability exists in multiple endpoints of the OpenAI-Compatible Server due to the ability to specify Jinja templates via the chat_template and chat_template_kwargs parameters. If an attacker can supply these parameters to the API, they can cause a service outage by exhausting CPU and/or memory resources.
Details
When using an LLM as a chat model, the conversation history must be rendered into a text input for the model. In hf/transformer, this rendering is performed using a Jinja template. The OpenAI-Compatible Server launched by vllm serve exposes a chat_template parameter that lets users specify that template. In addition, the server accepts a chat_template_kwargs parameter to pass extra keyword arguments to the rendering function.
Because Jinja templates support programming-language-like constructs (loops, nested iterations, etc.), a crafted template can consume extremely large amounts of CPU and memory and thereby trigger a denial-of-service condition.
Importantly, simply forbidding the chat_template parameter does not fully mitigate the issue. The implementation constructs a dictionary of keyword arguments for apply_hf_chat_template and then updates that dictionary with the user-supplied chat_template_kwargs via dict.update. Since dict.update can overwrite existing keys, an attacker can place a chat_template key inside chat_template_kwargs to replace the template that will be used by apply_hf_chat_template.
# vllm/entrypoints/openai/serving_engine.py#L794-L816
_chat_template_kwargs: dict[str, Any] = dict(
chat_template=chat_template,
add_generation_prompt=add_generation_prompt,
continue_final_message=continue_final_message,
tools=tool_dicts,
documents=documents,
)
_chat_template_kwargs.update(chat_template_kwargs or {})
request_prompt: Union[str, list[int]]
if isinstance(tokenizer, MistralTokenizer):
...
else:
request_prompt = apply_hf_chat_template(
tokenizer=tokenizer,
conversation=conversation,
model_config=model_config,
**_chat_template_kwargs,
)
Impact
If an OpenAI-Compatible Server exposes endpoints that accept chat_template or chat_template_kwargs from untrusted clients, an attacker can submit a malicious Jinja template (directly or by overriding chat_template inside chat_template_kwargs) that consumes excessive CPU and/or memory. This can result in a resource-exhaustion denial-of-service that renders the server unresponsive to legitimate requests.
Fixes
- https://github.com/vllm-project/vllm/pull/25794
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "vllm"
},
"ranges": [
{
"events": [
{
"introduced": "0.5.1"
},
{
"fixed": "0.11.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-61620"
],
"database_specific": {
"cwe_ids": [
"CWE-20",
"CWE-400",
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2025-10-07T21:35:22Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Summary\n\nA resource-exhaustion (denial-of-service) vulnerability exists in multiple endpoints of the OpenAI-Compatible Server due to the ability to specify Jinja templates via the `chat_template` and `chat_template_kwargs` parameters. If an attacker can supply these parameters to the API, they can cause a service outage by exhausting CPU and/or memory resources.\n\n### Details\n\nWhen using an LLM as a chat model, the conversation history must be rendered into a text input for the model. In `hf/transformer`, this rendering is performed using a Jinja template. The OpenAI-Compatible Server launched by vllm serve exposes a `chat_template` parameter that lets users specify that template. In addition, the server accepts a `chat_template_kwargs` parameter to pass extra keyword arguments to the rendering function.\n\nBecause Jinja templates support programming-language-like constructs (loops, nested iterations, etc.), a crafted template can consume extremely large amounts of CPU and memory and thereby trigger a denial-of-service condition.\n\nImportantly, simply forbidding the `chat_template` parameter does not fully mitigate the issue. The implementation constructs a dictionary of keyword arguments for `apply_hf_chat_template` and then updates that dictionary with the user-supplied `chat_template_kwargs` via `dict.update`. Since `dict.update` can overwrite existing keys, an attacker can place a `chat_template` key inside `chat_template_kwargs` to replace the template that will be used by `apply_hf_chat_template`.\n\n\n```python\n# vllm/entrypoints/openai/serving_engine.py#L794-L816\n_chat_template_kwargs: dict[str, Any] = dict(\n chat_template=chat_template,\n add_generation_prompt=add_generation_prompt,\n continue_final_message=continue_final_message,\n tools=tool_dicts,\n documents=documents,\n)\n_chat_template_kwargs.update(chat_template_kwargs or {})\n\nrequest_prompt: Union[str, list[int]]\nif isinstance(tokenizer, MistralTokenizer):\n ...\nelse:\n request_prompt = apply_hf_chat_template(\n tokenizer=tokenizer,\n conversation=conversation,\n model_config=model_config,\n **_chat_template_kwargs,\n )\n```\n\n### Impact\n\nIf an OpenAI-Compatible Server exposes endpoints that accept `chat_template` or `chat_template_kwargs` from untrusted clients, an attacker can submit a malicious Jinja template (directly or by overriding `chat_template` inside `chat_template_kwargs`) that consumes excessive CPU and/or memory. This can result in a resource-exhaustion denial-of-service that renders the server unresponsive to legitimate requests.\n\n### Fixes\n\n* https://github.com/vllm-project/vllm/pull/25794",
"id": "GHSA-6fvq-23cw-5628",
"modified": "2025-10-07T21:35:23Z",
"published": "2025-10-07T21:35:22Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/vllm-project/vllm/security/advisories/GHSA-6fvq-23cw-5628"
},
{
"type": "WEB",
"url": "https://github.com/vllm-project/vllm/pull/25794"
},
{
"type": "WEB",
"url": "https://github.com/vllm-project/vllm/commit/7977e5027c2250a4abc1f474c5619c40b4e5682f"
},
{
"type": "PACKAGE",
"url": "https://github.com/vllm-project/vllm"
}
],
"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"
}
],
"summary": "vLLM: Resource-Exhaustion (DoS) through Malicious Jinja Template in OpenAI-Compatible Server"
}
GHSA-6FWG-JRFW-FF7P
Vulnerability from github – Published: 2023-12-05 18:13 – Updated: 2023-12-05 18:13Summary
The traefik docker container uses 100% CPU when it serves as its own backend, which is an automatically generated route resulting from the Docker integration in the default configuration.
Details
While attempting to set up Traefik to handle traffic for Docker containers, I observed in the webUI a rule with the following information:
Host(traefik-service) | webwebsecure | traefik-service@docker | traefik-service
I assumed that this is something internal; however, I wondered why it would have a host rule on the web entrypoint configured.
So I have send a request with that hostname with curl -v --resolve "traefik-service:80:xxx.xxx.xxx.xxx" http://traefik-service. That made my whole server unresponsive.
I assume the name comes from a docker container with that name, traefik itself:
localhost ~ # docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
d1414e74aec7 traefik:v2.10 "/entrypoint.sh trae…" 4 minutes ago Up 4 minutes 0.0.0.0:80->80/tcp, :::80->80/tcp, 0.0.0.0:443->443/tcp, :::443->443/tcp, 127.0.0.1:8080->8080/tcp traefik.service
PoC
-
Start traefik with
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -p 80:80 --name foo -p 8080:8080 traefik:v2.10 --api.insecure=true --providers.docker -
curl -v --resolve "foo:80:127.0.0.1" http://foo
looks like this creates an endless loop of request.
Knowing the name of the docker container seems to be enough to trigger this, if the docker backend is used.
Impact
Server is unreachable and uses 100% CPU
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/traefik/traefik/v2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.10.6"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/traefik/traefik/v3"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.0.0-beta5"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-47633"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2023-12-05T18:13:53Z",
"nvd_published_at": "2023-12-04T21:15:34Z",
"severity": "HIGH"
},
"details": "### Summary\n\nThe traefik docker container uses 100% CPU when it serves as its own backend, which is an automatically generated route resulting from the Docker integration in the default configuration.\n\n### Details\n\nWhile attempting to set up Traefik to handle traffic for Docker containers, I observed in the webUI a rule with the following information:\n\n`Host(traefik-service) | webwebsecure | traefik-service@docker | traefik-service`\n\nI assumed that this is something internal; however, I wondered why it would have a host rule on the web entrypoint configured.\n\nSo I have send a request with that hostname with `curl -v --resolve \"traefik-service:80:xxx.xxx.xxx.xxx\" http://traefik-service`. That made my whole server unresponsive.\n\nI assume the name comes from a docker container with that name, traefik itself:\n```\nlocalhost ~ # docker ps\nCONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES\nd1414e74aec7 traefik:v2.10 \"/entrypoint.sh trae\u2026\" 4 minutes ago Up 4 minutes 0.0.0.0:80-\u003e80/tcp, :::80-\u003e80/tcp, 0.0.0.0:443-\u003e443/tcp, :::443-\u003e443/tcp, 127.0.0.1:8080-\u003e8080/tcp traefik.service\n```\n\n### PoC\n\n1. Start traefik with `docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -p 80:80 --name foo -p 8080:8080 traefik:v2.10 --api.insecure=true --providers.docker`\n\n2. `curl -v --resolve \"foo:80:127.0.0.1\" http://foo`\n\nlooks like this creates an endless loop of request.\n\nKnowing the name of the docker container seems to be enough to trigger this, if the docker backend is used.\n\n### Impact\n\nServer is unreachable and uses 100% CPU",
"id": "GHSA-6fwg-jrfw-ff7p",
"modified": "2023-12-05T18:13:54Z",
"published": "2023-12-05T18:13:53Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/traefik/traefik/security/advisories/GHSA-6fwg-jrfw-ff7p"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-47633"
},
{
"type": "PACKAGE",
"url": "https://github.com/traefik/traefik"
},
{
"type": "WEB",
"url": "https://github.com/traefik/traefik/releases/tag/v2.10.6"
},
{
"type": "WEB",
"url": "https://github.com/traefik/traefik/releases/tag/v3.0.0-beta5"
}
],
"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": "Traefik docker container using 100% CPU"
}
GHSA-6FXM-66HQ-FC96
Vulnerability from github – Published: 2022-05-13 01:07 – Updated: 2024-02-22 15:15Algorithmic complexity vulnerability in the sorting algorithms in bzip2 compressing stream (BZip2CompressorOutputStream) in Apache Commons Compress before 1.4.1 allows remote attackers to cause a denial of service (CPU consumption) via a file with many repeating inputs.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.commons:commons-compress"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.4.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2012-2098"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2022-07-13T21:10:51Z",
"nvd_published_at": "2012-06-29T19:55:00Z",
"severity": "MODERATE"
},
"details": "Algorithmic complexity vulnerability in the sorting algorithms in bzip2 compressing stream (BZip2CompressorOutputStream) in Apache Commons Compress before 1.4.1 allows remote attackers to cause a denial of service (CPU consumption) via a file with many repeating inputs.",
"id": "GHSA-6fxm-66hq-fc96",
"modified": "2024-02-22T15:15:53Z",
"published": "2022-05-13T01:07:05Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2012-2098"
},
{
"type": "WEB",
"url": "https://github.com/apache/commons-compress/commit/020c03d8ef579e80511023fb46ece30e9c3dd27d"
},
{
"type": "WEB",
"url": "https://github.com/apache/commons-compress/commit/0600296ab8f8a0bbdfedd483f51b38005eb8e34e"
},
{
"type": "WEB",
"url": "https://github.com/apache/commons-compress/commit/1ce57d976c4f25fe99edcadf079840c278f3cb84"
},
{
"type": "WEB",
"url": "https://github.com/apache/commons-compress/commit/2ab2fcb356753927afaa731b9d2dcc47d3083408"
},
{
"type": "WEB",
"url": "https://github.com/apache/commons-compress/commit/654222e628097763ee6ca561ae77be5c06666173"
},
{
"type": "WEB",
"url": "https://github.com/apache/commons-compress/commit/6ced422bf5eca3aac05396367bafb33ec21bf74e"
},
{
"type": "WEB",
"url": "https://github.com/apache/commons-compress/commit/6e95697e783767f3549f00d7d2e1b002eac4a3d4"
},
{
"type": "WEB",
"url": "https://github.com/apache/commons-compress/commit/8f702469cbf4c451b6dea349290bc4af0f6f76c7"
},
{
"type": "WEB",
"url": "https://github.com/apache/commons-compress/commit/b06f7b41c936ef1a79589d16ea5c1d8b93f71f66"
},
{
"type": "WEB",
"url": "https://github.com/apache/commons-compress/commit/cca0e6e5341aacddefd4c4d36cef7cbdbc2a8777"
},
{
"type": "WEB",
"url": "https://github.com/apache/commons-compress/commit/ea31005111f0abede7e43e4ba0012e62e0808b22"
},
{
"type": "WEB",
"url": "https://github.com/apache/commons-compress/commit/fdd7459bc5470e90024dbe762249166481cce769"
},
{
"type": "WEB",
"url": "https://web.archive.org/web/20140724002926/http://secunia.com/advisories/49286"
},
{
"type": "WEB",
"url": "https://web.archive.org/web/20140724023114/http://secunia.com/advisories/49255"
},
{
"type": "WEB",
"url": "https://web.archive.org/web/20200517014414/http://www.securitytracker.com/id?1027096"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpujan2021.html"
},
{
"type": "WEB",
"url": "https://web.archive.org/web/20130525085523/http://www.securityfocus.com/bid/53676"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r204ba2a9ea750f38d789d2bb429cc0925ad6133deea7cbc3001d96b5@\u003csolr-user.lucene.apache.org\u003e"
},
{
"type": "PACKAGE",
"url": "https://github.com/apache/commons-compress"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/75857"
},
{
"type": "WEB",
"url": "http://ant.apache.org/security.html"
},
{
"type": "WEB",
"url": "http://archives.neohapsis.com/archives/bugtraq/2012-05/0130.html"
},
{
"type": "WEB",
"url": "http://commons.apache.org/compress/security.html"
},
{
"type": "WEB",
"url": "http://lists.fedoraproject.org/pipermail/package-announce/2012-June/081697.html"
},
{
"type": "WEB",
"url": "http://lists.fedoraproject.org/pipermail/package-announce/2012-June/081746.html"
},
{
"type": "WEB",
"url": "http://lists.fedoraproject.org/pipermail/package-announce/2013-May/105049.html"
},
{
"type": "WEB",
"url": "http://lists.fedoraproject.org/pipermail/package-announce/2013-May/105060.html"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.org/files/113014/Apache-Commons-Compress-Apache-Ant-Denial-Of-Service.html"
},
{
"type": "WEB",
"url": "http://www-01.ibm.com/support/docview.wss?uid=swg21644047"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2023/09/13/3"
}
],
"schema_version": "1.4.0",
"severity": [],
"summary": "Uncontrolled Resource Consumption in Apache Commons Compress"
}
GHSA-6FXV-WQ7W-GJP3
Vulnerability from github – Published: 2021-12-16 00:01 – Updated: 2022-05-24 00:00{
"affected": [],
"aliases": [
"CVE-2021-43228"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-12-15T15:15:00Z",
"severity": "HIGH"
},
"details": "SymCrypt Denial of Service Vulnerability",
"id": "GHSA-6fxv-wq7w-gjp3",
"modified": "2022-05-24T00:00:45Z",
"published": "2021-12-16T00:01:57Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-43228"
},
{
"type": "WEB",
"url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2021-43228"
}
],
"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-6G6H-7V62-4X32
Vulnerability from github – Published: 2023-10-31 00:30 – Updated: 2023-11-06 21:31An issue discovered in Govee LED Strip v3.00.42 allows attackers to cause a denial of service via crafted Move and MoveWithOnoff commands.
{
"affected": [],
"aliases": [
"CVE-2023-45956"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-10-30T22:15:10Z",
"severity": "HIGH"
},
"details": "An issue discovered in Govee LED Strip v3.00.42 allows attackers to cause a denial of service via crafted Move and MoveWithOnoff commands.",
"id": "GHSA-6g6h-7v62-4x32",
"modified": "2023-11-06T21:31:06Z",
"published": "2023-10-31T00:30:59Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-45956"
},
{
"type": "WEB",
"url": "https://github.com/IoT-Fuzz/IoT-Fuzz/blob/main/Govee%20LED%20Strip%20Vulnerability%20Report.pdf"
}
],
"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-6G87-FF9Q-V847
Vulnerability from github – Published: 2018-09-17 20:46 – Updated: 2024-11-19 18:06The Python websockets library version 4 contains a CWE-409: Improper Handling of Highly Compressed Data (Data Amplification) vulnerability in Servers and clients, unless configured with compression=None that can result in Denial of Service by memory exhaustion. This attack appears to be exploitable via sending a specially crafted frame on an established connection. This vulnerability appears to have been fixed in version 5.0
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "websockets"
},
"ranges": [
{
"events": [
{
"introduced": "4.0"
},
{
"fixed": "5.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2018-1000518"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2020-06-16T21:19:15Z",
"nvd_published_at": "2018-06-26T16:29:00Z",
"severity": "HIGH"
},
"details": "The Python websockets library version 4 contains a CWE-409: Improper Handling of Highly Compressed Data (Data Amplification) vulnerability in Servers and clients, unless configured with compression=None that can result in Denial of Service by memory exhaustion. This attack appears to be exploitable via sending a specially crafted frame on an established connection. This vulnerability appears to have been fixed in version 5.0",
"id": "GHSA-6g87-ff9q-v847",
"modified": "2024-11-19T18:06:51Z",
"published": "2018-09-17T20:46:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-1000518"
},
{
"type": "WEB",
"url": "https://github.com/aaugustin/websockets/pull/407"
},
{
"type": "PACKAGE",
"url": "https://github.com/aaugustin/websockets"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/websockets/PYSEC-2018-79.yaml"
}
],
"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"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "websockets is vulnerable to denial of service by memory exhaustion"
}
GHSA-6G8V-HPGW-H2V7
Vulnerability from github – Published: 2021-01-20 21:21 – Updated: 2023-09-12 20:56There is a prototype pollution vulnerability in gsap which affects all versions before 3.6.0.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "gsap"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.6.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2020-28478"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2021-01-20T05:34:02Z",
"nvd_published_at": "2021-01-19T11:15:00Z",
"severity": "HIGH"
},
"details": "There is a prototype pollution vulnerability in gsap which affects all versions before 3.6.0.",
"id": "GHSA-6g8v-hpgw-h2v7",
"modified": "2023-09-12T20:56:09Z",
"published": "2021-01-20T21:21:50Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-28478"
},
{
"type": "WEB",
"url": "https://github.com/greensock/GSAP/blob/master/src/gsap-core.js#L150"
},
{
"type": "WEB",
"url": "https://github.com/greensock/GSAP/blob/master/src/gsap-core.js%23L147"
},
{
"type": "WEB",
"url": "https://github.com/greensock/GSAP/releases/tag/3.6.0"
},
{
"type": "WEB",
"url": "https://snyk.io/vuln/SNYK-JS-GSAP-1054614"
},
{
"type": "WEB",
"url": "https://www.npmjs.com/package/gsap/v/3.6.0"
}
],
"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": "Prototype pollution in gsap"
}
GHSA-6GFH-7RJR-VFMG
Vulnerability from github – Published: 2026-07-14 21:32 – Updated: 2026-07-14 21:32NVIDIA Triton Inference Server for Linux contains a vulnerability where an attacker can cause uncontrolled resource consumption. A successful exploit of this vulnerability might lead to denial of service.
{
"affected": [],
"aliases": [
"CVE-2026-47479"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-14T20:17:03Z",
"severity": "HIGH"
},
"details": "NVIDIA Triton Inference Server for Linux contains a vulnerability where an attacker can cause uncontrolled resource consumption. A successful exploit of this vulnerability might lead to denial of service.",
"id": "GHSA-6gfh-7rjr-vfmg",
"modified": "2026-07-14T21:32:17Z",
"published": "2026-07-14T21:32:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-47479"
},
{
"type": "WEB",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47479"
}
],
"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-6GHJ-FRRJ-JJJ3
Vulnerability from github – Published: 2026-06-08 19:02 – Updated: 2026-06-12 19:27Summary
An attacker can cause DoS by sending crafted Redis payloads across multiple connections without \r\n. This exhausts the server's direct memory pool (OutOfDirectMemoryError), preventing legitimate connections from being processed.
Details
io.netty.handler.codec.redis.RedisDecoder decodes the length of bulk strings and array headers using the decodeLength method. This method reads bytes from the network until it encounters a \n character. However, it does not enforce any maximum length check while buffering the bytes if the \n character is not found. An attacker can exploit this by sending a continuous stream of digits (e.g., $1111...) without ever sending a \n.
To cause a true Denial of Service, an attacker must open multiple concurrent connections and distribute the unbounded payloads among them.
According to the RESP specification (https://redis.io/docs/latest/develop/reference/protocol-spec/), all parts of the protocol are strictly terminated with \r\n. Furthermore, the length prefix itself is an integer representation that must fit within standard numeric limits (e.g., a 64-bit signed integer). Therefore, a stream of digits exceeding these bounds without \r\n is a protocol violation and should be rejected immediately rather than buffered indefinitely.
Impact
Denial of Service due to memory exhaustion. Any application using Netty's RedisDecoder to handle untrusted Redis traffic is vulnerable.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.2.14.Final"
},
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-codec-redis"
},
"ranges": [
{
"events": [
{
"introduced": "4.2.0.Final"
},
{
"fixed": "4.2.15.Final"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.1.134.Final"
},
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-codec-redis"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.135.Final"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-44890"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-08T19:02:09Z",
"nvd_published_at": "2026-06-11T22:16:56Z",
"severity": "HIGH"
},
"details": "### Summary\nAn attacker can cause DoS by sending crafted Redis payloads across multiple connections without `\\r\\n`. This exhausts the server\u0027s direct memory pool (OutOfDirectMemoryError), preventing legitimate connections from being processed.\n\n### Details\nio.netty.handler.codec.redis.RedisDecoder decodes the length of bulk strings and array headers using the `decodeLength` method. This method reads bytes from the network until it encounters a `\\n` character. However, it does not enforce any maximum length check while buffering the bytes if the `\\n` character is not found. An attacker can exploit this by sending a continuous stream of digits (e.g., `$1111...`) without ever sending a `\\n`.\n\nTo cause a true Denial of Service, an attacker must open multiple concurrent connections and distribute the unbounded payloads among them.\n\nAccording to the RESP specification (https://redis.io/docs/latest/develop/reference/protocol-spec/), all parts of the protocol are strictly terminated with `\\r\\n`. Furthermore, the length prefix itself is an integer representation that must fit within standard numeric limits (e.g., a 64-bit signed integer). Therefore, a stream of digits exceeding these bounds without `\\r\\n` is a protocol violation and should be rejected immediately rather than buffered indefinitely.\n\n### Impact\nDenial of Service due to memory exhaustion. Any application using Netty\u0027s RedisDecoder to handle untrusted Redis traffic is vulnerable.",
"id": "GHSA-6ghj-frrj-jjj3",
"modified": "2026-06-12T19:27:16Z",
"published": "2026-06-08T19:02:09Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/netty/netty/security/advisories/GHSA-6ghj-frrj-jjj3"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44890"
},
{
"type": "PACKAGE",
"url": "https://github.com/netty/netty"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/releases/tag/netty-4.1.135.Final"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/releases/tag/netty-4.2.15.Final"
}
],
"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": "Netty has Unbounded Direct Memory Consumption in its RedisDecoder"
}
GHSA-6GMF-2369-C76C
Vulnerability from github – Published: 2025-03-20 12:32 – Updated: 2025-06-30 12:51A Denial of Service (DoS) vulnerability in zenml-io/zenml version 0.66.0 allows unauthenticated attackers to cause excessive resource consumption by sending malformed multipart requests with arbitrary characters appended to the end of multipart boundaries. This flaw in the multipart request boundary processing mechanism leads to an infinite loop, resulting in a complete denial of service for all users. Affected endpoints include /api/v1/login and /api/v1/device_authorization.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "zenml"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.68.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-9340"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-835"
],
"github_reviewed": true,
"github_reviewed_at": "2025-03-21T03:38:21Z",
"nvd_published_at": "2025-03-20T10:15:48Z",
"severity": "HIGH"
},
"details": "A Denial of Service (DoS) vulnerability in zenml-io/zenml version 0.66.0 allows unauthenticated attackers to cause excessive resource consumption by sending malformed multipart requests with arbitrary characters appended to the end of multipart boundaries. This flaw in the multipart request boundary processing mechanism leads to an infinite loop, resulting in a complete denial of service for all users. Affected endpoints include `/api/v1/login` and `/api/v1/device_authorization`.",
"id": "GHSA-6gmf-2369-c76c",
"modified": "2025-06-30T12:51:38Z",
"published": "2025-03-20T12:32:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-9340"
},
{
"type": "WEB",
"url": "https://github.com/zenml-io/zenml/commit/cba152eb9ca3071c8372b0b91c02d9d3351de48d"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/zenml/PYSEC-2025-57.yaml"
},
{
"type": "PACKAGE",
"url": "https://github.com/zenml-io/zenml"
},
{
"type": "WEB",
"url": "https://huntr.com/bounties/c9200654-7dc0-4c1d-8573-ab79a87fb4f6"
}
],
"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"
}
],
"summary": "ZenML unauthenticated DoS via Multipart Boundry"
}
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.