CWE-405
Allowed-with-ReviewAsymmetric Resource Consumption (Amplification)
Abstraction: Class · Status: Incomplete
The product does not properly control situations in which an adversary can cause the product to consume or produce excessive resources without requiring the adversary to invest equivalent work or otherwise prove authorization, i.e., the adversary's influence is "asymmetric."
116 vulnerabilities reference this CWE, most recent first.
GHSA-GQHX-WXJR-RPHX
Vulnerability from github – Published: 2023-06-26 21:30 – Updated: 2024-09-16 15:32An unauthenticated denial of service vulnerability exists in the SMM v1, SMM v2, and FPC management web server which can be triggered under crafted conditions. Rebooting SMM or FPC will restore access to the management web server.
{
"affected": [],
"aliases": [
"CVE-2023-2992"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-405"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-06-26T20:15:09Z",
"severity": "HIGH"
},
"details": "An unauthenticated \u00a0denial of service vulnerability exists in the SMM v1, SMM v2, and FPC management web server which can be triggered under crafted conditions. Rebooting SMM or FPC will restore access to the management web server.",
"id": "GHSA-gqhx-wxjr-rphx",
"modified": "2024-09-16T15:32:44Z",
"published": "2023-06-26T21:30:59Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-2992"
},
{
"type": "WEB",
"url": "https://support.lenovo.com/us/en/product_security/LEN-127357"
}
],
"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-J3G3-5QV5-52MJ
Vulnerability from github – Published: 2025-04-28 14:17 – Updated: 2025-11-21 22:18Summary
There is a possibility for denial of service by memory exhaustion when net-imap reads server responses. At any time while the client is connected, a malicious server can send can send a "literal" byte count, which is automatically read by the client's receiver thread. The response reader immediately allocates memory for the number of bytes indicated by the server response.
This should not be an issue when securely connecting to trusted IMAP servers that are well-behaved. It can affect insecure connections and buggy, untrusted, or compromised servers (for example, connecting to a user supplied hostname).
Details
The IMAP protocol allows "literal" strings to be sent in responses, prefixed with their size in curly braces (e.g. {1234567890}\r\n). When Net::IMAP receives a response containing a literal string, it calls IO#read with that size. When called with a size, IO#read immediately allocates memory to buffer the entire string before processing continues. The server does not need to send any more data. There is no limit on the size of literals that will be accepted.
Fix
Upgrade
Users should upgrade to net-imap 0.5.7 or later. A configurable max_response_size limit has been added to Net::IMAP's response reader. The max_response_size limit has also been backported to net-imap 0.2.5, 0.3.9, and 0.4.20.
To set a global value for max_response_size, users must upgrade to net-imap ~> 0.4.20, or > 0.5.7.
Configuration
To avoid backward compatibility issues for secure connections to trusted well-behaved servers, the default max_response_size for net-imap 0.5.7 is very high (512MiB), and the default max_response_size for net-imap ~> 0.4.20, ~> 0.3.9, and 0.2.5 is nil (unlimited).
When connecting to untrusted servers or using insecure connections, a much lower max_response_size should be used.
# Set the global max_response_size (only ~> v0.4.20, > 0.5.7)
Net::IMAP.config.max_response_size = 256 << 10 # 256 KiB
# Set when creating the connection
imap = Net::IMAP.new(hostname, ssl: true,
max_response_size: 16 << 10) # 16 KiB
# Set after creating the connection
imap.max_response_size = 256 << 20 # 256 KiB
# flush currently waiting read, to ensure the new setting is loaded
imap.noop
Please Note: max_response_size only limits the size per response. It does not prevent a flood of individual responses and it does not limit how many unhandled responses may be stored on the responses hash. Users are responsible for adding response handlers to prune excessive unhandled responses.
Compatibility with lower max_response_size
A lower max_response_size may cause a few commands which legitimately return very large responses to raise an exception and close the connection. The max_response_size could be temporarily set to a higher value, but paginated or limited versions of commands should be used whenever possible. For example, to fetch message bodies:
imap.max_response_size = 256 << 20 # 256 KiB
imap.noop # flush currently waiting read
# fetch a message in 252KiB chunks
size = imap.uid_fetch(uid, "RFC822.SIZE").first.rfc822_size
limit = 252 << 10
message = ((0..size) % limit).each_with_object("") {|offset, str|
str << imap.uid_fetch(uid, "BODY.PEEK[]<#{offset}.#{limit}>").first.message(offset:)
}
imap.max_response_size = 16 << 20 # 16 KiB
imap.noop # flush currently waiting read
References
- PR to introduce max_response_size: https://github.com/ruby/net-imap/pull/444
- Specific commit: 0ae8576c1 - lib/net/imap/response_reader.rb
- Backport to 0.4: https://github.com/ruby/net-imap/pull/445
- Backport to 0.3: https://github.com/ruby/net-imap/pull/446
- Backport to 0.2: https://github.com/ruby/net-imap/pull/447
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.5.6"
},
"package": {
"ecosystem": "RubyGems",
"name": "net-imap"
},
"ranges": [
{
"events": [
{
"introduced": "0.5.0"
},
{
"fixed": "0.5.7"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.4.19"
},
"package": {
"ecosystem": "RubyGems",
"name": "net-imap"
},
"ranges": [
{
"events": [
{
"introduced": "0.4.0"
},
{
"fixed": "0.4.20"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.3.8"
},
"package": {
"ecosystem": "RubyGems",
"name": "net-imap"
},
"ranges": [
{
"events": [
{
"introduced": "0.3.0"
},
{
"fixed": "0.3.9"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.2.4"
},
"package": {
"ecosystem": "RubyGems",
"name": "net-imap"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.2.5"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-43857"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-405",
"CWE-770",
"CWE-789"
],
"github_reviewed": true,
"github_reviewed_at": "2025-04-28T14:17:32Z",
"nvd_published_at": "2025-04-28T16:15:33Z",
"severity": "MODERATE"
},
"details": "### Summary\n\nThere is a possibility for denial of service by memory exhaustion when `net-imap` reads server responses. At any time while the client is connected, a malicious server can send can send a \"literal\" byte count, which is automatically read by the client\u0027s receiver thread. The response reader immediately allocates memory for the number of bytes indicated by the server response.\n\nThis should not be an issue when securely connecting to trusted IMAP servers that are well-behaved. It can affect insecure connections and buggy, untrusted, or compromised servers (for example, connecting to a user supplied hostname).\n\n### Details\n\nThe IMAP protocol allows \"literal\" strings to be sent in responses, prefixed with their size in curly braces (e.g. `{1234567890}\\r\\n`). When `Net::IMAP` receives a response containing a literal string, it calls `IO#read` with that size. When called with a size, `IO#read` immediately allocates memory to buffer the entire string before processing continues. The server does not need to send any more data. There is no limit on the size of literals that will be accepted.\n\n### Fix\n#### Upgrade\nUsers should upgrade to `net-imap` 0.5.7 or later. A configurable `max_response_size` limit has been added to `Net::IMAP`\u0027s response reader. The `max_response_size` limit has also been backported to `net-imap` 0.2.5, 0.3.9, and 0.4.20.\n\nTo set a global value for `max_response_size`, users must upgrade to `net-imap` ~\u003e 0.4.20, or \u003e 0.5.7.\n\n#### Configuration\n\nTo avoid backward compatibility issues for secure connections to trusted well-behaved servers, the default `max_response_size` for `net-imap` 0.5.7 is _very high_ (512MiB), and the default `max_response_size` for `net-imap` ~\u003e 0.4.20, ~\u003e 0.3.9, and 0.2.5 is `nil` (unlimited).\n\nWhen connecting to untrusted servers or using insecure connections, a much lower `max_response_size` should be used.\n```ruby\n# Set the global max_response_size (only ~\u003e v0.4.20, \u003e 0.5.7)\nNet::IMAP.config.max_response_size = 256 \u003c\u003c 10 # 256 KiB\n\n# Set when creating the connection\nimap = Net::IMAP.new(hostname, ssl: true,\n max_response_size: 16 \u003c\u003c 10) # 16 KiB\n\n# Set after creating the connection\nimap.max_response_size = 256 \u003c\u003c 20 # 256 KiB\n# flush currently waiting read, to ensure the new setting is loaded\nimap.noop\n```\n\n_**Please Note:**_ `max_response_size` only limits the size _per response_. It does not prevent a flood of individual responses and it does not limit how many unhandled responses may be stored on the responses hash. Users are responsible for adding response handlers to prune excessive unhandled responses.\n\n#### Compatibility with lower `max_response_size`\n\nA lower `max_response_size` may cause a few commands which legitimately return very large responses to raise an exception and close the connection. The `max_response_size` could be temporarily set to a higher value, but paginated or limited versions of commands should be used whenever possible. For example, to fetch message bodies:\n\n```ruby\nimap.max_response_size = 256 \u003c\u003c 20 # 256 KiB\nimap.noop # flush currently waiting read\n\n# fetch a message in 252KiB chunks\nsize = imap.uid_fetch(uid, \"RFC822.SIZE\").first.rfc822_size\nlimit = 252 \u003c\u003c 10\nmessage = ((0..size) % limit).each_with_object(\"\") {|offset, str|\n str \u003c\u003c imap.uid_fetch(uid, \"BODY.PEEK[]\u003c#{offset}.#{limit}\u003e\").first.message(offset:)\n}\n\nimap.max_response_size = 16 \u003c\u003c 20 # 16 KiB\nimap.noop # flush currently waiting read\n```\n\n### References\n\n* PR to introduce max_response_size: https://github.com/ruby/net-imap/pull/444\n * Specific commit: [0ae8576c1 - lib/net/imap/response_reader.rb](https://github.com/ruby/net-imap/pull/444/commits/0ae8576c1a90bcd9573f81bdad4b4b824642d105#diff-53721cb4d9c3fb86b95cc8476ca2df90968ad8c481645220c607034399151462)\n* Backport to 0.4: https://github.com/ruby/net-imap/pull/445\n* Backport to 0.3: https://github.com/ruby/net-imap/pull/446\n* Backport to 0.2: https://github.com/ruby/net-imap/pull/447",
"id": "GHSA-j3g3-5qv5-52mj",
"modified": "2025-11-21T22:18:03Z",
"published": "2025-04-28T14:17:32Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/ruby/net-imap/security/advisories/GHSA-j3g3-5qv5-52mj"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-43857"
},
{
"type": "WEB",
"url": "https://github.com/ruby/net-imap/pull/442"
},
{
"type": "WEB",
"url": "https://github.com/ruby/net-imap/pull/444"
},
{
"type": "WEB",
"url": "https://github.com/ruby/net-imap/pull/444/commits/0ae8576c1a90bcd9573f81bdad4b4b824642d105#diff-53721cb4d9c3fb86b95cc8476ca2df90968ad8c481645220c607034399151462"
},
{
"type": "WEB",
"url": "https://github.com/ruby/net-imap/pull/445"
},
{
"type": "WEB",
"url": "https://github.com/ruby/net-imap/pull/446"
},
{
"type": "WEB",
"url": "https://github.com/ruby/net-imap/pull/447"
},
{
"type": "PACKAGE",
"url": "https://github.com/ruby/net-imap"
},
{
"type": "WEB",
"url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/net-imap/CVE-2025-43857.yml"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "net-imap rubygem vulnerable to possible DoS by memory exhaustion"
}
GHSA-J6GV-XG9Q-8H4P
Vulnerability from github – Published: 2026-08-18 15:31 – Updated: 2026-09-23 15:30An authenticated user is able to cause disproportionate CPU load on the Frontend webserver by sending specifically crafted requests to the Frontend validate.api.exists action, leading to potential denial of service.
{
"affected": [],
"aliases": [
"CVE-2026-23934"
],
"database_specific": {
"cwe_ids": [
"CWE-405"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-18T13:17:21Z",
"severity": "MODERATE"
},
"details": "An authenticated user is able to cause disproportionate CPU load on the Frontend webserver by sending specifically crafted requests to the Frontend validate.api.exists action, leading to potential denial of service.",
"id": "GHSA-j6gv-xg9q-8h4p",
"modified": "2026-09-23T15:30:36Z",
"published": "2026-08-18T15:31:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23934"
},
{
"type": "WEB",
"url": "https://support.zabbix.com/browse/ZBX-28072"
}
],
"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"
},
{
"score": "CVSS:4.0/AV:A/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:L/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-JJ6M-R8JC-2GP7
Vulnerability from github – Published: 2021-06-23 18:03 – Updated: 2022-10-25 20:24Impact
All versions of Pterodactyl Wings preior to 1.4.4 are vulnerable to system resource exhaustion due to improper container process limits being defined. A malicious user can consume more resources than intended and cause downstream impacts to other clients on the same hardware, eventually causing the physical server to stop responding.
Patches
Users should upgrade to 1.4.4.
Workarounds
There is no non-code based workaround for impacted versions of the software. Users running customized versions of this software can manually set a PID limit for containers created.
For more information
If you have any questions or comments about this advisory:
* Contact us on Discord
* Email us at dane ät pterodactyl dot io
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/pterodactyl/wings"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.4.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-32699"
],
"database_specific": {
"cwe_ids": [
"CWE-405",
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2021-06-22T15:43:57Z",
"nvd_published_at": "2021-06-22T20:15:00Z",
"severity": "MODERATE"
},
"details": "### Impact\nAll versions of Pterodactyl Wings preior to `1.4.4` are vulnerable to system resource exhaustion due to improper container process limits being defined. A malicious user can consume more resources than intended and cause downstream impacts to other clients on the same hardware, eventually causing the physical server to stop responding.\n\n### Patches\nUsers should upgrade to `1.4.4`.\n\n### Workarounds\nThere is no non-code based workaround for impacted versions of the software. Users running customized versions of this software can manually set a PID limit for containers created.\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Contact us on [Discord](https://discord.gg/pterodactyl)\n* Email us at `dane \u00e4t pterodactyl dot io`",
"id": "GHSA-jj6m-r8jc-2gp7",
"modified": "2022-10-25T20:24:52Z",
"published": "2021-06-23T18:03:18Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/pterodactyl/wings/security/advisories/GHSA-jj6m-r8jc-2gp7"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-32699"
},
{
"type": "WEB",
"url": "https://github.com/pterodactyl/wings/commit/e0078eee0a71d61573a94c75e6efcad069d78de3"
},
{
"type": "PACKAGE",
"url": "https://github.com/pterodactyl/wings"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Asymmetric Resource Consumption (Amplification) in Docker containers created by Wings "
}
GHSA-JM46-725R-HH9V
Vulnerability from github – Published: 2024-03-19 18:31 – Updated: 2024-03-25 00:30An issue was found in the CPython zipfile module affecting versions 3.12.2, 3.11.8, 3.10.13, 3.9.18, and 3.8.18 and prior.
The zipfile module is vulnerable to “quoted-overlap” zip-bombs which exploit the zip format to create a zip-bomb with a high compression ratio. The fixed versions of CPython makes the zipfile module reject zip archives which overlap entries in the archive.
{
"affected": [],
"aliases": [
"CVE-2024-0450"
],
"database_specific": {
"cwe_ids": [
"CWE-405"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-03-19T16:15:09Z",
"severity": "MODERATE"
},
"details": "An issue was found in the CPython `zipfile` module affecting versions 3.12.2, 3.11.8, 3.10.13, 3.9.18, and 3.8.18 and prior.\n\nThe zipfile module is vulnerable to \u201cquoted-overlap\u201d zip-bombs which exploit the zip format to create a zip-bomb with a high compression ratio. The fixed versions of CPython makes the zipfile module reject zip archives which overlap entries in the archive.\n\n",
"id": "GHSA-jm46-725r-hh9v",
"modified": "2024-03-25T00:30:30Z",
"published": "2024-03-19T18:31:59Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-0450"
},
{
"type": "WEB",
"url": "https://github.com/python/cpython/issues/109858"
},
{
"type": "WEB",
"url": "https://github.com/python/cpython/commit/30fe5d853b56138dbec62432d370a1f99409fc85"
},
{
"type": "WEB",
"url": "https://github.com/python/cpython/commit/66363b9a7b9fe7c99eba3a185b74c5fdbf842eba"
},
{
"type": "WEB",
"url": "https://github.com/python/cpython/commit/a2c59992e9e8d35baba9695eb186ad6c6ff85c51"
},
{
"type": "WEB",
"url": "https://github.com/python/cpython/commit/a956e510f6336d5ae111ba429a61c3ade30a7549"
},
{
"type": "WEB",
"url": "https://github.com/python/cpython/commit/d05bac0b74153beb541b88b4fca33bf053990183"
},
{
"type": "WEB",
"url": "https://github.com/python/cpython/commit/fa181fcf2156f703347b03a3b1966ce47be8ab3b"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/03/msg00024.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/03/msg00025.html"
},
{
"type": "WEB",
"url": "https://mail.python.org/archives/list/security-announce@python.org/thread/XELNUX2L3IOHBTFU7RQHCY6OUVEWZ2FG"
},
{
"type": "WEB",
"url": "https://www.bamsoftware.com/hacks/zipbomb"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-JXH8-WPM5-QP9X
Vulnerability from github – Published: 2025-08-15 00:31 – Updated: 2025-08-15 00:31HCL Connections Docs may mishandle validation of certain uploaded documents leading to denial of service due to resource exhaustion.
{
"affected": [],
"aliases": [
"CVE-2025-31987"
],
"database_specific": {
"cwe_ids": [
"CWE-405"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-08-14T23:15:33Z",
"severity": "MODERATE"
},
"details": "HCL Connections Docs may mishandle validation of certain uploaded documents leading to denial of service due to resource exhaustion.",
"id": "GHSA-jxh8-wpm5-qp9x",
"modified": "2025-08-15T00:31:48Z",
"published": "2025-08-15T00:31:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-31987"
},
{
"type": "WEB",
"url": "https://support.hcl-software.com/csm?id=kb_article\u0026sysparm_article=KB0123272"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-MCFM-6JVW-6QF6
Vulnerability from github – Published: 2026-09-15 21:31 – Updated: 2026-09-15 21:31Concrete CMS 9 before 9.5.3 did not escape SQL LIKE wildcard characters in the keyword search filters used by the file manager, file folders, and page list, allowing an authenticated user with editor-level or higher privileges to submit a crafted search containing many single-character wildcards. Because the keyword input was placed into the LIKE clause without neutralizing its wildcard metacharacters, a short request could force the database to evaluate every row and perform a full-table scan, and repeated or wildcard-dense searches could sustain elevated database CPU and I/O, degrading responsiveness for other users on large installations. The Concrete CMS security team gave this vulnerability a CVSS v4.0 score of 2.1 with vector CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N. Thanks noivan for reporting.
{
"affected": [],
"aliases": [
"CVE-2026-68531"
],
"database_specific": {
"cwe_ids": [
"CWE-405"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-15T19:17:36Z",
"severity": "LOW"
},
"details": "Concrete CMS 9 before 9.5.3 did not escape SQL LIKE wildcard characters in the keyword search filters used by the file manager, file folders, and page list, allowing an authenticated user with editor-level or higher privileges to submit a crafted search containing many single-character wildcards. Because the keyword input was placed into the LIKE clause without neutralizing its wildcard metacharacters, a short request could force the database to evaluate every row and perform a full-table scan, and repeated or wildcard-dense searches could sustain elevated database CPU and I/O, degrading responsiveness for other users on large installations.\u00a0The Concrete CMS security team gave this vulnerability a CVSS v4.0 score of 2.1 with vector CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N. Thanks noivan for reporting.",
"id": "GHSA-mcfm-6jvw-6qf6",
"modified": "2026-09-15T21:31:19Z",
"published": "2026-09-15T21:31:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-68531"
},
{
"type": "WEB",
"url": "https://documentation.concretecms.org/developers/introduction/version-history/953-release-notes"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:N/VC:N/VI:N/VA:L/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-MH63-6H87-95CP
Vulnerability from github – Published: 2025-03-21 22:04 – Updated: 2025-04-10 13:02Summary
Function parse.ParseUnverified currently splits (via a call to strings.Split) its argument (which is untrusted data) on periods.
As a result, in the face of a malicious request whose Authorization header consists of Bearer followed by many period characters, a call to that function incurs allocations to the tune of O(n) bytes (where n stands for the length of the function's argument), with a constant factor of about 16. Relevant weakness: CWE-405: Asymmetric Resource Consumption (Amplification)
Details
Impact
Excessive memory allocation
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/golang-jwt/jwt/v5"
},
"ranges": [
{
"events": [
{
"introduced": "5.0.0-rc.1"
},
{
"fixed": "5.2.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/golang-jwt/jwt/v4"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.5.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/golang-jwt/jwt"
},
"ranges": [
{
"events": [
{
"introduced": "3.2.0"
},
{
"last_affected": "3.2.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-30204"
],
"database_specific": {
"cwe_ids": [
"CWE-405"
],
"github_reviewed": true,
"github_reviewed_at": "2025-03-21T22:04:00Z",
"nvd_published_at": "2025-03-21T22:15:26Z",
"severity": "HIGH"
},
"details": "### Summary\n\nFunction [`parse.ParseUnverified`](https://github.com/golang-jwt/jwt/blob/c035977d9e11c351f4c05dfeae193923cbab49ee/parser.go#L138-L139) currently splits (via a call to [strings.Split](https://pkg.go.dev/strings#Split)) its argument (which is untrusted data) on periods.\n\nAs a result, in the face of a malicious request whose _Authorization_ header consists of `Bearer ` followed by many period characters, a call to that function incurs allocations to the tune of O(n) bytes (where n stands for the length of the function\u0027s argument), with a constant factor of about 16. Relevant weakness: [CWE-405: Asymmetric Resource Consumption (Amplification)](https://cwe.mitre.org/data/definitions/405.html)\n\n### Details\n\nSee [`parse.ParseUnverified`](https://github.com/golang-jwt/jwt/blob/c035977d9e11c351f4c05dfeae193923cbab49ee/parser.go#L138-L139) \n\n### Impact\n\nExcessive memory allocation",
"id": "GHSA-mh63-6h87-95cp",
"modified": "2025-04-10T13:02:34Z",
"published": "2025-03-21T22:04:00Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/golang-jwt/jwt/security/advisories/GHSA-mh63-6h87-95cp"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-30204"
},
{
"type": "WEB",
"url": "https://github.com/golang-jwt/jwt/commit/0951d184286dece21f73c85673fd308786ffe9c3"
},
{
"type": "WEB",
"url": "https://github.com/golang-jwt/jwt/commit/bf316c48137a1212f8d0af9288cc9ce8e59f1afb"
},
{
"type": "PACKAGE",
"url": "https://github.com/golang-jwt/jwt"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20250404-0002"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "jwt-go allows excessive memory allocation during header parsing"
}
GHSA-MJ63-M3RC-8PPR
Vulnerability from github – Published: 2026-08-06 20:42 – Updated: 2026-08-06 20:42Impact
XmlRenderer pretty-prints XML by emitting depth-proportional indentation whitespace for every opening and closing tag. For a tree of depth n, the indentation alone sums to O(n²) bytes of output (and corresponding memory), reachable through MarkdownToXmlConverter — e.g. str_repeat('> ', $depth) . "x\n", a single line of nested blockquotes — or through a direct XmlRenderer::renderDocument() call on an attacker-influenced AST.
This affects applications that convert untrusted Markdown to XML, which is an opt-in output path. The parser's max_nesting_level bounds the depth of parser-created trees, but its default is high enough to reach damaging sizes, can be raised by the host application, and does not constrain custom or programmatically built ASTs handed straight to the renderer. The result is a memory / output-size amplification rather than a hard crash, which is why this issue is rated Medium rather than High. No confidentiality or integrity impact. XML rendering was introduced in 2.0.0 (first shipped in 2.0.0-beta1, June 2021) and has emitted depth-proportional indentation ever since, so all 2.x releases are affected (verified against 2.8.x, clean upstream 1902f60f). 1.x has no XML renderer and is not affected.
Workarounds
Applications converting untrusted Markdown to XML should:
- Lower
max_nesting_levelto a conservative value appropriate to expected content, so the parser refuses to build extremely deep trees. This is the most direct lever for parser-produced ASTs, but does not protect trees built programmatically and passed straight toXmlRenderer. - Cap input size before conversion, since the amplification is driven by input-proportional depth.
- Constrain XML consumers with memory / output-size limits (and streaming or size caps on any downstream XML parser or storage) so one request cannot allocate unbounded output.
- Prefer HTML rendering for untrusted content where XML is not strictly required — the HTML renderer does not emit depth-proportional indentation and is not subject to this amplification.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "league/commonmark"
},
"ranges": [
{
"events": [
{
"introduced": "2.0.0"
},
{
"fixed": "2.9.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-405"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-06T20:42:54Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Impact\n\n`XmlRenderer` pretty-prints XML by emitting depth-proportional indentation whitespace for **every** opening and closing tag. For a tree of depth n, the indentation alone sums to **O(n\u00b2)** bytes of output (and corresponding memory), reachable through `MarkdownToXmlConverter` \u2014 e.g. `str_repeat(\u0027\u003e \u0027, $depth) . \"x\\n\"`, a single line of nested blockquotes \u2014 or through a direct `XmlRenderer::renderDocument()` call on an attacker-influenced AST.\n\nThis affects applications that convert untrusted Markdown to XML, which is an **opt-in** output path. The parser\u0027s `max_nesting_level` bounds the depth of *parser-created* trees, but its default is high enough to reach damaging sizes, can be raised by the host application, and does not constrain custom or programmatically built ASTs handed straight to the renderer. The result is a memory / output-size amplification rather than a hard crash, which is why this issue is rated **Medium** rather than High. No confidentiality or integrity impact. XML rendering was introduced in 2.0.0 (first shipped in 2.0.0-beta1, June 2021) and has emitted depth-proportional indentation ever since, so all 2.x releases are affected (verified against 2.8.x, clean upstream `1902f60f`). 1.x has no XML renderer and is not affected.\n\n### Workarounds\n\nApplications converting untrusted Markdown to XML should:\n\n- **Lower `max_nesting_level`** to a conservative value appropriate to expected content, so the parser refuses to build extremely deep trees. This is the most direct lever for parser-produced ASTs, but does not protect trees built programmatically and passed straight to `XmlRenderer`.\n- **Cap input size before conversion**, since the amplification is driven by input-proportional depth.\n- **Constrain XML consumers** with memory / output-size limits (and streaming or size caps on any downstream XML parser or storage) so one request cannot allocate unbounded output.\n- **Prefer HTML rendering** for untrusted content where XML is not strictly required \u2014 the HTML renderer does not emit depth-proportional indentation and is not subject to this amplification.",
"id": "GHSA-mj63-m3rc-8ppr",
"modified": "2026-08-06T20:42:55Z",
"published": "2026-08-06T20:42:54Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/thephpleague/commonmark/security/advisories/GHSA-mj63-m3rc-8ppr"
},
{
"type": "WEB",
"url": "https://github.com/thephpleague/commonmark/commit/b5ac8c3947ca81844e85a09c7e0a5b4148bde2e1"
},
{
"type": "PACKAGE",
"url": "https://github.com/thephpleague/commonmark"
},
{
"type": "WEB",
"url": "https://github.com/thephpleague/commonmark/releases/tag/2.9.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
}
],
"summary": "league/commonmark: Denial of service via deeply nested XML output"
}
GHSA-PPFJ-6M85-XQ47
Vulnerability from github – Published: 2026-10-02 12:31 – Updated: 2026-10-02 12:31Zebra before 6.0.0 contains a denial of service vulnerability that allows unauthenticated peers to stall Tokio workers by submitting mempool transactions requiring expensive synchronous script verification. Attackers can send non-standard high-sigop P2SH transactions that reach CachedFfiTransaction::is_valid() before standardness checks, saturating the verifier buffer and rendering the node unresponsive.
{
"affected": [],
"aliases": [
"CVE-2026-104431"
],
"database_specific": {
"cwe_ids": [
"CWE-405"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-10-02T12:17:13Z",
"severity": "HIGH"
},
"details": "Zebra before 6.0.0 contains a denial of service vulnerability that allows unauthenticated peers to stall Tokio workers by submitting mempool transactions requiring expensive synchronous script verification. Attackers can send non-standard high-sigop P2SH transactions that reach CachedFfiTransaction::is_valid() before standardness checks, saturating the verifier buffer and rendering the node unresponsive.",
"id": "GHSA-ppfj-6m85-xq47",
"modified": "2026-10-02T12:31:15Z",
"published": "2026-10-02T12:31:15Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/ZcashFoundation/zebra/security/advisories/GHSA-84j3-rw4c-gqmj"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-104431"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/zebra-before-6.0.0-denial-of-service-via-synchronous-script-ffi-verification"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/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"
}
]
}
Mitigation
An application must make resources available to a client commensurate with the client's access level.
Mitigation
An application must, at all times, keep track of allocated resources and meter their usage appropriately.
Mitigation
Consider disabling resource-intensive algorithms on the server side, such as Diffie-Hellman key exchange.
No CAPEC attack patterns related to this CWE.