CWE-789
AllowedMemory Allocation with Excessive Size Value
Abstraction: Variant · Status: Draft
The product allocates memory based on an untrusted, large size value, but it does not ensure that the size is within expected limits, allowing arbitrary amounts of memory to be allocated.
320 vulnerabilities reference this CWE, most recent first.
GHSA-HRR4-3WGR-68X3
Vulnerability from github – Published: 2026-02-04 00:14 – Updated: 2026-02-05 00:37Summary
Authenticated users can crash the Navidrome server by supplying an excessively large size parameter to /rest/getCoverArt or to a shared-image URL (/share/img/<token>). When processing such requests, the server attempts to create an extremely large resized image, causing uncontrolled memory growth. This triggers the Linux OOM killer, terminates the Navidrome process, and results in a full service outage.
If the system has sufficient memory and survives the allocation, Navidrome then writes these extremely large resized images into its cache directory, allowing an attacker to rapidly exhaust server disk space as well.
Details
Both /rest/getCoverArt and /share/img/<token> accept a size parameter that is passed directly into the image processing routine without any upper bound validation. When a very large integer is provided, Navidrome attempts to generate a resized image of that size. This leads to excessive memory allocation inside the image resizing path.
In the /rest/getCoverArt handler, the value is read as:
size := p.IntOr("size", 0)
imgReader, lastUpdate, err := api.artwork.GetOrPlaceholder(ctx, id, size, square)
Because no limit is enforced, the image subsystem receives the supplied value as-is. When the requested size is extremely large, the process consumes large amounts of RAM until it is killed by the kernel's OOM killer. If the system has enough available memory to complete the resize operation, the resulting oversized image is then written to Navidrome's cache directory, which can quickly fill the server's disk.
The same behavior is reachable through /share/img/<token> as long as the attacker possesses a valid sharing token.
PoC
- Authenticate normally to obtain access to
/rest/getCoverArtor a valid sharing link containing a/share/img/<token>URL. - Send a regular request with a small size value, for example:
/rest/getCoverArt?...&size=300&square=true
- Replace the
sizeparameter with a very large number, such as:
/rest/getCoverArt?...&size=300000&square=true
- The server rapidly allocates memory while attempting to create an oversized image. This leads to the Navidrome process being terminated by the OOM killer.
- The same behavior can be reproduced with a valid shared-image link:
/share/img/<token>?size=300000&square=true
If the system does not run out of memory, the oversized resized image is written to the cache directory, causing disk usage to grow quickly.
Impact
Supplying an excessively large size parameter to /rest/getCoverArt or /share/img/<token> allows any authenticated user to trigger a Denial of Service condition. During image resizing, the server attempts to allocate extremely large amounts of memory, which can cause not only Navidrome itself to be terminated by the OOM killer, but in some configurations may also destabilize or crash the entire host system.
On systems with sufficient memory, the oversized resized images are written to Navidrome's cache directory instead, allowing an attacker to rapidly consume all available disk space. This leads to a second form of Denial of Service, where the host becomes unable to write logs, operate dependent services, or perform basic system tasks due to storage exhaustion.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/navidrome/navidrome"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.60.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-25579"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-770",
"CWE-789"
],
"github_reviewed": true,
"github_reviewed_at": "2026-02-04T00:14:02Z",
"nvd_published_at": "2026-02-04T22:16:01Z",
"severity": "CRITICAL"
},
"details": "### Summary\nAuthenticated users can crash the Navidrome server by supplying an excessively large `size` parameter to `/rest/getCoverArt` or to a shared-image URL (`/share/img/\u003ctoken\u003e`). When processing such requests, the server attempts to create an extremely large resized image, causing uncontrolled memory growth. This triggers the Linux OOM killer, terminates the Navidrome process, and results in a full service outage.\n\nIf the system has sufficient memory and survives the allocation, Navidrome then writes these extremely large resized images into its cache directory, allowing an attacker to rapidly exhaust server disk space as well.\n\n### Details\nBoth `/rest/getCoverArt` and `/share/img/\u003ctoken\u003e` accept a `size` parameter that is passed directly into the image processing routine without any upper bound validation. When a very large integer is provided, Navidrome attempts to generate a resized image of that size. This leads to excessive memory allocation inside the image resizing path.\n\nIn the `/rest/getCoverArt` handler, the value is read as:\n\n```go\nsize := p.IntOr(\"size\", 0)\nimgReader, lastUpdate, err := api.artwork.GetOrPlaceholder(ctx, id, size, square)\n```\n\nBecause no limit is enforced, the image subsystem receives the supplied value as-is. When the requested size is extremely large, the process consumes large amounts of RAM until it is killed by the kernel\u0027s OOM killer. If the system has enough available memory to complete the resize operation, the resulting oversized image is then written to Navidrome\u0027s cache directory, which can quickly fill the server\u0027s disk.\n\nThe same behavior is reachable through `/share/img/\u003ctoken\u003e` as long as the attacker possesses a valid sharing token.\n\n### PoC\n1. Authenticate normally to obtain access to `/rest/getCoverArt` or a valid sharing link containing a `/share/img/\u003ctoken\u003e` URL.\n2. Send a regular request with a small size value, for example:\n\n```\n/rest/getCoverArt?...\u0026size=300\u0026square=true\n```\n\n3. Replace the `size` parameter with a very large number, such as:\n\n```\n/rest/getCoverArt?...\u0026size=300000\u0026square=true\n```\n\n4. The server rapidly allocates memory while attempting to create an oversized image. This leads to the Navidrome process being terminated by the OOM killer.\n5. The same behavior can be reproduced with a valid shared-image link:\n\n```\n/share/img/\u003ctoken\u003e?size=300000\u0026square=true\n```\n\nIf the system does not run out of memory, the oversized resized image is written to the cache directory, causing disk usage to grow quickly.\n\n### Impact\nSupplying an excessively large `size` parameter to `/rest/getCoverArt` or `/share/img/\u003ctoken\u003e` allows any authenticated user to trigger a Denial of Service condition. During image resizing, the server attempts to allocate extremely large amounts of memory, which can cause not only Navidrome itself to be terminated by the OOM killer, but in some configurations may also destabilize or crash the entire host system.\n\nOn systems with sufficient memory, the oversized resized images are written to Navidrome\u0027s cache directory instead, allowing an attacker to rapidly consume all available disk space. This leads to a second form of Denial of Service, where the host becomes unable to write logs, operate dependent services, or perform basic system tasks due to storage exhaustion.",
"id": "GHSA-hrr4-3wgr-68x3",
"modified": "2026-02-05T00:37:07Z",
"published": "2026-02-04T00:14:02Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/navidrome/navidrome/security/advisories/GHSA-hrr4-3wgr-68x3"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-25579"
},
{
"type": "PACKAGE",
"url": "https://github.com/navidrome/navidrome"
},
{
"type": "WEB",
"url": "https://github.com/navidrome/navidrome/releases/tag/v0.60.0"
}
],
"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:H/SC:N/SI:N/SA:H",
"type": "CVSS_V4"
}
],
"summary": "Navidrome affected by Denial of Service and disk exhaustion via oversized `size` parameter in `/rest/getCoverArt` and `/share/img/\u003ctoken\u003e` endpoints"
}
GHSA-J2F3-WQ62-6Q46
Vulnerability from github – Published: 2026-01-15 18:10 – Updated: 2026-01-15 22:33Summary
The experimental form remote function uses a binary data format containing a representation of submitted form data. A specially-crafted payload can cause the server to allocate a large amount of memory, causing DoS via memory exhaustion.
Details
When a form is submitted to a remote function endpoint, the SvelteKit client encodes the data using a custom format, and POSTs it to the endpoint as a request with an application/x-sveltekit-formdata content type.
The first few bytes of the request body encode the length of the data. SvelteKit will attempt to read the request body up until the specified offset, but if the body is not yet available then an array buffer of that size will be created eagerly to accommodate it as it arrives.
An attacker can force this code path by sending a small payload that specifies a large data length, then stalling the connection. The resulting array buffer will be held in memory, potentially causing memory exhaustion.
Impact
- Vulnerability type: Availability / memory exhaustion (memory amplification).
- Who is impacted: SvelteKit apps with
experimental.remoteFunctionsenabled, and that expose a reachable Remote Form endpoint. - Attack: an unauthenticated attacker can repeatedly open connections, send only the 8-byte header/prefix (with large data_length), and stall the body to hold large allocations, exhausting memory.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.49.4"
},
"package": {
"ecosystem": "npm",
"name": "@sveltejs/kit"
},
"ranges": [
{
"events": [
{
"introduced": "2.49.0"
},
{
"fixed": "2.49.5"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-22803"
],
"database_specific": {
"cwe_ids": [
"CWE-789"
],
"github_reviewed": true,
"github_reviewed_at": "2026-01-15T18:10:52Z",
"nvd_published_at": "2026-01-15T19:16:06Z",
"severity": "HIGH"
},
"details": "## Summary\n\nThe experimental `form` remote function uses a binary data format containing a representation of submitted form data. A specially-crafted payload can cause the server to allocate a large amount of memory, causing DoS via memory exhaustion.\n\n## Details\n\nWhen a form is submitted to a remote function endpoint, the SvelteKit client encodes the data using a custom format, and POSTs it to the endpoint as a request with an `application/x-sveltekit-formdata` content type.\n\nThe first few bytes of the request body encode the length of the data. SvelteKit will attempt to read the request body up until the specified offset, but if the body is not yet available then an array buffer of that size will be created eagerly to accommodate it as it arrives.\n\nAn attacker can force this code path by sending a small payload that specifies a large data length, then stalling the connection. The resulting array buffer will be held in memory, potentially causing memory exhaustion.\n\n## Impact\n\n- Vulnerability type: Availability / memory exhaustion (memory amplification).\n- Who is impacted: SvelteKit apps with `experimental.remoteFunctions` enabled, and that expose a reachable Remote Form endpoint.\n- Attack: an unauthenticated attacker can repeatedly open connections, send only the 8-byte header/prefix (with large data_length), and stall the body to hold large allocations, exhausting memory.",
"id": "GHSA-j2f3-wq62-6q46",
"modified": "2026-01-15T22:33:44Z",
"published": "2026-01-15T18:10:52Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/sveltejs/kit/security/advisories/GHSA-j2f3-wq62-6q46"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-22803"
},
{
"type": "WEB",
"url": "https://github.com/sveltejs/kit/commit/8ed8155215b9a74012fecffb942ad9a793b274e5"
},
{
"type": "PACKAGE",
"url": "https://github.com/sveltejs/kit"
},
{
"type": "WEB",
"url": "https://github.com/sveltejs/kit/releases/tag/%40sveltejs%2Fkit%402.49.5"
},
{
"type": "WEB",
"url": "https://github.com/sveltejs/kit/releases/tag/@sveltejs%2Fadapter-node@5.5.1"
}
],
"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": "@sveltejs/kit has memory amplification DoS vulnerability in Remote Functions binary form deserializer (application/x-sveltekit-formdata)"
}
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-J7XF-PGW2-75MR
Vulnerability from github – Published: 2023-10-04 18:30 – Updated: 2024-08-29 15:30RTPS dissector memory leak in Wireshark 4.0.0 to 4.0.8 and 3.6.0 to 3.6.16 allows denial of service via packet injection or crafted capture file
{
"affected": [],
"aliases": [
"CVE-2023-5371"
],
"database_specific": {
"cwe_ids": [
"CWE-770",
"CWE-789"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-10-04T17:15:10Z",
"severity": "MODERATE"
},
"details": "RTPS dissector memory leak in Wireshark 4.0.0 to 4.0.8 and 3.6.0 to 3.6.16 allows denial of service via packet injection or crafted capture file",
"id": "GHSA-j7xf-pgw2-75mr",
"modified": "2024-08-29T15:30:30Z",
"published": "2023-10-04T18:30:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-5371"
},
{
"type": "WEB",
"url": "https://gitlab.com/wireshark/wireshark/-/issues/19322"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/34DBP5P2RHQ7XUABPANYYMOGV5KS6VEP"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/MADSCHKZSCKQ5NLIX3UMOIJD2JZ65L4V"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202402-09"
},
{
"type": "WEB",
"url": "https://www.wireshark.org/security/wnpa-sec-2023-27.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-J9G2-35F7-X39P
Vulnerability from github – Published: 2022-05-24 17:39 – Updated: 2022-05-24 17:39A vulnerability in the logging subsystem of Cisco Data Center Network Manager (DCNM) could allow an authenticated, local attacker to view sensitive information in a system log file that should be restricted. The vulnerability exists because sensitive information is not properly masked before it is written to system log files. An attacker could exploit this vulnerability by authenticating to an affected device and inspecting a specific system log file. A successful exploit could allow the attacker to view sensitive information in the system log file. To exploit this vulnerability, the attacker would need to have valid user credentials.
{
"affected": [],
"aliases": [
"CVE-2021-1283"
],
"database_specific": {
"cwe_ids": [
"CWE-789"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-01-20T20:15:00Z",
"severity": "MODERATE"
},
"details": "\n A vulnerability in the logging subsystem of Cisco Data Center Network Manager (DCNM) could allow an authenticated, local attacker to view sensitive information in a system log file that should be restricted.\n The vulnerability exists because sensitive information is not properly masked before it is written to system log files. An attacker could exploit this vulnerability by authenticating to an affected device and inspecting a specific system log file. A successful exploit could allow the attacker to view sensitive information in the system log file. To exploit this vulnerability, the attacker would need to have valid user credentials.\n ",
"id": "GHSA-j9g2-35f7-x39p",
"modified": "2022-05-24T17:39:40Z",
"published": "2022-05-24T17:39:40Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-1283"
},
{
"type": "WEB",
"url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-dcnm-info-disc-QCSJB6YG"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-M3PX-Q5GJ-J9X7
Vulnerability from github – Published: 2026-06-11 00:32 – Updated: 2026-06-11 00:32kafka-python prior to 2.3.2 contains a denial-of-service vulnerability in the protocol parser that allows a malicious broker or machine-in-the-middle attacker to exhaust memory or hang connections by sending a crafted 4-byte frame length value without bounds validation. Attackers can send a specially crafted frame length through the receive_bytes() function to trigger either a multi-gigabyte memory allocation or an uncaught ValueError that leaves the connection in a broken state, causing requests to hang and consumers to stop heartbeating until restart.
{
"affected": [],
"aliases": [
"CVE-2026-10142"
],
"database_specific": {
"cwe_ids": [
"CWE-789"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-10T22:16:55Z",
"severity": "HIGH"
},
"details": "kafka-python prior to 2.3.2 contains a denial-of-service vulnerability in the protocol parser that allows a malicious broker or machine-in-the-middle attacker to exhaust memory or hang connections by sending a crafted 4-byte frame length value without bounds validation. Attackers can send a specially crafted frame length through the receive_bytes() function to trigger either a multi-gigabyte memory allocation or an uncaught ValueError that leaves the connection in a broken state, causing requests to hang and consumers to stop heartbeating until restart.",
"id": "GHSA-m3px-q5gj-j9x7",
"modified": "2026-06-11T00:32:04Z",
"published": "2026-06-11T00:32:04Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-10142"
},
{
"type": "WEB",
"url": "https://github.com/dpkp/kafka-python/pull/3019"
},
{
"type": "WEB",
"url": "https://github.com/dpkp/kafka-python/pull/3026"
},
{
"type": "WEB",
"url": "https://github.com/dpkp/kafka-python/commit/6e4831444f972d169cdd11f5c8d50333cea3f19b"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/kafka-python-prior-to-denial-of-service-via-protocol-parser-frame-length"
}
],
"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"
}
]
}
GHSA-M3WC-C8R8-V4HM
Vulnerability from github – Published: 2026-05-26 13:30 – Updated: 2026-05-26 13:30Notebook Pro 2.0 contains a denial of service vulnerability that allows local attackers to crash the application by supplying an excessively long string in the notebook name field. Attackers can create a malicious text file containing 500 or more characters, paste the content into the New Notebook Name field, and trigger an application crash when attempting to create and save the notebook.
{
"affected": [],
"aliases": [
"CVE-2018-25378"
],
"database_specific": {
"cwe_ids": [
"CWE-789"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-25T15:16:20Z",
"severity": "MODERATE"
},
"details": "Notebook Pro 2.0 contains a denial of service vulnerability that allows local attackers to crash the application by supplying an excessively long string in the notebook name field. Attackers can create a malicious text file containing 500 or more characters, paste the content into the New Notebook Name field, and trigger an application crash when attempting to create and save the notebook.",
"id": "GHSA-m3wc-c8r8-v4hm",
"modified": "2026-05-26T13:30:45Z",
"published": "2026-05-26T13:30:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-25378"
},
{
"type": "WEB",
"url": "https://www.exploit-db.com/exploits/45420"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/notebook-pro-denial-of-service-via-notebook-name-field"
}
],
"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"
},
{
"score": "CVSS:4.0/AV:L/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"
}
]
}
GHSA-MGV8-GGGW-MRG6
Vulnerability from github – Published: 2023-05-05 22:22 – Updated: 2024-11-19 16:31Impact
The storage allocator does not guard against allocation overflows. This can result in vulnerabilities like the following:
owner: public(address)
take_up_some_space: public(uint256[10])
buffer: public(uint256[max_value(uint256)])
@external
def initialize():
self.owner = msg.sender
@external
def foo(idx: uint256, data: uint256):
self.buffer[idx] = data
Per @toonvanhove, "An attacker can overwrite the owner variable by calling this contract with calldata: 0x04bc52f8 fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff5 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff (spaces inserted for readability)
0x04bc52f8 is the selector for foo(uint256, uint256), and the last argument fff...fff is the new value for the owner variable."
Patches
patched in 0bb7203b584e771b23536ba065a6efda457161bb
Workarounds
Is there a way for users to fix or remediate the vulnerability without upgrading?
References
Are there any links users can visit to find out more?
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "vyper"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.3.8"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-30837"
],
"database_specific": {
"cwe_ids": [
"CWE-789"
],
"github_reviewed": true,
"github_reviewed_at": "2023-05-05T22:22:23Z",
"nvd_published_at": "2023-05-08T17:15:12Z",
"severity": "HIGH"
},
"details": "### Impact\nThe storage allocator does not guard against allocation overflows. This can result in vulnerabilities like the following:\n```vyper\nowner: public(address)\ntake_up_some_space: public(uint256[10])\nbuffer: public(uint256[max_value(uint256)])\n\n@external\ndef initialize():\n self.owner = msg.sender\n\n@external\ndef foo(idx: uint256, data: uint256):\n self.buffer[idx] = data\n```\nPer @toonvanhove, \"An attacker can overwrite the owner variable by calling this contract with calldata: `0x04bc52f8 fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff5 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff` (spaces inserted for readability)\n`0x04bc52f8` is the selector for `foo(uint256, uint256)`, and the last argument `fff...fff` is the new value for the owner variable.\"\n\n### Patches\npatched in 0bb7203b584e771b23536ba065a6efda457161bb\n\n### Workarounds\n_Is there a way for users to fix or remediate the vulnerability without upgrading?_\n\n### References\n_Are there any links users can visit to find out more?_\n",
"id": "GHSA-mgv8-gggw-mrg6",
"modified": "2024-11-19T16:31:53Z",
"published": "2023-05-05T22:22:23Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/vyperlang/vyper/security/advisories/GHSA-mgv8-gggw-mrg6"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-30837"
},
{
"type": "WEB",
"url": "https://github.com/vyperlang/vyper/commit/0bb7203b584e771b23536ba065a6efda457161bb"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/vyper/PYSEC-2023-76.yaml"
},
{
"type": "PACKAGE",
"url": "https://github.com/vyperlang/vyper"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "vyper vulnerable to storage allocator overflow"
}
GHSA-MPG3-32G2-7QF5
Vulnerability from github – Published: 2026-05-19 09:31 – Updated: 2026-05-19 09:31Memory allocation with excessive size value vulnerability in Samsung Open Source Escargot allows Excessive Allocation.
This issue affects Escargot: 590345cc6258317c5da850d846ce6baaf2afc2d3.
{
"affected": [],
"aliases": [
"CVE-2026-47313"
],
"database_specific": {
"cwe_ids": [
"CWE-789"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-19T08:16:15Z",
"severity": "MODERATE"
},
"details": "Memory allocation with excessive size value vulnerability in Samsung Open Source Escargot allows Excessive Allocation.\n\nThis issue affects Escargot: 590345cc6258317c5da850d846ce6baaf2afc2d3.",
"id": "GHSA-mpg3-32g2-7qf5",
"modified": "2026-05-19T09:31:20Z",
"published": "2026-05-19T09:31:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-47313"
},
{
"type": "WEB",
"url": "https://github.com/Samsung/escargot/pull/1565"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-MR8R-92FQ-PJ8P
Vulnerability from github – Published: 2026-04-23 21:40 – Updated: 2026-04-23 21:40Summary
When exporting telemetry over gRPC using the OpenTelemetry Protocol (OTLP), the exporter may parse a server-provided grpc-status-details-bin trailer during retry handling. Prior to the fix, a malformed trailer could encode an extremely large length-delimited protobuf field which was used directly for allocation, allowing excessive memory allocation and potential denial of service (DoS).
Details
5980 introduced a retry path that parses grpc-status-details-bin to extract gRPC retry delay information for retryable responses.
On that path:
OtlpGrpcExportClientcapturesgrpc-status-details-binfrom retryable status responses (ResourceExhausted/Unavailable).OtlpRetryinvokesGrpcStatusDeserializer.TryGetGrpcRetryDelayusing this untrusted trailer value.GrpcStatusDeserializer.DecodeBytesdecoded a protobuf varint length and allocatednew byte[length]without validating the bounds against the remaining payload size.
A malicious or compromised collector (or a MitM in weakly-protected deployments) could return a crafted grpc-status-details-bin payload that forces oversized allocation and memory exhaustion in the instrumented process.
Impact
If an OTLP/gRPC endpoint is attacker-controlled (or traffic is intercepted), a crafted retryable response can trigger large allocations during trailer parsing, which may exhaust memory and cause process instability/crash (availability impact / DoS).
Mitigation
The application's configured back-end/collector endpoint needs to behave maliciously. If the collector/back-end is a well-behaved implementation response bodies should not be excessively large if a request error occurs.
Workarounds
None known.
Remediation
#7064 updates GrpcStatusDeserializer to validate decoded length-delimited field sizes before allocation by ensuring the requested length is sane and does not exceed the remaining payload.
This causes malformed or truncated grpc-status-details-bin payloads to fail safely instead of attempting unbounded allocation.
{
"affected": [
{
"package": {
"ecosystem": "NuGet",
"name": "OpenTelemetry.Exporter.OpenTelemetryProtocol"
},
"ranges": [
{
"events": [
{
"introduced": "1.13.1"
},
{
"fixed": "1.15.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-40891"
],
"database_specific": {
"cwe_ids": [
"CWE-789"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-23T21:40:29Z",
"nvd_published_at": "2026-04-23T18:16:28Z",
"severity": "MODERATE"
},
"details": "### Summary\n\nWhen exporting telemetry over gRPC using the OpenTelemetry Protocol (OTLP), the exporter may parse a server-provided `grpc-status-details-bin` trailer during retry handling. Prior to the fix, a malformed trailer could encode an extremely large length-delimited protobuf field which was used directly for allocation, allowing excessive memory allocation and potential denial of service (DoS).\n\n### Details\n\n#5980 introduced a retry path that parses `grpc-status-details-bin` to extract gRPC retry delay information for retryable responses.\n\nOn that path:\n\n- `OtlpGrpcExportClient` captures `grpc-status-details-bin` from retryable status responses (`ResourceExhausted` / `Unavailable`).\n- `OtlpRetry` invokes `GrpcStatusDeserializer.TryGetGrpcRetryDelay` using this untrusted trailer value.\n- `GrpcStatusDeserializer.DecodeBytes` decoded a protobuf varint length and allocated `new byte[length]` without validating the bounds against the remaining payload size.\n\nA malicious or compromised collector (or a MitM in weakly-protected deployments) could return a crafted `grpc-status-details-bin` payload that forces oversized allocation and memory exhaustion in the instrumented process.\n\n### Impact\n\nIf an OTLP/gRPC endpoint is attacker-controlled (or traffic is intercepted), a crafted retryable response can trigger large allocations during trailer parsing, which may exhaust memory and cause process instability/crash (availability impact / DoS).\n\n### Mitigation\n\nThe application\u0027s configured back-end/collector endpoint needs to behave maliciously. If the collector/back-end is a well-behaved implementation response bodies should not be excessively large if a request error occurs.\n\n### Workarounds\n\nNone known.\n\n### Remediation\n\n[#7064](https://github.com/open-telemetry/opentelemetry-dotnet/pull/7064) updates `GrpcStatusDeserializer` to validate decoded length-delimited field sizes before allocation by ensuring the requested length is sane and does not exceed the remaining payload.\n\nThis causes malformed or truncated `grpc-status-details-bin` payloads to fail safely instead of attempting unbounded allocation.",
"id": "GHSA-mr8r-92fq-pj8p",
"modified": "2026-04-23T21:40:29Z",
"published": "2026-04-23T21:40:29Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/open-telemetry/opentelemetry-dotnet/security/advisories/GHSA-mr8r-92fq-pj8p"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-40891"
},
{
"type": "WEB",
"url": "https://github.com/open-telemetry/opentelemetry-dotnet/pull/5980"
},
{
"type": "WEB",
"url": "https://github.com/open-telemetry/opentelemetry-dotnet/pull/7064"
},
{
"type": "PACKAGE",
"url": "https://github.com/open-telemetry/opentelemetry-dotnet"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "OpenTelemetry dotnet: Unbounded `grpc-status-details-bin` parsing in OTLP/gRPC retry handling"
}
Mitigation
Perform adequate input validation against any value that influences the amount of memory that is allocated. Define an appropriate strategy for handling requests that exceed the limit, and consider supporting a configuration option so that the administrator can extend the amount of memory to be used if necessary.
Mitigation
Run your program using system-provided resource limits for memory. This might still cause the program to crash or exit, but the impact to the rest of the system will be minimized.
No CAPEC attack patterns related to this CWE.