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-F46F-FJF4-H4M2
Vulnerability from github – Published: 2025-07-23 21:36 – Updated: 2025-07-25 06:30Redis through 7.4.3 allows memory consumption via a multi-bulk command composed of many bulks, sent by an authenticated user. This occurs because the server allocates memory for the command arguments of every bulk, even when the command is skipped because of insufficient permissions.
{
"affected": [],
"aliases": [
"CVE-2025-46686"
],
"database_specific": {
"cwe_ids": [
"CWE-401",
"CWE-789"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-23T19:15:33Z",
"severity": "MODERATE"
},
"details": "Redis through 7.4.3 allows memory consumption via a multi-bulk command composed of many bulks, sent by an authenticated user. This occurs because the server allocates memory for the command arguments of every bulk, even when the command is skipped because of insufficient permissions.",
"id": "GHSA-f46f-fjf4-h4m2",
"modified": "2025-07-25T06:30:30Z",
"published": "2025-07-23T21:36:45Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/redis/redis/security/advisories/GHSA-2r7g-8hpc-rpq9"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-46686"
},
{
"type": "WEB",
"url": "https://github.com/io-no/CVE-Reports/issues/1"
},
{
"type": "WEB",
"url": "https://github.com/redis/redis"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-F5V4-2WR6-HQMG
Vulnerability from github – Published: 2026-04-24 15:39 – Updated: 2026-05-13 13:34Summary
A pre-authentication denial-of-service vulnerability exists in the server's keyboard-interactive authentication handler. A malicious client can crash any russh-based server that implements keyboard-interactive auth (e.g., for 2FA/TOTP) with a single malformed packet, requiring no credentials.
Vulnerability Details
In russh/src/server/encrypted.rs, the function read_userauth_info_response decodes a u32 count from the client's SSH_MSG_USERAUTH_INFO_RESPONSE and passes it directly to Vec::with_capacity():
let n = map_err!(u32::decode(r))?;
// Bound both allocation and iteration by remaining packet data to
// prevent a malicious client from causing a multi-GB allocation or
// billions of loop iterations with a crafted count.
// Each response needs at least 4 bytes (length prefix).
let max_responses = r.remaining_len().saturating_add(3) / 4;
let n = (n as usize).min(max_responses);
let mut responses = Vec::with_capacity(n);
for _ in 0..n {
responses.push(Bytes::decode(r).ok())
}
An attacker can send n = 0x10000000 (268M) or larger in a minimal packet (~50 bytes after encryption). The server attempts to allocate n * ~24 bytes (size of Option<Bytes>) = ~6.4GB, causing an OOM crash.
Attack Flow
- Attacker connects via TCP, completes key exchange (no credentials needed -- this is the anonymous DH handshake, not authentication)
- Sends
USERAUTH_REQUESTwith methodkeyboard-interactive - Server handler returns
Auth::Partialwith prompts (standard for 2FA/TOTP) - Attacker sends
USERAUTH_INFO_RESPONSEwithn = 0x10000000and no response data - Server calls
Vec::with_capacity(268_435_456), OOM killed
No authentication is required. The allocation occurs before the handler validates any credentials. The attack is repeatable faster than the server can restart.
Affected Configurations
Any russh-based server where the Handler::auth_keyboard_interactive implementation returns Auth::Partial (i.e., sends prompts to the client). The default handler returns Auth::reject() and is not affected.
Source code review suggests that downstream projects using keyboard-interactive for multi-step auth (e.g., TOTP/2FA) follow the affected pattern, since returning Auth::Partial before credential verification is the intended API usage for prompting.
Confirmed End-to-End PoC
There is a complete Docker-contained PoC confirming the OOM kill:
- Minimal russh server returning Auth::Partial for keyboard-interactive
- Python client (paramiko for key exchange) sends malformed USERAUTH_INFO_RESPONSE
- Container with 512MB memory limit; server is OOM-killed (exit code 137)
Available on request.
Proposed Fix
Cap the Vec::with_capacity allocation to what the remaining packet data can actually contain. Each response requires at least 4 bytes (length prefix), so:
let n = map_err!(u32::decode(r))?;
// Bound both allocation and iteration by remaining packet data to
// prevent a malicious client from causing a multi-GB allocation or
// billions of loop iterations with a crafted count.
// Each response needs at least 4 bytes (length prefix).
let max_responses = r.remaining_len().saturating_add(3) / 4;
let n = (n as usize).min(max_responses);
let mut responses = Vec::with_capacity(n);
for _ in 0..n {
responses.push(Bytes::decode(r).ok())
}
This bounds the allocation to at most the packet size (~256KB), while preserving the existing behavior for well-formed packets. This fix has been implemented, tested, and contributed via the temporary private fork.
Severity
Pre-auth, remote, no credentials required, crashes the server process affecting all active sessions.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "russh"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.60.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-42189"
],
"database_specific": {
"cwe_ids": [
"CWE-770",
"CWE-789"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-24T15:39:37Z",
"nvd_published_at": "2026-05-08T20:16:31Z",
"severity": "HIGH"
},
"details": "## Summary\n\nA pre-authentication denial-of-service vulnerability exists in the server\u0027s keyboard-interactive authentication handler. A malicious client can crash any russh-based server that implements keyboard-interactive auth (e.g., for 2FA/TOTP) with a single malformed packet, requiring no credentials.\n\n## Vulnerability Details\n\nIn `russh/src/server/encrypted.rs`, the function `read_userauth_info_response` decodes a `u32` count from the client\u0027s `SSH_MSG_USERAUTH_INFO_RESPONSE` and passes it directly to `Vec::with_capacity()`:\n\n```rust\nlet n = map_err!(u32::decode(r))?;\n\n// Bound both allocation and iteration by remaining packet data to\n// prevent a malicious client from causing a multi-GB allocation or\n// billions of loop iterations with a crafted count.\n// Each response needs at least 4 bytes (length prefix).\nlet max_responses = r.remaining_len().saturating_add(3) / 4;\nlet n = (n as usize).min(max_responses);\nlet mut responses = Vec::with_capacity(n);\nfor _ in 0..n {\n responses.push(Bytes::decode(r).ok())\n}\n```\n\nAn attacker can send `n = 0x10000000` (268M) or larger in a minimal packet (~50 bytes after encryption). The server attempts to allocate `n * ~24 bytes` (size of `Option\u003cBytes\u003e`) = ~6.4GB, causing an OOM crash.\n\n## Attack Flow\n\n1. Attacker connects via TCP, completes key exchange (no credentials needed -- this is the anonymous DH handshake, not authentication)\n2. Sends `USERAUTH_REQUEST` with method `keyboard-interactive`\n3. Server handler returns `Auth::Partial` with prompts (standard for 2FA/TOTP)\n4. Attacker sends `USERAUTH_INFO_RESPONSE` with `n = 0x10000000` and no response data\n5. Server calls `Vec::with_capacity(268_435_456)`, OOM killed\n\nNo authentication is required. The allocation occurs before the handler validates any credentials. The attack is repeatable faster than the server can restart.\n\n## Affected Configurations\n\nAny russh-based server where the `Handler::auth_keyboard_interactive` implementation returns `Auth::Partial` (i.e., sends prompts to the client). The default handler returns `Auth::reject()` and is not affected.\n\nSource code review suggests that downstream projects using keyboard-interactive for multi-step auth (e.g., TOTP/2FA) follow the affected pattern, since returning `Auth::Partial` before credential verification is the intended API usage for prompting.\n\n## Confirmed End-to-End PoC\n\nThere is a complete Docker-contained PoC confirming the OOM kill:\n- Minimal russh server returning `Auth::Partial` for keyboard-interactive\n- Python client (paramiko for key exchange) sends malformed `USERAUTH_INFO_RESPONSE`\n- Container with 512MB memory limit; server is OOM-killed (exit code 137)\n\nAvailable on request.\n\n## Proposed Fix\n\nCap the `Vec::with_capacity` allocation to what the remaining packet data can actually contain. Each response requires at least 4 bytes (length prefix), so:\n\n```rust\nlet n = map_err!(u32::decode(r))?;\n\n// Bound both allocation and iteration by remaining packet data to\n// prevent a malicious client from causing a multi-GB allocation or\n// billions of loop iterations with a crafted count.\n// Each response needs at least 4 bytes (length prefix).\nlet max_responses = r.remaining_len().saturating_add(3) / 4;\nlet n = (n as usize).min(max_responses);\nlet mut responses = Vec::with_capacity(n);\nfor _ in 0..n {\n responses.push(Bytes::decode(r).ok())\n}\n```\n\nThis bounds the allocation to at most the packet size (~256KB), while preserving the existing behavior for well-formed packets. This fix has been implemented, tested, and contributed via the temporary private fork.\n\n## Severity\n\nPre-auth, remote, no credentials required, crashes the server process affecting all active sessions.",
"id": "GHSA-f5v4-2wr6-hqmg",
"modified": "2026-05-13T13:34:53Z",
"published": "2026-04-24T15:39:37Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/Eugeny/russh/security/advisories/GHSA-f5v4-2wr6-hqmg"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42189"
},
{
"type": "WEB",
"url": "https://github.com/Eugeny/russh/commit/6c3c80a9b6d60763d6227d60fa8310e57172a4d1"
},
{
"type": "PACKAGE",
"url": "https://github.com/Eugeny/russh"
},
{
"type": "WEB",
"url": "https://github.com/Eugeny/russh/releases/tag/v0.60.1"
}
],
"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": "russh has pre-auth DoS via unbounded allocation in its keyboard-interactive auth handler"
}
GHSA-F77W-PX59-CQF5
Vulnerability from github – Published: 2026-06-30 12:31 – Updated: 2026-06-30 15:30Memory Allocation with Excessive Size Value vulnerability in Apache ActiveMQ, Apache ActiveMQ All, Apache ActiveMQ Client, Apache ActiveMQ Broker.
An authenticated user can cause a broker DoS by sending a crafted OpenWire Message with a large encoded size value for the map. OpenWire message property maps are unmarshaled without size validation which can trigger OOM and crash the broker. This issue affects Apache ActiveMQ: before 5.19.8, from 6.0.0 before 6.2.7; Apache ActiveMQ All: before 5.19.8, from 6.0.0 before 6.2.7; Apache ActiveMQ Client: before 5.19.8, from 6.0.0 before 6.2.7; Apache ActiveMQ Broker: before 5.19.8, from 6.0.0 before 6.2.7.
Users are recommended to upgrade to version 6.2.7 or 5.19.8, which fixes the issue.
{
"affected": [],
"aliases": [
"CVE-2026-53917"
],
"database_specific": {
"cwe_ids": [
"CWE-789"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-30T11:16:30Z",
"severity": "HIGH"
},
"details": "Memory Allocation with Excessive Size Value vulnerability in Apache ActiveMQ, Apache ActiveMQ All, Apache ActiveMQ Client, Apache ActiveMQ Broker.\n\nAn authenticated user can cause a broker DoS by sending a crafted OpenWire Message with a large encoded size value for the map. OpenWire message property maps are unmarshaled without size validation\u00a0which can trigger OOM and crash the broker.\nThis issue affects Apache ActiveMQ: before 5.19.8, from 6.0.0 before 6.2.7; Apache ActiveMQ All: before 5.19.8, from 6.0.0 before 6.2.7; Apache ActiveMQ Client: before 5.19.8, from 6.0.0 before 6.2.7; Apache ActiveMQ Broker: before 5.19.8, from 6.0.0 before 6.2.7.\n\nUsers are recommended to upgrade to version 6.2.7 or 5.19.8, which fixes the issue.",
"id": "GHSA-f77w-px59-cqf5",
"modified": "2026-06-30T15:30:44Z",
"published": "2026-06-30T12:31:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53917"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/grrd1mwgkgblqjbwkkq6dvmdxd9ov2dx"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2026/06/29/14"
}
],
"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-F83W-W68R-F82V
Vulnerability from github – Published: 2026-05-16 18:31 – Updated: 2026-05-16 18:31Color Notes 1.4 contains a denial of service vulnerability that allows attackers to crash the application by pasting excessively long character strings into note fields. Attackers can generate a payload containing 350,000 repeated characters and paste it twice into a new note to cause the application to stop responding.
{
"affected": [],
"aliases": [
"CVE-2021-47969"
],
"database_specific": {
"cwe_ids": [
"CWE-789"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-16T16:16:22Z",
"severity": "HIGH"
},
"details": "Color Notes 1.4 contains a denial of service vulnerability that allows attackers to crash the application by pasting excessively long character strings into note fields. Attackers can generate a payload containing 350,000 repeated characters and paste it twice into a new note to cause the application to stop responding.",
"id": "GHSA-f83w-w68r-f82v",
"modified": "2026-05-16T18:31:38Z",
"published": "2026-05-16T18:31:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47969"
},
{
"type": "WEB",
"url": "https://www.exploit-db.com/exploits/49952"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/color-notes-denial-of-service-via-long-character-string"
}
],
"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-F962-QM93-MJ4C
Vulnerability from github – Published: 2026-07-06 20:54 – Updated: 2026-07-06 20:54Summary
NewDataBuilder in provisionersdk/proto/dataupload.go allocated a byte slice using the client-supplied FileSize from a DataUpload message without an upper-bound check. Although the DRPC wire limit is 4 MiB, the FileSize value itself was unconstrained
Impact
An authenticated user able to reach the provisioner daemon serve endpoint could send a roughly 50-byte message declaring a huge FileSize (for example 1 TiB), triggering an unrecoverable Go out-of-memory abort that terminates coderd. This is a single-message denial of service affecting the entire deployment.
Patches
The fix validates FileSize against an upper bound (MaxFileSize = 100 MiB) before allocation.
The fix was backported to all supported release lines:
| Release line | Patched version |
|---|---|
| 2.34 | v2.34.2 |
| 2.33 | v2.33.8 |
| 2.32 | v2.32.7 |
| 2.29 (ESR) | v2.29.17 |
Workarounds
Restrict access to the provisioner daemon serve endpoint to trusted provisioner daemon service accounts.
Resources
- Fix: #25710
Credits
Coder would like to thank Anthropic's Security Team (ANT-2026-22442) for independently disclosing this issue!
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/coder/coder/v2"
},
"ranges": [
{
"events": [
{
"introduced": "2.34.0"
},
{
"fixed": "2.34.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/coder/coder/v2"
},
"ranges": [
{
"events": [
{
"introduced": "2.33.0"
},
{
"fixed": "2.33.8"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/coder/coder/v2"
},
"ranges": [
{
"events": [
{
"introduced": "2.30.0"
},
{
"fixed": "2.32.7"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/coder/coder/v2"
},
"ranges": [
{
"events": [
{
"introduced": "2.24.0"
},
{
"fixed": "2.29.17"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-55079"
],
"database_specific": {
"cwe_ids": [
"CWE-789"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-06T20:54:41Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Summary\n\n`NewDataBuilder` in `provisionersdk/proto/dataupload.go` allocated a byte slice using the client-supplied `FileSize` from a `DataUpload` message without an upper-bound check. Although the DRPC wire limit is 4 MiB, the `FileSize` value itself was unconstrained\n\n### Impact\n\nAn authenticated user able to reach the provisioner daemon serve endpoint could send a roughly 50-byte message declaring a huge `FileSize` (for example 1 TiB), triggering an unrecoverable Go out-of-memory abort that terminates `coderd`. This is a single-message denial of service affecting the entire deployment.\n\n### Patches\n\nThe fix validates `FileSize` against an upper bound (`MaxFileSize = 100 MiB`) before allocation.\n\nThe fix was backported to all supported release lines:\n\n| Release line | Patched version |\n|---|---|\n| 2.34 | [v2.34.2](https://github.com/coder/coder/releases/tag/v2.34.2) |\n| 2.33 | [v2.33.8](https://github.com/coder/coder/releases/tag/v2.33.8) |\n| 2.32 | [v2.32.7](https://github.com/coder/coder/releases/tag/v2.32.7) |\n| 2.29 (ESR) | [v2.29.17](https://github.com/coder/coder/releases/tag/v2.29.17) |\n\n### Workarounds\n\nRestrict access to the provisioner daemon serve endpoint to trusted provisioner daemon service accounts.\n\n### Resources\n\n- Fix: #25710\n\n### Credits\n\nCoder would like to thank Anthropic\u0027s Security Team (ANT-2026-22442) for independently disclosing this issue!",
"id": "GHSA-f962-qm93-mj4c",
"modified": "2026-07-06T20:54:42Z",
"published": "2026-07-06T20:54:41Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/coder/coder/security/advisories/GHSA-f962-qm93-mj4c"
},
{
"type": "WEB",
"url": "https://github.com/coder/coder/pull/25710"
},
{
"type": "PACKAGE",
"url": "https://github.com/coder/coder"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Coder\u0027s unbounded memory allocation in provisioner file upload allows authenticated denial of service"
}
GHSA-F984-PCP8-V2P7
Vulnerability from github – Published: 2026-04-10 15:32 – Updated: 2026-04-10 15:32Impact
Wasmtime's Winch compiler backend contains a bug where translating the table.grow operator causes the result to be incorrectly typed. For 32-bit tables this means that the result of the operator, internally in Winch, is tagged as a 64-bit value instead of a 32-bit value. This invalid internal representation of Winch's compiler state compounds into further issues depending on how the value is consumed.
One example can be seen when the result of table.grow is used as the address of a load operation. The load operation is tricked into thinking the address is a 64-bit value, not a 32-bit value, which means that the final address to load from is calculated incorrectly. This can lead to a situation where the bytes before the start of linear memory can be loaded/stored to.
The primary consequence of this bug is that bytes in the host's address space can be stored/read from. This is only applicable to the 16 bytes before linear memory, however, as the only significant return value of table.grow that can be misinterpreted is -1. The bytes before linear memory are, by default, unmapped memory. Wasmtime will detect this fault and abort the process, however, because wasm should not be able to access these bytes.
Overall this this bug in Winch represents a DoS vector by crashing the host process, a correctness issue within Winch, and a possible leak of up to 16-bytes before linear memory. Wasmtime's default compiler is Cranelift, not Winch, and Wasmtime's default settings are to place guard pages before linear memory. This means that Wasmtime's default configuration is not affected by this issue, and when explicitly choosing Winch Wasmtime's otherwise default configuration leads to a DoS. Disabling guard pages before linear memory is required to possibly leak up to 16-bytes of host data.
Patches
Wasmtime 43.0.1, 42.0.2, and 36.0.7 have been released with fixes for this issue.
Workaround
There are no workarounds within the Winch compiler backend while using the affected versions. Users of Wasmtime are encouraged either to upgrade to patched versions or, if that is not possible, use the Cranelift compiler backend.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "wasmtime"
},
"ranges": [
{
"events": [
{
"introduced": "25.0.0"
},
{
"fixed": "36.0.7"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "crates.io",
"name": "wasmtime"
},
"ranges": [
{
"events": [
{
"introduced": "37.0.0"
},
{
"fixed": "42.0.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "crates.io",
"name": "wasmtime"
},
"ranges": [
{
"events": [
{
"introduced": "43.0.0"
},
{
"fixed": "43.0.1"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"43.0.0"
]
}
],
"aliases": [
"CVE-2026-35186"
],
"database_specific": {
"cwe_ids": [
"CWE-789"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-10T15:32:49Z",
"nvd_published_at": "2026-04-09T19:16:25Z",
"severity": "MODERATE"
},
"details": "### Impact\n\nWasmtime\u0027s Winch compiler backend contains a bug where translating the `table.grow` operator causes the result to be incorrectly typed. For 32-bit tables this means that the result of the operator, internally in Winch, is tagged as a 64-bit value instead of a 32-bit value. This invalid internal representation of Winch\u0027s compiler state compounds into further issues depending on how the value is consumed.\n\nOne example can be seen when the result of `table.grow` is used as the address of a load operation. The load operation is tricked into thinking the address is a 64-bit value, not a 32-bit value, which means that the final address to load from is calculated incorrectly. This can lead to a situation where the bytes before the start of linear memory can be loaded/stored to.\n\nThe primary consequence of this bug is that bytes in the host\u0027s address space can be stored/read from. This is only applicable to the 16 bytes before linear memory, however, as the only significant return value of `table.grow` that can be misinterpreted is -1. The bytes before linear memory are, by default, unmapped memory. Wasmtime will detect this fault and abort the process, however, because wasm should not be able to access these bytes.\n\nOverall this this bug in Winch represents a DoS vector by crashing the host process, a correctness issue within Winch, and a possible leak of up to 16-bytes before linear memory. Wasmtime\u0027s default compiler is Cranelift, not Winch, and Wasmtime\u0027s default settings are to place guard pages before linear memory. This means that Wasmtime\u0027s default configuration is not affected by this issue, and when explicitly choosing Winch Wasmtime\u0027s otherwise default configuration leads to a DoS. Disabling guard pages before linear memory is required to possibly leak up to 16-bytes of host data.\n\n### Patches\n\nWasmtime 43.0.1, 42.0.2, and 36.0.7 have been released with fixes for this issue.\n\n### Workaround\n\nThere are no workarounds within the Winch compiler backend while using the affected versions. Users of Wasmtime are encouraged either to upgrade to patched versions or, if that is not possible, use the Cranelift compiler backend.",
"id": "GHSA-f984-pcp8-v2p7",
"modified": "2026-04-10T15:32:49Z",
"published": "2026-04-10T15:32:49Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-f984-pcp8-v2p7"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-35186"
},
{
"type": "PACKAGE",
"url": "https://github.com/bytecodealliance/wasmtime"
},
{
"type": "WEB",
"url": "https://rustsec.org/advisories/RUSTSEC-2026-0094.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:L/VI:L/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Wasmtime has improperly masked return value from `table.grow` with Winch compiler backend"
}
GHSA-FG3J-Q579-V8X4
Vulnerability from github – Published: 2021-06-15 15:54 – Updated: 2022-02-08 21:22In Apache PDFBox, a carefully crafted PDF file can trigger an OutOfMemory-Exception while loading the file. This issue affects Apache PDFBox version 2.0.23 and prior 2.0.x versions.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.pdfbox:pdfbox"
},
"ranges": [
{
"events": [
{
"introduced": "2.0.0"
},
{
"fixed": "2.0.24"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.pdfbox:pdfbox-parent"
},
"ranges": [
{
"events": [
{
"introduced": "2.0.0"
},
{
"fixed": "2.0.24"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-31811"
],
"database_specific": {
"cwe_ids": [
"CWE-770",
"CWE-789"
],
"github_reviewed": true,
"github_reviewed_at": "2021-06-14T19:39:19Z",
"nvd_published_at": "2021-06-12T10:15:00Z",
"severity": "MODERATE"
},
"details": "In Apache PDFBox, a carefully crafted PDF file can trigger an OutOfMemory-Exception while loading the file. This issue affects Apache PDFBox version 2.0.23 and prior 2.0.x versions.",
"id": "GHSA-fg3j-q579-v8x4",
"modified": "2022-02-08T21:22:40Z",
"published": "2021-06-15T15:54:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-31811"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpuoct2021.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpujul2022.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpujan2022.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpuapr2022.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com//security-alerts/cpujul2021.html"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/MDJKJQOMVFDFIDS27OQJXNOYHV2O273D"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/7HHWJRFXZ3PTKLJCOM7WJEYZFKFWMNSV"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rfe26bcaba564deb505c32711ba68df7ec589797dcd96ff3389a8aaba@%3Cnotifications.ofbiz.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rf937c2236e6c79cdb99f76a70690dd345e53dbe0707cb506a202e43e@%3Cannounce.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/re3bd16f0cc8f1fbda46b06a4b8241cd417f71402809baa81548fc20e@%3Cusers.pdfbox.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/re3bd16f0cc8f1fbda46b06a4b8241cd417f71402809baa81548fc20e%40%3Cusers.pdfbox.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/re0cacd3fb337cdf8469853913ed2b4ddd8f8bfc52ff0ddbe61c1dfba@%3Ccommits.ofbiz.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rd4b6db6c3b8ab3c70f1c3bbd725a40920896453ffc2744ade6afd9fb@%3Cnotifications.ofbiz.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r2090789e4dcc2c87aacbd87d5f18e2d64dcb9f6eb7c47f5cf7d293cb@%3Cnotifications.ofbiz.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r179cc3b6822c167702ab35fe36093d5da4c99af44238c8a754c6860f@%3Ccommits.ofbiz.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r143fd8445e0e778f4a85187bd79438630b96b8040e9401751fdb8aea@%3Ccommits.ofbiz.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r132e9dbbe0ebdc08b39583d8be0a575fdba573d60a42d940228bceff@%3Cnotifications.ofbiz.apache.org%3E"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2021/06/12/2"
}
],
"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"
}
],
"summary": "Uncontrolled memory consumption"
}
GHSA-FM65-XRRR-C358
Vulnerability from github – Published: 2026-05-13 18:30 – Updated: 2026-06-16 21:31A vulnerability exists in the ngx_http_scgi_module and ngx_http_uwsgi_module modules that may result in excessive memory allocation or an over-read of data. When scgi_pass or uwsgi_pass is configured, an unauthenticated attacker with man-in-the-middle (MITM) ability to control responses from an upstream server may be able to read the memory of the NGINX worker process or restart it. Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.
{
"affected": [],
"aliases": [
"CVE-2026-42946"
],
"database_specific": {
"cwe_ids": [
"CWE-789"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-13T16:16:50Z",
"severity": "HIGH"
},
"details": "A vulnerability exists in the ngx_http_scgi_module\u00a0and ngx_http_uwsgi_module\u00a0modules that may result in excessive memory allocation or an over-read of data. When scgi_pass\u00a0or uwsgi_pass\u00a0is configured, an unauthenticated attacker with man-in-the-middle (MITM) ability to control responses from an upstream server may be able to read the memory of the NGINX worker process or restart it.\u00a0 Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.",
"id": "GHSA-fm65-xrrr-c358",
"modified": "2026-06-16T21:31:53Z",
"published": "2026-05-13T18:30:56Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42946"
},
{
"type": "WEB",
"url": "https://my.f5.com/manage/s/article/K000161027"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-FPF5-4JW8-67X8
Vulnerability from github – Published: 2026-05-07 01:54 – Updated: 2026-05-07 01:54Impact
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 cherry-pick 57f5fb.
Workarounds
- Do not accept
zserio-encoded messages from non-trusted sources. - Allocate a maximum heap amount to
rust-zerioto avoid impacting other applications.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.5.3"
},
"package": {
"ecosystem": "crates.io",
"name": "rust-zserio"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.5.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-789"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-07T01:54:57Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"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 cherry-pick [57f5fb](https://github.com/Danaozhong/rust-zserio/commit/57f5fb4a2a8611d58dbcc1a9221349206dd99c3c).\n\n### Workarounds\n\n- Do not accept `zserio`-encoded messages from non-trusted sources.\n- Allocate a maximum heap amount to `rust-zerio` to avoid impacting other applications.",
"id": "GHSA-fpf5-4jw8-67x8",
"modified": "2026-05-07T01:54:57Z",
"published": "2026-05-07T01:54:57Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/Danaozhong/rust-zserio/security/advisories/GHSA-fpf5-4jw8-67x8"
},
{
"type": "WEB",
"url": "https://github.com/ndsev/zserio/security/advisories/GHSA-cwq5-8pvq-j65j"
},
{
"type": "WEB",
"url": "https://github.com/Danaozhong/rust-zserio/commit/57f5fb4a2a8611d58dbcc1a9221349206dd99c3c"
},
{
"type": "PACKAGE",
"url": "https://github.com/Danaozhong/rust-zserio"
}
],
"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": "rust-zserio has Unbounded Memory Allocation"
}
GHSA-FW7G-X8Q3-H9PR
Vulnerability from github – Published: 2024-11-15 18:30 – Updated: 2024-11-15 18:30A vulnerability in the TL1 function of Cisco Network Convergence System (NCS) 4000 Series could allow an authenticated, local attacker to cause a memory leak in the TL1 process. This vulnerability is due to TL1 not freeing memory under some conditions. An attacker could exploit this vulnerability by connecting to the device and issuing TL1 commands after being authenticated. A successful exploit could allow the attacker to cause the TL1 process to consume large amounts of memory. When the memory reaches a threshold, the Resource Monitor (Resmon) process will begin to restart or shutdown the top five consumers of memory, resulting in a denial of service (DoS).Cisco has released software updates that address this vulnerability. There are no workarounds that address this vulnerability.This advisory is part of the September 2022 release of the Cisco IOS XR Software Security Advisory Bundled Publication. For a complete list of the advisories and links to them, see .
{
"affected": [],
"aliases": [
"CVE-2022-20845"
],
"database_specific": {
"cwe_ids": [
"CWE-789"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-15T16:15:22Z",
"severity": "MODERATE"
},
"details": "A vulnerability in the TL1 function of Cisco\u0026nbsp;Network Convergence System (NCS) 4000 Series could allow an authenticated, local attacker to cause a memory leak in the TL1 process.\nThis vulnerability is due to TL1 not freeing memory under some conditions. An attacker could exploit this vulnerability by connecting to the device and issuing TL1 commands after being authenticated. A successful exploit could allow the attacker to cause the TL1 process to consume large amounts of memory. When the memory reaches a threshold, the Resource Monitor (Resmon)\u0026nbsp;process will begin to restart or shutdown the top five consumers of memory, resulting in a denial of service (DoS).Cisco\u0026nbsp;has released software updates that address this vulnerability. There are no workarounds that address this vulnerability.This advisory is part of the September 2022 release of the Cisco\u0026nbsp;IOS XR Software Security Advisory Bundled Publication. For a complete list of the advisories and links to them, see .",
"id": "GHSA-fw7g-x8q3-h9pr",
"modified": "2024-11-15T18:30:49Z",
"published": "2024-11-15T18:30:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-20845"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:C/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.