Andy Garcia · dev freelance
FRENES
Volver al blog
Seguridad

Next.js publicó otros dos parches críticos de ejecución remota de código el 14 de octubre. Uno afecta al modelo que ahora recomienda

19 de octubre de 2026 7 min de lectura

El miércoles 14 de octubre de 2026, el equipo de Next.js publicó una actualización de seguridad fuera de calendario: Next.js 16.4.1 en la línea Active LTS y 15.5.28 en la línea Maintenance LTS. Corrige dos vulnerabilidades Critical, ambas de ejecución remota de código sin autenticación, y una denegación de servicio de gravedad High. El equipo la había anunciado el 8 de octubre y decía que dos de las tres correcciones se habían aplazado desde la publicación de seguridad del 30 de septiembre «por coordinación con upstream».

Ya escribí sobre el parche de emergencia del 25 de agosto. Este merece su propia lectura, por dos razones. El retraso dice algo sobre quién controla hoy el calendario de seguridad de un framework. Y en la línea 16.x, la corrección solo existe en la 16.4, la versión menor que el 6 de octubre empezó a recomendar Cache Components como «la mejor opción para toda aplicación Next.js». Uso Next.js en producción, así que te cuento cómo leo ambas cosas y qué haría con una aplicación existente.

Por qué las correcciones llegaron en una segunda oleada

La cronología está entera en el blog de Next.js. El 23 de septiembre, el equipo anunció una publicación programada para el 30 de septiembre. El 30 de septiembre, una nota añadida a ese anuncio cambió la cuenta: la publicación «ahora corrige siete vulnerabilidades en lugar de nueve», y las dos restantes, una Critical y una High, estaban «pendientes de coordinación con upstream». La publicación de septiembre salió como 16.3.8 y 15.5.27. El 8 de octubre llegó el aviso para el 14 de octubre.

El aviso del 8 de octubre nunca nombra el upstream. El artículo del 14 de octubre y los advisories sí. Dos de los tres advisories de octubre tienen un gemelo en el propio repositorio de React. La ejecución remota de código en las funciones use cache (GHSA-673q-mjm6-r5xr) remite a GHSA-xqc2-xf4c-x3h3, «Unauthenticated Remote Code Execution in React Server Components». La denegación de servicio de las Server Actions remite a GHSA-h3gv-c5rc-p453. Ambas afectan a los paquetes react-server-dom para webpack, Turbopack y Parcel, y React retroportó las correcciones a cuatro líneas de versiones: 19.0.9, 19.1.10, 19.2.9 y 19.3.1. El tercer bug está en «una biblioteca upstream usada para la optimización de imágenes», y su solución alternativa es sharp 0.35.5 o posterior.

El registro de npm muestra la coreografía. Las cuatro versiones corregidas de react-server-dom-webpack del lado de React aparecieron entre las 16:49 y las 16:55 UTC del 14 de octubre. Next.js 15.5.28 llegó a las 17:36 y 16.4.1 a las 17:43. Cuatro líneas de React y dos de Next.js en menos de una hora.

Next.js no dice qué upstream causó la espera, ni cuál de los dos bugs Critical fue el aplazado. Una cosa se deduce por eliminación: septiembre retuvo una Critical y una High, y octubre tiene una sola High. Así que la denegación de servicio de las Server Actions salió 14 días después de la publicación a la que estaba destinada.

Esa es la lección práctica. Cuando un bug vive en una capa compartida como los React Server Components, un framework no puede publicar solo. Su fecha pasa a ser la de la publicación coordinada más lenta. Para quien usa Next.js, las entradas de «próxima actualización de seguridad» son la señal real: el aviso del 8 de octubre dejaba seis días para reservar un hueco de actualización.

Qué está expuesto, y el detalle en el lockfile

El bug de use cache (CVSS 9,5) afecta de la 16.0.0 a la 16.4.0, en aplicaciones App Router con Cache Components, cuando una función use cache devuelve varios arrays tipados. No hay solución alternativa, y el advisory dice que hay que actualizar «aunque tu aplicación no tenga funciones similares». La primera versión corregida es la 16.4.1. No existe una 16.3.9 en npm. Si te quedaste en la 16.3.8 después de septiembre, la corrección de seguridad llega ahora con una actualización menor: React 19.3, cambios en Turbopack, nuevas API.

El bug de imágenes, CVE-2026-96889 (también 9,5 en el advisory de Next.js), se aplica cuando Next.js corre en Linux basado en glibc. El advisory de sharp sitúa el fallo en librsvg, que los binarios precompilados de sharp incluyen, así que la solución alternativa es una versión de sharp. Este es el detalle que es fácil pasar por alto. Next.js 16.4.1 declara sharp como ^0.35.5, por lo que la actualización fuerza una versión corregida. Next.js 15.5.28 declara ^0.34.3 || ^0.35.5. Una aplicación 15.5 cuyo lockfile ya resuelve sharp 0.34.x cumple ese rango y la conserva tras la actualización. El advisory de Next.js nombra la 0.35.5 como mínimo, y el advisory de sharp para el mismo CVE lista como vulnerable toda versión anterior a la 0.35.5: no existe una 0.34.x corregida. En la 15.5, comprobaría qué sharp resuelve realmente el lockfile, no solo la versión de Next.js. sharp 0.35.5 está en npm desde el 27 de septiembre, y sharp publicó su advisory el 30 de septiembre, dos semanas antes que Next.js.

