Un mantenedor corrigió un error de memoria, subió el commit y siguió con lo suyo. Sin aviso de seguridad, sin etiqueta, sin identificador CVE. Esa única omisión explica por qué Vercel pasó dos semanas de agosto coordinando parches en cuatro proyectos de código abierto y terminó desactivando la optimización de imágenes AVIF en todas las aplicaciones que aloja.
Puntos clave
- Vercel desactivó la optimización AVIF en toda su plataforma el 13 de agosto y publicó una versión de seguridad de Next.js el 25 de agosto, tras rastrear el RCE reportado hasta libheif y no hasta su propio código.
- La ruta vulnerable va de next/image a sharp y de ahí a libvips, que llama a libheif para decodificar AVIF: una cadena que comparten ImageMagick, WordPress y buena parte de la web.
- Vercel señaló que los reportes privados de vulnerabilidades en GitHub pasaron de 500 por semana en enero a 3.000 por semana en mayo de 2026, con 1.560 avisos revisados solo ese mes.
La falla real fue no etiquetar el arreglo
Sin una etiqueta de seguridad, nada se activa aguas abajo. Quienes empaquetan las distribuciones no reciben ninguna señal para retroportar el cambio y los escáneres de dependencias no tienen identificador con el cual cotejar. Debian 12 y 13 siguieron distribuyendo versiones afectadas, y la actualización propia de Debian no llegó hasta el 8 de agosto. Todos los que usaban esos paquetes heredaron la exposición mientras la corrección permanecía en el historial público de git, a la vista de cualquiera que leyera el diff con suficiente atención.
Durante años ese modo de falla resultó tolerable. Revisar un año de commits de un decodificador para dar con un arreglo de memoria sin etiquetar exigía una especialización costosa. Ya no lo es. Un relevamiento hecho por tres investigadores sobre la exposición de Slack, Meta, GitHub Enterprise, Ruby on Rails, Next.js, Astro y Gatsby tomó dos meses y costó menos de 3.000 dólares en tokens.
Por qué el reporte llegó al proyecto equivocado
Hacktron AI le presentó el caso a Vercel en agosto, planteado como un RCE en la optimización de imágenes de Next.js. La investigación trasladó la responsabilidad aguas arriba muy rápido. Las aplicaciones de Next.js que usan el componente Image pueden redimensionar y optimizar archivos AVIF. Al hacerlo invocan a sharp, sharp invoca a libvips y libvips llama a libheif para decodificar.
Eso implicaba que una imagen AVIF maliciosa enviada al endpoint de optimización podía alcanzar el código vulnerable del decodificador sin tocar una sola línea de Next.js. El framework era un conducto, no el defecto. También era la única capa que Vercel controlaba directamente en ese momento.
La cronología de la divulgación
El informe de ingeniería de Vercel fecha cada paso. Hacktron reportó el 11 y el 12 de agosto, y ambos equipos reprodujeron el RCE contra una compilación vigente de Next.js con una prueba de concepto funcional.
El 13 de agosto Vercel aplicó una mitigación a nivel de plataforma. Todas las solicitudes de optimización de imágenes en Vercel pasan por un único servicio central, así que desactivar allí la optimización y el redimensionado de AVIF cortó la ruta para todos los clientes alojados de una sola vez. Los archivos AVIF entrantes dejaron de llegar a libheif.
Las instalaciones autogestionadas eran otro problema, y la razón por la que la cronología continúa. Vercel escribió a los mantenedores de sharp y libvips, y abrió la coordinación con libheif mediante un GitHub Security Advisory. Hacktron envió los detalles de su exploit a libheif por separado. El 19 de agosto el equipo de Next.js se reunió con el mantenedor de libvips para alinear la vía de remediación. Los socios de seguridad fueron notificados el 24 de agosto.
El 25 de agosto se cerró el caso. Next.js incorporó la mitigación de AVIF en una versión de seguridad prevista originalmente para un asunto distinto y la publicó un día antes, desactivando por completo la optimización y el redimensionado de AVIF. El mantenedor de libheif lanzó ese mismo día la v1.23.2 con el RCE corregido, seis días después de aquella reunión de coordinación.
Hasta dónde llega el mismo decodificador
libheif es dependencia de ImageMagick, WordPress y sharp, y por eso un fallo tan poco conocido tiene un radio de impacto inusualmente amplio. El decodificador ya había sido corregido aguas arriba el año anterior, pero como el commit no llevaba ninguna marca de seguridad, la corrección nunca se propagó como tal.
El alcance no era teórico. Semanas antes del reporte a Vercel, unos investigadores encadenaron el mismo tipo de desbordamiento en libheif con una debilidad de SSO para llegar al monorepo interno de OpenAI a través de la carga de imágenes de un foro comunitario: otro producto, otro punto de entrada y otra vía de remediación, construidos sobre el mismo defecto sin etiquetar.
Perspectiva
Vercel planteó el problema de volumen sin rodeos: el programa CVE publicó más de 35.000 identificadores en 2026 y la empresa espera que aparezcan más fallos aguas arriba como este a medida que los modelos de lenguaje aceleran la investigación de vulnerabilidades. También advirtió que las versiones de seguridad de Next.js se han vuelto más frecuentes y que la tendencia debería continuar.
La consecuencia práctica para los equipos es más acotada de lo que sugiere el titular. Los clientes de la plataforma quedaron cubiertos el 13 de agosto sin hacer nada. Quien opera su propio pipeline de imágenes tiene que confirmar qué compilación de libheif está usando realmente, que es justo la pregunta que un arreglo sin etiquetar vuelve difícil de responder.
Preguntas frecuentes
¿La vulnerabilidad estaba en Next.js?
No. El defecto estaba en libheif, el decodificador AVIF al que se llega a través de sharp y libvips cuando Next.js optimiza imágenes AVIF. Next.js desactivó la optimización AVIF como mitigación porque era la capa que podía parchearse rápido, no porque contuviera el fallo.
¿Hay que hacer algo si despliego en Vercel?
No hace falta ninguna acción. Vercel desactivó la optimización y el redimensionado de AVIF en su Image Optimization Service central el 13 de agosto, lo que bloqueó la ruta para todas las aplicaciones alojadas. Las instalaciones autogestionadas necesitan la versión de seguridad de Next.js del 25 de agosto o una compilación de libheif v1.23.2 o posterior.
¿Por qué importa tanto que un arreglo aguas arriba no lleve etiqueta?
Las herramientas de seguridad funcionan con identificadores. Un commit que corrige en silencio un error de memoria nunca entra en la base de datos de avisos, así que las distribuciones no lo retroportan y los escáneres de CI no pueden marcar las versiones afectadas. El arreglo existe en código público mientras todos los consumidores aguas abajo siguen expuestos.
