Next.js npm Audit Flags sharp: Test the Override on Vercel

A clean install of Next.js 16.2.11 can resolve sharp 0.34.5 and make an audit report GHSA-f88m-g3jw-g9cj. The obvious response is to force sharp 0.35.x. That removes the affected version, but it can create a separate runtime failure on Vercel if you do not test the image-processing path after deployment.

The practical response is a short exposure check followed by a preview deployment. Confirm which sharp version is installed, decide whether the application processes untrusted images, apply the smallest supported update, and invoke the real server path before promoting it.

Why Next.js still resolves the affected line

The Next.js issue that reproduces the audit warning uses Next.js 16.2.11 and reports sharp 0.34.5. A Next.js maintainer notes that sharp is an optional dependency and suggests using the package manager's override mechanism when it is installed.

Next.js 16.2.12 is newer, but its published package manifest still declares sharp as an optional dependency with the range ^0.34.5. The 16.2.12 release notes list documentation and TypeScript 7 work, not a sharp update. Upgrading from 16.2.11 to 16.2.12 alone therefore does not move this dependency to 0.35.x.

The sharp advisory marks versions before 0.35.0 as affected and says the risk applies to software that processes untrusted input. It recommends the current sharp release, listed as 0.35.3 when the advisory was updated, for users of sharp's prebuilt binaries.

Check the installed path before changing it

Start with the lockfile you actually deploy. These commands are diagnostic examples. Use the one for your package manager.

npm ls next sharp
# or
pnpm why sharp

Record three facts: the Next.js version, the resolved sharp version, and which package introduced sharp. Then identify the code path that can call it. A direct upload handler that passes user files to sharp has a different exposure from an application that never accepts images.

Do not treat optional dependency as meaning harmless or unused. It describes how the package is installed, not whether a deployed path can execute it. Check the framework image optimizer, custom loaders, Server Actions, Route Handlers, background jobs, and any direct sharp imports.

Choose a response from the exposure

If your application imports sharp directly, add a supported 0.35.x release as a direct dependency, regenerate the lockfile, and run the image tests. That makes ownership explicit instead of relying on the version selected through Next.js.

If sharp arrives only through Next.js, a package-manager override is the current maintainer-suggested control. The syntax below is illustrative. Pin the exact reviewed release your team intends to deploy and inspect the lockfile rather than copying a floating range.

{
  "overrides": {
    "sharp": "0.35.3"
  }
}

For pnpm 11, put project overrides in pnpm-workspace.yaml rather than the old package.json pnpm field. Use the pnpm 11 override migration note if the repository still keeps overrides in package.json.

The advisory also documents a code-level workaround that blocks GIF, TIFF, and VIPS decoders. That option is relevant only when your own code controls the sharp instance and those formats are not required. It is not a general substitute for upgrading, and it does not automatically change Next.js internals.

The Vercel runtime trap

A separate sharp issue reports sharp 0.35.3 building successfully in a Next.js 16.2.10 Vercel deployment, then failing when a Server Action invokes it. The reported error is ERR_DLOPEN_FAILED for libvips-cpp.so.8.18.3. Downgrading removed that runtime error, but returns to the affected sharp line, so it is not a security fix.

That report is specific to Vercel, Turbopack, pnpm 11.9.0, and a Server Action. It does not prove that every Next.js deployment with sharp 0.35.3 fails. It does prove that a successful install and build are not enough evidence for this update.

Deploy a preview and invoke the exact route that loads sharp. Upload a representative image through the same Server Action, Route Handler, or job entrypoint used in production. Check runtime logs for native-module loading errors. If the preview fails, keep production unchanged and track the upstream Next.js issue rather than accepting a vulnerable downgrade as the final state.

A safe rollout checklist

1. Create a small dependency-only change and save the current Next.js, sharp, Node.js, package-manager, and deployment runtime versions.

2. Add the direct dependency or override, install from a clean state, and review the lockfile. Confirm that no sharp version below 0.35.0 remains.

3. Run the package-manager audit again. Keep its output with the change so the reason for the override is reviewable.

4. Run the normal lint, typecheck, tests, and production build. Add an image-processing test that uses an accepted format and a rejected or malformed input.

5. Deploy a preview on the same platform and architecture as production. Invoke the real sharp path after the deployment is live.

6. Promote only after the runtime check passes. Keep the previous known-good deployment available while the override and native binary change settle.

7. Track the Next.js issue and remove the override when a stable Next.js release declares a compatible patched sharp range and your deployed test confirms it.

What not to claim from the audit

An audit warning tells you that the installed dependency matches an advisory. It does not, by itself, describe whether your application exposes the affected operation to untrusted input. The sharp advisory gives that exposure condition, so include it in triage without using it to dismiss the update.

The current evidence also does not support saying Next.js 16.2.12 fixes the warning, or that every Vercel deployment breaks with sharp 0.35.3. Keep the statement narrow: affected sharp versions can be resolved through current Next.js packages, an override is available, and at least one Vercel Server Action setup has a reported runtime conflict.

The useful finish line is not a green audit command on a laptop. It is a lockfile without the affected sharp line and a deployed image path that still runs.