La denegación de servicio (CVSS 8,2) afecta a las aplicaciones App Router con al menos una Server Action, desde la 13.0.0. Las aplicaciones Pages Router y las que no tienen Server Actions no están afectadas. No hay solución alternativa salvo actualizar. Igual que el bug de imágenes, que se remonta a la 10.0.0, no tiene corrección por debajo de la 15.5.28: una aplicación que sigue en 13.x o 14.x tiene que cambiar de versión mayor para obtenerla.

Cache Components ya tiene historial de seguridad

Pon las dos publicaciones una al lado de la otra. La del 30 de septiembre tenía siete advisories, dos de ellos en use cache: una clave de caché que podía filtrar contenido entre valores de root params, y un llenado de caché pendiente que podía filtrar contenido de Draft Mode en respuestas normales y páginas persistidas. Los dos en Medium. El 14 de octubre añadió la Critical. Tres advisories de diez, en dos publicaciones, tocan la directiva que está en el centro del modelo que Next.js recomienda ahora.

No lo leo como una razón para evitar Cache Components. Los caminos de código nuevos son donde miran los investigadores, y este es un modelo joven que recibe mucha atención. Lo leo como un coste de adopción: si lo activas, tu cadencia de parches tiene que ser más ajustada que antes.

Esta es la parte tranquilizadora. Actualizar a la 16.4.1 no activa Cache Components. El artículo de la 16.4 dice que se usa el modelo «activando dos flags», cacheComponents y partialPrefetching. Solo las aplicaciones nuevas creadas con create-next-app lo traen por defecto. El parche y la migración son dos decisiones separadas.

Qué cambia realmente la migración

El artículo de la 16.4 dice que Cache Components «será el predeterminado en Next.js 17» y no da fecha para la 17. El coste está en la guía de migración:

  • Las configuraciones de segmento de ruta dynamic, revalidate y fetchCache dan error en cuanto se activa el flag, y exportar dynamicParams hace fallar el build.
  • use cache usa por defecto almacenamiento en memoria: las entradas se descartan cuando se destruye una instancia serverless, y están limitadas a un único despliegue. El antiguo Data Cache de fetch y unstable_cache persisten entre despliegues e instancias serverless. use cache: remote o un cache handler sobrevive a la destrucción de la instancia, pero incluso con almacenamiento duradero la guía dice que hay que esperar que los valores en caché se recalculen tras un nuevo despliegue. Eso es una línea en la factura de hosting, no solo un refactor.
  • El estado de los componentes ahora sobrevive a la navegación. Los formularios conservan sus valores y los desplegables siguen abiertos, porque las rutas se ocultan con Activity de React en lugar de desmontarse.
  • generateStaticParams que devuelve un array vacío ahora da error.
  • new Date(), Math.random() y crypto.randomUUID() durante el prerenderizado hacen fallar el build, incluso en las rutas excluidas con instant = false.
  • Requiere Next.js 16.

Nada de esto es exótico. Todo es trabajo.

El reloj de la 15.x

La política de soporte de Next.js dice que cada versión mayor permanece en Maintenance LTS «durante dos años tras su lanzamiento inicial». Next.js 15 se lanzó el 21 de octubre de 2024. Según la aritmética de la propia política, su ventana termina el 21 de octubre de 2026. La página no indica fecha de fin, y mantiene una cláusula para corregir versiones fuera de la política «en circunstancias excepcionales». Aun así planificaría como si la 15.5.28 pudiera ser una de las últimas correcciones rutinarias de esa línea. Y como Cache Components exige la 16, una aplicación 15.x se enfrenta a dos actualizaciones, no a una.

Qué haría

Parchear primero, solo. Una 16.x pasa a 16.4.1 o posterior, la 15.5 pasa a 15.5.28. Una única pull request sin nada más, para que un rollback siga siendo un rollback. Después, confirmar sharp en 0.35.5 o posterior, en el lockfile y en el build desplegado.

Si Cache Components ya está activo en producción, lista todas las funciones use cache. Estabas dentro del alcance del bug Critical y, si sirves previsualizaciones de Draft Mode, de uno de los de septiembre.

En la 15.x, programa ya el paso a la 16, como proyecto aparte.

Para la migración, usa una rama y el camino incremental que describe la guía: el codemod cache-components-instant-false excluye cada ruta de la validación, corriges la E/S síncrona (lo único que la exclusión no aplaza) y luego conviertes las rutas una a una. Antes de fusionar, despliega dos veces y observa cómo se comporta la caché tras el segundo despliegue, y haz clic en cada formulario que tengas.

Yo orquesto mi trabajo con Claude Code, así que next upgrade --agent y la skill de adopción de Cache Components apuntan a gente como yo. El comando prepara para el agente guías de migración, codemods y pasos de verificación. Lo que comprobaría antes de dejar que un agente lo ejecute: que la actualización de seguridad y la migración lleguen en pull requests separadas, que la versión de sharp resuelta sea la correcta y que la verificación incluya un despliegue real, no solo un build local. La 16.4 añade también experimental.agentUpgrade, cuya política por defecto, 'security', te recuerda durante next dev y next build las actualizaciones que corrigen vulnerabilidades conocidas en tu versión instalada. La dejaría activada.

El parche es un cambio de versión. La migración cambia cómo tu aplicación cachea, renderiza y factura. Next.js 17 decidirá el valor por defecto. Tú decides el orden.

Fuentes

¿Un proyecto del mismo estilo?

Diseño y despliego productos como este. Hablemos.

Hablemos