CWE-400
DiscouragedUncontrolled Resource Consumption
Abstraction: Class · Status: Draft
The product does not properly control the allocation and maintenance of a limited resource.
5424 vulnerabilities reference this CWE, most recent first.
GHSA-C77C-XC78-VG5V
Vulnerability from github – Published: 2022-05-24 16:50 – Updated: 2023-02-03 00:30DoS in EdgeMAX EdgeSwitch prior to 1.8.2 allow an Admin user to Crash the SSH CLI interface by using crafted commands.
{
"affected": [],
"aliases": [
"CVE-2019-5445"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-07-10T20:15:00Z",
"severity": "MODERATE"
},
"details": "DoS in EdgeMAX EdgeSwitch prior to 1.8.2 allow an Admin user to Crash the SSH CLI interface by using crafted commands.",
"id": "GHSA-c77c-xc78-vg5v",
"modified": "2023-02-03T00:30:19Z",
"published": "2022-05-24T16:50:00Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-5445"
},
{
"type": "WEB",
"url": "https://community.ui.com/releases/EdgeMAX-EdgeSwitch-Firmware-v1-8-2/824d58b1-6027-49cf-878d-2076c01948b7"
}
],
"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"
}
]
}
GHSA-C77W-XW87-XVP3
Vulnerability from github – Published: 2022-05-24 17:09 – Updated: 2022-05-24 17:09In Wireshark 3.2.0 to 3.2.1, 3.0.0 to 3.0.8, and 2.6.0 to 2.6.14, the LTE RRC dissector could leak memory. This was addressed in epan/dissectors/packet-lte-rrc.c by adjusting certain append operations.
{
"affected": [],
"aliases": [
"CVE-2020-9431"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-02-27T23:15:00Z",
"severity": "MODERATE"
},
"details": "In Wireshark 3.2.0 to 3.2.1, 3.0.0 to 3.0.8, and 2.6.0 to 2.6.14, the LTE RRC dissector could leak memory. This was addressed in epan/dissectors/packet-lte-rrc.c by adjusting certain append operations.",
"id": "GHSA-c77w-xw87-xvp3",
"modified": "2022-05-24T17:09:56Z",
"published": "2022-05-24T17:09:56Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-9431"
},
{
"type": "WEB",
"url": "https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16341"
},
{
"type": "WEB",
"url": "https://code.wireshark.org/review/gitweb?p=wireshark.git;a=commit;h=086003c9d616906e08bbeeab9c17b3aa4c6ff850"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2021/02/msg00008.html"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DZBICEY2HGSNQ3RPBLMDDYVAHGOGS4E2"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/JDVMBCADP73TBISYCS6ARKOSNNJOGXXZ"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/XN2GMGLT5XND7U34WX3O23WKUZ7JHMVN"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202007-13"
},
{
"type": "WEB",
"url": "https://www.wireshark.org/security/wnpa-sec-2020-03.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2020-03/msg00027.html"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-C7PM-4C7W-3R3R
Vulnerability from github – Published: 2022-05-06 00:00 – Updated: 2022-05-13 00:00On F5 BIG-IP 16.1.x versions prior to 16.1.2.2, when the stream profile is configured on a virtual server, undisclosed requests can cause an increase in memory resource utilization. Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated
{
"affected": [],
"aliases": [
"CVE-2022-28701"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-05-05T17:15:00Z",
"severity": "HIGH"
},
"details": "On F5 BIG-IP 16.1.x versions prior to 16.1.2.2, when the stream profile is configured on a virtual server, undisclosed requests can cause an increase in memory resource utilization. Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated",
"id": "GHSA-c7pm-4c7w-3r3r",
"modified": "2022-05-13T00:00:55Z",
"published": "2022-05-06T00:00:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-28701"
},
{
"type": "WEB",
"url": "https://support.f5.com/csp/article/K99123750"
}
],
"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-C7QV-Q95Q-8V27
Vulnerability from github – Published: 2024-10-19 06:30 – Updated: 2024-10-22 19:47Versions of the package http-proxy-middleware before 2.0.7, from 3.0.0 and before 3.0.3 are vulnerable to Denial of Service (DoS) due to an UnhandledPromiseRejection error thrown by micromatch. An attacker could kill the Node.js process and crash the server by making requests to certain paths.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "http-proxy-middleware"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.0.7"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "http-proxy-middleware"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.0"
},
{
"fixed": "3.0.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-21536"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2024-10-22T19:47:41Z",
"nvd_published_at": "2024-10-19T05:15:13Z",
"severity": "HIGH"
},
"details": "Versions of the package http-proxy-middleware before 2.0.7, from 3.0.0 and before 3.0.3 are vulnerable to Denial of Service (DoS) due to an UnhandledPromiseRejection error thrown by micromatch. An attacker could kill the Node.js process and crash the server by making requests to certain paths.",
"id": "GHSA-c7qv-q95q-8v27",
"modified": "2024-10-22T19:47:41Z",
"published": "2024-10-19T06:30:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-21536"
},
{
"type": "WEB",
"url": "https://github.com/chimurai/http-proxy-middleware/commit/0b4274e8cc9e9a2c5a06f35fbf456ccfcebc55a5"
},
{
"type": "WEB",
"url": "https://github.com/chimurai/http-proxy-middleware/commit/788b21e4aff38332d6319557d4a5b1b13b1f9a22"
},
{
"type": "WEB",
"url": "https://gist.github.com/mhassan1/28be67266d82a53708ed59ce5dc3c94a"
},
{
"type": "PACKAGE",
"url": "https://github.com/chimurai/http-proxy-middleware"
},
{
"type": "WEB",
"url": "https://security.snyk.io/vuln/SNYK-JS-HTTPPROXYMIDDLEWARE-8229906"
}
],
"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 http-proxy-middleware"
}
GHSA-C7VQ-CH45-23MM
Vulnerability from github – Published: 2022-05-01 06:48 – Updated: 2022-05-01 06:48Microsoft w3wp (aka w3wp.exe) does not properly handle when the AspCompat directive is not used when referencing COM components in ASP.NET, which allows remote attackers to cause a denial of service (resource consumption or crash) by repeatedly requesting each of several documents that refer to COM components, or are restricted documents located under the ASP.NET application path.
{
"affected": [],
"aliases": [
"CVE-2006-1364"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2006-03-23T11:06:00Z",
"severity": "HIGH"
},
"details": "Microsoft w3wp (aka w3wp.exe) does not properly handle when the AspCompat directive is not used when referencing COM components in ASP.NET, which allows remote attackers to cause a denial of service (resource consumption or crash) by repeatedly requesting each of several documents that refer to COM components, or are restricted documents located under the ASP.NET application path.",
"id": "GHSA-c7vq-ch45-23mm",
"modified": "2022-05-01T06:48:45Z",
"published": "2022-05-01T06:48:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2006-1364"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/25392"
},
{
"type": "WEB",
"url": "https://www.exploit-db.com/exploits/1601"
},
{
"type": "WEB",
"url": "http://hackingspirits.com/vuln-rnd/w3wp-remote-dos.zip"
},
{
"type": "WEB",
"url": "http://lists.grok.org.uk/pipermail/full-disclosure/2006-March/044291.html"
},
{
"type": "WEB",
"url": "http://lists.grok.org.uk/pipermail/full-disclosure/2006-March/044292.html"
},
{
"type": "WEB",
"url": "http://securitytracker.com/id?1015825"
},
{
"type": "WEB",
"url": "http://www.securiteam.com/windowsntfocus/5KP0O0KI0Y.html"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/archive/1/428622/100/0/threaded"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/17188"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-C7XP-Q6Q8-HG76
Vulnerability from github – Published: 2026-03-31 23:25 – Updated: 2026-04-06 16:39Product: Nuxt OG Image Version: 6.1.2 CWE-ID: CWE-404: Improper Resource Shutdown or Release Description: Failure to limit the length and width of the generated image results in a denial of service. Impact: Denial of service Exploitation condition: An external user Mitigation: Implement a limitation on the width and length of the generated image. Researcher: Dmitry Prokhorov (Positive Technologies)
Research
During the analysis of the nuxt-og-image package, which is shipped with the nuxt-seo package, a zero‑day vulnerability was discovered.
This research revealed that the image‑generation component by the URI: /_og/d/ (and, in older versions, /og-image/) contains a Denial of Service (DoS) vulnerability. The issue arises because there is no restriction on the width and height parameters of the generated image. The vulnerability was reproduced using the standard configuration and the default templates.
Listing 1. The content of the configuration file nuxt.config.ts
export default defineNuxtConfig({
modules: ['nuxt-og-image'],
devServer: {
host: 'web-test.local',
port: 3000
},
site: {
url: 'http://web-test.local:3000',
},
ogImage: {
fonts: [
'Inter:400',
'Inter:700'
],
}
})
Vulnerability reproduction
To demonstrate the proof‑of‑concept, a request should be sent with the increased width and height parameters. This will cause a delay and exhaust the server’s resources during image generation.
Listing 2. HTTP-request example
GET /_og/d/og.png?width=20000&height=20000 HTTP/1.1
Host: web-test.local:3000
Figure 1. HTTP-response: denial-of-service error
After sending a HTTP-request, the test server's memory was exhausted.
Figure 2. Video memory exhausted error
Credits
Researcher: Dmitry Prokhorov (Positive Technologies)
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "nuxt-og-image"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.2.5"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-34404"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-404"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-31T23:25:53Z",
"nvd_published_at": "2026-03-31T22:16:18Z",
"severity": "MODERATE"
},
"details": "**Product:** Nuxt OG Image \n**Version:** 6.1.2\n**CWE-ID:** [CWE-404](https://cwe.mitre.org/data/definitions/404.html): Improper Resource Shutdown or Release\n**Description:** Failure to limit the length and width of the generated image results in a denial of service.\n**Impact:** Denial of service\n**Exploitation condition:** An external user\n**Mitigation:** Implement a limitation on the width and length of the generated image.\n**Researcher:** Dmitry Prokhorov (Positive Technologies)\n\n## Research \nDuring the analysis of the nuxt-og-image package, which is shipped with the nuxt-seo package, a zero\u2011day vulnerability was discovered.\nThis research revealed that the image\u2011generation component by the URI: `/_og/d/` (and, in older versions, `/og-image/`) contains a Denial of Service (DoS) vulnerability. The issue arises because there is no restriction on the width and height parameters of the generated image. The vulnerability was reproduced using the standard configuration and the default templates.\n\n_Listing 1. The content of the configuration file `nuxt.config.ts`_ \n```\nexport default defineNuxtConfig({\n modules: [\u0027nuxt-og-image\u0027],\n devServer: {\n host: \u0027web-test.local\u0027,\n port: 3000\n },\n site: {\n url: \u0027http://web-test.local:3000\u0027,\n },\n ogImage: {\n fonts: [\n \u0027Inter:400\u0027, \n \u0027Inter:700\u0027\n ],\n }\n})\n```\n\n## Vulnerability reproduction\nTo demonstrate the proof\u2011of\u2011concept, a request should be sent with the increased `width`\u202fand\u202f`height`\u202fparameters. This will cause a delay and exhaust the server\u2019s resources during image generation.\n\n_Listing 2. HTTP-request example_\n```\nGET /_og/d/og.png?width=20000\u0026height=20000 HTTP/1.1\nHost: web-test.local:3000\n```\n\n_Figure 1. HTTP-response: denial-of-service error_\n\u003cimg width=\"974\" height=\"663\" alt=\"image\" src=\"https://github.com/user-attachments/assets/ff625249-2e0d-4a03-a734-3a77fd0cbb81\" /\u003e\n\nAfter sending a HTTP-request, the test server\u0027s memory was exhausted.\n\n_Figure 2. Video memory exhausted error_\n\u003cimg width=\"863\" height=\"1033\" alt=\"image\" src=\"https://github.com/user-attachments/assets/66b5919a-f039-468e-812e-1f709c468287\" /\u003e\n\n\n## Credits\nResearcher: Dmitry Prokhorov (Positive Technologies)",
"id": "GHSA-c7xp-q6q8-hg76",
"modified": "2026-04-06T16:39:48Z",
"published": "2026-03-31T23:25:53Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/nuxt-modules/og-image/security/advisories/GHSA-c7xp-q6q8-hg76"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34404"
},
{
"type": "PACKAGE",
"url": "https://github.com/nuxt-modules/og-image"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Nuxt OG Image is vulnerable to Denial of Service via unbounded image dimensions"
}
GHSA-C827-HFW6-QWVM
Vulnerability from github – Published: 2023-10-18 18:27 – Updated: 2024-08-27 14:22Summary
When using rustix::fs::Dir using the linux_raw backend, it's possible for the iterator to "get stuck" when an IO error is encountered. Combined with a memory over-allocation issue in rustix::fs::Dir::read_more, this can cause quick and unbounded memory explosion (gigabytes in a few seconds if used on a hot path) and eventually lead to an OOM crash of the application.
Details
Discovery
The symptoms were initially discovered in https://github.com/imsnif/bandwhich/issues/284. That post has lots of details of our investigation. See this post and the Discord thread for details.
Diagnosis
This issue is caused by the combination of two independent bugs:
- Stuck iterator
- The
rustix::fs::Diriterator can fail to halt after encountering an IO error, causing the caller to be stuck in an infinite loop. - Memory over-allocation
Dir::read_moreincorrectly grows the read buffer unconditionally each time it is called, regardless of necessity.
Since <Dir as Iterator>::next calls Dir::read, which in turn calls Dir::read_more, this means an IO error encountered during reading a directory can lead to rapid and unbounded growth of memory use.
PoC
fn main() -> Result<(), Box<dyn std::error::Error>> {
// create a directory, get a FD to it, then unlink the directory but keep the FD
std::fs::create_dir("tmp_dir")?;
let dir_fd = rustix::fs::openat(
rustix::fs::CWD,
rustix::cstr!("tmp_dir"),
rustix::fs::OFlags::RDONLY | rustix::fs::OFlags::CLOEXEC,
rustix::fs::Mode::empty(),
)?;
std::fs::remove_dir("tmp_dir")?;
// iterator gets stuck in infinite loop and memory explodes
rustix::fs::Dir::read_from(dir_fd)?
// the iterator keeps returning `Some(Err(_))`, but never halts by returning `None`
// therefore if the implementation ignores the error (or otherwise continues
// after seeing the error instead of breaking), the loop will not halt
.filter_map(|dirent_maybe_error| dirent_maybe_error.ok())
.for_each(|dirent| {
// your happy path
println!("{dirent:?}");
});
Ok(())
}
Impact
If a program tries to access a directory with its file descriptor after the file has been unlinked (or any other action that leaves the Dir iterator in the stuck state), and the implementation does not break after seeing an error, it can cause a memory explosion.
As an example, Linux's various virtual file systems (e.g. /proc, /sys) can contain directories that spontaneously pop in and out of existence. Attempting to iterate over them using rustix::fs::Dir directly or indirectly (e.g. with the procfs crate) can trigger this fault condition if the implementation decides to continue on errors.
An attacker knowledgeable about the implementation details of a vulnerable target can therefore try to trigger this fault condition via any one or a combination of several available APIs. If successful, the application host will quickly run out of memory, after which the application will likely be terminated by an OOM killer, leading to denial of service.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "rustix"
},
"ranges": [
{
"events": [
{
"introduced": "0.35.11"
},
{
"fixed": "0.35.15"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "crates.io",
"name": "rustix"
},
"ranges": [
{
"events": [
{
"introduced": "0.36.0"
},
{
"fixed": "0.36.16"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "crates.io",
"name": "rustix"
},
"ranges": [
{
"events": [
{
"introduced": "0.37.0"
},
{
"fixed": "0.37.25"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "crates.io",
"name": "rustix"
},
"ranges": [
{
"events": [
{
"introduced": "0.38.0"
},
{
"fixed": "0.38.19"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-43806"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2023-10-18T18:27:47Z",
"nvd_published_at": "2024-08-26T19:15:08Z",
"severity": "MODERATE"
},
"details": "### Summary\n\nWhen using `rustix::fs::Dir` using the `linux_raw` backend, it\u0027s possible for the iterator to \"get stuck\" when an IO error is encountered. Combined with a memory over-allocation issue in `rustix::fs::Dir::read_more`, this can cause quick and unbounded memory explosion (gigabytes in a few seconds if used on a hot path) and eventually lead to an OOM crash of the application.\n\n### Details\n\n#### Discovery\n\nThe symptoms were initially discovered in https://github.com/imsnif/bandwhich/issues/284. That post has lots of details of our investigation. See [this post](https://github.com/imsnif/bandwhich/issues/284#issuecomment-1754321993) and the [Discord thread](https://discord.com/channels/273534239310479360/1161137828395237556) for details.\n\n#### Diagnosis\n\nThis issue is caused by the combination of two independent bugs:\n\n1. Stuck iterator\n- The `rustix::fs::Dir` iterator can fail to halt after encountering an IO error, causing the caller to be stuck in an infinite loop.\n2. Memory over-allocation\n- `Dir::read_more` incorrectly grows the read buffer unconditionally each time it is called, regardless of necessity.\n\nSince `\u003cDir as Iterator\u003e::next` calls `Dir::read`, which in turn calls `Dir::read_more`, this means an IO error encountered during reading a directory can lead to rapid and unbounded growth of memory use.\n\n### PoC\n\n```rust\nfn main() -\u003e Result\u003c(), Box\u003cdyn std::error::Error\u003e\u003e {\n // create a directory, get a FD to it, then unlink the directory but keep the FD\n std::fs::create_dir(\"tmp_dir\")?;\n let dir_fd = rustix::fs::openat(\n rustix::fs::CWD,\n rustix::cstr!(\"tmp_dir\"),\n rustix::fs::OFlags::RDONLY | rustix::fs::OFlags::CLOEXEC,\n rustix::fs::Mode::empty(),\n )?;\n std::fs::remove_dir(\"tmp_dir\")?;\n\n // iterator gets stuck in infinite loop and memory explodes\n rustix::fs::Dir::read_from(dir_fd)?\n // the iterator keeps returning `Some(Err(_))`, but never halts by returning `None`\n // therefore if the implementation ignores the error (or otherwise continues\n // after seeing the error instead of breaking), the loop will not halt\n .filter_map(|dirent_maybe_error| dirent_maybe_error.ok())\n .for_each(|dirent| {\n // your happy path\n println!(\"{dirent:?}\");\n });\n\n Ok(())\n}\n```\n\n### Impact\n\nIf a program tries to access a directory with its file descriptor after the file has been unlinked (or any other action that leaves the `Dir` iterator in the stuck state), and the implementation does not break after seeing an error, it can cause a memory explosion.\n\nAs an example, Linux\u0027s various virtual file systems (e.g. `/proc`, `/sys`) can contain directories that spontaneously pop in and out of existence. Attempting to iterate over them using `rustix::fs::Dir` directly or indirectly (e.g. with the `procfs` crate) can trigger this fault condition if the implementation decides to continue on errors.\n\nAn attacker knowledgeable about the implementation details of a vulnerable target can therefore try to trigger this fault condition via any one or a combination of several available APIs. If successful, the application host will quickly run out of memory, after which the application will likely be terminated by an OOM killer, leading to denial of service.",
"id": "GHSA-c827-hfw6-qwvm",
"modified": "2024-08-27T14:22:19Z",
"published": "2023-10-18T18:27:47Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/bytecodealliance/rustix/security/advisories/GHSA-c827-hfw6-qwvm"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43806"
},
{
"type": "WEB",
"url": "https://github.com/imsnif/bandwhich/issues/284"
},
{
"type": "WEB",
"url": "https://github.com/imsnif/bandwhich/issues/284#issuecomment-1754321993"
},
{
"type": "WEB",
"url": "https://github.com/bytecodealliance/rustix/commit/31fd98ca723b93cc6101a3e29843ea5cf094e159"
},
{
"type": "WEB",
"url": "https://github.com/bytecodealliance/rustix/commit/87481a97f4364d12d5d6f30cdd025a0fc509b8ec"
},
{
"type": "WEB",
"url": "https://github.com/bytecodealliance/rustix/commit/df3c3a192cf144af0da8a57417fb4addbdc611f6"
},
{
"type": "WEB",
"url": "https://github.com/bytecodealliance/rustix/commit/eecece4a84fc58eafdc809cc2cedd374dee876a5"
},
{
"type": "WEB",
"url": "https://discord.com/channels/273534239310479360/1161137828395237556"
},
{
"type": "PACKAGE",
"url": "https://github.com/bytecodealliance/rustix"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "rustix\u0027s `rustix::fs::Dir` iterator with the `linux_raw` backend can cause memory explosion"
}
GHSA-C875-H985-HVRC
Vulnerability from github – Published: 2026-03-24 22:13 – Updated: 2026-07-06 13:03Summary
Scriban's LoopLimit only applies to script loop statements, not to expensive iteration performed inside operators and builtins. An attacker can submit a single expression such as {{ 1..1000000 | array.size }} and force large amounts of CPU work even when LoopLimit is set to a very small value.
Details
The relevant code path is:
ScriptBlockStatement.Evaluate()callscontext.CheckAbort()once per statement insrc/Scriban/Syntax/Statements/ScriptBlockStatement.cslines 41–46.LoopLimitenforcement is tied to script loop execution viaTemplateContext.StepLoop(), not to internal helper iteration.array.sizeinsrc/Scriban/Functions/ArrayFunctions.cslines 596–609 callslist.Cast<object>().Count()for non-collection enumerables.1..Ncreates aScriptRangefromScriptBinaryExpression.RangeInclude()insrc/Scriban/Syntax/Expressions/ScriptBinaryExpression.cslines 745–748.ScriptRangethen yields every element one by one without going throughStepLoop()insrc/Scriban/Runtime/ScriptRange.cs.
This means a single statement can perform arbitrarily large iteration without being stopped by LoopLimit.
There is also a related memory-amplification path in string * int:
ScriptBinaryExpression.CalculateToString()appends in a plainforloop insrc/Scriban/Syntax/Expressions/ScriptBinaryExpression.cslines 301–334.
Proof of Concept
Setup
mkdir scriban-poc3
cd scriban-poc3
dotnet new console --framework net8.0
dotnet add package Scriban --version 6.6.0
Program.cs
using Scriban;
var template = Template.Parse("{{ 1..1000000 | array.size }}");
var context = new TemplateContext
{
LoopLimit = 1
};
Console.WriteLine(template.Render(context));
Run
dotnet run
Actual Output
1000000
Expected Behavior
A safety limit of LoopLimit = 1 should prevent a template from performing one million iterations worth of work.
Optional Stronger Variant (Memory Amplification)
using Scriban;
var template = Template.Parse("{{ 'A' * 200000000 }}");
var context = new TemplateContext
{
LoopLimit = 1
};
template.Render(context);
This variant demonstrates that LoopLimit also does not constrain large internal allocation work.
Impact
This is an uncontrolled resource consumption issue. Any application that accepts attacker-controlled templates and relies on LoopLimit as part of its safe-runtime configuration can still be forced into heavy CPU or memory work by a single expression.
The issue impacts:
- Template-as-a-service systems
- CMS or email rendering systems that accept user templates
- Any multi-tenant use of Scriban with untrusted template content
{
"affected": [
{
"package": {
"ecosystem": "NuGet",
"name": "scriban"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "7.0.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Scriban.Signed"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "7.0.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-24T22:13:08Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "## Summary\n\nScriban\u0027s `LoopLimit` only applies to script loop statements, not to expensive iteration performed inside operators and builtins. An attacker can submit a single expression such as `{{ 1..1000000 | array.size }}` and force large amounts of CPU work even when `LoopLimit` is set to a very small value.\n\n## Details\n\nThe relevant code path is:\n\n- `ScriptBlockStatement.Evaluate()` calls `context.CheckAbort()` once per statement in `src/Scriban/Syntax/Statements/ScriptBlockStatement.cs` lines 41\u201346.\n- `LoopLimit` enforcement is tied to script loop execution via `TemplateContext.StepLoop()`, not to internal helper iteration.\n- `array.size` in `src/Scriban/Functions/ArrayFunctions.cs` lines 596\u2013609 calls `list.Cast\u003cobject\u003e().Count()` for non-collection enumerables.\n- `1..N` creates a `ScriptRange` from `ScriptBinaryExpression.RangeInclude()` in `src/Scriban/Syntax/Expressions/ScriptBinaryExpression.cs` lines 745\u2013748.\n- `ScriptRange` then yields every element one by one **without going through `StepLoop()`** in `src/Scriban/Runtime/ScriptRange.cs`.\n\nThis means a single statement can perform arbitrarily large iteration without being stopped by `LoopLimit`.\n\nThere is also a related memory-amplification path in `string * int`:\n\n- `ScriptBinaryExpression.CalculateToString()` appends in a plain `for` loop in `src/Scriban/Syntax/Expressions/ScriptBinaryExpression.cs` lines 301\u2013334.\n\n---\n\n## Proof of Concept\n\n### Setup\n\n```bash\nmkdir scriban-poc3\ncd scriban-poc3\ndotnet new console --framework net8.0\ndotnet add package Scriban --version 6.6.0\n```\n\n### `Program.cs`\n\n```csharp\nusing Scriban;\n\nvar template = Template.Parse(\"{{ 1..1000000 | array.size }}\");\n\nvar context = new TemplateContext\n{\n LoopLimit = 1\n};\n\nConsole.WriteLine(template.Render(context));\n```\n\n### Run\n\n```bash\ndotnet run\n```\n\n### Actual Output\n\n```\n1000000\n```\n\n### Expected Behavior\n\nA safety limit of `LoopLimit = 1` should prevent a template from performing one million iterations worth of work.\n\n### Optional Stronger Variant (Memory Amplification)\n\n```csharp\nusing Scriban;\n\nvar template = Template.Parse(\"{{ \u0027A\u0027 * 200000000 }}\");\nvar context = new TemplateContext\n{\n LoopLimit = 1\n};\n\ntemplate.Render(context);\n```\n\nThis variant demonstrates that `LoopLimit` also does not constrain large internal allocation work.\n\n---\n\n## Impact\n\nThis is an uncontrolled resource consumption issue. Any application that accepts attacker-controlled templates and relies on `LoopLimit` as part of its safe-runtime configuration can still be forced into heavy CPU or memory work by a single expression.\n\nThe issue impacts:\n\n- Template-as-a-service systems\n- CMS or email rendering systems that accept user templates\n- Any multi-tenant use of Scriban with untrusted template content",
"id": "GHSA-c875-h985-hvrc",
"modified": "2026-07-06T13:03:19Z",
"published": "2026-03-24T22:13:08Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/scriban/scriban/security/advisories/GHSA-c875-h985-hvrc"
},
{
"type": "PACKAGE",
"url": "https://github.com/scriban/scriban"
}
],
"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": "Scriban: Built-in operations bypass LoopLimit and delay cancellation, enabling Denial of Service"
}
GHSA-C8QM-3X9V-XJGR
Vulnerability from github – Published: 2022-05-13 01:38 – Updated: 2022-05-13 01:38A vulnerability was found in Openstack Glance. No limits are enforced within the Glance image service for both v1 and v2 /images API POST method for authenticated users, resulting in possible denial of service attacks through database table saturation.
{
"affected": [],
"aliases": [
"CVE-2016-8611"
],
"database_specific": {
"cwe_ids": [
"CWE-20",
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-07-31T20:29:00Z",
"severity": "MODERATE"
},
"details": "A vulnerability was found in Openstack Glance. No limits are enforced within the Glance image service for both v1 and v2 `/images` API POST method for authenticated users, resulting in possible denial of service attacks through database table saturation.",
"id": "GHSA-c8qm-3x9v-xjgr",
"modified": "2022-05-13T01:38:40Z",
"published": "2022-05-13T01:38:40Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2016-8611"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2016-8611"
},
{
"type": "WEB",
"url": "https://h20566.www2.hpe.com/hpsc/doc/public/display?docLocale=en_US\u0026docId=emr_na-c05333384"
},
{
"type": "WEB",
"url": "http://seclists.org/oss-sec/2016/q4/266"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/94378"
},
{
"type": "WEB",
"url": "http://www.securitytracker.com/id/1037312"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-C8V5-2JCX-X4J2
Vulnerability from github – Published: 2024-02-28 09:30 – Updated: 2024-08-07 18:30In the Linux kernel, the following vulnerability has been resolved:
net: Only allow init netns to set default tcp cong to a restricted algo
tcp_set_default_congestion_control() is netns-safe in that it writes to &net->ipv4.tcp_congestion_control, but it also sets ca->flags |= TCP_CONG_NON_RESTRICTED which is not namespaced. This has the unintended side-effect of changing the global net.ipv4.tcp_allowed_congestion_control sysctl, despite the fact that it is read-only: 97684f0970f6 ("net: Make tcp_allowed_congestion_control readonly in non-init netns")
Resolve this netns "leak" by only allowing the init netns to set the default algorithm to one that is restricted. This restriction could be removed if tcp_allowed_congestion_control were namespace-ified in the future.
This bug was uncovered with https://github.com/JonathonReinhart/linux-netns-sysctl-verify
{
"affected": [],
"aliases": [
"CVE-2021-47010"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-02-28T09:15:38Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: Only allow init netns to set default tcp cong to a restricted algo\n\ntcp_set_default_congestion_control() is netns-safe in that it writes\nto \u0026net-\u003eipv4.tcp_congestion_control, but it also sets\nca-\u003eflags |= TCP_CONG_NON_RESTRICTED which is not namespaced.\nThis has the unintended side-effect of changing the global\nnet.ipv4.tcp_allowed_congestion_control sysctl, despite the fact that it\nis read-only: 97684f0970f6 (\"net: Make tcp_allowed_congestion_control\nreadonly in non-init netns\")\n\nResolve this netns \"leak\" by only allowing the init netns to set the\ndefault algorithm to one that is restricted. This restriction could be\nremoved if tcp_allowed_congestion_control were namespace-ified in the\nfuture.\n\nThis bug was uncovered with\nhttps://github.com/JonathonReinhart/linux-netns-sysctl-verify",
"id": "GHSA-c8v5-2jcx-x4j2",
"modified": "2024-08-07T18:30:38Z",
"published": "2024-02-28T09:30:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47010"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6c1ea8bee75df8fe2184a50fcd0f70bf82986f42"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8d432592f30fcc34ef5a10aac4887b4897884493"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9884f745108f7d25b189bbcd6754e284fb29ab68"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/992de06308d9a9584d59b96d294ac676f924e437"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e7d7bedd507bb732e600403b7a96f9fe48d0ca31"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/efe1532a6e1a8e3c343d04fff510f0ed80328f9c"
}
],
"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"
}
]
}
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.