Un fallo en las imágenes OG de Next.js puede ejecutar código en su servidor. Actualice a 16.3.6.
Vercel lanzó una versión de Next.js fuera del ciclo habitual el 22 de septiembre. Si su aplicación genera imágenes Open Graph, lea esto antes que cualquier otra cosa hoy. La actualización, versiones 16.3.6 y 15.5.26, corrige un fallo crítico de ejecución remota de código en next/og, identificado como CVE-2026-94545 (aviso GHSA-vcvr-r3jv-pc5j). La puntuación CVSS es 9,5. Eso es prácticamente lo peor que puede ser un fallo de framework.
El fallo reside en la versión Node.js de ImageResponse, la herramienta que la mayoría de los equipos usa para generar tarjetas de compartición dinámicas: esas pequeñas vistas previas con título e imagen en miniatura que aparecen cuando alguien comparte su enlace en Slack, LinkedIn o un chat grupal. En su interior, ImageResponse pasa su JSX a Satori, que lo convierte en SVG y luego renderiza ese SVG en un PNG. La causa raíz está una capa más abajo, en Satori, que tiene su propio aviso (GHSA-wx4j-mvgx-mqwp): no escapaba ciertos valores antes de escribirlos en el SVG. De modo que un valor que parecía texto plano podía escapar e interpretarse como marcado SVG activo. Cuando el renderizador procesaba ese marcado, la entrada controlada por el atacante podía ejecutarse en el servidor.
¿Está usted realmente expuesto?
La condición que le hace vulnerable es específica, y vale la pena ser honesto al respecto. Está expuesto si ejecuta ImageResponse en Node.js (la opción predeterminada del App Router cuando una ruta no usa Edge) y envía a la imagen un valor que el visitante controla. Una palabra extraída de la URL. Un nombre de perfil. Un parámetro de la cadena de consulta. Ese no es un patrón exótico. Es exactamente la receta que todo el mundo usa para generar una tarjeta de compartición por artículo. Si su ruta OG solo renderiza títulos estáticos o valores de una base de datos de confianza, no está en la zona de impacto. La implementación Edge de ImageResponse tampoco está afectada.
Las versiones afectadas son Next.js 16.2.0 hasta 16.3.5. La corrección es la 16.3.6. Vercel también publicó la 15.5.26 el mismo día, pero esa versión solo incluye medidas de refuerzo; la rama 15.x no era vulnerable al RCE.
El punto donde la gente se confunde
Aquí es donde pasamos mucho tiempo durante los compromisos de pentesting: parchear el framework es necesario, pero no siempre suficiente. npm install next@16.3.6 actualiza el Satori que incluye Next.js. No hace nada con el satori o @vercel/og que usted agregó en su propio package.json. Lo vemos constantemente. Un equipo actualiza la dependencia principal, el escáner sigue marcando alertas y nadie entiende por qué. Si usa Satori directamente en algún lugar, actualícelo a la versión 0.33.5 o posterior de forma independiente, y compruebe lo que su lockfile resuelve realmente en lugar de confiar en la versión de nivel superior.
Qué hacer esta semana
Empiece buscando en su código next/og, opengraph-image y twitter-image. Si no aparece nada, puede respirar tranquilo y programar la actualización en su cadencia habitual. Si aparece algo, trate cada una de esas rutas como accesibles hasta que las haya revisado. Hágase una pregunta por ruta: ¿puede un visitante influir en algún valor que llegue a la imagen? Luego actualice a 16.3.6 (o 15.5.26 en la rama 15), reinstale para que el lockfile se actualice, reconstruya y redespliegue. Confirme la versión de Satori resuelta en la salida compilada, no solo en package.json.
Si realmente no puede hacer el despliegue hoy, la solución alternativa oficial de Vercel es contundente pero efectiva: deje de pasar entrada no confiable a la imagen. Sustituya el valor dinámico por un marcador de posición seguro, o mueva la ruta al runtime Edge si funciona allí sin cambios. Ninguna es una solución a largo plazo. Ambas le dan un día más.
La lección más importante
Hay un patrón aquí, y es el mismo que Log4Shell y el reciente fallo de prototype-pollution en axios nos enseñaron. Las vulnerabilidades peligrosas rara vez están en su propio código. Están una o dos capas más abajo, en una biblioteca de confianza generalizada que el framework incluye por usted. Cuando desarrollamos aplicaciones cloud-native para clientes empresariales, por eso insistimos en un software bill of materials real y en un análisis automático de dependencias integrado en el CI, no en una auditoría trimestral. Quiere que las herramientas le digan «usted usa Satori 0.31, ahora es vulnerable» la mañana en que se publica el aviso, no tres semanas después cuando un cliente le reenvía un escaneo.
La forma de inyección-a-RCE también es un recordatorio útil sobre cómo pensar en cualquier renderizador, en el backend o dentro de una aplicación móvil. Todo lo que toma entrada estructurada y produce un documento (SVG, HTML, un PDF, un payload de WebView) es un lugar donde «solo texto» puede convertirse silenciosamente en «ejecutable». En nuestros proyectos nativos de iOS y Android aplicamos la misma regla a todo lo que renderiza contenido impulsado por el servidor: escapar en el límite y nunca asumir que la capa inferior lo hizo por usted. La corrección de Satori fue exactamente eso, escapar los valores de texto y atributos antes de que lleguen al SVG. El framework había confiado en que la biblioteca haría algo que la biblioteca no estaba haciendo.
Si quiere una segunda opinión sobre cuáles de sus rutas next/og puede alcanzar realmente un visitante, ese es un trabajo rutinario para nosotros. Vea cómo abordamos la seguridad de aplicaciones web. Y si un aviso crítico que llega un viernes por la tarde con nadie seguro sobre qué rutas están expuestas le resulta familiar, hablemos.