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.
444 vulnerabilities reference this CWE, most recent first.
GHSA-GR8H-7QG5-VH27
Vulnerability from github – Published: 2026-09-11 18:31 – Updated: 2026-09-14 21:31OOM Denial of Service via Unbounded Map Pre-Sizing in Apache OpenNLP SymSpellModelSerializer
Versions Affected:
- 3.0.0-M4
- 3.0.0-M5
(The opennlp-spellcheck extension was introduced in 3.0.0-M4. Releases 1.x and 2.x do not contain the affected code.)
Description:
The SymSpellModelSerializer.create() method reads two 32-bit signed integer count fields (unigramCount and bigramCount) from a binary SymSpell model stream and passes each value directly to LinkedHashMap.newLinkedHashMap() after validating only that it is non-negative. No upper bound is applied, so the count is fully attacker-controlled when the model file originates from an untrusted source.
A crafted .bin model file in which either count field is set to Integer.MAX_VALUE (or any value large enough to exhaust the available heap) causes the map to be pre-sized to a capacity of 2^30 entries. The oversized backing array is allocated on the first put() into that map, requesting 4–8 GB depending on whether compressed oops are in effect, and the load fails with an OutOfMemoryError. Because the count fields sit immediately after a fixed-size header (magic, format version, three UTF strings, the configuration fields, and the edit-distance identifier) the attacker pays no meaningful size cost to weaponize a payload: a file of well under 100 bytes plus a single real entry is sufficient to crash a JVM that loads it.
Any code path that deserializes a SymSpell model is affected, including SymSpellModels.deserialize(InputStream), SymSpellModels.fromBytes(byte[]), classpath model loading via SymSpellModelResolver.resolveByLanguage(String), the CorrectTextTool command-line tool, and model-archive loading through the registered ArtifactSerializer. The opennlp-spellcheck extension ships in the official OpenNLP binary distribution.
The practical impact is denial of service against processes that load SymSpell model files from untrusted or semi-trusted origins.
Mitigation:
- 3.x users should upgrade to 3.0.0-M6.
Note: The fix applies an upper bound to both count fields, checked before the map is pre-sized; counts that are negative or exceed the bound cause an IOException to be thrown and the read to fail fast with no large allocation. The bound is the existing AbstractModelReader.MAX_ENTRIES limit introduced earlie, which the current change promotes to public visibility so that serializers implementing their own binary format can share it. The default bound is 10,000,000, which is well above the entry counts of legitimate SymSpell dictionaries but far below any value that would threaten heap exhaustion. Deployments that legitimately need to load larger dictionaries can raise the limit at JVM startup by setting the OPENNLP_MAX_ENTRIES system property to the desired positive integer (e.g. -DOPENNLP_MAX_ENTRIES=50000000); invalid or non-positive values fall back to the default. Note that this property is shared with the model-reader limit and raising it relaxes both.
Users who cannot upgrade immediately should treat all SymSpell .bin model files as untrusted input unless their provenance is verified, and should avoid loading models supplied by end users or fetched from third-party repositories without integrity checks.
{
"affected": [],
"aliases": [
"CVE-2026-67211"
],
"database_specific": {
"cwe_ids": [
"CWE-789"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-11T18:16:57Z",
"severity": "HIGH"
},
"details": "OOM Denial of Service via Unbounded Map Pre-Sizing in Apache OpenNLP SymSpellModelSerializer\n\nVersions Affected: \n\n- 3.0.0-M4\n- 3.0.0-M5\n\n(The opennlp-spellcheck extension was introduced in 3.0.0-M4. Releases 1.x and 2.x do not contain the affected code.)\n\nDescription:\n\nThe SymSpellModelSerializer.create() method reads two 32-bit signed integer count fields (unigramCount and bigramCount) from a binary SymSpell model stream and passes each value directly to LinkedHashMap.newLinkedHashMap() after validating only that it is non-negative. No upper bound is applied, so the count is fully attacker-controlled when the model file originates from an untrusted source.\n\nA crafted .bin model file in which either count field is set to Integer.MAX_VALUE (or any value large enough to exhaust the available heap) causes the map to be pre-sized to a capacity of 2^30 entries. The oversized backing array is allocated on the first put() into that map, requesting 4\u20138 GB depending on whether compressed oops are in effect, and the load fails with an OutOfMemoryError. Because the count fields sit immediately after a fixed-size header (magic, format version, three UTF strings, the configuration fields, and the edit-distance identifier) the attacker pays no meaningful size cost to weaponize a payload: a file of well under 100 bytes plus a single real entry is sufficient to crash a JVM that loads it.\n\nAny code path that deserializes a SymSpell model is affected, including SymSpellModels.deserialize(InputStream), SymSpellModels.fromBytes(byte[]), classpath model loading via SymSpellModelResolver.resolveByLanguage(String), the CorrectTextTool command-line tool, and model-archive loading through the registered ArtifactSerializer. The opennlp-spellcheck extension ships in the official OpenNLP binary distribution.\n\nThe practical impact is denial of service against processes that load SymSpell model files from untrusted or semi-trusted origins.\n\nMitigation:\n\n- 3.x users should upgrade to 3.0.0-M6.\n\nNote: The fix applies an upper bound to both count fields, checked before the map is pre-sized; counts that are negative or exceed the bound cause an IOException to be thrown and the read to fail fast with no large allocation. The bound is the existing AbstractModelReader.MAX_ENTRIES limit introduced earlie, which the current change promotes to public visibility so that serializers implementing their own binary format can share it. The default bound is 10,000,000, which is well above the entry counts of legitimate SymSpell dictionaries but far below any value that would threaten heap exhaustion. Deployments that legitimately need to load larger dictionaries can raise the limit at JVM startup by setting the OPENNLP_MAX_ENTRIES system property to the desired positive integer (e.g. -DOPENNLP_MAX_ENTRIES=50000000); invalid or non-positive values fall back to the default. Note that this property is shared with the model-reader limit and raising it relaxes both.\n\nUsers who cannot upgrade immediately should treat all SymSpell .bin model files as untrusted input unless their provenance is verified, and should avoid loading models supplied by end users or fetched from third-party repositories without integrity checks.",
"id": "GHSA-gr8h-7qg5-vh27",
"modified": "2026-09-14T21:31:25Z",
"published": "2026-09-11T18:31:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-67211"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/gnobdsj640c60xl76q8g9o73c7jsybjm"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2026/09/11/9"
}
],
"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-GV7F-72RW-M4WF
Vulnerability from github – Published: 2025-05-29 21:31 – Updated: 2025-05-29 21:31IBM Db2 for Linux, UNIX and Windows (includes DB2 Connect Server) 11.5.0 through 11.5.9 and 12.1.0 through 12.1.1
is vulnerable to a denial of service as the server may crash under certain conditions with a specially crafted query.
{
"affected": [],
"aliases": [
"CVE-2025-2518"
],
"database_specific": {
"cwe_ids": [
"CWE-789"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-29T20:15:26Z",
"severity": "MODERATE"
},
"details": "IBM Db2 for Linux, UNIX and Windows (includes DB2 Connect Server) 11.5.0 through 11.5.9 and 12.1.0 through 12.1.1 \n\nis vulnerable to a denial of service as the server may crash under certain conditions with a specially crafted query.",
"id": "GHSA-gv7f-72rw-m4wf",
"modified": "2025-05-29T21:31:37Z",
"published": "2025-05-29T21:31:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-2518"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/pages/node/7235072"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-GWQP-9QGW-C5PV
Vulnerability from github – Published: 2026-09-11 03:30 – Updated: 2026-09-11 06:31The nscd service in the GNU C Library 2.3.4 onwards may crash due to a stack overflow when a malicious DNS server returns too large a response for a DNS query, resulting in degraded DNS resolution for the system.
Exploitation of this bug needs a system that has nscd enabled and using an untrusted DNS server for name resolution, with the compromised DNS server being capable of processing records large enough to result in a stack overflow in an nscd thread stack. During experimentation, bind 9 was unable to handle large records, but that could change in future or with a different name server. In typical installations, nscd is executed in an isolated context as its own user without a shell, due to which any compromise of that service is isolated.
There is a remote possibility of nscd cache corruption if an attacker manages to get the stack pointer into a desired point in the heap, potentially resulting in other caches in nscd being overwritten with corrupt data through the stack overflow, until the buggy code path eventually results in a crash.
Finally, a crash in nscd may result in performance degradation when resolving names, but it does not result in a denial of service.
{
"affected": [],
"aliases": [
"CVE-2026-89092"
],
"database_specific": {
"cwe_ids": [
"CWE-789"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-11T02:18:35Z",
"severity": "MODERATE"
},
"details": "The nscd service in the GNU C Library 2.3.4 onwards may crash due to a \nstack overflow when a malicious DNS server returns too large a response \nfor a DNS query, resulting in degraded DNS resolution for the system.\n\n\n\nExploitation of this bug needs a system that has nscd enabled and using \nan untrusted DNS server for name resolution, with the compromised DNS \nserver being capable of processing records large enough to result in a \nstack overflow in an nscd thread stack.\u00a0 During experimentation, bind 9 \nwas unable to handle large records, but that could change in future or \nwith a different name server.\u00a0 In typical installations, nscd is \nexecuted in an isolated context as its own user without a shell, due to \nwhich any compromise of that service is isolated.\n\n\n\nThere is a remote possibility of nscd cache corruption if an attacker \nmanages to get the stack pointer into a desired point in the heap, \npotentially resulting in other caches in nscd being overwritten with \ncorrupt data through the stack overflow, until the buggy code path \neventually results in a crash.\n\n\n\nFinally, a crash in nscd may result in performance degradation when \nresolving names, but it does not result in a denial of service.",
"id": "GHSA-gwqp-9qgw-c5pv",
"modified": "2026-09-11T06:31:12Z",
"published": "2026-09-11T03:30:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89092"
},
{
"type": "WEB",
"url": "https://sourceware.org/bugzilla/show_bug.cgi?id=34624"
},
{
"type": "WEB",
"url": "https://sourceware.org/git/?p=glibc.git;a=blob_plain;f=advisories/GLIBC-SA-2026-0016"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2026/09/11/2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-GXVQ-F5Q4-6G92
Vulnerability from github – Published: 2025-01-22 18:31 – Updated: 2025-01-22 18:31A vulnerability in the SIP processing subsystem of Cisco BroadWorks could allow an unauthenticated, remote attacker to halt the processing of incoming SIP requests, resulting in a denial of service (DoS) condition.
This vulnerability is due to improper memory handling for certain SIP requests. An attacker could exploit this vulnerability by sending a high number of SIP requests to an affected system. A successful exploit could allow the attacker to exhaust the memory that was allocated to the Cisco BroadWorks Network Servers that handle SIP traffic. If no memory is available, the Network Servers can no longer process incoming requests, resulting in a DoS condition that requires manual intervention to recover.
{
"affected": [],
"aliases": [
"CVE-2025-20165"
],
"database_specific": {
"cwe_ids": [
"CWE-476",
"CWE-789"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-22T17:15:13Z",
"severity": "HIGH"
},
"details": "A vulnerability in the SIP processing subsystem of Cisco BroadWorks could allow an unauthenticated, remote attacker to halt the processing of incoming SIP requests, resulting in a denial of service (DoS) condition.\n\nThis vulnerability is due to improper memory handling for certain SIP requests. An attacker could exploit this vulnerability by sending a high number of SIP requests to an affected system. A successful exploit could allow the attacker to exhaust the memory that was allocated to the Cisco BroadWorks Network Servers that handle SIP traffic. If no memory is available, the Network Servers can no longer process incoming requests, resulting in a DoS condition that requires manual intervention to recover.",
"id": "GHSA-gxvq-f5q4-6g92",
"modified": "2025-01-22T18:31:56Z",
"published": "2025-01-22T18:31:55Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-20165"
},
{
"type": "WEB",
"url": "https://blog.clamav.net/2025/01/clamav-142-and-108-security-patch.html"
},
{
"type": "WEB",
"url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-bw-sip-dos-mSySbrmt"
},
{
"type": "WEB",
"url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-clamav-ole2-H549rphA"
}
],
"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-H33J-VRHG-4Q7J
Vulnerability from github – Published: 2026-08-11 09:32 – Updated: 2026-09-18 00:31A flaw was found in Wildfly. A remote unauthenticated attacker can trigger OutOfMemoryError as CSIv2Util's GSS token decoder reads an attacker-controlled length field without bounds checking and attempts to allocate a byte array of that size.
{
"affected": [],
"aliases": [
"CVE-2026-15567"
],
"database_specific": {
"cwe_ids": [
"CWE-789"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-11T09:17:13Z",
"severity": "HIGH"
},
"details": "A flaw was found in Wildfly. A remote unauthenticated attacker can trigger OutOfMemoryError as CSIv2Util\u0027s GSS token decoder reads an attacker-controlled length field without bounds checking and attempts to allocate a byte array of that size.",
"id": "GHSA-h33j-vrhg-4q7j",
"modified": "2026-09-18T00:31:06Z",
"published": "2026-08-11T09:32:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-15567"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:53644"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:53645"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:53646"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:53806"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2026-15567"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2491620"
}
],
"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-H7PQ-86H8-RP5X
Vulnerability from github – Published: 2026-07-16 19:20 – Updated: 2026-07-16 19:20Vulnerability report without repro case. Repro case may be added later after harness is complete.
Preconditions (4): - Tenant can create EnvoyExtensionPolicy (baseline) - Controller has egress to attacker-controlled OCI registry - No registry allowlist (none exists in code) - Layer presents Docker/OCI media type
Description
At imagefetcher.go:287, make([]byte, h.Size) uses the attacker-controlled tar-header size; the LimitReader at :278 bounds bytes read from the stream but not the header-declared size returned by tr.Next() (a 512-byte header can claim a multi-TB entry via PAX/GNU encoding). Reached from untrusted tenant input via EnvoyExtensionPolicy spec.wasm[].code.image.url (envoyextensionpolicy.go:1157 → cache.go:262/299 → imagefetcher.go:218 → :287), and the allocation happens for every tar entry regardless of filename. The resulting Go runtime OOM throw is unrecoverable and, because the CRD persists, crash-loops the shared controller — single-request, non-volumetric, cluster-wide DoS.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/envoyproxy/gateway"
},
"ranges": [
{
"events": [
{
"introduced": "1.8.0-rc.0"
},
{
"fixed": "1.8.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/envoyproxy/gateway"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.7.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-53717"
],
"database_specific": {
"cwe_ids": [
"CWE-789"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-16T19:20:05Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "Vulnerability report without repro case. Repro case may be added later after harness is complete.\n\n**Preconditions (4):**\n- Tenant can create EnvoyExtensionPolicy (baseline)\n- Controller has egress to attacker-controlled OCI registry\n- No registry allowlist (none exists in code)\n- Layer presents Docker/OCI media type\n\n**Description**\n\nAt imagefetcher.go:287, make([]byte, h.Size) uses the attacker-controlled tar-header size; the LimitReader at :278 bounds bytes read from the stream but not the header-declared size returned by tr.Next() (a 512-byte header can claim a multi-TB entry via PAX/GNU encoding). Reached from untrusted tenant input via EnvoyExtensionPolicy spec.wasm[].code.image.url (envoyextensionpolicy.go:1157 \u2192 cache.go:262/299 \u2192 imagefetcher.go:218 \u2192 :287), and the allocation happens for every tar entry regardless of filename. The resulting Go runtime OOM throw is unrecoverable and, because the CRD persists, crash-loops the shared controller \u2014 single-request, non-volumetric, cluster-wide DoS.",
"id": "GHSA-h7pq-86h8-rp5x",
"modified": "2026-07-16T19:20:05Z",
"published": "2026-07-16T19:20:05Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/envoyproxy/gateway/security/advisories/GHSA-h7pq-86h8-rp5x"
},
{
"type": "PACKAGE",
"url": "https://github.com/envoyproxy/gateway"
}
],
"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": "Envoy Gateway: OCI layer extraction allocates make([]byte, h.Size) from untrusted tar header"
}
GHSA-H9FQ-4HJ4-G596
Vulnerability from github – Published: 2024-03-21 15:31 – Updated: 2024-06-10 18:30A flaw was found in the RPC library APIs of libvirt. The RPC server deserialization code allocates memory for arrays before the non-negative length check is performed by the C API entry points. Passing a negative length to the g_new0 function results in a crash due to the negative length being treated as a huge positive number. This flaw allows a local, unprivileged user to perform a denial of service attack by causing the libvirt daemon to crash.
{
"affected": [],
"aliases": [
"CVE-2024-2494"
],
"database_specific": {
"cwe_ids": [
"CWE-789"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-03-21T14:15:10Z",
"severity": "MODERATE"
},
"details": "A flaw was found in the RPC library APIs of libvirt. The RPC server deserialization code allocates memory for arrays before the non-negative length check is performed by the C API entry points. Passing a negative length to the g_new0 function results in a crash due to the negative length being treated as a huge positive number. This flaw allows a local, unprivileged user to perform a denial of service attack by causing the libvirt daemon to crash.",
"id": "GHSA-h9fq-4hj4-g596",
"modified": "2024-06-10T18:30:53Z",
"published": "2024-03-21T15:31:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-2494"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2024:2560"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2024:3253"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2024-2494"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2270115"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/04/msg00000.html"
},
{
"type": "WEB",
"url": "https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/BKRQXPLPC6B7FLHJXSBQYW7HNDEBW6RJ"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20240517-0009"
}
],
"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-HM63-VWJ4-MJ2Q
Vulnerability from github – Published: 2026-04-10 00:30 – Updated: 2026-04-10 20:19Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-4qwc-c7g9-4xcw. This link is maintained to preserve external references.
Original Description
OpenClaw before 2026.3.22 contains an unbounded memory allocation vulnerability in remote media HTTP error handling that allows attackers to trigger excessive memory consumption. Attackers can send crafted HTTP error responses with large bodies to remote media endpoints, causing the application to allocate unbounded memory before failure handling occurs.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "openclaw"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2026.3.22"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-789"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-10T20:19:29Z",
"nvd_published_at": "2026-04-09T22:16:32Z",
"severity": "MODERATE"
},
"details": "### Duplicate Advisory\nThis advisory has been withdrawn because it is a duplicate of GHSA-4qwc-c7g9-4xcw. This link is maintained to preserve external references.\n\n### Original Description\nOpenClaw before 2026.3.22 contains an unbounded memory allocation vulnerability in remote media HTTP error handling that allows attackers to trigger excessive memory consumption. Attackers can send crafted HTTP error responses with large bodies to remote media endpoints, causing the application to allocate unbounded memory before failure handling occurs.",
"id": "GHSA-hm63-vwj4-mj2q",
"modified": "2026-04-10T20:19:29Z",
"published": "2026-04-10T00:30:30Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-4qwc-c7g9-4xcw"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-35633"
},
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/commit/630f1479c44f78484dfa21bb407cbe6f171dac87"
},
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/commit/81445a901091a5d27ef0b56fceedbe4724566438"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/openclaw-unbounded-memory-allocation-via-remote-media-error-responses"
}
],
"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: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"
}
],
"summary": "Duplicate Advisory: OpenClaw: Remote media error responses could trigger unbounded memory allocation before failure",
"withdrawn": "2026-04-10T20:19:29Z"
}
GHSA-HQ75-PVPQ-98XX
Vulnerability from github – Published: 2022-04-13 00:00 – Updated: 2022-04-21 00:00Due to an uncontrolled recursion in SAP Web Dispatcher and SAP Internet Communication Manager, the application may crash, leading to denial of service, but can be restarted automatically.
{
"affected": [],
"aliases": [
"CVE-2022-28773"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-674",
"CWE-789"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-04-12T17:15:00Z",
"severity": "HIGH"
},
"details": "Due to an uncontrolled recursion in SAP Web Dispatcher and SAP Internet Communication Manager, the application may crash, leading to denial of service, but can be restarted automatically.",
"id": "GHSA-hq75-pvpq-98xx",
"modified": "2022-04-21T00:00:52Z",
"published": "2022-04-13T00:00:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-28773"
},
{
"type": "WEB",
"url": "https://launchpad.support.sap.com/#/notes/3111293"
},
{
"type": "WEB",
"url": "https://www.sap.com/documents/2022/02/fa865ea4-167e-0010-bca6-c68f7e60039b.html"
}
],
"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-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"
}
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.