Next.js saca un parche de seguridad fuera de banda el 14 de octubre: qué le pasa a tu runbook cuando el calendario se rompe

Next.js publicará el miércoles 14 de octubre una actualización de seguridad fuera de banda: tres vulnerabilidades en dependencias upstream —dos críticas y una alta— y dos de ellas aplazadas del release programado de septiembre. Los advisories completos salen ese mismo día, así que hoy no existe un número de versión parcheada al que apuntar; lo único que decides hoy es cómo llegas al miércoles, y ahí es donde un runbook construido sobre «los parches son eventos de calendario» se queda corto. Nosotros escribimos ese runbook en agosto. Esta semana hay que ajustarlo en dos puntos.

Lo que se anunció el 8 de octubre

El 8 de octubre, Josh Story, Karim Rahal y Sebastian Silbermann publicaron en el blog de Next.js un aviso con una estructura que ya nos resulta familiar: fecha, severidad, número de vulnerabilidades y una promesa de advisory completo el día del release. La frase que cambia el guion es esta: «Two of these fixes were postponed from the September security release due to upstream coordination».

Es decir, dos de los tres agujeros ya se sabían desde septiembre. No falló la detección, falló la coordinación con un proyecto externo del que Next.js depende. Y cuando eso pasa, la fecha que tenías en el calendario deja de ser confiable.

La tercera vulnerabilidad —el aviso habla de dos críticas y una alta, mientras septiembre aplazó un crítico y una alta— es la cuenta que no cierra del todo. O hay un crítico nuevo desde entonces o la clasificación cambió con la coordinación. Lo dirá el advisory el miércoles; mientras tanto, asumir «son las dos de septiembre y punto» es exactamente el tipo de tranquilidad que cuesta caro.

Los últimos cinco golpes, en una tabla

Antes de decidir nada conviene ver el patrón. Estos son los releases de seguridad de Next.js desde que Vercel formalizó el programa el 13 de julio:

Dos lecturas de esa fila. Primera: en los últimos tres releases, dos han sido fuera de banda. El calendario mensual sigue existiendo, pero ya no es el único camino por el que llega una vulnerabilidad crítica a producción. Segunda: la salida del 30 de septiembre tiene una trampa documentada — Next.js 16.3.7, publicada el 29 de septiembre, es un bugfix sin ninguno de los arreglos de seguridad, que llegaron al día siguiente en la 16.3.8. «Estoy en la versión más reciente» no es lo mismo que «estoy parcheado».

«Upstream» es la palabra que importa

Cuando el 22 de septiembre saltó el RCE de next/og, el problema no estaba en el código de Next.js: estaba en Satori, la librería que Next.js empaqueta para generar imágenes OG, y en otras dependencias aguas arriba que convertían un SVG mal escapado en ejecución de código. Next.js solo tenía que subir de versión la dependencia y coordinar el anuncio.

Ese es el modelo que se repite el 14 de octubre, y cambia cómo se hace el triage. Con una vulnerabilidad del framework, tu pregunta es «¿en qué versión estoy?». Con una vulnerabilidad upstream, la pregunta es «¿uso yo la superficie afectada?»:

• ¿Generas imágenes con next/og o ImageResponse? Ahí cayó el RCE de septiembre.
• ¿Tienes images.remotePatterns configurado? Sin esa configuración no te alcanza el SSRF de image optimization del 30 de septiembre; con ella, sí.
• ¿Tienes rewrites hacia un backend propio? La familia de request smuggling que afectó a Next.js en marzo nacía de una librería upstream empaquetada, y solo aplica a ese patrón de proxy.
• ¿Auto-hospedas ISR/SSG? Los problemas de cache poisoning del 30 de septiembre eran de tu servidor, no de Vercel.

Ninguna de esas respuestas sale de package.json. Es el motivo por el que nuestro triage por proyecto mapea superficie de API antes que versión: escribimos el mismo razonamiento cuando analizamos el parche de autenticación de Astro 7.2.4, donde la pregunta correcta era si usabas basePath en middleware, no si estabas en la última versión. En nuestro benchmark real de Astro frente a Next.js se ve la otra cara de la moneda: cuanto más runtime de servidor tienes, más superficie de este tipo acumulas.

Qué cambia en el runbook cuando el calendario no lo controlas

En nuestro runbook de parches de Next.js escribimos en agosto que la ventaja del programa nuevo era la fecha conocida: reservas ventana de mantenimiento, avisas al cliente, preparas staging sin improvisar. Funciona cuando el release llega según lo anunciado. El 14 de octubre enseña sus dos puntos ciegos:

1. La cadencia ya no es mensual y no depende de Vercel. Entre julio y octubre hubo cinco releases de seguridad y dos fueron fuera de banda. Si tu plan asume «el próximo aviso llegará dentro de un mes», el aviso del 8 de octubre te deja seis días, no treinta.
2. Anunciado no quiere decir completo. El 30 de septiembre el contenido del release cambió el propio día: nueve vulnerabilidades prometidas, siete entregadas, y la 16.3.7 publicada un día antes resultó no llevar ninguno de los arreglos. El runbook ya no puede dar por buena la cifra del anuncio ni la etiqueta «última versión»: hay que verificar contra la lista de advisories del día.

La matriz que usamos el miércoles a la mañana es esta:

Esa última fila no es una precaución teórica. La decisión sobre Cache Components que publicamos el 8 de octubre es exactamente una mejora de features que merece su propio ciclo de pruebas; meterla en el mismo commit que un parche crítico es cómo un cambio de una hora se convierte en un sprint — y cómo ese sprint se pospone hasta que alguien decide que ya no hace falta.

Lo que haremos nosotros el miércoles

Nuestra operación con clientes no admite «esperemos a ver qué sale». El lunes cerramos el inventario: npx next info por proyecto, npm ls next para detectar copias anidadas, y la lista de proyectos que tocan next/og, remotePatterns, rewrites o middleware. El martes dejamos la rama de upgrade preparada con el diff de lockfile y las pruebas de humo escritas: login, rutas con rewrite, generación de OG images y un build completo. El miércoles, con el advisory en la mano, mapeamos impacto → proyectos afectados → staging → producción con etiqueta de rollback.

Lo que no haremos: subir por pánico un sitio estático sin superficie de servidor, ni posponer un dashboard con auth porque «ya subimos en septiembre». La severidad la pone el advisory; la urgencia la pone tu superficie. Y lo que ya sabemos que vamos a leer el miércoles, porque es lo que ha fallado dos veces seguidas: que el arreglo dependía de una librería externa y la coordinación tardó.

Las 48 horas previas, en concreto

• Hoy: inventario de versiones y de superficie de API en todos los proyectos Next.js que llevas.
• Hoy: staging verde — si la rama de upgrade se rompe, que se rompa antes del miércoles.
• Mañana: etiqueta de rollback creada y decidido quién despliega y a qué hora.
• Miércoles: leer el advisory completo antes de tocar nada —impacto, versiones afectadas, instrucciones— y después decidir con la matriz de arriba. El propio Next.js lo resume en una línea: «Upgrade to a patched version as soon as the update is available». La disciplina está en la primera parte: as soon as, no whenever.

Si te quedas con una sola idea: el calendario de parches sigue siendo la mejor cosa que le ha pasado a la gestión de vulnerabilidades de Next.js en años, pero ya no es una garantía. La garantía la construyes tú con inventario, staging y una matriz de decisiones que sobreviva a un release que llega cuando a un proyecto externo le apetece.