CWE-400
DiscouragedUncontrolled Resource Consumption
Abstraction: Class · Status: Draft
The product does not properly control the allocation and maintenance of a limited resource.
6201 vulnerabilities reference this CWE, most recent first.
GHSA-52CG-MJ79-8933
Vulnerability from github – Published: 2022-05-13 01:13 – Updated: 2022-05-13 01:13Memory leak in the ReadPSDLayers function in coders/psd.c in ImageMagick before 6.9.6-3 allows remote attackers to cause a denial of service (memory consumption) via a crafted image file.
{
"affected": [],
"aliases": [
"CVE-2016-10058"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-03-23T17:59:00Z",
"severity": "HIGH"
},
"details": "Memory leak in the ReadPSDLayers function in coders/psd.c in ImageMagick before 6.9.6-3 allows remote attackers to cause a denial of service (memory consumption) via a crafted image file.",
"id": "GHSA-52cg-mj79-8933",
"modified": "2022-05-13T01:13:31Z",
"published": "2022-05-13T01:13:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2016-10058"
},
{
"type": "WEB",
"url": "https://github.com/ImageMagick/ImageMagick/commit/47e8e6ceef979327614d0b8f0c76c6ecb18e09cf"
},
{
"type": "WEB",
"url": "https://github.com/ImageMagick/ImageMagick/commit/4ec444f4eab88cf4bec664fafcf9cab50bc5ff6a"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=1410467"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2016/12/26/9"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/95212"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-52CP-R559-CP3M
Vulnerability from github – Published: 2026-07-20 21:19 – Updated: 2026-07-20 21:19Impact
js-yaml can spend quadratic CPU time parsing a document whose size grows only linearly. The issue is triggered by a chain of mappings where each mapping merges the previous one:
a0: &a0 { k0: 0 }
a1: &a1 { <<: *a0, k1: 1 }
a2: &a2 { <<: *a1, k2: 2 }
a3: &a3 { <<: *a2, k3: 3 }
...
b: *aN
For each new mapping, the loader has to enumerate the keys inherited from the previous mapping. With N chained mappings, this results in roughly 1 + 2 + ... + N merged-key visits, i.e., O(N^2) work for O(N) input size.
PoC
From N = 4000 delay become > 1s (doc size < 100K)
import { performance } from 'node:perf_hooks'
import { Buffer } from 'node:buffer'
import { load, YAML11_SCHEMA } from 'js-yaml'
const n = Number(process.argv[2] || 4000)
function makeMergeChain (count) {
const lines = ['a0: &a0 { k0: 0 }']
for (let i = 1; i < count; i++) {
lines.push(`a${i}: &a${i} { <<: *a${i - 1}, k${i}: ${i} }`)
}
lines.push(`b: *a${count - 1}`)
return `${lines.join('\n')}\n`
}
const source = makeMergeChain(n)
console.log(source.split('\n').slice(0, 8).join('\n'))
console.log('...')
console.log(source.split('\n').slice(-4).join('\n'))
console.log()
console.log(`N: ${n}`)
console.log(`YAML size: ${Buffer.byteLength(source)} bytes`)
const started = performance.now()
const result = load(source, { schema: YAML11_SCHEMA })
const elapsed = performance.now() - started
console.log(`parse time: ${elapsed.toFixed(1)} ms`)
console.log(`top-level keys: ${Object.keys(result).length}`)
console.log(`b keys: ${Object.keys(result.b).length}`)
Patches
Fix released. The most robust protection is to limit the total number of merged keys per parse call. This should close all past and future edge cases with merge. The default 10K-key limit should be okay in most cases.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "js-yaml"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.0"
},
{
"fixed": "3.15.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "js-yaml"
},
"ranges": [
{
"events": [
{
"introduced": "4.0.0"
},
{
"fixed": "4.3.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-59869"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-407"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-20T21:19:09Z",
"nvd_published_at": "2026-07-08T16:16:33Z",
"severity": "HIGH"
},
"details": "### Impact\n\njs-yaml can spend quadratic CPU time parsing a document whose size grows only linearly. The issue is triggered by a chain of mappings where each mapping merges the previous one:\n\n```yaml\na0: \u0026a0 { k0: 0 }\na1: \u0026a1 { \u003c\u003c: *a0, k1: 1 }\na2: \u0026a2 { \u003c\u003c: *a1, k2: 2 }\na3: \u0026a3 { \u003c\u003c: *a2, k3: 3 }\n...\nb: *aN\n```\n\nFor each new mapping, the loader has to enumerate the keys inherited from the previous mapping. With N chained mappings, this results in roughly 1 + 2 + ... + N merged-key visits, i.e., O(N^2) work for O(N) input size.\n\n### PoC\n\nFrom N = 4000 delay become \u003e 1s (doc size \u003c 100K)\n\n```js\nimport { performance } from \u0027node:perf_hooks\u0027\nimport { Buffer } from \u0027node:buffer\u0027\nimport { load, YAML11_SCHEMA } from \u0027js-yaml\u0027\n\nconst n = Number(process.argv[2] || 4000)\n\nfunction makeMergeChain (count) {\n const lines = [\u0027a0: \u0026a0 { k0: 0 }\u0027]\n\n for (let i = 1; i \u003c count; i++) {\n lines.push(`a${i}: \u0026a${i} { \u003c\u003c: *a${i - 1}, k${i}: ${i} }`)\n }\n\n lines.push(`b: *a${count - 1}`)\n return `${lines.join(\u0027\\n\u0027)}\\n`\n}\n\nconst source = makeMergeChain(n)\n\nconsole.log(source.split(\u0027\\n\u0027).slice(0, 8).join(\u0027\\n\u0027))\nconsole.log(\u0027...\u0027)\nconsole.log(source.split(\u0027\\n\u0027).slice(-4).join(\u0027\\n\u0027))\nconsole.log()\nconsole.log(`N: ${n}`)\nconsole.log(`YAML size: ${Buffer.byteLength(source)} bytes`)\n\nconst started = performance.now()\nconst result = load(source, { schema: YAML11_SCHEMA })\nconst elapsed = performance.now() - started\n\nconsole.log(`parse time: ${elapsed.toFixed(1)} ms`)\nconsole.log(`top-level keys: ${Object.keys(result).length}`)\nconsole.log(`b keys: ${Object.keys(result.b).length}`)\n```\n\n### Patches\n\nFix released. The most robust protection is to limit the total number of merged keys per parse call. This should close all past and future edge cases with merge. The default 10K-key limit should be okay in most cases.",
"id": "GHSA-52cp-r559-cp3m",
"modified": "2026-07-20T21:19:10Z",
"published": "2026-07-20T21:19:09Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/nodeca/js-yaml/security/advisories/GHSA-52cp-r559-cp3m"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-59869"
},
{
"type": "WEB",
"url": "https://github.com/nodeca/js-yaml/commit/24f13e79ee1343a7e30bd6f6c9d9cdbf0ac9b2b7"
},
{
"type": "WEB",
"url": "https://github.com/nodeca/js-yaml/commit/59423c6f8cdc78742ac00e25a4dd39ef16b702e4"
},
{
"type": "PACKAGE",
"url": "https://github.com/nodeca/js-yaml"
},
{
"type": "WEB",
"url": "https://github.com/nodeca/js-yaml/releases/tag/3.15.0"
},
{
"type": "WEB",
"url": "https://github.com/nodeca/js-yaml/releases/tag/4.3.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": "js-yaml: YAML merge-key chains can force quadratic CPU consumption"
}
GHSA-52FW-44HJ-GQQP
Vulnerability from github – Published: 2025-09-10 21:30 – Updated: 2025-09-10 21:30An issue was discovered in rust-ffmpeg 0.3.0 (after comit 5ac0527) Integer overflow and invalid input vulnerability in the cached method allows an attacker to cause a denial of service or potentially execute arbitrary code. The vulnerability occurs when dimension parameters are zero or exceed i32::MAX, leading to an unchecked cast that violates the underlying C function's preconditions and triggers undefined behavior.
{
"affected": [],
"aliases": [
"CVE-2025-57614"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-02T16:15:40Z",
"severity": "HIGH"
},
"details": "An issue was discovered in rust-ffmpeg 0.3.0 (after comit 5ac0527) Integer overflow and invalid input vulnerability in the cached method allows an attacker to cause a denial of service or potentially execute arbitrary code. The vulnerability occurs when dimension parameters are zero or exceed i32::MAX, leading to an unchecked cast that violates the underlying C function\u0027s preconditions and triggers undefined behavior.",
"id": "GHSA-52fw-44hj-gqqp",
"modified": "2025-09-10T21:30:18Z",
"published": "2025-09-10T21:30:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-57614"
},
{
"type": "WEB",
"url": "https://github.com/meh/rust-ffmpeg/issues/192"
}
],
"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-52MW-589C-4MV9
Vulnerability from github – Published: 2022-05-24 19:04 – Updated: 2022-07-13 00:00Brocade Fabric OS prior to v9.0.1a and 8.2.3a and after v9.0.0 and 8.2.2d may observe high CPU load during security scanning, which could lead to a slower response to CLI commands and other operations.
{
"affected": [],
"aliases": [
"CVE-2020-15386"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-06-09T16:15:00Z",
"severity": "MODERATE"
},
"details": "Brocade Fabric OS prior to v9.0.1a and 8.2.3a and after v9.0.0 and 8.2.2d may observe high CPU load during security scanning, which could lead to a slower response to CLI commands and other operations.",
"id": "GHSA-52mw-589c-4mv9",
"modified": "2022-07-13T00:00:43Z",
"published": "2022-05-24T19:04:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-15386"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20210819-0002"
},
{
"type": "WEB",
"url": "https://www.broadcom.com/support/fibre-channel-networking/security-advisories/brocade-security-advisory-2021-1495"
}
],
"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"
}
]
}
GHSA-52VM-MXX8-F227
Vulnerability from github – Published: 2026-07-09 13:37 – Updated: 2026-07-09 13:37Impact
In Phantom <= 1.3.0, when PHANTOM_OUTPUT_DIR was unset (the default), the MCP tools accepted arbitrary absolute output paths with no confinement. Anything able to send tool calls (e.g. an AI agent driving the MCP interface) could write or overwrite arbitrary files the process user can write — including shell startup files (~/.zshrc) or a Reaper __startup.lua, which is effectively local code execution on a developer workstation.
Separately, the stem-separation and render paths decoded input audio with no size/duration cap (the analysis path was already guarded). A small, highly compressed FLAC/OGG could expand to multi-gigabyte PCM, causing memory-exhaustion DoS, and widened exposure to decoder bugs including libsndfile CVE-2026-37555.
Patches
Fixed in 1.3.1:
- File writes are always confined to PHANTOM_OUTPUT_DIR (default ~/.phantom/output); symlinks resolved and re-verified on the final path.
- Decode/duration/size guards mirrored onto the separation and render paths (plus ffmpeg -max_alloc/-t/-fs).
- Atomic O_CREAT|O_EXCL output creation in reference matching and symlink-TOCTOU hardening on confined input reads.
Workarounds
Set PHANTOM_OUTPUT_DIR (and optionally PHANTOM_AUDIO_DIR) to dedicated directories before starting the server.
Credit
Found during an internal security audit.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.3.0"
},
"package": {
"ecosystem": "PyPI",
"name": "phantom-audio"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.3.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-22",
"CWE-400",
"CWE-73"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-09T13:37:34Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Impact\n\nIn Phantom \u003c= 1.3.0, when `PHANTOM_OUTPUT_DIR` was unset (the default), the MCP tools accepted arbitrary absolute output paths with no confinement. Anything able to send tool calls (e.g. an AI agent driving the MCP interface) could **write or overwrite arbitrary files** the process user can write \u2014 including shell startup files (`~/.zshrc`) or a Reaper `__startup.lua`, which is effectively local code execution on a developer workstation.\n\nSeparately, the stem-separation and render paths decoded input audio with no size/duration cap (the analysis path was already guarded). A small, highly compressed FLAC/OGG could expand to multi-gigabyte PCM, causing memory-exhaustion DoS, and widened exposure to decoder bugs including libsndfile CVE-2026-37555.\n\n### Patches\nFixed in **1.3.1**:\n- File writes are always confined to `PHANTOM_OUTPUT_DIR` (default `~/.phantom/output`); symlinks resolved and re-verified on the final path.\n- Decode/duration/size guards mirrored onto the separation and render paths (plus ffmpeg `-max_alloc`/`-t`/`-fs`).\n- Atomic `O_CREAT|O_EXCL` output creation in reference matching and symlink-TOCTOU hardening on confined input reads.\n\n### Workarounds\nSet `PHANTOM_OUTPUT_DIR` (and optionally `PHANTOM_AUDIO_DIR`) to dedicated directories before starting the server.\n\n### Credit\nFound during an internal security audit.",
"id": "GHSA-52vm-mxx8-f227",
"modified": "2026-07-09T13:37:34Z",
"published": "2026-07-09T13:37:34Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/fadelabs/phantom/security/advisories/GHSA-52vm-mxx8-f227"
},
{
"type": "PACKAGE",
"url": "https://github.com/fadelabs/phantom"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Phantom: Arbitrary file write and decode-bomb DoS via unconfined MCP tool paths"
}
GHSA-52VV-3VF7-F7WH
Vulnerability from github – Published: 2022-02-19 00:01 – Updated: 2022-03-02 21:57A flaw was found in vscode-xml in versions prior to 0.19.0. Schema download could lead to blind SSRF or DoS via a large file.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.eclipse.lemminx:lemminx-parent"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.19.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-0671"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2022-02-23T15:02:26Z",
"nvd_published_at": "2022-02-18T18:15:00Z",
"severity": "CRITICAL"
},
"details": "A flaw was found in vscode-xml in versions prior to 0.19.0. Schema download could lead to blind SSRF or DoS via a large file.",
"id": "GHSA-52vv-3vf7-f7wh",
"modified": "2022-03-02T21:57:09Z",
"published": "2022-02-19T00:01:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-0671"
},
{
"type": "WEB",
"url": "https://github.com/eclipse/lemminx/issues/1169"
},
{
"type": "PACKAGE",
"url": "https://github.com/eclipse/lemminx"
},
{
"type": "WEB",
"url": "https://github.com/eclipse/lemminx/blob/master/CHANGELOG.md#0190-february-14-2022"
},
{
"type": "WEB",
"url": "https://github.com/redhat-developer/vscode-xml/blob/master/CHANGELOG.md#0190-february-14-2022"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Server-Side Request Forgery and Uncontrolled Resource Consumption in LemMinX"
}
GHSA-52WG-PQ5C-F82W
Vulnerability from github – Published: 2026-09-15 21:31 – Updated: 2026-09-15 21:31A vulnerability in HPE Networking EdgeConnect SD-WAN Gateways could allow an unauthenticated adjacent attacker to conduct a denial of service attack. Successful exploitation could allow an attacker to crash the system, preventing it from rebooting without manual intervention and disrupting network operations.
{
"affected": [],
"aliases": [
"CVE-2026-76696"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-15T20:17:53Z",
"severity": "MODERATE"
},
"details": "A vulnerability in HPE Networking EdgeConnect SD-WAN Gateways could allow an unauthenticated adjacent attacker to conduct a denial of service attack. Successful exploitation could allow an attacker to crash the system, preventing it from rebooting without manual intervention and disrupting network operations.",
"id": "GHSA-52wg-pq5c-f82w",
"modified": "2026-09-15T21:31:36Z",
"published": "2026-09-15T21:31:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-76696"
},
{
"type": "WEB",
"url": "https://support.hpe.com/hpesc/public/docDisplay?docId=hpesbnw05135en_us\u0026docLocale=en_US"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-535W-7CP7-47Q4
Vulnerability from github – Published: 2026-09-08 21:28 – Updated: 2026-09-08 21:28Impact
multer is vulnerable to a Denial of Service (DoS) via a crafted array index in multipart field names. The append-field dependency parses bracket notation in field names, and a large numeric index such as items[4294967294] forces allocation of a maximum-length sparse array. A following field with a non-numeric key on the same base then converts that array to an object by iterating its full length, which consumes CPU synchronously and leaves the process unable to handle other requests. A single HTTP request with a crafted multipart body is sufficient to exploit this, and it affects multer 1.x and 2.x.
Patches
Users should upgrade to 2.3.0 and configure limits.fieldArrayIndexLimit to the minimum array index their application requires.
Workarounds
None.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "multer"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.3.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-82333"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-08T21:28:43Z",
"nvd_published_at": "2026-08-28T22:16:57Z",
"severity": "HIGH"
},
"details": "### Impact\n\nmulter is vulnerable to a Denial of Service (DoS) via a crafted array index in multipart field names. The `append-field` dependency parses bracket notation in field names, and a large numeric index such as `items[4294967294]` forces allocation of a maximum-length sparse array. A following field with a non-numeric key on the same base then converts that array to an object by iterating its full length, which consumes CPU synchronously and leaves the process unable to handle other requests. A single HTTP request with a crafted multipart body is sufficient to exploit this, and it affects multer 1.x and 2.x.\n\n### Patches\n\nUsers should upgrade to `2.3.0` and configure `limits.fieldArrayIndexLimit` to the minimum array index their application requires.\n\n### Workarounds\n\nNone.",
"id": "GHSA-535w-7cp7-47q4",
"modified": "2026-09-08T21:28:43Z",
"published": "2026-09-08T21:28:43Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/expressjs/multer/security/advisories/GHSA-535w-7cp7-47q4"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-82333"
},
{
"type": "WEB",
"url": "https://github.com/expressjs/multer/pull/1438"
},
{
"type": "WEB",
"url": "https://github.com/expressjs/multer/commit/73c1759fa93b87366bc6dbd7abe1b80ddff7d27c"
},
{
"type": "WEB",
"url": "https://cna.openjsf.org/security-advisories.html"
},
{
"type": "PACKAGE",
"url": "https://github.com/expressjs/multer"
},
{
"type": "WEB",
"url": "https://github.com/expressjs/multer/releases/tag/v2.3.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": "multer vulnerable to Denial of Service via oversized array index in field names"
}
GHSA-5379-R78W-42H2
Vulnerability from github – Published: 2021-08-30 16:11 – Updated: 2024-02-10 00:55Impact
A malicious SAML payload can require transforms that consume significant system resources to process, thereby resulting in reduced or denied service. This would be an effective way to perform a denial-of-service attack.
Patches
This has been resolved in version 3.1.0. The resolution is to limit the number of allowable transforms to 2.
References
https://github.com/node-saml/passport-saml/pull/595
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "passport-saml"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.1.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-39171"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2021-08-27T23:25:28Z",
"nvd_published_at": "2021-08-27T22:15:00Z",
"severity": "MODERATE"
},
"details": "### Impact\nA malicious SAML payload can require transforms that consume significant system resources to process, thereby resulting in reduced or denied service. This would be an effective way to perform a denial-of-service attack.\n\n### Patches\nThis has been resolved in version 3.1.0. The resolution is to limit the number of allowable transforms to 2.\n\n### References\nhttps://github.com/node-saml/passport-saml/pull/595\n",
"id": "GHSA-5379-r78w-42h2",
"modified": "2024-02-10T00:55:45Z",
"published": "2021-08-30T16:11:57Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/node-saml/passport-saml/security/advisories/GHSA-5379-r78w-42h2"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-39171"
},
{
"type": "WEB",
"url": "https://github.com/node-saml/passport-saml/pull/595"
},
{
"type": "WEB",
"url": "https://github.com/node-saml/passport-saml/commit/f1e00b64c21a725f545e675cd810bbaa435a3972"
},
{
"type": "PACKAGE",
"url": "https://github.com/node-saml/passport-saml"
}
],
"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": "Unlimited transforms allowed for signed nodes"
}
GHSA-538C-55JV-C5G9
Vulnerability from github – Published: 2026-04-01 21:10 – Updated: 2026-04-01 21:10Summary
The ExternalDataInfo class in ONNX was using Python’s setattr() function to load metadata (like file paths or data lengths) directly from an ONNX model file. The problem? It didn’t check if the "keys" in the file were valid. Because it blindly trusted the file, an attacker could craft a malicious model that overwrites internal object properties.
Why its Dangerous
Instant Crash DoS: An attacker can set the length property to a massive number like 9 petabytes. When the system tries to load the model, it attempts to allocate all that RAM at once, causing the server to crash or freeze Out of Memory.
Access Bypass: By setting a negative offset -1, an attacker can trick the system into reading parts of a file it wasn't supposed to touch.
Object Corruption: Attackers can even inject "dunder" attributes like class to change the object's type entirely, which could lead to more complex exploits.
Fixed: https://github.com/onnx/onnx/pull/7751 object state corruption and DoS via ExternalDataInfo attribute injection
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.20.1"
},
"package": {
"ecosystem": "PyPI",
"name": "onnx"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.21.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-34445"
],
"database_specific": {
"cwe_ids": [
"CWE-20",
"CWE-400",
"CWE-915"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-01T21:10:52Z",
"nvd_published_at": "2026-04-01T18:16:30Z",
"severity": "HIGH"
},
"details": "### Summary\nThe ExternalDataInfo class in ONNX was using Python\u2019s setattr() function to load metadata (like file paths or data lengths) directly from an ONNX model file. The problem? It didn\u2019t check if the \"keys\" in the file were valid. Because it blindly trusted the file, an attacker could craft a malicious model that overwrites internal object properties.\n\n### Why its Dangerous\n**Instant Crash DoS**: An attacker can set the length property to a massive number like 9 petabytes. When the system tries to load the model, it attempts to allocate all that RAM at once, causing the server to crash or freeze Out of Memory.\n\n**Access Bypass**: By setting a negative offset -1, an attacker can trick the system into reading parts of a file it wasn\u0027t supposed to touch.\n\n**Object Corruption**: Attackers can even inject \"dunder\" attributes like __class__ to change the object\u0027s type entirely, which could lead to more complex exploits.\n\n**Fixed**: https://github.com/onnx/onnx/pull/7751 object state corruption and DoS via ExternalDataInfo attribute injection",
"id": "GHSA-538c-55jv-c5g9",
"modified": "2026-04-01T21:10:52Z",
"published": "2026-04-01T21:10:52Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/onnx/onnx/security/advisories/GHSA-538c-55jv-c5g9"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34445"
},
{
"type": "WEB",
"url": "https://github.com/onnx/onnx/pull/7751"
},
{
"type": "WEB",
"url": "https://github.com/onnx/onnx/commit/e30c6935d67cc3eca2fa284e37248e7c0036c46b"
},
{
"type": "PACKAGE",
"url": "https://github.com/onnx/onnx"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:H",
"type": "CVSS_V3"
}
],
"summary": "ONNX: Malicious ONNX models can crash servers by exploiting unprotected object settings."
}
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.