Record 2.0.3 as the first patched version for GHSA-w3rx-r6r6-pgpr (image-size ICNS)

[DrDustinEdwards]

Records 2.0.3 as the first patched version, replacing last_affected: 2.0.2, and adds the upstream fix commit as a FIX reference.

Why the range needs changing

The advisory currently ends at last_affected: 2.0.2, which was accurate when it was published: 2.0.2 was the newest version in existence. A fix has since been released, so the range can now carry the stronger statement, and fixed is the field remediation tooling reads to construct an upgrade target. With only last_affected present, automated remediation has nothing to aim at and opens nothing, which is how this came to my attention.

The fix

Upstream commit e6e83a5578961de81f6d5834d90fb7430d8f29a5, "fix infinite loops to satisfy security theatre", touches lib/types/icns.ts, lib/types/jxl.ts and lib/types/heif.ts and adds three regression fixtures, one of which is specs/images/invalid/icns-zero-length-entry.icns, the exact input this advisory describes. It is the commit immediately before the 2.0.3 release commit fa82e6b9eeb33ad871a6f753319776b602161f85.

Verified in the bytes published to npm rather than inferred from the version number. image-size@2.0.2 has:

// dist/types/icns.mjs
while (imageOffset < fileLength && imageOffset < inputLength) {
  const imageHeader = readImageHeader(input, imageOffset)
  ...
  imageOffset += imageHeader[1]   // a UInt32BE read from the file
}

A zero entry length never advances imageOffset, which is the loop this advisory describes. image-size@2.0.3 adds the guard that makes the loop always advance:

// dist/esm/types/icns.js
const entryLength = imageHeader[1]
if (entryLength < 8) {
  throw new TypeError('Invalid ICNS')
}

2.0.3 is the first release containing it: 2.0.0, 2.0.1 and 2.0.2 do not, and 2.0.4 differs from 2.0.3 only by an unrelated bounds check in the ICO parser.

One thing a reviewer should know

The project has moved from GitHub to Codeberg. The PACKAGE reference still points at github.com/image-size/image-size, whose last push is 2026-06-03 and whose newest release is v2.0.2; the pull request this advisory cites resolves only through its web.archive.org snapshot. The active repository is codeberg.org/image-size/image-size, which is where the fix commit lives and why the FIX reference points there. 2.0.3 and 2.0.4 were published to npm on 2026-09-14 by the same maintainer account that published 2.0.2, and carry no upstream git tags. I have left the PACKAGE reference alone, since changing it is a separate improvement to a separate field, but it looks stale and you may want it.

The sibling advisory GHSA-5p2g-fcmc-qvqq covers the JXL and HEIF loops fixed by the same commit. It is submitted separately, per the one-advisory-per-pull-request rule in CONTRIBUTING.

[xiao201208]

Independent confirmation with a runtime repro.

Crafted ICNS: 100 bytes, magic icns, declared file length 100, one ic07 entry at offset 8 whose 4-byte length field at offset 12 is 0. Passed to imageSize():

version	result
2.0.2	hung — killed after 6118 ms, event loop never returned
2.0.3	threw TypeError: Invalid ICNS in 4 ms

2.0.2 advances with imageOffset += imageHeader[1], so a zero entry length leaves imageOffset at 8 and the loop condition stays true indefinitely while the images array grows without bound. 2.0.3's entryLength < 8 guard throws before that.

Same downstream cost as the sibling advisory: in aliyun/elastic-compute-control-cli Dependabot saw first_patched_version: null, opened no pull request, and the alert sat open from 2026-08-10 until a maintainer traced npm by hand and bumped the lockfile (#80, merged 2026-09-22). It flipped to fixed 4 seconds after the merge commit landed.