A flaw in the Nuxt Image route: what happened and what we did

On 30 October 2026 the Nuxt team published advisory GHSA-p5vf-pjf5-ggj3 for the Nuxt Image module, rated high severity (CVSS score 8.1). Nuxt Image is a module many sites use to resize and convert images. On a site that runs as a server, the module registers a route called /_ipx automatically, with no configuration.

That route uses a library called ipx to read images. The library has an integer overflow when it decodes a multi page image, such as TIFF, GIF, WebP, or AVIF. A crafted image can corrupt memory while it is decoded. As a result, a single unauthenticated request is enough to crash the server process. Under certain conditions that memory corruption can be used to run code with the privileges of the server process.

The affected versions are Nuxt Image 2.0.0 up to but not including 2.2.1, and 1.0.0 up to but not including 1.11.2. Version 0.x has reached end of life and will not receive a fix.

The risk is real when all three of the following conditions hold:

1. The site runs as a server with the default ipx image provider, so the /_ipx route is active.
2. An attacker can place a crafted image where ipx reads from, for example through an upload feature, a user content host listed in the image domains, or a configuration that allows any image host.
3. The /_ipx route is reachable without authentication, which is the default.

Static builds, sites on edge platforms such as Cloudflare Workers, and sites that use a platform image provider such as Vercel or Netlify do not register this route.

We checked every one of our sites that uses Nuxt Image. Four sites ran an affected version (Nuxt Image 2.0.0 or 2.1.0, with the ipx library at 3.1.1 or 4.0.0 beta). On each site we raised Nuxt Image to 2.2.1, confirmed that the dependency lockfile uses the patched ipx 4.1.0, ran the full test suite, and released it to production. All four sites have been released. After each release we confirmed from the outside that the image route still serves images as it should, on all four sites.

While fixing, we also checked whether anyone had tried to use the flaw. We read the access logs and application logs that are still kept on three of the sites and searched for every request to /_ipx. All we found were ordinary requests for our own images, with no error messages and no sign of a process stopping unexpectedly. One IP address requested about ten of our own images in sequence, and every one of those requests was only redirected, not processed.

We need to state the limits of this check. The logs we still have cover a range from about one hour to about nine days, depending on the site, so this check does not prove that nothing was tried earlier. For the fourth site, which runs on shared hosting, we did not check logs at all. What we can state is that the logs available from three sites show no sign of an attack. The image sources on our sites are also only our own storage, so an attacker has no easy way to place a crafted image.

For maintainers of sites that use Nuxt Image:

1. Upgrade to 2.2.1 (or 1.11.2 if still on the 1.x line), then run npm ls ipx to confirm that ipx moved to a patched version as well.
2. If you cannot upgrade yet, block /_ipx/** at the reverse proxy when the route is not needed, or register your own handler on that route that returns 404.
3. Make sure third party images cannot become an ipx source: keep uploads outside public paths and limit the image domains list to hosts you control. Checking the file extension or Content-Type is not enough, because the decoder is chosen from the file contents.
4. On 2.2.1 and later, turn on the restrictDecoders option if other image formats are not needed, because it blocks the decoders that are not required.

Sources: GHSA-p5vf-pjf5-ggj3 and GHSA-qf89-6xm4-66wm