CWE-770
AllowedAllocation of Resources Without Limits or Throttling
Abstraction: Base · Status: Incomplete
The product allocates a reusable resource or group of resources on behalf of an actor without imposing any intended restrictions on the size or number of resources that can be allocated.
4103 vulnerabilities reference this CWE, most recent first.
GHSA-X593-M4Q5-JXPR
Vulnerability from github – Published: 2023-01-26 21:30 – Updated: 2023-02-01 18:30In many functions of AutomaticZenRule.java, there is a possible failure to persist permissions settings due to resource exhaustion. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-10 Android-11 Android-12 Android-12L Android-13Android ID: A-242703460
{
"affected": [],
"aliases": [
"CVE-2022-20489"
],
"database_specific": {
"cwe_ids": [
"CWE-770"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-01-26T21:15:00Z",
"severity": "HIGH"
},
"details": "In many functions of AutomaticZenRule.java, there is a possible failure to persist permissions settings due to resource exhaustion. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-10 Android-11 Android-12 Android-12L Android-13Android ID: A-242703460",
"id": "GHSA-x593-m4q5-jxpr",
"modified": "2023-02-01T18:30:31Z",
"published": "2023-01-26T21:30:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-20489"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/2023-01-01"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-X5FP-WJ9C-MXMX
Vulnerability from github – Published: 2026-09-02 14:46 – Updated: 2026-09-02 14:46Summary
qs v6.15.3 allows bracket-key input to bypass arrayLimit and throwOnLimitExceeded when comma: true. The input a[]=1,2,3,4 succeeds with arrayLimit: 3, while the equivalent plain-key input is rejected.
Affected version tested:
qs v6.15.3
commit 18d085e919dae70c8f1b200ab99323058edab2c2
Details
parseArrayValue() enforces the comma limit only for flat values. The a[] form is marked non-flat, so its comma-separated value is wrapped after parsing and the inner array is not checked. A single parameter can therefore materialize arbitrarily large arrays.
PoC
const qs = require('qs')
const options = { comma: true, arrayLimit: 3, throwOnLimitExceeded: true }
const result = qs.parse('a[]=1,2,3,4', options)
console.log(result.a[0].length) // 4; expected RangeError
const big = qs.parse('a[]=' + '1,'.repeat(1000000) + '1', { comma: true, arrayLimit: 20 })
console.log(big.a[0].length) // 1000001
On v6.15.3, the first input parses successfully and the second creates an array with 1,000,001 elements. The equivalent a=1,2,3,4 input throws RangeError as expected.
Impact
An attacker who can supply a query string or form body can bypass configured array limits and force excessive memory allocation, causing denial of service. The limit must be applied after comma splitting and before the resulting array is wrapped.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 6.15.3"
},
"package": {
"ecosystem": "npm",
"name": "qs"
},
"ranges": [
{
"events": [
{
"introduced": "6.14.2"
},
{
"fixed": "6.16.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-82562"
],
"database_specific": {
"cwe_ids": [
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-02T14:46:57Z",
"nvd_published_at": "2026-08-30T01:20:32Z",
"severity": "MODERATE"
},
"details": "### Summary\n\n`qs` `v6.15.3` allows bracket-key input to bypass `arrayLimit` and `throwOnLimitExceeded` when `comma: true`. The input `a[]=1,2,3,4` succeeds with `arrayLimit: 3`, while the equivalent plain-key input is rejected.\n\nAffected version tested:\n\n```text\nqs v6.15.3\ncommit 18d085e919dae70c8f1b200ab99323058edab2c2\n```\n\n### Details\n\n`parseArrayValue()` enforces the comma limit only for flat values. The `a[]` form is marked non-flat, so its comma-separated value is wrapped after parsing and the inner array is not checked. A single parameter can therefore materialize arbitrarily large arrays.\n\n### PoC\n\n```js\nconst qs = require(\u0027qs\u0027)\nconst options = { comma: true, arrayLimit: 3, throwOnLimitExceeded: true }\n\nconst result = qs.parse(\u0027a[]=1,2,3,4\u0027, options)\nconsole.log(result.a[0].length) // 4; expected RangeError\n\nconst big = qs.parse(\u0027a[]=\u0027 + \u00271,\u0027.repeat(1000000) + \u00271\u0027, { comma: true, arrayLimit: 20 })\nconsole.log(big.a[0].length) // 1000001\n```\n\nOn `v6.15.3`, the first input parses successfully and the second creates an array with 1,000,001 elements. The equivalent `a=1,2,3,4` input throws `RangeError` as expected.\n\n### Impact\n\nAn attacker who can supply a query string or form body can bypass configured array limits and force excessive memory allocation, causing denial of service. The limit must be applied after comma splitting and before the resulting array is wrapped.",
"id": "GHSA-x5fp-wj9c-mxmx",
"modified": "2026-09-02T14:46:57Z",
"published": "2026-09-02T14:46:57Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/ljharb/qs/security/advisories/GHSA-w7fw-mjwx-w883"
},
{
"type": "WEB",
"url": "https://github.com/ljharb/qs/security/advisories/GHSA-x5fp-wj9c-mxmx"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-82562"
},
{
"type": "WEB",
"url": "https://github.com/ljharb/qs/commit/8859c37470e11b42b547b275e4e9bd0bc8cc5464"
},
{
"type": "PACKAGE",
"url": "https://github.com/ljharb/qs"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "qs array-limit bypass via bracket-key comma parsing"
}
GHSA-X62C-6MXR-74FH
Vulnerability from github – Published: 2022-07-21 00:00 – Updated: 2026-10-14 15:31In libtirpc before 1.3.3rc1, remote attackers could exhaust the file descriptors of a process that uses libtirpc because idle TCP connections are mishandled. This can, in turn, lead to an svc_run infinite loop without accepting new connections.
{
"affected": [],
"aliases": [
"CVE-2021-46828"
],
"database_specific": {
"cwe_ids": [
"CWE-755",
"CWE-770"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-07-20T06:15:00Z",
"severity": "HIGH"
},
"details": "In libtirpc before 1.3.3rc1, remote attackers could exhaust the file descriptors of a process that uses libtirpc because idle TCP connections are mishandled. This can, in turn, lead to an svc_run infinite loop without accepting new connections.",
"id": "GHSA-x62c-6mxr-74fh",
"modified": "2026-10-14T15:31:13Z",
"published": "2022-07-21T00:00:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-46828"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-398330.html"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-558014.html"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-561322.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2022/08/msg00004.html"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202210-33"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20221007-0004"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2022/dsa-5200"
},
{
"type": "WEB",
"url": "http://git.linux-nfs.org/?p=steved/libtirpc.git%3Ba=commit%3Bh=86529758570cef4c73fb9b9c4104fdc510f701ed"
},
{
"type": "WEB",
"url": "http://git.linux-nfs.org/?p=steved/libtirpc.git;a=commit;h=86529758570cef4c73fb9b9c4104fdc510f701ed"
}
],
"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-X63G-263F-3P2W
Vulnerability from github – Published: 2024-05-14 15:32 – Updated: 2024-05-14 15:32IBM App Connect Enterprise 11.0.0.1 through 11.0.0.25 and 12.0.1.0 through 12.0.12.0 dashboard is vulnerable to a denial of service due to improper restrictions of resource allocation. IBM X-Force ID: 285244.
{
"affected": [],
"aliases": [
"CVE-2024-28760"
],
"database_specific": {
"cwe_ids": [
"CWE-770"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-14T15:14:40Z",
"severity": "MODERATE"
},
"details": "IBM App Connect Enterprise 11.0.0.1 through 11.0.0.25 and 12.0.1.0 through 12.0.12.0 dashboard is vulnerable to a denial of service due to improper restrictions of resource allocation. IBM X-Force ID: 285244.",
"id": "GHSA-x63g-263f-3p2w",
"modified": "2024-05-14T15:32:54Z",
"published": "2024-05-14T15:32:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-28760"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/285244"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/pages/node/7150845"
}
],
"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:L",
"type": "CVSS_V3"
}
]
}
GHSA-X64G-4XX9-FH6X
Vulnerability from github – Published: 2020-06-10 20:02 – Updated: 2021-10-21 21:14CiphertextHeader.java in Cryptacular before 1.2.4, as used in Apereo CAS and other products, allows attackers to trigger excessive memory allocation during a decode operation, because the nonce array length associated with "new byte" may depend on untrusted input within the header of encoded data.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.cryptacular:cryptacular"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.1.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.cryptacular:cryptacular"
},
"ranges": [
{
"events": [
{
"introduced": "1.2.0"
},
{
"fixed": "1.2.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2020-7226"
],
"database_specific": {
"cwe_ids": [
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2020-06-10T18:23:35Z",
"nvd_published_at": "2020-01-24T15:15:00Z",
"severity": "HIGH"
},
"details": "CiphertextHeader.java in Cryptacular before 1.2.4, as used in Apereo CAS and other products, allows attackers to trigger excessive memory allocation during a decode operation, because the nonce array length associated with \u0026quot;new byte\u0026quot; may depend on untrusted input within the header of encoded data.",
"id": "GHSA-x64g-4xx9-fh6x",
"modified": "2021-10-21T21:14:28Z",
"published": "2020-06-10T20:02:58Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-7226"
},
{
"type": "WEB",
"url": "https://github.com/vt-middleware/cryptacular/issues/52"
},
{
"type": "WEB",
"url": "https://github.com/apereo/cas/pull/4685"
},
{
"type": "WEB",
"url": "https://github.com/vt-middleware/cryptacular/pull/56"
},
{
"type": "WEB",
"url": "https://github.com/apereo/cas/commit/8810f2b6c71d73341d4dde6b09a18eb46cfd6d45"
},
{
"type": "WEB",
"url": "https://github.com/apereo/cas/commit/93b1c3e9d90e36a19d0fa0f6efb863c6f0235e75"
},
{
"type": "WEB",
"url": "https://github.com/apereo/cas/commit/a042808d6adbbf44753d52c55cac5f533e24101f"
},
{
"type": "WEB",
"url": "https://github.com/vt-middleware/cryptacular/commit/311baf12252abf21947afd07bf0a0291ec3ec796"
},
{
"type": "WEB",
"url": "https://github.com/vt-middleware/cryptacular/commit/ec2fb65f2455c479376695e3d75d30c7f6884b3f"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpuoct2021.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpuapr2022.html"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rfa4647c58e375996e62a9094bffff6dc350ec311ba955b430e738945@%3Cdev.ws.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/re7f46c4cc29a4616e0aa669c84a0eb34832e83a8eef05189e2e59b44@%3Cdev.ws.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/re04e4f8f0d095387fb6b0ff9016a0af8c93f42e1de93b09298bfa547@%3Ccommits.ws.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rc36b75cabb4d700b48035d15ad8b8c2712bb32123572a1bdaec2510a@%3Cdev.ws.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r77c48cd851f60833df9a9c9c31f12243508e15d1b2a0961066d44fc6@%3Ccommits.tomee.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r4a62133ad01d5f963755021027a4cce23f76b8674a13860d2978c7c8@%3Ccommits.tomee.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r380781f5b489cb3c818536cd3b3757e806bfe0bca188591e0051ac03@%3Ccommits.ws.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r2237a27040b57adc2fcc5570bd530ad2038e67fcb2a3ce65283d3143@%3Ccommits.tomee.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r209de85beae4d257d27fc577e3a3e97039bdb4c2dc6f4a8e5a5a5811@%3Ccommits.tomee.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r0847c7eb78c8f9e87d5b841fbd5da52b2ad4b4345e04b51c30621d88@%3Ccommits.tomee.apache.org%3E"
},
{
"type": "WEB",
"url": "https://github.com/vt-middleware/cryptacular/blob/master/src/main/java/org/cryptacular/CiphertextHeader.java#L153"
},
{
"type": "WEB",
"url": "https://github.com/vt-middleware/cryptacular/blob/fafccd07ab1214e3588a35afe3c361519129605f/src/main/java/org/cryptacular/CiphertextHeader.java#L153"
},
{
"type": "PACKAGE",
"url": "https://github.com/vt-middleware/cryptacular"
}
],
"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": "Denial of Service in Cryptacular"
}
GHSA-X6C8-X7C4-FPQR
Vulnerability from github – Published: 2026-07-14 18:31 – Updated: 2026-07-14 18:31Allocation of resources without limits or throttling in ASP.NET Core allows an unauthorized attacker to deny service over a network.
{
"affected": [],
"aliases": [
"CVE-2026-45646"
],
"database_specific": {
"cwe_ids": [
"CWE-770"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-14T17:16:49Z",
"severity": "HIGH"
},
"details": "Allocation of resources without limits or throttling in ASP.NET Core allows an unauthorized attacker to deny service over a network.",
"id": "GHSA-x6c8-x7c4-fpqr",
"modified": "2026-07-14T18:31:59Z",
"published": "2026-07-14T18:31:59Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45646"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-45646"
}
],
"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-X6JW-W885-QWPC
Vulnerability from github – Published: 2024-03-15 12:30 – Updated: 2024-03-15 12:30Mattermost versions 8.1.x before 8.1.10, 9.2.x before 9.2.6, 9.3.x before 9.3.2, and 9.4.x before 9.4.3 fail to limit the number of @-mentions processed per message, allowing an authenticated attacker to crash the client applications of other users via large, crafted messages.
{
"affected": [],
"aliases": [
"CVE-2024-2446"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-770"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-03-15T10:15:08Z",
"severity": "MODERATE"
},
"details": "Mattermost versions 8.1.x before 8.1.10, 9.2.x before 9.2.6, 9.3.x before 9.3.2, and 9.4.x before 9.4.3 fail to limit the number of @-mentions processed per message, allowing an authenticated attacker to crash the client applications of other users via large, crafted messages.\n\n",
"id": "GHSA-x6jw-w885-qwpc",
"modified": "2024-03-15T12:30:36Z",
"published": "2024-03-15T12:30:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-2446"
},
{
"type": "WEB",
"url": "https://mattermost.com/security-updates"
}
],
"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:L",
"type": "CVSS_V3"
}
]
}
GHSA-X6MC-67GF-CHW4
Vulnerability from github – Published: 2026-10-05 23:42 – Updated: 2026-10-05 23:43Summary
An unauthenticated remote attacker can exhaust the memory of the vLLM API-server process by raising the request-level media_io_kwargs.video.max_frames and fps knobs on any deployment serving a Qwen2-VL or Qwen3-VL model. 74 extra bytes of JSON took the server's peak RSS from 2 271 MiB to 13 629 MiB over unauthenticated POST /tokenize.
The num_frames ceiling reported in GHSA-vxqj-p4gw-9h4c and fixed by open PR #51969 does not reach this path: the Qwen samplers do not read num_frames at all. The same knobs were already capped upstream for GLMGAVideoBackend as an accepted security fix in 8b6de0eb9 (PR #54935, merged 2026-09-04); that cap never reached Qwen.
Details
Relationship to GHSA-vxqj-p4gw-9h4c and PR #51969 (read this first)
GHSA-vxqj-p4gw-9h4c reported that request-level media_io_kwargs.video.num_frames overrides the engine frame-count ceiling, and open PR #51969 fixes it by clamping num_frames inside VideoMediaIO.merge_kwargs.
That clamp does not reach the Qwen samplers. Qwen2VLVideoBackend and Qwen3VLVideoBackend do not read num_frames at all — Qwen2VLVideoBackend's own docstring says so ("num_frames is ignored (fps-driven, like the Qwen3-VL loader)"). They bound on max_frames, read from the same merged dict with no ceiling:
# vllm/multimodal/video.py — Qwen3VLVideoBackend.compute_frames_index_to_sample
min_frames = kwargs.get("min_frames", 4)
max_frames = kwargs.get("max_frames", 768)
num_frames = int(total_frames_num / original_fps * fps)
num_frames = min(max(num_frames, min_frames), max_frames, total_frames_num)
With max_frames raised from the request, the only remaining bound is total_frames_num — every frame in the container.
I applied PR #51969's patch locally and re-ran both paths through the real merge layer (merge_media_io_kwargs → VideoMediaIO.merge_kwargs → MediaConnector), against main @ b23433088:
request media_io_kwargs.video |
merged kwargs after #51969 | frames decoded | peak RSS |
|---|---|---|---|
| (absent) | None |
32 | 706 MiB |
{"video_backend":"opencv","num_frames":-1} |
{…,"num_frames":32} |
32 — fixed | 706 MiB |
{"video_backend":"qwen3_vl"} |
{…,"num_frames":32} |
60 | 779 MiB |
{"video_backend":"qwen3_vl","max_frames":1e9,"fps":1e6} |
{…,"max_frames":1000000000,"fps":1000000,"num_frames":32} |
900 — survives | 2 994 MiB |
51969 does exactly what it claims for num_frames; the clamp writes num_frames: 32 into the merged dict and the Qwen sampler ignores it, while max_frames and fps pass through untouched.
The codebase already has the fix pattern, on other backends
This is not a new control being proposed. Commit 8b6de0eb9 — "[Security] Cap GLMGA video sampling to prevent request-driven resource exhaustion" (PR #54935, merged 2026-09-04, same author as #51969) — caps precisely these two knobs for GLMGAVideoBackend:
_MAX_FRAMES: ClassVar[int] = 640
_MAX_FPS: ClassVar[int] = 30
...
target_fps = min(target.fps, cls._MAX_FPS)
max_frames = min(kwargs.get("max_frames", cls._MAX_FRAMES), cls._MAX_FRAMES)
Its description states the root cause as "both target_fps and max_frames are controllable via request-level media_io_kwargs", and says it follows "the pattern established by GLM46VVideoBackend" (which caps via _MAX_FRAME_COUNT_DYNAMIC = 640 and _MAX_DURATION = 2400).
So two backends cap request-controlled fps/max_frames as an accepted security measure. Qwen2VLVideoBackend and Qwen3VLVideoBackend — the most widely deployed video models on vLLM — cap neither. In GLMGA the uncapped knobs sized an intermediate index list; in the Qwen samplers they size the decoded frame buffer, which is larger by the per-frame pixel count.
Reachability — default configuration, no authentication
media_io_kwargsis a request body field onChatCompletionRequestand is carried by/v1/chat/completions,/v1/embeddings,/v1/responses,/tokenizeand/invocations. No flag gates it.api_keydefaults toNone(vllm/entrypoints/launchers/cli_args.py), andAuthenticationMiddlewareis installed only when a key is configured — a defaultvllm serveis entirely unauthenticated.- Even with
--api-keyset,GUARDED_PREFIX = ("/v1", "/v2", "/inference", "/cohere")(vllm/entrypoints/serve/middleware/authenticate.py:11), so/invocations— which validates the sameChatCompletionRequestbody — and/tokenize— which performs full media ingestion — remain unauthenticated. MediaConnector.fetch_videoapplies the model's registered sampler only when the request did not name one (if "video_backend" not in video_io_kwargs), sovideo_backend: "qwen3_vl"is selectable on any deployment; request-level selection of stock sampler subclasses is already established as reachable by GHSA-j682-9xp5-rrf3. On a Qwen deployment novideo_backendkey is needed at all.- Default-on for any video-capable Qwen model.
The Rust frontend is not affected. rust/src/server/src/routes/openai/chat_completions/validate.rs:90 rejects media_io_kwargs with "media_io_kwargs is not supported." No second front is needed.
Impact
Unauthenticated remote denial of service by memory exhaustion of the API-server process. The decode runs in the frontend during chat parsing, before scheduling or admission control, so every tenant on the instance is affected. --limit-mm-per-prompt does not apply — it bounds media items, not frames within an item. CWE-770 / CWE-400.
Measured over unauthenticated HTTP: 1.43 MiB request body, 74 extra bytes of JSON, server peak RSS 2 271 → 13 629 MiB. In-process, the same request takes the decode from 60 to 900 frames. The frame count is bounded only by total_frames_num, which is the attacker's choice of video, and decoded bytes are frames × H × W × 3.
Context, measured on the num_frames path (GHSA-vxqj-p4gw-9h4c's path), not this one — these figures show what an unbounded frame count costs once the source video is chosen for it, and they transfer to this path because both converge on the same _read_frames_no_recovery allocation:
- 5.74 MiB request body → 9.27 GiB decoded, 9.73 GiB of new resident memory (1 736×).
- 117.6 MiB
video/jpegpayload → process OOM-killed:Out of memory: Killed process 182667 (python) total-vm:38665704kB, anon-rss:21121616kB
The two were not re-run at the larger sizes through the Qwen sampler; the 900-frame figure above is what I measured on this path.
Suggested fix
Extend the ceiling to the sampler-side knobs rather than clamping the single num_frames key. Two options, either acceptable:
- Per-backend caps, matching
8b6de0eb9. GiveQwen2VLVideoBackendandQwen3VLVideoBackendthe_MAX_FRAMES/_MAX_FPStreatment already applied toGLMGAVideoBackend, sokwargs.get("max_frames", …)andtarget.fpsare clamped to class constants. Smallest change; consistent with the accepted precedent. It leavesGlm5NextVideoBackend,Molmo2VideoBackend,NemotronVLVideoBackend,DynamicVideoBackendandOpenCVDynamicOpenPanguVideoBackendto be audited one by one, which is the current trajectory (#55727, #56207, #56390). - Strip the frame-count knobs at the merge boundary. In
VideoMediaIO.merge_kwargs, dropmax_frames/min_frames/fpsfromruntime_kwargsthe wayhw_decoders,pool_size,deviceand unconfigured GPU backends are already dropped there. That treats the whole frame-count family as startup-only in one place and is robust to future sampler subclasses, at the cost of removing a request-level knob some users may rely on. A clamp-don't-strip variant (request may lower, never raise) preserves the feature.
Option 2 composes with #51969 and needs no per-backend audit; I would favour it, but option 1 is the more conservative change and matches what has already been merged.
Affected versions
>= 0.24.0, through v0.29.1rc0 and main @ b23433088.
Lower bound established by probing release tags through the GitHub contents API; no version below is inferred, each was read out of the file at that tag.
Confirmed present — Qwen samplers reading unclamped max_frames (max_frames = kwargs.get("max_frames", 768) inside Qwen2VLVideoBackend / Qwen3VLVideoBackend in vllm/multimodal/video.py):
| ref | Qwen3VLVideoBackend present |
unclamped max_frames |
|---|---|---|
| v0.23.0 | no (class does not exist) | n/a |
| v0.24.0 | yes | yes |
| v0.25.0, v0.26.0, v0.27.0, v0.28.0, v0.29.0, v0.29.1rc0 | yes | yes |
main @ b23433088 |
yes | yes |
Confirmed present — request-level media_io_kwargs (field on the chat request model, and VideoMediaIO.merge_kwargs present): every ref probed, v0.19.0 through v0.29.1rc0 and main @ b23433088.
Confirmed absent — any num_frames ceiling clamp (PR #51969 unmerged): every ref probed, v0.19.0 through v0.29.1rc0 and main @ b23433088.
Not resolved, and why:
- The introducing commit/PR for
Qwen2VLVideoBackend/Qwen3VLVideoBackend. My clone is shallow (--depth=300), sogit log -S'max_frames'cannot reach it; the v0.23.0 → v0.24.0 boundary above is the tightest bound I established by probing release tags. - The rc tags between v0.23.0 and v0.24.0, to tighten the lower bound to a specific release candidate.
- Whether a
max_framesknob on a differently named pre-v0.24.0 backend is separately affected — at v0.23.0GLMGAVideoBackendalready carriedmax_frames = kwargs.get("max_frames", 640)with no clamp, and that clamp was only added on 2026-09-04 by8b6de0eb9. Versions between are plausibly affected through GLMGA rather than Qwen; I did not test that path. - Whether GHSA-vxqj-p4gw-9h4c's own affected range differs, which I cannot see — the advisory returns 404 to me.
No dependency versions are asserted anywhere in this report.
Weaknesses of this report, stated upfront
- No GPU was used. This host has no CUDA device, so the HTTP results come from the in-tree GPU-less render server rather than a full
vllm serve. That server runs the real frontend — the same request model, the samemerge_media_io_kwargs→VideoMediaIO.merge_kwargs→MediaConnector.fetch_videochain, the same/tokenizeroute — and media decoding happens entirely in the frontend, so I do not believe the engine's presence changes the result. I have not confirmed that on a GPU deployment, and a reviewer may reasonably want that repeated undervllm serve. - The in-process measurements (the #51969 comparison table) were taken by importing the tree directly at
b23433088, verified by__file__, with novllmwheel installed. - Amplification figures are a floor. The OpenCV build available here offers only
mp4v/XVID, giving ~2 200× compression on static content. An attacker using x264/x265 would do materially better for the same frame count. - The two large figures in the Impact section (9.73 GiB RSS; the OOM kill) were measured on the
num_framespath, not this one, and are labelled as such. - Per-frame pixels remain bounded by
VLLM_MAX_IMAGE_PIXELS; this concerns the unbounded frame count, which multiplies it. VLLM_MAX_MEDIA_DOWNLOAD_SIZE_MB(default 256) caps the compressed size of an HTTP-fetched video but not adata:URI, whichMediaConnector.load_from_urldispatches before any size logic is reached.
Prepared with AI assistance (Claude), per the repository's contributing guidance on disclosing AI-assisted contributions. All findings were verified by executing vLLM's own code at the commits cited; the analysis and the claims are my own.
Reported by Eva Crystal / 0xiviel (XSource Security).
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "vllm"
},
"ranges": [
{
"events": [
{
"introduced": "0.24.0"
},
{
"fixed": "0.30.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-105758"
],
"database_specific": {
"cwe_ids": [
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-05T23:42:59Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Summary\n\nAn unauthenticated remote attacker can exhaust the memory of the vLLM API-server process by raising the request-level `media_io_kwargs.video.max_frames` and `fps` knobs on any deployment serving a Qwen2-VL or Qwen3-VL model. 74 extra bytes of JSON took the server\u0027s peak RSS from 2 271 MiB to 13 629 MiB over unauthenticated `POST /tokenize`.\n\nThe `num_frames` ceiling reported in GHSA-vxqj-p4gw-9h4c and fixed by open PR #51969 does not reach this path: the Qwen samplers do not read `num_frames` at all. The same knobs were already capped upstream for `GLMGAVideoBackend` as an accepted security fix in `8b6de0eb9` (PR #54935, merged 2026-09-04); that cap never reached Qwen.\n\n### Details\n\n#### Relationship to GHSA-vxqj-p4gw-9h4c and PR #51969 (read this first)\n\nGHSA-vxqj-p4gw-9h4c reported that request-level `media_io_kwargs.video.num_frames` overrides the engine frame-count ceiling, and open PR #51969 fixes it by clamping `num_frames` inside `VideoMediaIO.merge_kwargs`.\n\nThat clamp does not reach the Qwen samplers. `Qwen2VLVideoBackend` and `Qwen3VLVideoBackend` do not read `num_frames` at all \u2014 `Qwen2VLVideoBackend`\u0027s own docstring says so (\"``num_frames`` is ignored (fps-driven, like the Qwen3-VL loader)\"). They bound on `max_frames`, read from the same merged dict with no ceiling:\n\n```python\n# vllm/multimodal/video.py \u2014 Qwen3VLVideoBackend.compute_frames_index_to_sample\nmin_frames = kwargs.get(\"min_frames\", 4)\nmax_frames = kwargs.get(\"max_frames\", 768)\nnum_frames = int(total_frames_num / original_fps * fps)\nnum_frames = min(max(num_frames, min_frames), max_frames, total_frames_num)\n```\n\nWith `max_frames` raised from the request, the only remaining bound is `total_frames_num` \u2014 every frame in the container.\n\nI applied PR #51969\u0027s patch locally and re-ran both paths through the real merge layer (`merge_media_io_kwargs` \u2192 `VideoMediaIO.merge_kwargs` \u2192 `MediaConnector`), against `main` @ `b23433088`:\n\n| request `media_io_kwargs.video` | merged kwargs after #51969 | frames decoded | peak RSS |\n|---|---|---|---|\n| *(absent)* | `None` | 32 | 706 MiB |\n| `{\"video_backend\":\"opencv\",\"num_frames\":-1}` | `{\u2026,\"num_frames\":32}` | **32 \u2014 fixed** | 706 MiB |\n| `{\"video_backend\":\"qwen3_vl\"}` | `{\u2026,\"num_frames\":32}` | 60 | 779 MiB |\n| `{\"video_backend\":\"qwen3_vl\",\"max_frames\":1e9,\"fps\":1e6}` | `{\u2026,\"max_frames\":1000000000,\"fps\":1000000,\"num_frames\":32}` | **900 \u2014 survives** | **2 994 MiB** |\n\n#51969 does exactly what it claims for `num_frames`; the clamp writes `num_frames: 32` into the merged dict and the Qwen sampler ignores it, while `max_frames` and `fps` pass through untouched.\n\n#### The codebase already has the fix pattern, on other backends\n\nThis is not a new control being proposed. Commit `8b6de0eb9` \u2014 \"[Security] Cap GLMGA video sampling to prevent request-driven resource exhaustion\" (PR #54935, merged 2026-09-04, same author as #51969) \u2014 caps precisely these two knobs for `GLMGAVideoBackend`:\n\n```python\n_MAX_FRAMES: ClassVar[int] = 640\n_MAX_FPS: ClassVar[int] = 30\n...\ntarget_fps = min(target.fps, cls._MAX_FPS)\nmax_frames = min(kwargs.get(\"max_frames\", cls._MAX_FRAMES), cls._MAX_FRAMES)\n```\n\nIts description states the root cause as \"both `target_fps` and `max_frames` are controllable via request-level `media_io_kwargs`\", and says it follows \"the pattern established by `GLM46VVideoBackend`\" (which caps via `_MAX_FRAME_COUNT_DYNAMIC = 640` and `_MAX_DURATION = 2400`).\n\nSo two backends cap request-controlled `fps`/`max_frames` as an accepted security measure. `Qwen2VLVideoBackend` and `Qwen3VLVideoBackend` \u2014 the most widely deployed video models on vLLM \u2014 cap neither. In GLMGA the uncapped knobs sized an intermediate *index list*; in the Qwen samplers they size the *decoded frame buffer*, which is larger by the per-frame pixel count.\n\n#### Reachability \u2014 default configuration, no authentication\n\n* `media_io_kwargs` is a request body field on `ChatCompletionRequest` and is carried by `/v1/chat/completions`, `/v1/embeddings`, `/v1/responses`, `/tokenize` and `/invocations`. No flag gates it.\n* `api_key` defaults to `None` (`vllm/entrypoints/launchers/cli_args.py`), and `AuthenticationMiddleware` is installed only when a key is configured \u2014 a default `vllm serve` is entirely unauthenticated.\n* Even with `--api-key` set, `GUARDED_PREFIX = (\"/v1\", \"/v2\", \"/inference\", \"/cohere\")` (`vllm/entrypoints/serve/middleware/authenticate.py:11`), so `/invocations` \u2014 which validates the same `ChatCompletionRequest` body \u2014 and `/tokenize` \u2014 which performs full media ingestion \u2014 remain unauthenticated.\n* `MediaConnector.fetch_video` applies the model\u0027s registered sampler only when the request did not name one (`if \"video_backend\" not in video_io_kwargs`), so `video_backend: \"qwen3_vl\"` is selectable on any deployment; request-level selection of stock sampler subclasses is already established as reachable by GHSA-j682-9xp5-rrf3. On a Qwen deployment no `video_backend` key is needed at all.\n* Default-on for any video-capable Qwen model.\n\n**The Rust frontend is not affected.** `rust/src/server/src/routes/openai/chat_completions/validate.rs:90` rejects `media_io_kwargs` with \"media_io_kwargs is not supported.\" No second front is needed.\n\n### Impact\n\nUnauthenticated remote denial of service by memory exhaustion of the API-server process. The decode runs in the frontend during chat parsing, before scheduling or admission control, so every tenant on the instance is affected. `--limit-mm-per-prompt` does not apply \u2014 it bounds media *items*, not frames within an item. CWE-770 / CWE-400.\n\nMeasured over unauthenticated HTTP: 1.43 MiB request body, 74 extra bytes of JSON, server peak RSS 2 271 \u2192 13 629 MiB. In-process, the same request takes the decode from 60 to 900 frames. The frame count is bounded only by `total_frames_num`, which is the attacker\u0027s choice of video, and decoded bytes are `frames \u00d7 H \u00d7 W \u00d7 3`.\n\n**Context, measured on the `num_frames` path (GHSA-vxqj-p4gw-9h4c\u0027s path), not this one** \u2014 these figures show what an unbounded frame count costs once the source video is chosen for it, and they transfer to this path because both converge on the same `_read_frames_no_recovery` allocation:\n\n* 5.74 MiB request body \u2192 9.27 GiB decoded, 9.73 GiB of new resident memory (1 736\u00d7).\n* 117.6 MiB `video/jpeg` payload \u2192 process OOM-killed: `Out of memory: Killed process 182667 (python) total-vm:38665704kB, anon-rss:21121616kB`\n\nThe two were not re-run at the larger sizes through the Qwen sampler; the 900-frame figure above is what I measured on this path.\n\n### Suggested fix\n\nExtend the ceiling to the sampler-side knobs rather than clamping the single `num_frames` key. Two options, either acceptable:\n\n1. **Per-backend caps, matching `8b6de0eb9`.** Give `Qwen2VLVideoBackend` and `Qwen3VLVideoBackend` the `_MAX_FRAMES` / `_MAX_FPS` treatment already applied to `GLMGAVideoBackend`, so `kwargs.get(\"max_frames\", \u2026)` and `target.fps` are clamped to class constants. Smallest change; consistent with the accepted precedent. It leaves `Glm5NextVideoBackend`, `Molmo2VideoBackend`, `NemotronVLVideoBackend`, `DynamicVideoBackend` and `OpenCVDynamicOpenPanguVideoBackend` to be audited one by one, which is the current trajectory (#55727, #56207, #56390).\n2. **Strip the frame-count knobs at the merge boundary.** In `VideoMediaIO.merge_kwargs`, drop `max_frames` / `min_frames` / `fps` from `runtime_kwargs` the way `hw_decoders`, `pool_size`, `device` and unconfigured GPU backends are already dropped there. That treats the whole frame-count family as startup-only in one place and is robust to future sampler subclasses, at the cost of removing a request-level knob some users may rely on. A clamp-don\u0027t-strip variant (request may lower, never raise) preserves the feature.\n\nOption 2 composes with #51969 and needs no per-backend audit; I would favour it, but option 1 is the more conservative change and matches what has already been merged.\n\n### Affected versions\n\n`\u003e= 0.24.0`, through v0.29.1rc0 and `main` @ `b23433088`.\n\nLower bound established by probing release tags through the GitHub contents API; no version below is inferred, each was read out of the file at that tag.\n\n**Confirmed present \u2014 Qwen samplers reading unclamped `max_frames`** (`max_frames = kwargs.get(\"max_frames\", 768)` inside `Qwen2VLVideoBackend` / `Qwen3VLVideoBackend` in `vllm/multimodal/video.py`):\n\n| ref | `Qwen3VLVideoBackend` present | unclamped `max_frames` |\n|---|---|---|\n| v0.23.0 | no (class does not exist) | n/a |\n| v0.24.0 | yes | yes |\n| v0.25.0, v0.26.0, v0.27.0, v0.28.0, v0.29.0, v0.29.1rc0 | yes | yes |\n| `main` @ `b23433088` | yes | yes |\n\n**Confirmed present \u2014 request-level `media_io_kwargs`** (field on the chat request model, and `VideoMediaIO.merge_kwargs` present): every ref probed, v0.19.0 through v0.29.1rc0 and `main` @ `b23433088`.\n\n**Confirmed absent \u2014 any `num_frames` ceiling clamp** (PR #51969 unmerged): every ref probed, v0.19.0 through v0.29.1rc0 and `main` @ `b23433088`.\n\n**Not resolved, and why:**\n\n1. The introducing commit/PR for `Qwen2VLVideoBackend` / `Qwen3VLVideoBackend`. My clone is shallow (`--depth=300`), so `git log -S\u0027max_frames\u0027` cannot reach it; the v0.23.0 \u2192 v0.24.0 boundary above is the tightest bound I established by probing release tags.\n2. The rc tags between v0.23.0 and v0.24.0, to tighten the lower bound to a specific release candidate.\n3. Whether a `max_frames` knob on a *differently named* pre-v0.24.0 backend is separately affected \u2014 at v0.23.0 `GLMGAVideoBackend` already carried `max_frames = kwargs.get(\"max_frames\", 640)` with no clamp, and that clamp was only added on 2026-09-04 by `8b6de0eb9`. Versions between are plausibly affected through GLMGA rather than Qwen; I did not test that path.\n4. Whether GHSA-vxqj-p4gw-9h4c\u0027s own affected range differs, which I cannot see \u2014 the advisory returns 404 to me.\n\nNo dependency versions are asserted anywhere in this report.\n\n### Weaknesses of this report, stated upfront\n\n* **No GPU was used.** This host has no CUDA device, so the HTTP results come from the in-tree GPU-less render server rather than a full `vllm serve`. That server runs the real frontend \u2014 the same request model, the same `merge_media_io_kwargs` \u2192 `VideoMediaIO.merge_kwargs` \u2192 `MediaConnector.fetch_video` chain, the same `/tokenize` route \u2014 and media decoding happens entirely in the frontend, so I do not believe the engine\u0027s presence changes the result. I have not confirmed that on a GPU deployment, and a reviewer may reasonably want that repeated under `vllm serve`.\n* The in-process measurements (the #51969 comparison table) were taken by importing the tree directly at `b23433088`, verified by `__file__`, with no `vllm` wheel installed.\n* **Amplification figures are a floor.** The OpenCV build available here offers only `mp4v`/`XVID`, giving ~2 200\u00d7 compression on static content. An attacker using x264/x265 would do materially better for the same frame count.\n* The two large figures in the Impact section (9.73 GiB RSS; the OOM kill) were measured on the `num_frames` path, not this one, and are labelled as such.\n* Per-frame pixels remain bounded by `VLLM_MAX_IMAGE_PIXELS`; this concerns the unbounded frame *count*, which multiplies it.\n* `VLLM_MAX_MEDIA_DOWNLOAD_SIZE_MB` (default 256) caps the compressed size of an HTTP-fetched video but not a `data:` URI, which `MediaConnector.load_from_url` dispatches before any size logic is reached.\n\n\n---\n\n*Prepared with AI assistance (Claude), per the repository\u0027s contributing guidance on disclosing AI-assisted contributions. All findings were verified by executing vLLM\u0027s own code at the commits cited; the analysis and the claims are my own.*\n\n*Reported by Eva Crystal / 0xiviel (XSource Security).*",
"id": "GHSA-x6mc-67gf-chw4",
"modified": "2026-10-05T23:43:00Z",
"published": "2026-10-05T23:42:59Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/vllm-project/vllm/security/advisories/GHSA-x6mc-67gf-chw4"
},
{
"type": "WEB",
"url": "https://github.com/vllm-project/vllm/pull/56729"
},
{
"type": "WEB",
"url": "https://github.com/vllm-project/vllm/commit/ea723c81c3ea26425cb69503a5d5e90822a04a45"
},
{
"type": "PACKAGE",
"url": "https://github.com/vllm-project/vllm"
},
{
"type": "WEB",
"url": "https://github.com/vllm-project/vllm/releases/tag/v0.30.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:L",
"type": "CVSS_V3"
}
],
"summary": "vLLM: Qwen2-VL / Qwen3-VL video samplers bound on request-controlled max_frames, which the num_frames ceiling does not reach"
}
GHSA-X6MF-6C4H-P75J
Vulnerability from github – Published: 2026-02-11 15:30 – Updated: 2026-02-12 21:31An allocation of resources without limits or throttling vulnerability has been reported to affect File Station 5. If a remote attacker gains an administrator account, they can then exploit the vulnerability to prevent other systems, applications, or processes from accessing the same type of resource.
We have already fixed the vulnerability in the following version: File Station 5 5.5.6.5018 and later
{
"affected": [],
"aliases": [
"CVE-2025-54155"
],
"database_specific": {
"cwe_ids": [
"CWE-770"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-02-11T13:15:54Z",
"severity": "LOW"
},
"details": "An allocation of resources without limits or throttling vulnerability has been reported to affect File Station 5. If a remote attacker gains an administrator account, they can then exploit the vulnerability to prevent other systems, applications, or processes from accessing the same type of resource.\n\nWe have already fixed the vulnerability in the following version:\nFile Station 5 5.5.6.5018 and later",
"id": "GHSA-x6mf-6c4h-p75j",
"modified": "2026-02-12T21:31:25Z",
"published": "2026-02-11T15:30:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-54155"
},
{
"type": "WEB",
"url": "https://www.qnap.com/en/security-advisory/qsa-26-03"
}
],
"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"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:H/E:U/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-X6XQ-WHH3-GG32
Vulnerability from github – Published: 2024-08-27 18:14 – Updated: 2024-08-27 20:31Impact
Instances of the Apollo Router using either of the following may be impacted by a denial-of-service vulnerability.
- External Coprocessing with specific configurations; or
- Native Rust Plugins accessing the Router request body in the RouterService layer
Router customizations using Rhai scripts are not impacted.
When using External Coprocessing:
Instances of the Apollo Router running versions >=1.21.0 and <1.52.1 are impacted by a denial-of-service vulnerability if all of the following are true:
- Router has been configured to support External Coprocessing.
- Router has been configured to send request bodies to coprocessors. This is a non-default configuration and must be configured intentionally by administrators.
You can identify if you are impacted by reviewing your router's configuration YAML for the following config:
...
coprocessor:
url: http://localhost:9000 # likely different in your environment
router:
request:
body: true # this must be set to 'true' to be impacted
...
External Coprocessing was initially made available as an experimental feature with Router version 1.21.0 on 2023-06-20 and was made generally available with Router version 1.38.0 on 2024-01-19. More information about the Router’s External Coprocessing feature is available here.
When using Native Rust Plugins:
Instances of the Apollo Router running versions >=1.7.0 and <1.52.1 are impacted by a denial-of-service vulnerability if all of the following are true:
- Router has been configured to use a custom-developed Native Rust Plugin
- The plugin accesses
Request.router_requestin theRouterServicelayer - You are accumulating the body from
Request.router_requestinto memory
To use a plugin, you need to be running a customized Router binary. Additionally, you need to have a plugins section with at least one plugin defined in your Router’s configuration YAML. That plugin would also need to define a custom router_service method.
You can check for a defined plugin by reviewing for the following in your Router’s configuration YAML:
...
plugins:
custom_plugin_name:
# custom config here
...
You can check for a custom router_service method in a plugin, by reviewing for the following function signature in your plugin’s source:
fn router_service(&self, service: router::BoxService) -> router::BoxService
More information about the Router’s Native Rust Plugin feature is available here.
Impact Detail
If using an impacted configuration, the Router will load entire HTTP request bodies into memory without respect to other HTTP request size-limiting configurations like limits.http_max_request_bytes. This can cause the Router to be out-of-memory (OOM) terminated if a sufficiently large request is sent to the Router.
By default, the Router sets limits.http_max_request_bytes to 2 MB. More information about the Router’s request limiting features is available here.
Patches
If you have an impacted configuration as defined above, please upgrade to at least Apollo Router 1.52.1.
Workarounds
If you cannot upgrade, you can mitigate the denial-of-service opportunity impacting External Coprocessors by setting the coprocessor.router.request.body configuration option to false. Please note that changing this configuration option will change the information sent to any coprocessors you have configured and may impact functionality implemented by those coprocessors.
If you have developed a Native Rust Plugin and cannot upgrade, you can update your plugin to either not accumulate the request body or enforce a maximum body size limit.
You can also mitigate this issue by limiting HTTP body payload sizes prior to the Router (e.g., in a proxy or web application firewall appliance).
References
Apollo Router 1.52.1 Release Notes External Coprocessing documentation HTTP Request Limiting documentation Native Rust Plugin documentation
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "apollo-router"
},
"ranges": [
{
"events": [
{
"introduced": "1.7.0"
},
{
"fixed": "1.52.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-43783"
],
"database_specific": {
"cwe_ids": [
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2024-08-27T18:14:29Z",
"nvd_published_at": "2024-08-27T18:15:15Z",
"severity": "HIGH"
},
"details": "## Impact\n\nInstances of the Apollo Router using either of the following may be impacted by a denial-of-service vulnerability.\n\n1. External Coprocessing with specific configurations; or\n2. Native Rust Plugins accessing the Router request body in the RouterService layer \n\nRouter customizations using Rhai scripts are **not** impacted.\n\n### When using External Coprocessing:\n\nInstances of the Apollo Router running versions \u003e=1.21.0 and \u003c1.52.1 are impacted by a denial-of-service vulnerability if **all** of the following are true:\n\n1. Router has been configured to support External Coprocessing.\n2. Router has been configured to send request bodies to coprocessors. This is a non-default configuration and must be configured intentionally by administrators.\n\nYou can identify if you are impacted by reviewing your router\u0027s configuration YAML for the following config:\n\n```yaml\n...\ncoprocessor:\n url: http://localhost:9000 # likely different in your environment\n router:\n request:\n body: true # this must be set to \u0027true\u0027 to be impacted\n...\n```\nExternal Coprocessing was initially made available as an experimental feature with [Router version 1.21.0](https://github.com/apollographql/router/releases/tag/v1.21.0) on 2023-06-20 and was made generally available with [Router version 1.38.0](https://github.com/apollographql/router/releases/tag/v1.38.0) on 2024-01-19. More information about the Router\u2019s [External Coprocessing feature is available here](https://www.apollographql.com/docs/router/customizations/coprocessor).\n\n### When using Native Rust Plugins:\n\nInstances of the Apollo Router running versions \u003e=1.7.0 and \u003c1.52.1 are impacted by a denial-of-service vulnerability if **all** of the following are true:\n\n1. Router has been configured to use a custom-developed Native Rust Plugin\n2. The plugin accesses `Request.router_request` in the `RouterService` layer\n3. You are accumulating the body from `Request.router_request` into memory\n\nTo use a plugin, you need to be running a customized Router binary. Additionally, you need to have a `plugins` section with at least one plugin defined in your Router\u2019s configuration YAML. That plugin would also need to define a custom `router_service` method.\n\nYou can check for a defined plugin by reviewing for the following in your Router\u2019s configuration YAML:\n\n```yaml\n...\nplugins:\n custom_plugin_name:\n # custom config here\n...\n```\n\nYou can check for a custom `router_service` method in a plugin, by reviewing for the following function signature in your plugin\u2019s source:\n\n```rust\nfn router_service(\u0026self, service: router::BoxService) -\u003e router::BoxService\n```\n\nMore information about the Router\u2019s [Native Rust Plugin feature is available here](https://www.apollographql.com/docs/router/customizations/native).\n\n## Impact Detail\n\nIf using an impacted configuration, the Router will load entire HTTP request bodies into memory without respect to other HTTP request size-limiting configurations like `limits.http_max_request_bytes`. This can cause the Router to be out-of-memory (OOM) terminated if a sufficiently large request is sent to the Router.\n\nBy default, the Router sets `limits.http_max_request_bytes` to 2 MB. More information about the Router\u2019s [request limiting features is available here](https://www.apollographql.com/docs/router/configuration/overview/#request-limits).\n\n## Patches\n\n[Apollo Router 1.52.1](https://github.com/apollographql/router/releases/tag/v1.52.1)\n\nIf you have an impacted configuration as defined above, please upgrade to at least Apollo Router 1.52.1.\n\n## Workarounds\nIf you cannot upgrade, you can mitigate the denial-of-service opportunity impacting External Coprocessors by setting the `coprocessor.router.request.body` configuration option to `false`. Please note that changing this configuration option will change the information sent to any coprocessors you have configured and may impact functionality implemented by those coprocessors. \n\nIf you have developed a Native Rust Plugin and cannot upgrade, you can update your plugin to either not accumulate the request body or enforce a maximum body size limit. \n\nYou can also mitigate this issue by limiting HTTP body payload sizes prior to the Router (e.g., in a proxy or web application firewall appliance).\n\n## References\n[Apollo Router 1.52.1 Release Notes](https://github.com/apollographql/router/releases/tag/v1.52.1)\n[External Coprocessing documentation](https://www.apollographql.com/docs/router/customizations/coprocessor)\n[HTTP Request Limiting documentation](https://www.apollographql.com/docs/router/configuration/overview/#request-limits)\n[Native Rust Plugin documentation](https://www.apollographql.com/docs/router/customizations/native)\n",
"id": "GHSA-x6xq-whh3-gg32",
"modified": "2024-08-27T20:31:40Z",
"published": "2024-08-27T18:14:29Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/apollographql/router/security/advisories/GHSA-x6xq-whh3-gg32"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43783"
},
{
"type": "WEB",
"url": "https://github.com/apollographql/router/commit/7a9c020608a62dcaa306b72ed0f6980f15923b14"
},
{
"type": "PACKAGE",
"url": "https://github.com/apollographql/router"
},
{
"type": "WEB",
"url": "https://github.com/apollographql/router/releases/tag/v1.52.1"
},
{
"type": "WEB",
"url": "https://www.apollographql.com/docs/router/configuration/overview/#request-limits"
},
{
"type": "WEB",
"url": "https://www.apollographql.com/docs/router/customizations/coprocessor"
},
{
"type": "WEB",
"url": "https://www.apollographql.com/docs/router/customizations/native"
}
],
"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"
},
{
"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": "Apollo Router Coprocessors may cause Denial-of-Service when handling request bodies"
}
Mitigation
Clearly specify the minimum and maximum expectations for capabilities, and dictate which behaviors are acceptable when resource allocation reaches limits.
Mitigation
Limit the amount of resources that are accessible to unprivileged users. Set per-user limits for resources. Allow the system administrator to define these limits. Be careful to avoid CWE-410.
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, and it will help the administrator to identify who is committing the abuse. 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 MIT-5
Strategy: Input Validation
- Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
- When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."
- Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
Mitigation MIT-15
For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.
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 can be difficult to effectively institute -- and even when properly done, it does not provide a full solution. It simply requires more resources on the part of the attacker.
- recognizes the attack and denies that user further access for a given amount of time, typically by using increasing time delays
- 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 MIT-38.1
- If the program must fail, ensure that it fails gracefully (fails closed). There may be a temptation to simply let the program fail poorly in cases such as low memory conditions, but an attacker may be able to assert control before the software has fully exited. Alternately, an uncontrolled failure could cause cascading problems with other downstream components; for example, the program could send a signal to a downstream process so the process immediately knows that a problem has occurred and has a better chance of recovery.
- Ensure that all failures in resource allocation place the system into a safe posture.
Mitigation MIT-47
Strategy: Resource Limitation
- Use quotas or other resource-limiting settings provided by the operating system or environment. For example, when managing system resources in POSIX, setrlimit() can be used to set limits for certain types of resources, and getrlimit() can determine how many resources are available. However, these functions are not available on all operating systems.
- When the current levels get close to the maximum that is defined for the application (see CWE-770), then limit the allocation of further resources to privileged users; alternately, begin releasing resources for less-privileged users. While this mitigation may protect the system from attack, it will not necessarily stop attackers from adversely impacting other users.
- Ensure that the application performs the appropriate error checks and error handling in case resources become unavailable (CWE-703).
CAPEC-125: Flooding
An adversary consumes the resources of a target by rapidly engaging in a large number of interactions with the target. This type of attack generally exposes a weakness in rate limiting or flow. When successful this attack prevents legitimate users from accessing the service and can cause the target to crash. This attack differs from resource depletion through leaks or allocations in that the latter attacks do not rely on the volume of requests made to the target but instead focus on manipulation of the target's operations. The key factor in a flooding attack is the number of requests the adversary can make in a given period of time. The greater this number, the more likely an attack is to succeed against a given target.
CAPEC-130: Excessive Allocation
An adversary causes the target to allocate excessive resources to servicing the attackers' request, thereby reducing the resources available for legitimate services and degrading or denying services. Usually, this attack focuses on memory allocation, but any finite resource on the target could be the attacked, including bandwidth, processing cycles, or other resources. This attack does not attempt to force this allocation through a large number of requests (that would be Resource Depletion through Flooding) but instead uses one or a small number of requests that are carefully formatted to force the target to allocate excessive resources to service this request(s). Often this attack takes advantage of a bug in the target to cause the target to allocate resources vastly beyond what would be needed for a normal request.
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-197: Exponential Data Expansion
An adversary submits data to a target application which contains nested exponential data expansion to produce excessively large output. Many data format languages allow the definition of macro-like structures that can be used to simplify the creation of complex structures. However, this capability can be abused to create excessive demands on a processor's CPU and memory. A small number of nested expansions can result in an exponential growth in demands on memory.
CAPEC-229: Serialized Data Parameter Blowup
This attack exploits certain serialized data parsers (e.g., XML, YAML, etc.) which manage data in an inefficient manner. The attacker crafts an serialized data file with multiple configuration parameters in the same dataset. In a vulnerable parser, this results in a denial of service condition where CPU resources are exhausted because of the parsing algorithm. The weakness being exploited is tied to parser implementation and not language specific.
CAPEC-230: Serialized Data with Nested Payloads
Applications often need to transform data in and out of a data format (e.g., XML and YAML) by using a parser. It may be possible for an adversary to inject data that may have an adverse effect on the parser when it is being processed. Many data format languages allow the definition of macro-like structures that can be used to simplify the creation of complex structures. By nesting these structures, causing the data to be repeatedly substituted, an adversary can cause the parser to consume more resources while processing, causing excessive memory consumption and CPU utilization.
CAPEC-231: Oversized Serialized Data Payloads
An adversary injects oversized serialized data payloads into a parser during data processing to produce adverse effects upon the parser such as exhausting system resources and arbitrary code execution.
CAPEC-469: HTTP DoS
An attacker performs flooding at the HTTP level to bring down only a particular web application rather than anything listening on a TCP/IP connection. This denial of service attack requires substantially fewer packets to be sent which makes DoS harder to detect. This is an equivalent of SYN flood in HTTP. The idea is to keep the HTTP session alive indefinitely and then repeat that hundreds of times. This attack targets resource depletion weaknesses in web server software. The web server will wait to attacker's responses on the initiated HTTP sessions while the connection threads are being exhausted.
CAPEC-482: TCP Flood
An adversary may execute a flooding attack using the TCP protocol with the intent to deny legitimate users access to a service. These attacks exploit the weakness within the TCP protocol where there is some state information for the connection the server needs to maintain. This often involves the use of TCP SYN messages.
CAPEC-486: UDP Flood
An adversary may execute a flooding attack using the UDP protocol with the intent to deny legitimate users access to a service by consuming the available network bandwidth. Additionally, firewalls often open a port for each UDP connection destined for a service with an open UDP port, meaning the firewalls in essence save the connection state thus the high packet nature of a UDP flood can also overwhelm resources allocated to the firewall. UDP attacks can also target services like DNS or VoIP which utilize these protocols. Additionally, due to the session-less nature of the UDP protocol, the source of a packet is easily spoofed making it difficult to find the source of the attack.
CAPEC-487: ICMP Flood
An adversary may execute a flooding attack using the ICMP protocol with the intent to deny legitimate users access to a service by consuming the available network bandwidth. A typical attack involves a victim server receiving ICMP packets at a high rate from a wide range of source addresses. Additionally, due to the session-less nature of the ICMP protocol, the source of a packet is easily spoofed making it difficult to find the source of the attack.
CAPEC-488: HTTP Flood
An adversary may execute a flooding attack using the HTTP protocol with the intent to deny legitimate users access to a service by consuming resources at the application layer such as web services and their infrastructure. These attacks use legitimate session-based HTTP GET requests designed to consume large amounts of a server's resources. Since these are legitimate sessions this attack is very difficult to detect.
CAPEC-489: SSL Flood
An adversary may execute a flooding attack using the SSL protocol with the intent to deny legitimate users access to a service by consuming all the available resources on the server side. These attacks take advantage of the asymmetric relationship between the processing power used by the client and the processing power used by the server to create a secure connection. In this manner the attacker can make a large number of HTTPS requests on a low provisioned machine to tie up a disproportionately large number of resources on the server. The clients then continue to keep renegotiating the SSL connection. When multiplied by a large number of attacking machines, this attack can result in a crash or loss of service to legitimate users.
CAPEC-490: Amplification
An adversary may execute an amplification where the size of a response is far greater than that of the request that generates it. The goal of this attack is to use a relatively few resources to create a large amount of traffic against a target server. To execute this attack, an adversary send a request to a 3rd party service, spoofing the source address to be that of the target server. The larger response that is generated by the 3rd party service is then sent to the target server. By sending a large number of initial requests, the adversary can generate a tremendous amount of traffic directed at the target. The greater the discrepancy in size between the initial request and the final payload delivered to the target increased the effectiveness of this attack.
CAPEC-491: Quadratic Data Expansion
An adversary exploits macro-like substitution to cause a denial of service situation due to excessive memory being allocated to fully expand the data. The result of this denial of service could cause the application to freeze or crash. This involves defining a very large entity and using it multiple times in a single entity substitution. CAPEC-197 is a similar attack pattern, but it is easier to discover and defend against. This attack pattern does not perform multi-level substitution and therefore does not obviously appear to consume extensive resources.
CAPEC-493: SOAP Array Blowup
An adversary may execute an attack on a web service that uses SOAP messages in communication. By sending a very large SOAP array declaration to the web service, the attacker forces the web service to allocate space for the array elements before they are parsed by the XML parser. The attacker message is typically small in size containing a large array declaration of say 1,000,000 elements and a couple of array elements. This attack targets exhaustion of the memory resources of the web service.
CAPEC-494: TCP Fragmentation
An adversary may execute a TCP Fragmentation attack against a target with the intention of avoiding filtering rules of network controls, by attempting to fragment the TCP packet such that the headers flag field is pushed into the second fragment which typically is not filtered.
CAPEC-495: UDP Fragmentation
An attacker may execute a UDP Fragmentation attack against a target server in an attempt to consume resources such as bandwidth and CPU. IP fragmentation occurs when an IP datagram is larger than the MTU of the route the datagram has to traverse. Typically the attacker will use large UDP packets over 1500 bytes of data which forces fragmentation as ethernet MTU is 1500 bytes. This attack is a variation on a typical UDP flood but it enables more network bandwidth to be consumed with fewer packets. Additionally it has the potential to consume server CPU resources and fill memory buffers associated with the processing and reassembling of fragmented packets.
CAPEC-496: ICMP Fragmentation
An attacker may execute a ICMP Fragmentation attack against a target with the intention of consuming resources or causing a crash. The attacker crafts a large number of identical fragmented IP packets containing a portion of a fragmented ICMP message. The attacker these sends these messages to a target host which causes the host to become non-responsive. Another vector may be sending a fragmented ICMP message to a target host with incorrect sizes in the header which causes the host to hang.
CAPEC-528: XML Flood
An adversary may execute a flooding attack using XML messages with the intent to deny legitimate users access to a web service. These attacks are accomplished by sending a large number of XML based requests and letting the service attempt to parse each one. In many cases this type of an attack will result in a XML Denial of Service (XDoS) due to an application becoming unstable, freezing, or crashing.