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.
321 vulnerabilities reference this CWE, most recent first.
GHSA-4439-4HH6-5J2W
Vulnerability from github – Published: 2026-05-16 18:31 – Updated: 2026-05-16 18:31Macaron Notes 5.5 contains a denial of service vulnerability that allows attackers to crash the application by creating notes with excessively long character strings. Attackers can generate a payload containing 350000 repeated characters and paste it into a note field to trigger application crash and stop functionality.
{
"affected": [],
"aliases": [
"CVE-2021-47970"
],
"database_specific": {
"cwe_ids": [
"CWE-789"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-16T16:16:22Z",
"severity": "HIGH"
},
"details": "Macaron Notes 5.5 contains a denial of service vulnerability that allows attackers to crash the application by creating notes with excessively long character strings. Attackers can generate a payload containing 350000 repeated characters and paste it into a note field to trigger application crash and stop functionality.",
"id": "GHSA-4439-4hh6-5j2w",
"modified": "2026-05-16T18:31:38Z",
"published": "2026-05-16T18:31:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47970"
},
{
"type": "WEB",
"url": "https://www.exploit-db.com/exploits/49953"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/macaron-notes-denial-of-service-via-buffer-overflow"
}
],
"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-44MV-JQ72-GJ49
Vulnerability from github – Published: 2026-03-16 15:30 – Updated: 2026-04-27 14:19Mattermost versions 11.3.x <= 11.3.0, 11.2.x <= 11.2.2, 10.11.x <= 10.11.10 fail to bound memory allocation when processing PSD image files which allows an authenticated attacker to cause server memory exhaustion and denial of service via uploading a specially crafted PSD file. Mattermost Advisory ID: MMSA-2026-00572
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/mattermost/mattermost/server/v8"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "8.0.0-20260115183946-38b413a27604"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/mattermost/mattermost-server"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.3.2-0.20260115183946-38b413a27604"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/mattermost/mattermost-server"
},
"ranges": [
{
"events": [
{
"introduced": "10.11.0-rc1"
},
{
"fixed": "10.11.11"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/mattermost/mattermost-server"
},
"ranges": [
{
"events": [
{
"introduced": "11.2.0-rc1"
},
{
"fixed": "11.2.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/mattermost/mattermost-server"
},
"ranges": [
{
"events": [
{
"introduced": "11.3.0-rc1"
},
{
"fixed": "11.3.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-26246"
],
"database_specific": {
"cwe_ids": [
"CWE-789"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-17T19:59:53Z",
"nvd_published_at": "2026-03-16T14:18:26Z",
"severity": "MODERATE"
},
"details": "Mattermost versions 11.3.x \u003c= 11.3.0, 11.2.x \u003c= 11.2.2, 10.11.x \u003c= 10.11.10 fail to bound memory allocation when processing PSD image files which allows an authenticated attacker to cause server memory exhaustion and denial of service via uploading a specially crafted PSD file. Mattermost Advisory ID: MMSA-2026-00572",
"id": "GHSA-44mv-jq72-gj49",
"modified": "2026-04-27T14:19:12Z",
"published": "2026-03-16T15:30:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-26246"
},
{
"type": "WEB",
"url": "https://github.com/mattermost/mattermost/commit/38b413a27604e8721fbe008f8ec4b4e6c47ad4f0"
},
{
"type": "PACKAGE",
"url": "https://github.com/mattermost/mattermost"
},
{
"type": "WEB",
"url": "https://mattermost.com/security-updates"
}
],
"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:L",
"type": "CVSS_V3"
}
],
"summary": "Mattermost fails to bound memory allocation when processing PSD image files"
}
GHSA-45XM-V8GQ-7JQX
Vulnerability from github – Published: 2018-10-17 16:19 – Updated: 2022-04-25 20:23In version from 3.0.0 to 3.5.3 of Eclipse Vert.x, the WebSocket HTTP upgrade implementation buffers the full http request before doing the handshake, holding the entire request body in memory. There should be a reasonnable limit (8192 bytes) above which the WebSocket gets an HTTP response with the 413 status code and the connection gets closed.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "io.vertx:vertx-core"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.0"
},
{
"fixed": "3.5.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2018-12541"
],
"database_specific": {
"cwe_ids": [
"CWE-119",
"CWE-789"
],
"github_reviewed": true,
"github_reviewed_at": "2020-06-16T20:57:32Z",
"nvd_published_at": "2018-10-10T20:29:00Z",
"severity": "MODERATE"
},
"details": "In version from 3.0.0 to 3.5.3 of Eclipse Vert.x, the WebSocket HTTP upgrade implementation buffers the full http request before doing the handshake, holding the entire request body in memory. There should be a reasonnable limit (8192 bytes) above which the WebSocket gets an HTTP response with the 413 status code and the connection gets closed.",
"id": "GHSA-45xm-v8gq-7jqx",
"modified": "2022-04-25T20:23:45Z",
"published": "2018-10-17T16:19:59Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-12541"
},
{
"type": "WEB",
"url": "https://github.com/eclipse-vertx/vert.x/issues/2648"
},
{
"type": "WEB",
"url": "https://github.com/eclipse-vertx/vert.x/commit/269a583330695d1418a4f5578f7169350b2e1332"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/reb3cc4f3e10264896a541813c0030ec9d9466ba9b722fe5d4adc91cd@%3Cissues.bookkeeper.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/re5ddabee26fbcadc7254d03a5a073d64080a9389adc9e452529664ed@%3Ccommits.pulsar.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rd0e44e8ef71eeaaa3cf3d1b8b41eb25894372e2995ec908ce7624d26@%3Ccommits.pulsar.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rbdc279ecdb7ac496a03befb05a53605c4ce2b67e14f8f4df4cfa1203@%3Cissues.bookkeeper.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r98dc06e2b1c498d0e9eb5038d8e1aefd24e411e50522e7082dd9e0b7@%3Ccommits.bookkeeper.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r8db0431ecf93f2dd2128db5ddca897b33ba883b7f126648d6a9e4c47@%3Ccommits.pulsar.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r79789a0afb184abd13a2c07016e6e7ab8e64331f332b630bf82a2eed@%3Ccommits.pulsar.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r3da899890536af744dec897fbc561fd9810ac45e79a16164b53c31b2@%3Ccommits.pulsar.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r362835e6c7f34324ed24e318b363fcdd20cea91d0cea0b2e1164f73e@%3Cissues.bookkeeper.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r344235b1aea2f7fa2381495df1d77d02b595e3d7e4626e701f7c1062@%3Ccommits.pulsar.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r1af71105539fe01fcecb92d2ecd8eea56c515fb1c80ecab4df424553@%3Cissues.bookkeeper.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r11789cd6d67ecca2d6f6bbb11e34495e68ee99287b6c59edf5b1a09c@%3Ccommits.pulsar.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r01123837ffbfdf5809e0a4ac354ad546e4ca8f18df89ee5a10eeb81b@%3Cissues.bookkeeper.apache.org%3E"
},
{
"type": "PACKAGE",
"url": "https://github.com/eclipse-vertx/vert.x"
},
{
"type": "WEB",
"url": "https://bugs.eclipse.org/bugs/show_bug.cgi?id=539170"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2018:2946"
}
],
"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": "Excessive memory allocation"
}
GHSA-496J-2RQ6-J6CC
Vulnerability from github – Published: 2023-08-09 15:30 – Updated: 2024-07-30 21:37gRPC contains a vulnerability that allows hpack table accounting errors could lead to unwanted disconnects between clients and servers in exceptional cases/ Three vectors were found that allow the following DOS attacks:
- Unbounded memory buffering in the HPACK parser
- Unbounded CPU consumption in the HPACK parser
The unbounded CPU consumption is down to a copy that occurred per-input-block in the parser, and because that could be unbounded due to the memory copy bug we end up with an O(n^2) parsing loop, with n selected by the client.
The unbounded memory buffering bugs:
- The header size limit check was behind the string reading code, so we needed to first buffer up to a 4 gigabyte string before rejecting it as longer than 8 or 16kb.
- HPACK varints have an encoding quirk whereby an infinite number of 0’s can be added at the start of an integer. gRPC’s hpack parser needed to read all of them before concluding a parse.
- gRPC’s metadata overflow check was performed per frame, so that the following sequence of frames could cause infinite buffering: HEADERS: containing a: 1 CONTINUATION: containing a: 2 CONTINUATION: containing a: 3 etc…
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "grpcio"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.53.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "grpcio"
},
"ranges": [
{
"events": [
{
"introduced": "1.54.0"
},
{
"fixed": "1.54.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "grpcio"
},
"ranges": [
{
"events": [
{
"introduced": "1.55.0"
},
{
"fixed": "1.55.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "grpcio"
},
"ranges": [
{
"events": [
{
"introduced": "1.56.0"
},
{
"fixed": "1.56.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "RubyGems",
"name": "grpc"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.53.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "RubyGems",
"name": "grpc"
},
"ranges": [
{
"events": [
{
"introduced": "1.54.0"
},
{
"fixed": "1.54.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "RubyGems",
"name": "grpc"
},
"ranges": [
{
"events": [
{
"introduced": "1.55.0"
},
{
"fixed": "1.55.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "RubyGems",
"name": "grpc"
},
"ranges": [
{
"events": [
{
"introduced": "1.56.0"
},
{
"fixed": "1.56.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-33953"
],
"database_specific": {
"cwe_ids": [
"CWE-770",
"CWE-789"
],
"github_reviewed": true,
"github_reviewed_at": "2024-07-30T10:26:43Z",
"nvd_published_at": "2023-08-09T13:15:09Z",
"severity": "HIGH"
},
"details": "gRPC contains a vulnerability that allows hpack table accounting errors could lead to unwanted disconnects between clients and servers in exceptional cases/\u00a0Three vectors were found that allow the following DOS attacks:\n\n- Unbounded memory buffering in the HPACK parser\n- Unbounded CPU consumption in the HPACK parser\n\nThe unbounded CPU consumption is down to a copy that occurred per-input-block in the parser, and because that could be unbounded due to the memory copy bug we end up with an O(n^2) parsing loop, with n selected by the client.\n\nThe unbounded memory buffering bugs:\n\n- The header size limit check was behind the string reading code, so we needed to first buffer up to a 4 gigabyte string before rejecting it as longer than 8 or 16kb.\n- HPACK varints have an encoding quirk whereby an infinite number of 0\u2019s can be added at the start of an integer. gRPC\u2019s hpack parser needed to read all of them before concluding a parse.\n- gRPC\u2019s metadata overflow check was performed per frame, so that the following sequence of frames could cause infinite buffering: HEADERS: containing a: 1 CONTINUATION: containing a: 2 CONTINUATION: containing a: 3 etc\u2026",
"id": "GHSA-496j-2rq6-j6cc",
"modified": "2024-07-30T21:37:50Z",
"published": "2023-08-09T15:30:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-33953"
},
{
"type": "WEB",
"url": "https://cloud.google.com/support/bulletins#gcp-2023-022"
},
{
"type": "ADVISORY",
"url": "https://github.com/advisories/GHSA-496j-2rq6-j6cc"
},
{
"type": "WEB",
"url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/grpc/CVE-2023-33953.yml"
},
{
"type": "WEB",
"url": "https://security.snyk.io/vuln/SNYK-RUBY-GRPC-5834442"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Excessive Iteration in gRPC"
}
GHSA-4CMH-GV22-J4M7
Vulnerability from github – Published: 2026-04-27 00:30 – Updated: 2026-04-27 00:30ObserverIP Scan Tool 1.4.0.1 contains a denial of service vulnerability that allows local attackers to crash the application by submitting an excessively long string in the IP input field. Attackers can paste a 2000-byte buffer of repeated characters into the IP field and trigger a search operation to cause an application crash.
{
"affected": [],
"aliases": [
"CVE-2018-25295"
],
"database_specific": {
"cwe_ids": [
"CWE-789"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-26T22:17:30Z",
"severity": "MODERATE"
},
"details": "ObserverIP Scan Tool 1.4.0.1 contains a denial of service vulnerability that allows local attackers to crash the application by submitting an excessively long string in the IP input field. Attackers can paste a 2000-byte buffer of repeated characters into the IP field and trigger a search operation to cause an application crash.",
"id": "GHSA-4cmh-gv22-j4m7",
"modified": "2026-04-27T00:30:26Z",
"published": "2026-04-27T00:30:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-25295"
},
{
"type": "WEB",
"url": "https://p10.secure.hostingprod.com/@site.ambientweatherstore.com/ssl/iptools/IPTools64bit.exe"
},
{
"type": "WEB",
"url": "https://www.ambientweather.com"
},
{
"type": "WEB",
"url": "https://www.exploit-db.com/exploits/45204"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/observerip-scan-tool-denial-of-service-via-ip-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-4HFP-H4CW-HJ8P
Vulnerability from github – Published: 2025-04-10 13:48 – Updated: 2025-04-10 13:48A Helm contributor discovered that a specially crafted chart archive file can cause Helm to use all available memory and have an out of memory (OOM) termination.
Impact
A chart archive file can be crafted in a manner where it expands to be significantly larger uncompressed than compressed (e.g., >800x difference). When Helm loads this specially crafted chart, memory can be exhausted causing the application to terminate.
Patches
This issue has been resolved in Helm v3.17.3.
Workarounds
Ensure that any chart archive files being loaded by Helm do not contain files that are large enough to cause the Helm Client or SDK to use up available memory leading to a termination.
For more information
Helm's security policy is spelled out in detail in our SECURITY document.
Credits
Disclosed by Jakub Ciolek at AlphaSense.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "helm.sh/helm/v3"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.17.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-32386"
],
"database_specific": {
"cwe_ids": [
"CWE-770",
"CWE-789"
],
"github_reviewed": true,
"github_reviewed_at": "2025-04-10T13:48:05Z",
"nvd_published_at": "2025-04-09T23:15:37Z",
"severity": "MODERATE"
},
"details": "A Helm contributor discovered that a specially crafted chart archive file can cause Helm to use all available memory and have an out of memory (OOM) termination.\n\n### Impact\nA chart archive file can be crafted in a manner where it expands to be significantly larger uncompressed than compressed (e.g., \u003e800x difference). When Helm loads this specially crafted chart, memory can be exhausted causing the application to terminate.\n\n### Patches\nThis issue has been resolved in Helm v3.17.3.\n\n### Workarounds\nEnsure that any chart archive files being loaded by Helm do not contain files that are large enough to cause the Helm Client or SDK to use up available memory leading to a termination.\n\n### For more information\nHelm\u0027s security policy is spelled out in detail in our [SECURITY](https://github.com/helm/community/blob/master/SECURITY.md) document.\n\n### Credits\nDisclosed by Jakub Ciolek at AlphaSense.",
"id": "GHSA-4hfp-h4cw-hj8p",
"modified": "2025-04-10T13:48:05Z",
"published": "2025-04-10T13:48:05Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/helm/helm/security/advisories/GHSA-4hfp-h4cw-hj8p"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-32386"
},
{
"type": "WEB",
"url": "https://github.com/helm/helm/commit/d8ca55fc669645c10c0681d49723f4bb8c0b1ce7"
},
{
"type": "PACKAGE",
"url": "https://github.com/helm/helm"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Helm Allows A Specially Crafted Chart Archive To Cause Out Of Memory Termination"
}
GHSA-4JMV-JVRV-QCV7
Vulnerability from github – Published: 2023-11-15 00:31 – Updated: 2024-09-27 21:31Uncontrolled resource consumption in Zoom Team Chat for Zoom Desktop Client for Windows and Zoom VDI Client may allow an unauthenticated user to conduct a disclosure of information via network access.
{
"affected": [],
"aliases": [
"CVE-2023-39203"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-789"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-11-14T23:15:08Z",
"severity": "MODERATE"
},
"details": "Uncontrolled resource consumption in Zoom Team Chat for Zoom Desktop Client for Windows and Zoom VDI Client may allow an unauthenticated user to conduct a disclosure of information via network access.",
"id": "GHSA-4jmv-jvrv-qcv7",
"modified": "2024-09-27T21:31:45Z",
"published": "2023-11-15T00:31:07Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-39203"
},
{
"type": "WEB",
"url": "https://explore.zoom.us/en/trust/security/security-bulletin"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-4P6F-M4F9-CH88
Vulnerability from github – Published: 2022-09-16 21:25 – Updated: 2022-09-16 21:25Impact
What kind of vulnerability is it? Who is impacted?
The vulnerability is a memory allocation vulnerability that can be exploited to allocate slices in memory with (arbitrary) excessive size value, which can either exhaust available memory or crash the whole program.
When using github.com/gagliardetto/binary to parse unchecked (or wrong type of) data from untrusted sources of input (e.g. the blockchain) into slices, it's possible to allocate memory with excessive size.
When dec.Decode(&val) method is used to parse data into a structure that is or contains slices of values, the length of the slice was previously read directly from the data itself without any checks on the size of it, and then a slice was allocated. This could lead to an overflow and an allocation of memory with excessive size value.
Example:
package main
import (
"github.com/gagliardetto/binary" // any version before v0.7.1 is vulnerable
"log"
)
type MyStruct struct {
Field1 []byte // field is a slice (could be a slice of any type)
}
func main() {
// Let's assume that the data is coming from the blockchain:
data := []byte{0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x10}
var val MyStruct
// - To determine the size of the val.Field1 slice, the decoder will read the length
// of the slice from the data itself without any checks on the size of it.
//
// - This could lead to an allocation of memory with excessive size value.
// Which means: []byte{0x01, 0x02, 0x03, 0x04} will be read as the length
// of the slice (= 67305985) and then an allocation of memory with 67305985 bytes will be made.
//
dec := binary.NewBorshDecoder(data)
err := dec.Decode(&val) // or binary.UnmarshalBorsh(&val, data) or binary.UnmarshalBin(&val, data) etc.
if err != nil {
log.Fatal(err)
}
}
Patches
Has the problem been patched? What versions should users upgrade to?
The vulnerability has been patched in github.com/gagliardetto/binary v0.7.1
Users should upgrade to v0.7.1 or higher.
To upgrade to v0.7.1 or higher, run:
go get github.com/gagliardetto/binary@v0.7.1
# or
go get github.com/gagliardetto/binary@latest
Workarounds
Is there a way for users to fix or remediate the vulnerability without upgrading?
A workaround is not to rely on the dec.Decode(&val) function to parse the data, but to use a custom UnmarshalWithDecoder() method that reads and checks the length of any slice.
References
Are there any links users can visit to find out more?
For more information
If you have any questions or comments about this advisory: * Open an issue in github.com/gagliardetto/binary * DM me on twitter
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/gagliardetto/binary"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.7.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-36078"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-789"
],
"github_reviewed": true,
"github_reviewed_at": "2022-09-16T21:25:03Z",
"nvd_published_at": "2022-09-02T13:15:00Z",
"severity": "HIGH"
},
"details": "### Impact\n\u003e _What kind of vulnerability is it? Who is impacted?_\n\nThe vulnerability is a memory allocation vulnerability that can be exploited to allocate slices in memory with (arbitrary) excessive size value, which can either exhaust available memory or crash the whole program.\n\nWhen using `github.com/gagliardetto/binary` to parse unchecked (or wrong type of) data from untrusted sources of input (e.g. the blockchain) into slices, it\u0027s possible to allocate memory with excessive size.\n\nWhen `dec.Decode(\u0026val)` method is used to parse data into a structure that is or contains slices of values, the length of the slice was previously read directly from the data itself without any checks on the size of it, and then a slice was allocated. This could lead to an overflow and an allocation of memory with excessive size value.\n\nExample:\n\n```go\npackage main\n\nimport (\n\t\"github.com/gagliardetto/binary\" // any version before v0.7.1 is vulnerable\n\t\"log\"\n)\n\ntype MyStruct struct {\n\tField1 []byte // field is a slice (could be a slice of any type)\n}\n\nfunc main() {\n\t// Let\u0027s assume that the data is coming from the blockchain:\n\tdata := []byte{0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x10}\n\t\n\tvar val MyStruct\n\t// - To determine the size of the val.Field1 slice, the decoder will read the length\n\t// of the slice from the data itself without any checks on the size of it.\n\t//\n\t// - This could lead to an allocation of memory with excessive size value.\n\t// Which means: []byte{0x01, 0x02, 0x03, 0x04} will be read as the length\n\t// of the slice (= 67305985) and then an allocation of memory with 67305985 bytes will be made.\n\t//\n\tdec := binary.NewBorshDecoder(data)\n\terr := dec.Decode(\u0026val) // or binary.UnmarshalBorsh(\u0026val, data) or binary.UnmarshalBin(\u0026val, data) etc.\n\tif err != nil {\n\t\tlog.Fatal(err)\n\t}\n}\n```\n\n### Patches\n\u003e _Has the problem been patched? What versions should users upgrade to?_\n\nThe vulnerability has been patched in `github.com/gagliardetto/binary` `v0.7.1`\n\nUsers should upgrade to `v0.7.1` or higher.\n\nTo upgrade to `v0.7.1` or higher, run:\n\n```bash\ngo get github.com/gagliardetto/binary@v0.7.1\n\n# or\n\ngo get github.com/gagliardetto/binary@latest\n```\n\n### Workarounds\n\u003e _Is there a way for users to fix or remediate the vulnerability without upgrading?_\n\nA workaround is not to rely on the `dec.Decode(\u0026val)` function to parse the data, but to use a custom `UnmarshalWithDecoder()` method that reads and checks the length of any slice.\n\n### References\n\u003e _Are there any links users can visit to find out more?_\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Open an issue in [github.com/gagliardetto/binary](https://github.com/gagliardetto/binary)\n* DM me on [twitter](https://twitter.com/immaterial_ink)\n",
"id": "GHSA-4p6f-m4f9-ch88",
"modified": "2022-09-16T21:25:03Z",
"published": "2022-09-16T21:25:03Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/gagliardetto/binary/security/advisories/GHSA-4p6f-m4f9-ch88"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-36078"
},
{
"type": "WEB",
"url": "https://github.com/gagliardetto/binary/pull/7"
},
{
"type": "PACKAGE",
"url": "https://github.com/gagliardetto/binary"
},
{
"type": "WEB",
"url": "https://github.com/gagliardetto/binary/releases/tag/v0.7.1"
},
{
"type": "WEB",
"url": "https://pkg.go.dev/vuln/GO-2022-0963"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Binary vulnerable to Slice Memory Allocation with Excessive Size Value"
}
GHSA-5888-36J9-C92P
Vulnerability from github – Published: 2026-01-27 18:32 – Updated: 2026-01-29 18:31Issue summary: A TLS 1.3 connection using certificate compression can be forced to allocate a large buffer before decompression without checking against the configured certificate size limit.
Impact summary: An attacker can cause per-connection memory allocations of up to approximately 22 MiB and extra CPU work, potentially leading to service degradation or resource exhaustion (Denial of Service).
In affected configurations, the peer-supplied uncompressed certificate length from a CompressedCertificate message is used to grow a heap buffer prior to decompression. This length is not bounded by the max_cert_list setting, which otherwise constrains certificate message sizes. An attacker can exploit this to cause large per-connection allocations followed by handshake failure. No memory corruption or information disclosure occurs.
This issue only affects builds where TLS 1.3 certificate compression is compiled in (i.e., not OPENSSL_NO_COMP_ALG) and at least one compression algorithm (brotli, zlib, or zstd) is available, and where the compression extension is negotiated. Both clients receiving a server CompressedCertificate and servers in mutual TLS scenarios receiving a client CompressedCertificate are affected. Servers that do not request client certificates are not vulnerable to client-initiated attacks.
Users can mitigate this issue by setting SSL_OP_NO_RX_CERTIFICATE_COMPRESSION to disable receiving compressed certificates.
The FIPS modules in 3.6, 3.5, 3.4 and 3.3 are not affected by this issue, as the TLS implementation is outside the OpenSSL FIPS module boundary.
OpenSSL 3.6, 3.5, 3.4 and 3.3 are vulnerable to this issue.
OpenSSL 3.0, 1.1.1 and 1.0.2 are not affected by this issue.
{
"affected": [],
"aliases": [
"CVE-2025-66199"
],
"database_specific": {
"cwe_ids": [
"CWE-789"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-01-27T16:16:15Z",
"severity": "MODERATE"
},
"details": "Issue summary: A TLS 1.3 connection using certificate compression can be\nforced to allocate a large buffer before decompression without checking\nagainst the configured certificate size limit.\n\nImpact summary: An attacker can cause per-connection memory allocations of\nup to approximately 22 MiB and extra CPU work, potentially leading to\nservice degradation or resource exhaustion (Denial of Service).\n\nIn affected configurations, the peer-supplied uncompressed certificate\nlength from a CompressedCertificate message is used to grow a heap buffer\nprior to decompression. This length is not bounded by the max_cert_list\nsetting, which otherwise constrains certificate message sizes. An attacker\ncan exploit this to cause large per-connection allocations followed by\nhandshake failure. No memory corruption or information disclosure occurs.\n\nThis issue only affects builds where TLS 1.3 certificate compression is\ncompiled in (i.e., not OPENSSL_NO_COMP_ALG) and at least one compression\nalgorithm (brotli, zlib, or zstd) is available, and where the compression\nextension is negotiated. Both clients receiving a server CompressedCertificate\nand servers in mutual TLS scenarios receiving a client CompressedCertificate\nare affected. Servers that do not request client certificates are not\nvulnerable to client-initiated attacks.\n\nUsers can mitigate this issue by setting SSL_OP_NO_RX_CERTIFICATE_COMPRESSION\nto disable receiving compressed certificates.\n\nThe FIPS modules in 3.6, 3.5, 3.4 and 3.3 are not affected by this issue,\nas the TLS implementation is outside the OpenSSL FIPS module boundary.\n\nOpenSSL 3.6, 3.5, 3.4 and 3.3 are vulnerable to this issue.\n\nOpenSSL 3.0, 1.1.1 and 1.0.2 are not affected by this issue.",
"id": "GHSA-5888-36j9-c92p",
"modified": "2026-01-29T18:31:37Z",
"published": "2026-01-27T18:32:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-66199"
},
{
"type": "WEB",
"url": "https://github.com/openssl/openssl/commit/3ed1f75249932b155eef993a8e66a99cb98bfef4"
},
{
"type": "WEB",
"url": "https://github.com/openssl/openssl/commit/6184a4fb08ee6d7bca570d931a4e8bef40b64451"
},
{
"type": "WEB",
"url": "https://github.com/openssl/openssl/commit/895150b5e021d16b52fb32b97e1dd12f20448be5"
},
{
"type": "WEB",
"url": "https://github.com/openssl/openssl/commit/966a2478046c311ed7dae50c457d0db4cafbf7e4"
},
{
"type": "WEB",
"url": "https://openssl-library.org/news/secadv/20260127.txt"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-5F8V-QP5P-3GMV
Vulnerability from github – Published: 2024-12-07 15:34 – Updated: 2024-12-07 15:34IBM Db2 for Linux, UNIX and Windows (includes Db2 Connect Server) 10.5, 11.1, and 11.5 could allow an authenticated user to cause a denial of service with a specially crafted query due to improper memory allocation.
{
"affected": [],
"aliases": [
"CVE-2024-37071"
],
"database_specific": {
"cwe_ids": [
"CWE-789"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-12-07T13:15:04Z",
"severity": "MODERATE"
},
"details": "IBM Db2 for Linux, UNIX and Windows (includes Db2 Connect Server) 10.5, 11.1, and 11.5 could allow an authenticated user to cause a denial of service with a specially crafted query due to improper memory allocation.",
"id": "GHSA-5f8v-qp5p-3gmv",
"modified": "2024-12-07T15:34:10Z",
"published": "2024-12-07T15:34:10Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-37071"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/pages/node/7175940"
}
],
"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"
}
]
}
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.