CWE-400
DiscouragedUncontrolled Resource Consumption
Abstraction: Class · Status: Draft
The product does not properly control the allocation and maintenance of a limited resource.
6465 vulnerabilities reference this CWE, most recent first.
GHSA-JHMP-MQWM-3GQ8
Vulnerability from github – Published: 2026-07-20 18:57 – Updated: 2026-07-20 18:57Summary
The _parseparam function in Tornado's httputil.py is used to parse specific HTTP header values, such as those in multipart/form-data. This function uses an inefficient algorithm that repeatedly calls string.count() within a nested loop while processing quoted semicolons (e.g., param=";").
As a result, if an attacker sends a request with a large number of maliciously crafted parameters in a Content-Disposition header, the server's CPU usage increases quadratically (O(n²)) during parsing. Due to Tornado's single event loop architecture, a single malicious request can cause the entire server to become unresponsive for an extended period, leading to a Denial of Service (DoS).
Severity: High
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "tornado"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.5.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-67726"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-20T18:57:54Z",
"nvd_published_at": "2025-12-12T07:15:44Z",
"severity": "HIGH"
},
"details": "## Summary\n\nThe `_parseparam` function in Tornado\u0027s `httputil.py` is used to parse specific HTTP header values, such as those in `multipart/form-data`. This function uses an inefficient algorithm that repeatedly calls `string.count()` within a nested loop while processing quoted semicolons (e.g., `param=\";\"`).\n\nAs a result, if an attacker sends a request with a large number of maliciously crafted parameters in a `Content-Disposition` header, the server\u0027s CPU usage increases quadratically (O(n\u00b2)) during parsing. Due to Tornado\u0027s single event loop architecture, a single malicious request can cause the entire server to become unresponsive for an extended period, leading to a Denial of Service (DoS).\n\n**Severity: High**",
"id": "GHSA-jhmp-mqwm-3gq8",
"modified": "2026-07-20T18:57:54Z",
"published": "2026-07-20T18:57:54Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/tornadoweb/tornado/security/advisories/GHSA-jhmp-mqwm-3gq8"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-67726"
},
{
"type": "WEB",
"url": "https://github.com/tornadoweb/tornado/commit/771472cfdaeebc0d89a9cc46e249f8891a6b29cd"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/tornado/PYSEC-2025-267.yaml"
},
{
"type": "PACKAGE",
"url": "https://github.com/tornadoweb/tornado"
},
{
"type": "WEB",
"url": "https://github.com/tornadoweb/tornado/releases/tag/v6.5.3"
}
],
"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": "Tornado: Quadratic DoS via Crafted Multipart Parameters"
}
GHSA-JHP8-JFXV-5GGJ
Vulnerability from github – Published: 2026-02-12 00:31 – Updated: 2026-06-30 03:35The issue was addressed with improved memory handling. This issue is fixed in macOS Tahoe 26.3, iOS 18.7.5 and iPadOS 18.7.5, visionOS 26.3, iOS 26.3 and iPadOS 26.3, Safari 26.3. A remote attacker may be able to cause a denial-of-service.
{
"affected": [],
"aliases": [
"CVE-2026-20652"
],
"database_specific": {
"cwe_ids": [
"CWE-120",
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-02-11T23:16:08Z",
"severity": "HIGH"
},
"details": "The issue was addressed with improved memory handling. This issue is fixed in macOS Tahoe 26.3, iOS 18.7.5 and iPadOS 18.7.5, visionOS 26.3, iOS 26.3 and iPadOS 26.3, Safari 26.3. A remote attacker may be able to cause a denial-of-service.",
"id": "GHSA-jhp8-jfxv-5ggj",
"modified": "2026-06-30T03:35:35Z",
"published": "2026-02-12T00:31:05Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-20652"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/126354"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/126353"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/126348"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/126347"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/126346"
},
{
"type": "WEB",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-20652.json"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2448793"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2026-20652"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:9692"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:22136"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:19535"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:19206"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:16695"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:16056"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:14659"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:13845"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:11814"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:11329"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:10702"
}
],
"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-JHQP-VF4W-RPWQ
Vulnerability from github – Published: 2022-06-21 22:51 – Updated: 2022-06-21 22:51Impact
All versions of Argo CD starting with v0.7.0 are vulnerable to an uncontrolled memory consumption bug, allowing an authorized malicious user to crash the repo-server service. The repo-server is a critical component of Argo CD, so crashing the repo-server effectively denies core Argo CD services (such as syncing Application updates).
To achieve denial of service, the attacker must be an authenticated Argo CD user authorized to deploy Applications from a repository which contains (or can be made to contain) a large file.
Patches
A patch for this vulnerability has been released in the following Argo CD versions:
- v2.4.1
- v2.3.5
- v2.2.10
- v2.1.16
The patch introduces a new reposerver.max.combined.directory.manifests.size config parameter, which you should tune before upgrading in production. It caps the maximum total file size of .yaml/.yml/.json files in directory-type (raw manifest) Applications. The default max is 10M per Application. This max is designed to keep any single app from consuming more than 3G of memory in the repo-server (manifests consume more space in memory than on disk). The 300x ratio assumes a maliciously-crafted manifest file. If you only want to protect against accidental excessive memory use, it is probably safe to use a smaller ratio.
If your organization uses directory-type Applications with very many manifests or very large manifests then check the size of those manifests and tune the config parameter before deploying this change to production. When testing, make sure to do a "hard refresh" in either the CLI or UI to test your directory-type App. That will make sure you're using the new max logic instead of relying on cached manifest responses from Redis.
Workarounds
There is no workaround besides upgrading.
To mitigate the issue, carefully limit 1) who can configure repos (determined by RBAC), 2) which repos are allowed (determined by Project limitations), and 3) who has push access to those repos (determined by your SCM provider configuration).
Credits
Disclosed by ADA Logics in a security audit of the Argo project sponsored by CNCF and facilitated by OSTIF. Thanks to Adam Korczynski and David Korczynski for their work on the audit.
For more information
- Open an issue in the Argo CD issue tracker or discussions
- Join us on Slack in channel #argo-cd
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.8.7"
},
"package": {
"ecosystem": "Go",
"name": "github.com/argoproj/argo-cd"
},
"ranges": [
{
"events": [
{
"introduced": "0.7.0"
},
{
"fixed": "2.1.16"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/argoproj/argo-cd/v2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.1.16"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/argoproj/argo-cd/v2"
},
"ranges": [
{
"events": [
{
"introduced": "2.2.0"
},
{
"fixed": "2.2.10"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/argoproj/argo-cd/v2"
},
"ranges": [
{
"events": [
{
"introduced": "2.3.0"
},
{
"fixed": "2.3.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/argoproj/argo-cd/v2"
},
"ranges": [
{
"events": [
{
"introduced": "2.4.0"
},
{
"fixed": "2.4.1"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"2.4.0"
]
}
],
"aliases": [
"CVE-2022-31016"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2022-06-21T22:51:05Z",
"nvd_published_at": "2022-06-25T08:15:00Z",
"severity": "MODERATE"
},
"details": "### Impact\n\nAll versions of Argo CD starting with v0.7.0 are vulnerable to an uncontrolled memory consumption bug, allowing an authorized malicious user to crash the [repo-server](https://argo-cd.readthedocs.io/en/stable/operator-manual/architecture/#repository-server) service. The repo-server is a critical component of Argo CD, so crashing the repo-server effectively denies core Argo CD services (such as syncing Application updates).\n\nTo achieve denial of service, the attacker must be an authenticated Argo CD user authorized to deploy Applications from a repository which contains (or can be made to contain) a large file. \n\n### Patches\n\nA patch for this vulnerability has been released in the following Argo CD versions:\n\n* v2.4.1\n* v2.3.5\n* v2.2.10\n* v2.1.16\n\n**The patch introduces a new `reposerver.max.combined.directory.manifests.size` config parameter, which you should tune before upgrading in production.** It caps the maximum total file size of .yaml/.yml/.json files in directory-type (raw manifest) Applications. The default max is `10M` per Application. This max is designed to keep any single app from consuming more than 3G of memory in the repo-server (manifests consume more space in memory than on disk). The 300x ratio assumes a maliciously-crafted manifest file. If you only want to protect against accidental excessive memory use, it is probably safe to use a smaller ratio.\n\nIf your organization uses directory-type Applications with very many manifests or very large manifests then **check the size of those manifests and tune the config parameter before deploying this change to production**. When testing, make sure to do a \"hard refresh\" in either the CLI or UI to test your directory-type App. That will make sure you\u0027re using the new max logic instead of relying on cached manifest responses from Redis.\n\n### Workarounds\n\nThere is no workaround besides upgrading.\n\nTo mitigate the issue, carefully limit 1) who can configure repos (determined by [RBAC](https://argo-cd.readthedocs.io/en/stable/getting_started/)), 2) which repos are allowed (determined by [Project](https://argo-cd.readthedocs.io/en/stable/user-guide/projects/) limitations), and 3) who has push access to those repos (determined by your SCM provider configuration).\n\n### Credits\n\nDisclosed by ADA Logics in a security audit of the Argo project sponsored by CNCF and facilitated by OSTIF. Thanks to Adam Korczynski and David Korczynski for their work on the audit.\n\n### For more information\n\n* Open an issue in [the Argo CD issue tracker](https://github.com/argoproj/argo-cd/issues) or [discussions](https://github.com/argoproj/argo-cd/discussions)\n* Join us on [Slack](https://argoproj.github.io/community/join-slack) in channel #argo-cd\n",
"id": "GHSA-jhqp-vf4w-rpwq",
"modified": "2022-06-21T22:51:05Z",
"published": "2022-06-21T22:51:05Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/argoproj/argo-cd/security/advisories/GHSA-jhqp-vf4w-rpwq"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-31016"
},
{
"type": "PACKAGE",
"url": "https://github.com/argoproj/argo-cd"
}
],
"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": "DoS through large manifest files in Argo CD"
}
GHSA-JHV8-V22G-62JM
Vulnerability from github – Published: 2025-11-11 18:30 – Updated: 2025-11-11 18:30Uncontrolled resource consumption for some Gaudi software before version 1.21.0 within Ring 3: User Applications may allow a denial of service. System software adversary with an authenticated user combined with a low complexity attack may enable denial of service. This result may potentially occur via local access when attack requirements are not present without special internal knowledge and requires no user interaction. The potential vulnerability may impact the confidentiality (none), integrity (none) and availability (high) of the vulnerable system, resulting in subsequent system confidentiality (none), integrity (none) and availability (none) impacts.
{
"affected": [],
"aliases": [
"CVE-2025-27249"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-11-11T17:15:45Z",
"severity": "MODERATE"
},
"details": "Uncontrolled resource consumption for some Gaudi software before version 1.21.0 within Ring 3: User Applications may allow a denial of service. System software adversary with an authenticated user combined with a low complexity attack may enable denial of service. This result may potentially occur via local access when attack requirements are not present without special internal knowledge and requires no user interaction. The potential vulnerability may impact the confidentiality (none), integrity (none) and availability (high) of the vulnerable system, resulting in subsequent system confidentiality (none), integrity (none) and availability (none) impacts.",
"id": "GHSA-jhv8-v22g-62jm",
"modified": "2025-11-11T18:30:18Z",
"published": "2025-11-11T18:30:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-27249"
},
{
"type": "WEB",
"url": "https://intel.com/content/www/us/en/security-center/advisory/intel-sa-01374.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/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-JHWX-MHWW-RGC3
Vulnerability from github – Published: 2024-03-29 19:04 – Updated: 2024-03-29 19:04Impact
All versions of ArgoCD starting from v2.4 have a bug where the ArgoCD repo-server component is vulnerable to a Denial-of-Service attack vector. Specifically, it's possible to crash the repo server component through an out of memory error by pointing it to a malicious Helm registry. The loadRepoIndex() function in the ArgoCD's helm package, does not limit the size nor time while fetching the data. It fetches it and creates a byte slice from the retrieved data in one go. If the registry is implemented to push data continuously, the repo server will keep allocating memory until it runs out of it.
Patches
A patch for this vulnerability has been released in the following Argo CD versions:
v2.10.5 v2.9.10 v2.8.14
For more information
If you have any questions or comments about this advisory:
Open an issue in the Argo CD issue tracker or discussions Join us on Slack in channel #argo-cd
Credits
This vulnerability was found & reported by Jakub Ciolek
The Argo team would like to thank these contributors for their responsible disclosure and constructive communications during the resolve of this issue
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/argoproj/argo-cd/v2"
},
"ranges": [
{
"events": [
{
"introduced": "2.4.0"
},
{
"fixed": "2.8.14"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/argoproj/argo-cd/v2"
},
"ranges": [
{
"events": [
{
"introduced": "2.9.0"
},
{
"fixed": "2.9.10"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/argoproj/argo-cd/v2"
},
"ranges": [
{
"events": [
{
"introduced": "2.10.0"
},
{
"fixed": "2.10.5"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-29893"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2024-03-29T19:04:27Z",
"nvd_published_at": "2024-03-29T15:15:12Z",
"severity": "MODERATE"
},
"details": "### Impact\nAll versions of ArgoCD starting from v2.4 have a bug where the ArgoCD repo-server component is vulnerable to a Denial-of-Service attack vector. Specifically, it\u0027s possible to crash the repo server component through an out of memory error by pointing it to a malicious Helm registry.\nThe loadRepoIndex() function in the ArgoCD\u0027s helm package, does not limit the size nor time while fetching the data. It fetches it and creates a byte slice from the retrieved data in one go. If the registry is implemented to push data continuously, the repo server will keep allocating memory until it runs out of it.\n\n### Patches\nA patch for this vulnerability has been released in the following Argo CD versions:\n\nv2.10.5\nv2.9.10\nv2.8.14\n\n### For more information\nIf you have any questions or comments about this advisory:\n\nOpen an issue in [the Argo CD issue tracker](https://github.com/argoproj/argo-cd/issues) or [discussions](https://github.com/argoproj/argo-cd/discussions)\nJoin us on [Slack](https://argoproj.github.io/community/join-slack) in channel #argo-cd\n\n\n### Credits\nThis vulnerability was found \u0026 reported by Jakub Ciolek\n\nThe Argo team would like to thank these contributors for their responsible disclosure and constructive communications during the resolve of this issue",
"id": "GHSA-jhwx-mhww-rgc3",
"modified": "2024-03-29T19:04:27Z",
"published": "2024-03-29T19:04:27Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/argoproj/argo-cd/security/advisories/GHSA-jhwx-mhww-rgc3"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-29893"
},
{
"type": "WEB",
"url": "https://github.com/argoproj/argo-cd/commit/14f681e3ee7c38731943b98f92277e88a3db109d"
},
{
"type": "WEB",
"url": "https://github.com/argoproj/argo-cd/commit/36b8a12a38f8d92d55bffc81deed44389bf6eb59"
},
{
"type": "WEB",
"url": "https://github.com/argoproj/argo-cd/commit/3e5a878f6e30d935fa149723ea2a2e93748fcddd"
},
{
"type": "PACKAGE",
"url": "https://github.com/argoproj/argo-cd"
}
],
"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": "ArgoCD\u0027s repo server has Uncontrolled Resource Consumption vulnerability"
}
GHSA-JJ2R-MJ3G-9H98
Vulnerability from github – Published: 2022-05-13 01:33 – Updated: 2022-05-13 01:33Yokogawa STARDOM Controllers FCJ,FCN-100, FCN-RTU, FCN-500, All versions R4.10 and prior, The controller application fails to prevent memory exhaustion by unauthorized requests. This could allow an attacker to cause the controller to become unstable.
{
"affected": [],
"aliases": [
"CVE-2018-17898"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-10-12T14:29:00Z",
"severity": "HIGH"
},
"details": "Yokogawa STARDOM Controllers FCJ,FCN-100, FCN-RTU, FCN-500, All versions R4.10 and prior, The controller application fails to prevent memory exhaustion by unauthorized requests. This could allow an attacker to cause the controller to become unstable.",
"id": "GHSA-jj2r-mj3g-9h98",
"modified": "2022-05-13T01:33:47Z",
"published": "2022-05-13T01:33:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-17898"
},
{
"type": "WEB",
"url": "https://ics-cert.us-cert.gov/advisories/ICSA-18-151-03"
},
{
"type": "WEB",
"url": "https://web-material3.yokogawa.com/YSAR-18-0007-E.pdf"
}
],
"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-JJ32-297R-PCV8
Vulnerability from github – Published: 2022-05-14 03:22 – Updated: 2025-04-20 03:32NTP before 4.2.8p6 and 4.3.0 before 4.3.90 allows a remote attackers to cause a denial of service (stack exhaustion) via an ntpdc relist command, which triggers recursive traversal of the restriction list.
{
"affected": [],
"aliases": [
"CVE-2015-7978"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-01-30T21:59:00Z",
"severity": "HIGH"
},
"details": "NTP before 4.2.8p6 and 4.3.0 before 4.3.90 allows a remote attackers to cause a denial of service (stack exhaustion) via an ntpdc relist command, which triggers recursive traversal of the restriction list.",
"id": "GHSA-jj32-297r-pcv8",
"modified": "2025-04-20T03:32:02Z",
"published": "2022-05-14T03:22:58Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2015-7978"
},
{
"type": "WEB",
"url": "https://bto.bluecoat.com/security-advisory/sa113"
},
{
"type": "WEB",
"url": "https://security.FreeBSD.org/advisories/FreeBSD-SA-16:09.ntp.asc"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/201607-15"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20171031-0001"
},
{
"type": "WEB",
"url": "https://www.kb.cert.org/vuls/id/718152"
},
{
"type": "WEB",
"url": "http://lists.fedoraproject.org/pipermail/package-announce/2016-February/177507.html"
},
{
"type": "WEB",
"url": "http://lists.fedoraproject.org/pipermail/package-announce/2016-January/176434.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2016-04/msg00059.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2016-04/msg00060.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2016-05/msg00020.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2016-05/msg00038.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2016-05/msg00048.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2016-07/msg00026.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2016-08/msg00042.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-updates/2016-05/msg00114.html"
},
{
"type": "WEB",
"url": "http://rhn.redhat.com/errata/RHSA-2016-0780.html"
},
{
"type": "WEB",
"url": "http://rhn.redhat.com/errata/RHSA-2016-2583.html"
},
{
"type": "WEB",
"url": "http://support.ntp.org/bin/view/Main/SecurityNotice#April_2016_NTP_4_2_8p7_Security"
},
{
"type": "WEB",
"url": "http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20160127-ntpd"
},
{
"type": "WEB",
"url": "http://www.debian.org/security/2016/dsa-3629"
},
{
"type": "WEB",
"url": "http://www.oracle.com/technetwork/topics/security/linuxbulletinapr2016-2952096.html"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/81962"
},
{
"type": "WEB",
"url": "http://www.securitytracker.com/id/1034782"
},
{
"type": "WEB",
"url": "http://www.ubuntu.com/usn/USN-3096-1"
}
],
"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-JJ4C-53QH-FP5V
Vulnerability from github – Published: 2022-05-24 17:35 – Updated: 2022-05-24 17:35CAPI (Cloud Controller) versions prior to 1.101.0 are vulnerable to a denial-of-service attack in which an unauthenticated malicious attacker can send specially-crafted YAML files to certain endpoints, causing the YAML parser to consume excessive CPU and RAM.
{
"affected": [],
"aliases": [
"CVE-2020-5423"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-12-02T02:15:00Z",
"severity": "HIGH"
},
"details": "CAPI (Cloud Controller) versions prior to 1.101.0 are vulnerable to a denial-of-service attack in which an unauthenticated malicious attacker can send specially-crafted YAML files to certain endpoints, causing the YAML parser to consume excessive CPU and RAM.",
"id": "GHSA-jj4c-53qh-fp5v",
"modified": "2022-05-24T17:35:20Z",
"published": "2022-05-24T17:35:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-5423"
},
{
"type": "WEB",
"url": "https://www.cloudfoundry.org/blog/cve-2020-5423"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-JJ6H-H6XP-PHMH
Vulnerability from github – Published: 2026-08-14 15:32 – Updated: 2026-08-14 15:32A vulnerability was found in TRENDnet TEW-816DRM GURNC4.OT182B-C-TN-R1B028-US.EN. This impacts an unknown function of the file /etc/bftpd.conf of the component bftpd. The manipulation of the argument USERLIMIT_GLOBAL results in allocation of resources. It is possible to launch the attack remotely. This vulnerability only affects products that are no longer supported by the maintainer.
{
"affected": [],
"aliases": [
"CVE-2026-19830"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-14T14:16:51Z",
"severity": "MODERATE"
},
"details": "A vulnerability was found in TRENDnet TEW-816DRM GURNC4.OT182B-C-TN-R1B028-US.EN. This impacts an unknown function of the file /etc/bftpd.conf of the component bftpd. The manipulation of the argument USERLIMIT_GLOBAL results in allocation of resources. It is possible to launch the attack remotely. This vulnerability only affects products that are no longer supported by the maintainer.",
"id": "GHSA-jj6h-h6xp-phmh",
"modified": "2026-08-14T15:32:50Z",
"published": "2026-08-14T15:32:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-19830"
},
{
"type": "WEB",
"url": "https://app.notion.com/p/TEW-816DRM-GURNC4-OT182B-C-TN-R1B028-US-EN-2018-05-16-38b1f5ba989080759a1ee701542f1935?source=copy_link"
},
{
"type": "WEB",
"url": "https://vuldb.com/cve/CVE-2026-19830"
},
{
"type": "WEB",
"url": "https://vuldb.com/submit/870259"
},
{
"type": "WEB",
"url": "https://vuldb.com/vuln/389971"
},
{
"type": "WEB",
"url": "https://vuldb.com/vuln/389971/cti"
}
],
"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"
},
{
"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/E:P/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-JJF9-W5VJ-R6VP
Vulnerability from github – Published: 2026-04-01 00:14 – Updated: 2026-04-06 17:24Summary
Ash.Type.Module.cast_input/2 unconditionally creates a new Erlang atom via Module.concat([value]) for any user-supplied binary string that starts with "Elixir.", before verifying whether the referenced module exists. Because Erlang atoms are never garbage-collected and the BEAM atom table has a hard default limit of approximately 1,048,576 entries, an attacker who can submit values to any resource attribute or argument of type :module can exhaust this table and crash the entire BEAM VM, taking down the application.
Details
Setup: A resource with a :module-typed attribute exposed to user input, which is a supported and documented usage of the Ash.Type.Module built-in type:
defmodule MyApp.Widget do
use Ash.Resource, domain: MyApp, data_layer: AshPostgres.DataLayer
attributes do
uuid_primary_key :id
attribute :handler_module, :module, public?: true
end
actions do
defaults [:read, :destroy]
create :create do
accept [:handler_module]
end
end
end
Vulnerable code in lib/ash/type/module.ex, lines 105-113:
def cast_input("Elixir." <> _ = value, _) do
module = Module.concat([value]) # <-- Creates new atom unconditionally
if Code.ensure_loaded?(module) do
{:ok, module}
else
:error # <-- Returns error but atom is already created
end
end
Exploit: Submit repeated Ash.create requests (e.g., via a JSON API endpoint) with unique "Elixir.*" strings:
# Attacker-controlled loop (or HTTP requests to an API endpoint)
for i <- 1..1_100_000 do
Ash.Changeset.for_create(MyApp.Widget, :create, %{handler_module: "Elixir.Attack#{i}"})
|> Ash.create()
# Each iteration: Module.concat(["Elixir.Attack#{i}"]) creates a new atom
# cast_input returns :error but the atom :"Elixir.Attack#{i}" persists
end
# After ~1,048,576 unique strings: BEAM crashes with system_limit
Contrast: The non-"Elixir." path in the same function correctly uses String.to_existing_atom/1, which is safe because it only looks up atoms that already exist:
def cast_input(value, _) when is_binary(value) do
atom = String.to_existing_atom(value) # safe - raises if atom doesn't exist
...
end
Additional occurrence: cast_stored/2 at line 141 contains the identical pattern, which is reachable when reading :module-typed values from the database if an attacker can write arbitrary "Elixir.*" strings to the relevant database column.
Impact
An attacker who can submit requests to any API endpoint backed by an Ash resource with a :module-typed attribute or argument can crash the entire BEAM VM process. This is a complete denial of service: all resources served by that VM instance (not just the targeted resource) become unavailable. The crash cannot be prevented once the atom table is full, and recovery requires a full process restart.
Fix direction: Replace Module.concat([value]) with String.to_existing_atom(value) wrapped in a rescue ArgumentError block (as already done in the non-"Elixir." branch), or validate that the atom already exists before calling Module.concat by first attempting String.to_existing_atom and only falling back to Module.concat on success.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.21.3"
},
"package": {
"ecosystem": "Hex",
"name": "ash"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.22.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-34593"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-01T00:14:40Z",
"nvd_published_at": "2026-04-02T18:16:31Z",
"severity": "HIGH"
},
"details": "## Summary\n\n`Ash.Type.Module.cast_input/2` unconditionally creates a new Erlang atom via `Module.concat([value])` for any user-supplied binary string that starts with `\"Elixir.\"`, before verifying whether the referenced module exists. Because Erlang atoms are never garbage-collected and the BEAM atom table has a hard default limit of approximately 1,048,576 entries, an attacker who can submit values to any resource attribute or argument of type `:module` can exhaust this table and crash the entire BEAM VM, taking down the application.\n\n## Details\n\n**Setup**: A resource with a `:module`-typed attribute exposed to user input, which is a supported and documented usage of the `Ash.Type.Module` built-in type:\n\n```elixir\ndefmodule MyApp.Widget do\n use Ash.Resource, domain: MyApp, data_layer: AshPostgres.DataLayer\n\n attributes do\n uuid_primary_key :id\n attribute :handler_module, :module, public?: true\n end\n\n actions do\n defaults [:read, :destroy]\n create :create do\n accept [:handler_module]\n end\n end\nend\n```\n\n**Vulnerable code** in `lib/ash/type/module.ex`, lines 105-113:\n\n```elixir\ndef cast_input(\"Elixir.\" \u003c\u003e _ = value, _) do\n module = Module.concat([value]) # \u003c-- Creates new atom unconditionally\n if Code.ensure_loaded?(module) do\n {:ok, module}\n else\n :error # \u003c-- Returns error but atom is already created\n end\nend\n```\n\n**Exploit**: Submit repeated `Ash.create` requests (e.g., via a JSON API endpoint) with unique `\"Elixir.*\"` strings:\n\n```elixir\n# Attacker-controlled loop (or HTTP requests to an API endpoint)\nfor i \u003c- 1..1_100_000 do\n Ash.Changeset.for_create(MyApp.Widget, :create, %{handler_module: \"Elixir.Attack#{i}\"})\n |\u003e Ash.create()\n # Each iteration: Module.concat([\"Elixir.Attack#{i}\"]) creates a new atom\n # cast_input returns :error but the atom :\"Elixir.Attack#{i}\" persists\nend\n# After ~1,048,576 unique strings: BEAM crashes with system_limit\n```\n\n**Contrast**: The non-`\"Elixir.\"` path in the same function correctly uses `String.to_existing_atom/1`, which is safe because it only looks up atoms that already exist:\n\n```elixir\ndef cast_input(value, _) when is_binary(value) do\n atom = String.to_existing_atom(value) # safe - raises if atom doesn\u0027t exist\n ...\nend\n```\n\n**Additional occurrence**: `cast_stored/2` at line 141 contains the identical pattern, which is reachable when reading `:module`-typed values from the database if an attacker can write arbitrary `\"Elixir.*\"` strings to the relevant database column.\n\n## Impact\n\nAn attacker who can submit requests to any API endpoint backed by an Ash resource with a `:module`-typed attribute or argument can crash the entire BEAM VM process. This is a complete denial of service: all resources served by that VM instance (not just the targeted resource) become unavailable. The crash cannot be prevented once the atom table is full, and recovery requires a full process restart.\n\n**Fix direction**: Replace `Module.concat([value])` with `String.to_existing_atom(value)` wrapped in a `rescue ArgumentError` block (as already done in the non-`\"Elixir.\"` branch), or validate that the atom already exists before calling `Module.concat` by first attempting `String.to_existing_atom` and only falling back to `Module.concat` on success.",
"id": "GHSA-jjf9-w5vj-r6vp",
"modified": "2026-04-06T17:24:41Z",
"published": "2026-04-01T00:14:40Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/ash-project/ash/security/advisories/GHSA-jjf9-w5vj-r6vp"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34593"
},
{
"type": "WEB",
"url": "https://github.com/ash-project/ash/commit/7031103da38cd1366cec8c96d6bcdc9b989aa3c2"
},
{
"type": "PACKAGE",
"url": "https://github.com/ash-project/ash"
},
{
"type": "WEB",
"url": "https://github.com/ash-project/ash/releases/tag/v3.22.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Ash.Type.Module.cast_input/2 atom exhaustion via unchecked Module.concat allows BEAM VM crash"
}
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.