Replace unmaintained dependency image-size with active CVEs (CVSS 7.5)

[rainecheck]

Have you read the Contributing Guidelines on issues?

• I have read the Contributing Guidelines on issues.

Prerequisites

• I'm using the latest version of Docusaurus.
• I have tried the npm run clear or yarn clear command.
• I have tried rm -rf node_modules yarn.lock package-lock.json and re-installing packages.
• I have tried creating a repro with https://new.docusaurus.io.
• I have read the console error message carefully (if applicable).

Description

MDX Loader pulls in image-size. This dependency is now archived, see https://github.com/image-size/image-size#tired-maintainer-doesnt-want-your-slop

Two active CVES: CVE-2025-71329, CVE-2025-71330
CVE CWE: 835

See https://joshua.hu/image-size-infinite-loop-dos-vulnerabilities for practical info.

I image there will be an alternative fork out there somewhere, or another util that could be used.

Reproducible demo

No response

Steps to reproduce

$ yarn why image-size
yarn why v1.22.22
[1/4] 🤔  Why do we have the module "image-size"...?
[2/4] 🚚  Initialising dependency graph...
[3/4] 🔍  Finding dependency...
[4/4] 🚡  Calculating file sizes...
=> Found "image-size@2.0.2"
info Reasons this module exists
   - "@docusaurus#core#@docusaurus#mdx-loader" depends on it
   - Hoisted from "@docusaurus#core#@docusaurus#mdx-loader#image-size"
info Disk size without dependencies: "748KB"
info Disk size with unique dependencies: "748KB"
info Disk size with transitive dependencies: "748KB"
info Number of shared dependencies: 0

Expected behavior

Less CVEs in my pipelines ;(

Actual behavior

2 CVEs in my pipeline :(

Your environment

Self-service

• I'd be willing to fix this bug myself.

[Oliver-ke]

I'm happy to work on this. Can it be assigned to me?
The plan is to replace image-size with a maintained, lightweight dimension reader as well as doing proper regression tests

[1012ayush]

Hi @Oliver-ke, I saw your comment and wanted to let you know that I have already implemented this fix in PR #12235.

I’ve replaced image-size with image-dimensions, updated the loader logic to use a secure buffer-based approach, and verified it with the project's test suite. Since the fix is already submitted and passing checks, you might want to save your time for other issues—but please feel free to take a look at the PR if you're interested in the implementation!

[slorber]

Although I understand it's annoying to get CVE warnings, these are usually harmless for us because a DoS due to a malicious image can only affect the build, not your live website. And you are normally in control of all image inputs, so you can only DoS yourself by adding a malicious image to your Git repo. If an attacker has access to your Git repo, you have more important problems to solve in the first place.

It's similar to ReDoS CVEs: those do not really affect us compared to projects with a server runtime.
See also: https://overreacted.io/npm-audit-broken-by-design/

---

I'm ok to consider swapping the image-size lib. However, other libs such as image-dimensions behave differently, so this will be a breaking change, and the impact of this swap must be analyzed first and minimized for our community.

If you are not ready to do this analysis and provide a non-disruptive rollout plan, don't submit a vide-coded PR, because the majority of the work is not the code swap itself, but the impact analysis and rollout plan.

If the impact is important, and it could annoy users, a possible solution would be to do the swap the default lib, and expose a siteConfig.markdown.hooks.measureImage() hook. Users could still fall back to the former image-size lib if they really need to.

[tats-u]

For pnpm users:

audit:
  ignore:
    - GHSA-w3rx-r6r6-pgpr # image-size is abandoned and published built pages themselves won't be affected
    - GHSA-5p2g-fcmc-qvqq # ditto