Nuxt Image advisory: unauthenticated attacks via default /_ipx route

@nuxt/image registers the /_ipx image transformation route by default on server deployments and serves it with ipx. A GitHub advisory says ipx has an integer overflow (GHSA-qf89-6xm4-66wm) when decoding multi-page images, so a crafted source image can corrupt memory during decoding. An attacker who controls a source image may use one unauthenticated request to crash the server process, and the memory corruption may allow remote code execution with that process's privileges.

Affected deployments and versions

The issue affects deployments where the site runs as a server with the default ipx provider, so /_ipx is registered without configuration; attacker-controlled image bytes can become an IPX source; and /_ipx is reachable without authentication, which is the default. No special modifier is needed, and a single request is enough. Affected @nuxt/image versions are >= 2.0.0 and < 2.2.1, >= 1.0.0 and < 1.11.2, and >= 0.6.0 and < 1.0.0. Deployments using a platform image provider are not affected as long as image.ipx is not also configured; edge or worker runtimes such as Cloudflare Workers do not register the route, and static builds do not register it either. In the reported reproduction, the server process ran as root in a stock container, putting secrets, source code and uploaded data in the container within reach.

Patched releases

Fixed in @nuxt/image 2.2.1 and 1.11.2, which require patched ipx 4.1.0 and 2.1.2 respectively. Before decoding all pages of a multi-page image such as TIFF, GIF, WebP or AVIF, those versions check the image's total height and reject the request with 400 if it is too large. Version 2.2.1 also limits /_ipx to common web image formats by default: a source whose detected format is not JPEG, PNG, WebP, GIF, SVG, AVIF or HEIC is rejected with 403 before it is decoded. To accept other formats, set image.ipx.allowedInputFormats. If sources are not fully trusted, the advisory also recommends enabling image.ipx.restrictDecoders, which blocks decoders of every other format; it applies to every use of sharp in the server process. These two options are not available on 1.x. Nuxt Image 0.x has reached end of life and will not receive a fix. ipx is an optional dependency, so after upgrading, check that it resolves to a patched version, for example with npm ls ipx, and upgrade it directly if the project also depends on it.

Workarounds and severity

If you cannot upgrade yet, register your own server handler on the /_ipx route, for example one that returns 404; the module detects an existing handler and does not install its own. You can also block /_ipx/** at your reverse proxy if the route is not needed. Make sure attacker-controlled bytes cannot become an IPX source: keep uploads outside served public paths, and restrict image.domains to hosts you control. Checking the file extension or Content-Type of uploads is not enough, since the decoder is chosen from the file's contents. Restricting modifiers with allowedModifiers does not help, because the issue is reachable without any modifier. The advisory severity is High with an overall CVSS score of 8.1. CVSS v3 base metrics list network attack vector, high attack complexity, no privileges required, no user interaction, unchanged scope, and high confidentiality, integrity and availability impact. There is no known CVE. The weakness is CWE-20, Improper Input Validation. Credits go to @l8BL for the detailed report, reproduction and coordinated disclosure. The advisory was published Oct 30, 2026 under GHSA-p5vf-pjf5-ggj3.

Sources: GitHub Advisory · IPX Advisory · Cloudflare · GitHub