Should I update: sharp@0.35.3 with breaking changes for node_modules/ipx > @indiekit/endpoint-image?

[eclecticpassions]

Report from npm audit:

# npm audit report

sharp  <0.35.0
Severity: high
sharp inherited vulnerabilities in libvips: CVE-2026-33327, CVE-2026-33328, CVE-2026-35590, CVE-2026-35591 - https://github.com/advisories/GHSA-f88m-g3jw-g9cj
fix available via `npm audit fix --force`
Will install sharp@0.35.3, which is a breaking change
node_modules/sharp
  ipx  <=4.0.0-alpha.1
  Depends on vulnerable versions of sharp
  node_modules/ipx
    @indiekit/endpoint-image  *
    Depends on vulnerable versions of ipx
    node_modules/@indiekit/endpoint-image
      @indiekit/indiekit  >=1.0.0-alpha.0
      Depends on vulnerable versions of @indiekit/endpoint-image
      node_modules/@indiekit/indiekit

4 high severity vulnerabilities

To address all issues (including breaking changes), run:
  npm audit fix --force

Should I go ahead with the fix --force or wait for endpoint-image and/or ipx to support the new version of sharp v0.35.3 first?

[eclecticpassions]

@paulrobertlloyd, sorry to ping. I don't know how to assess if this vulnerability is urgent to fix. Will --force break the functionality of Indiekit? If not, I would want to fix it asap due to the many CVEs listed. Thanks.

[paulrobertlloyd]

I’m aiming to get a release out later today which will update some dependencies. Looking into this it looks like it has a dependency on ipx v4.0.0-alpha.1, which is a breaking change. I’ll look into seeing whether I can use this alpha version and reduce the number of audit issues.

[paulrobertlloyd]

This is fixed in 17eca52

[rmdes]

Not Paul, but I ran into this exact failure today and can answer the "will --force break it?" half concretely.

Short answer: yes, if it moves ipx off 4.x it breaks Indiekit at startup — and you probably don't need it to fix the sharp CVEs anyway.

packages/endpoint-image/index.js on main imports:

import { createIPX, ipxFSStorage, ipxHttpStorage, createIPXNodeHandler } from "ipx";

and packages/endpoint-image/package.json pins "ipx": "4.0.0-beta.1". I unpacked both versions from npm to check what actually exports that symbol:

	exports createIPXNodeHandler	its own sharp dep
ipx@4.0.0-beta.1	yes (3 files in dist)	^0.35.3
ipx@3.1.1	no	^0.34.3

So two things follow.

1. ipx@4.0.0-beta.1 already requires sharp@^0.35.3. If your lockfile is resolving an older sharp, that is a stale resolution rather than something Indiekit is pinning — npm install (or deleting node_modules and the lockfile entry for sharp) should bring 0.35.3 in on its own, without --force. Worth checking npm ls sharp first to see what you actually have and why.

2. If --force moves ipx to 3.x it will break the server, not just the image endpoint. The import is top-level ESM, so it fails during plugin loading before anything serves. I hit this today on a checkout whose node_modules was out of step with the lockfile:

SyntaxError: The requested module 'ipx' does not provide an export named 'createIPXNodeHandler'
    at getInstalledPlugins (packages/indiekit/lib/plugins.js:11:41)
    at Indiekit.installPlugins (packages/indiekit/index.js:160:5)
    at Indiekit.server (packages/indiekit/index.js:189:5)

Every test that boots a server failed with it. In my case a plain npm install fixed it — the lockfile was right, the installed tree wasn't.

One caveat on scope: I have not run npm audit fix --force against your tree, so I can't say which version it would actually pick for you — 4.0.0-beta.1 being a prerelease makes that harder to predict than usual. Before running it, npm ls ipx sharp and then a dry run would tell you whether it intends to touch ipx at all. If it leaves ipx alone and only bumps sharp, you should be fine.