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.
324 vulnerabilities reference this CWE, most recent first.
GHSA-XHJ4-G6W8-2XJW
Vulnerability from github – Published: 2026-04-24 16:25 – Updated: 2026-04-24 16:25Impact
When deserializing arrays, strings or bytes (blob) types zserio first reads the size of the variable, and then allocates sufficient memory to load data. Since the size is always trusted this can be abused by creating a data file with a large size value, causing the zserio runtime to allocate large amounts of memory.
Patches
Please apply this commit.
Workarounds
- Do not accept zserio data from non-trusted sources.
- Use secure transportation protocols (like TLS).
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/woven-planet/go-zserio"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.9.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-789"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-24T16:25:54Z",
"nvd_published_at": null,
"severity": "CRITICAL"
},
"details": "### Impact\n\nWhen deserializing arrays, strings or bytes (blob) types zserio first reads the size of the variable, and then allocates sufficient memory to load data. Since the size is always trusted this can be abused by creating a data file with a large size value, causing the zserio runtime to allocate large amounts of memory.\n\n### Patches\n\nPlease apply [this commit](https://github.com/woven-by-toyota/go-zserio/commit/39ef1decde7e9766207794d396018776b33c6e45).\n\n### Workarounds\n\n- Do not accept zserio data from non-trusted sources.\n- Use secure transportation protocols (like TLS).",
"id": "GHSA-xhj4-g6w8-2xjw",
"modified": "2026-04-24T16:25:54Z",
"published": "2026-04-24T16:25:54Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/woven-by-toyota/go-zserio/security/advisories/GHSA-xhj4-g6w8-2xjw"
},
{
"type": "WEB",
"url": "https://github.com/woven-by-toyota/go-zserio/commit/39ef1decde7e9766207794d396018776b33c6e45"
},
{
"type": "PACKAGE",
"url": "https://github.com/woven-by-toyota/go-zserio"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "go-zserio has Unbounded Memory Allocation for All Platforms"
}
GHSA-XR5H-RXWF-6Q73
Vulnerability from github – Published: 2022-01-26 00:01 – Updated: 2022-02-01 00:00This vulnerability allows local attackers to escalate privileges on affected installations of Parallels Desktop 16.1.3-49160. An attacker must first obtain the ability to execute low-privileged code on the target guest system in order to exploit this vulnerability. The specific flaw exists within the Toolgate component. The issue results from the lack of proper validation of user-supplied data, which can result in an uncontrolled memory allocation. An attacker can leverage this vulnerability to escalate privileges and execute arbitrary code in the context of the hypervisor. Was ZDI-CAN-13712.
{
"affected": [],
"aliases": [
"CVE-2021-34868"
],
"database_specific": {
"cwe_ids": [
"CWE-789"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-01-25T16:15:00Z",
"severity": "HIGH"
},
"details": "This vulnerability allows local attackers to escalate privileges on affected installations of Parallels Desktop 16.1.3-49160. An attacker must first obtain the ability to execute low-privileged code on the target guest system in order to exploit this vulnerability. The specific flaw exists within the Toolgate component. The issue results from the lack of proper validation of user-supplied data, which can result in an uncontrolled memory allocation. An attacker can leverage this vulnerability to escalate privileges and execute arbitrary code in the context of the hypervisor. Was ZDI-CAN-13712.",
"id": "GHSA-xr5h-rxwf-6q73",
"modified": "2022-02-01T00:00:49Z",
"published": "2022-01-26T00:01:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-34868"
},
{
"type": "WEB",
"url": "https://kb.parallels.com/125013"
},
{
"type": "WEB",
"url": "https://www.zerodayinitiative.com/advisories/ZDI-21-1056"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-XRVJ-V92F-53GJ
Vulnerability from github – Published: 2026-06-08 23:43 – Updated: 2026-06-11 14:07Impact
An uncontrolled-resource-consumption (memory exhaustion) denial-of-service vulnerability (CWE-400 / CWE-789).
A client with push access could push a tiny crafted thin pack (~174 bytes) whose delta header declares a huge dest_size. When dulwich ingested it via add_thin_pack / apply_delta, it would allocate hundreds of MB of memory based on that attacker-controlled size, with no relationship to the actual bytes received.
Who is impacted: Operators running a Dulwich-based Git server that exposes git-receive-pack (i.e. accepts pushes) - for example via dulwich.server functionality, the HTTP smart server, or anything built on ReceivePackHandler.
Patches
Patched in 1.2.5.
add_thin_pack now accepts a max_input_size keyword (bytes; 0/None = unlimited, matching git's semantics), and ReceivePackHandler reads receive.maxInputSize from the repository config and passes it through. Wire reads are counted and a PackInputTooLarge exception is raised once the cap is exceeded - equivalent to git index-pack --max-input-size.
Users should upgrade to Dulwich 1.2.5 or later and set receive.maxInputSize in their server's repository config to a sane bound for their environment.
Workarounds
On unpatched versions, receive.maxInputSize has no effect, so it cannot be used as a workaround. Until upgrading, operators should:
- Restrict dulwich-receive-pack (push) access to trusted, authenticated clients only, or disable it entirely on servers that only need to serve fetches.
- Run the server under an OS-level memory limit (e.g. ulimit, cgroups/MemoryMax, or a container memory limit) so a malicious push is killed rather than taking down the host.
Resources
- git's receive.maxInputSize / git index-pack --max-input-size documentation
- Reported by Liyi, Ziyue, Strick, Maurice and Chenchen @ University of Sydney
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "dulwich"
},
"ranges": [
{
"events": [
{
"introduced": "0.1.0"
},
{
"fixed": "1.2.5"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-47734"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-789"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-08T23:43:42Z",
"nvd_published_at": "2026-06-10T23:16:48Z",
"severity": "MODERATE"
},
"details": "## Impact\n\nAn uncontrolled-resource-consumption (memory exhaustion) denial-of-service vulnerability (CWE-400 / CWE-789).\n\nA client with push access could push a tiny crafted thin pack (~174 bytes) whose delta header declares a huge dest_size. When dulwich ingested it via add_thin_pack / apply_delta, it would allocate hundreds of MB of memory based on that attacker-controlled size, with no relationship to the actual bytes received.\n\nWho is impacted: Operators running a Dulwich-based Git server that exposes git-receive-pack (i.e. accepts pushes) -\nfor example via dulwich.server functionality, the HTTP smart server, or anything built on ReceivePackHandler. \n\n## Patches\n\nPatched in 1.2.5.\n\nadd_thin_pack now accepts a max_input_size keyword (bytes; 0/None = unlimited, matching git\u0027s semantics), and ReceivePackHandler reads receive.maxInputSize from the repository config and passes it through. Wire reads are counted and a PackInputTooLarge exception is raised once the cap is exceeded - equivalent to git index-pack --max-input-size.\n\nUsers should upgrade to Dulwich 1.2.5 or later and set receive.maxInputSize in their server\u0027s repository config to a sane bound for their environment.\n\n## Workarounds\n\nOn unpatched versions, receive.maxInputSize has no effect, so it cannot be used as a workaround. Until upgrading, operators should:\n\n- Restrict dulwich-receive-pack (push) access to trusted, authenticated clients only, or disable it entirely on servers that only need to serve fetches.\n- Run the server under an OS-level memory limit (e.g. ulimit, cgroups/MemoryMax, or a container memory limit) so a malicious push is killed rather than taking down the host.\n\n## Resources\n\n- git\u0027s receive.maxInputSize / git index-pack --max-input-size documentation \n- Reported by Liyi, Ziyue, Strick, Maurice and Chenchen @ University of Sydney",
"id": "GHSA-xrvj-v92f-53gj",
"modified": "2026-06-11T14:07:18Z",
"published": "2026-06-08T23:43:42Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/jelmer/dulwich/security/advisories/GHSA-xrvj-v92f-53gj"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-47734"
},
{
"type": "PACKAGE",
"url": "https://github.com/jelmer/dulwich"
},
{
"type": "WEB",
"url": "https://github.com/jelmer/dulwich/releases/tag/dulwich-1.2.5"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Dulwich has unbounded memory allocation in receive-pack from crafted thin packs"
}
GHSA-XV2P-WCHJ-QJHP
Vulnerability from github – Published: 2026-03-16 15:30 – Updated: 2026-03-17 19:59Mattermost 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 DOC files which allows an authenticated attacker to cause server memory exhaustion and denial of service via uploading a specially crafted DOC file.. Mattermost Advisory ID: MMSA-2026-00581
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/mattermost/mattermost/server/v8"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "8.0.0-20260123215601-86797c508c44"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/mattermost/mattermost-server"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.3.2-0.20260123215601-86797c508c44"
}
],
"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-25780"
],
"database_specific": {
"cwe_ids": [
"CWE-789"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-17T19:59:29Z",
"nvd_published_at": "2026-03-16T14:18:23Z",
"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 DOC files which allows an authenticated attacker to cause server memory exhaustion and denial of service via uploading a specially crafted DOC file.. Mattermost Advisory ID: MMSA-2026-00581",
"id": "GHSA-xv2p-wchj-qjhp",
"modified": "2026-03-17T19:59:29Z",
"published": "2026-03-16T15:30:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-25780"
},
{
"type": "WEB",
"url": "https://github.com/mattermost/mattermost/commit/86797c508c444e299b20889ce241fde505a402cc"
},
{
"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 DOC files"
}
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.