Next.js 16.4.1 y 15.5.28: corregir las fallas RCE en un VPS

Qué se publicó el 14 de octubre

Lo esencial

• GHSA-673q-mjm6-r5xr (crítica) — ejecución remota de código sin autenticación en una aplicación App Router con Cache Components, cuando una función use cache devuelve varios arreglos tipados. No se conoce ninguna solución alternativa. El aviso indica el rango 16.0.0 a 16.4.0 y una puntuación CVSS de 9.5.
• CVE-2026-96889 / GHSA-2464-fhr4-w9xw (crítica) — ejecución remota de código a través de una biblioteca de origen de la API de optimización de imágenes, cuando se usan archivos SVG, en Linux basado en glibc. Puntuación de 9.5. Medida oficial: sharp 0.35.5 o superior.
• GHSA-p3m5-59mp-jv5r (alta) — denegación de servicio en una aplicación App Router con al menos una Server Action: peticiones manipuladas saturan el procesador y bloquean las siguientes peticiones del mismo proceso. Puntuación de 8.2. El Pages Router, o la ausencia de Server Actions, no está afectado.
• Versiones corregidas — 16.4.1 para la línea 16 y 15.5.28 para la línea 15, con los comandos oficiales npm install [email protected] y npm install [email protected].
• Sin CVE en dos avisos de tres — solo la RCE de imágenes lleva un identificador CVE. Los otros dos se siguen por su identificador GHSA: una herramienta que solo busque CVE los pasará por alto.
• Incluso sin uso directo — para la RCE de use cache, Vercel pide actualizar aunque la aplicación no contenga una función similar.

Sin use cache ni SVG, por qué no basta

Qué versión instalar según su línea

Desplace la tabla

Saber qué está funcionando realmente

Hacer inventario en cinco comprobaciones

1. 01

   Leer las versiones de Next.js y de sharp

   Desde la raíz del proyecto: npm ls next sharp, o pnpm why sharp con pnpm. Para la versión exacta de Next.js: node -p "require('next/package.json').version". Un sharp inferior a 0.35.5 bajo next hay que corregirlo.

2. 02

   Localizar Cache Components y use cache

   grep -rn "cacheComponents" next.config.* y después grep -rln "use cache" app src. Si cacheComponents no aparece, su aplicación no recorre el camino descrito en el aviso. Actualice igualmente: Vercel lo pide en todos los casos.

3. 03

   Localizar el uso de SVG

   grep -rn "dangerouslyAllowSVG\|remotePatterns" next.config.* y find public -name "*.svg". Por defecto, la documentación indica que Next.js no optimiza las imágenes SVG y que dangerouslyAllowSVG las permite. La ausencia de este ajuste es buena señal, no una prueba: el aviso no detalla el camino exacto.

4. 04

   Localizar las Server Actions

   grep -rln "use server" app src. Un solo archivo basta para que una aplicación App Router quede expuesta a la denegación de servicio.

5. 05

   Reconocer la biblioteca C del sistema

   ldd --version muestra GNU libc en Debian, Ubuntu, AlmaLinux o Rocky, y musl libc en Alpine. El aviso solo menciona glibc y no dice nada de musl: no deduzca que Alpine se libra. En un contenedor: docker exec <contenedor> ldd --version.

Actualizar y luego revisar el lockfile

Redesplegar según su entorno

1. 06

   Validar la construcción

   npm ci, después npm run build y luego npm ls next sharp. Si la construcción falla por Node, compruebe la versión que exige la línea elegida.

2. 07

   PM2

   Construya en el directorio que ejecuta PM2 y después pm2 reload <nombre>. Compruebe con pm2 describe <nombre> que el directorio de ejecución es el que acaba de reconstruir: con un esquema de releases, un enlace simbólico olvidado reinicia el código antiguo.

3. 08

   Docker

   Reconstruya sin caché: docker build --no-cache -t miapp:corregida ., o al menos invalide la capa npm ci. Reinicie con docker compose up -d --force-recreate. Compare después la imagen del contenedor en marcha (docker inspect -f '{{.Image}}' <contenedor>) con la que acaba de construir.

4. 09

   Coolify

   Lance un redespliegue que ignore la caché de construcción y lea el registro: el paso de instalación de dependencias debe ejecutarse, no figurar como reutilizado. Un simple reinicio no reconstruye nada.

5. 10

   Demostrar la corrección

   Lea la versión en el proceso en marcha, no en el repositorio: docker exec <contenedor> node -p "require('next/package.json').version" debe mostrar 16.4.1 o 15.5.28 (o una versión más reciente de la misma línea). Compruebe sharp con docker exec <contenedor> grep '"version"' node_modules/sharp/package.json, que debe mostrar 0.35.5 o superior.

Si no puede redesplegar hoy

Mitigaciones provisionales, no correcciones

• Subir solo sharp — es la medida oficial para la RCE de imágenes: sharp 0.35.5 o superior. Compruebe que la construcción pasa y que la optimización de imágenes sigue funcionando.
• No servir SVG con el optimizador — deje dangerouslyAllowSVG desactivado y no lo active sin una necesidad demostrada.
• Restringir images.remotePatterns — limite las fuentes remotas que acepta el optimizador a los hosts que usted controla.
• Node como ejecutable PIE — el aviso de sharp cita este modo para reducir el riesgo de ejecución de código, y precisa que los binarios oficiales de Node.js no son PIE.
• Reducir el daño posible — proceso sin permisos de root, contenedor de solo lectura (docker run --read-only), ningún secreto innecesario en el entorno.
• Limitar el caudal delante de Next.js — una regla limit_req en nginx y una alerta de procesador frenan una denegación de servicio sin impedirla.

Tras la corrección: vigilar y planificar la línea 15

La documentación oficial