Rotar, redesplegar, revocar: nuestra respuesta al incidente de Vercel

El 19 de abril de 2026, Vercel comunicó un incidente de seguridad originado en una aplicación OAuth de terceros comprometida dentro de su Google Workspace. Ejecutamos la respuesta en todos los proyectos Vercel gestionados por webvise antes de que terminara el fin de semana, y los registros de auditoría tanto de Vercel como de los Google Workspaces que administramos resultaron limpios. No se trató de una vulnerabilidad en el propio código de Vercel. Fue un compromiso de la cadena de suministro SaaS-to-SaaS a través de un límite de confianza OAuth, y su forma específica cambia el aspecto que debe tener una respuesta adecuada.

Rotar los secretos en el panel de Vercel representa, como mucho, la mitad de la respuesta. La otra mitad reside en Google Workspace, y la mayoría de los análisis publicados no la cubren.

Usted leyó la comunicación y rotó todas las claves que pudo encontrar. Ese es el primer movimiento correcto. Este artículo describe lo que ejecutamos de principio a fin, el detalle técnico que hace que la rotación afecte a las funciones en ejecución, y por qué la forma de esta brecha cambia el aspecto que debería tener su plan de respuesta la próxima vez.

• Rotar las env vars de Vercel cambia el panel, no las funciones en ejecución. Los valores solo tienen efecto en el siguiente despliegue.

• La auditoría OAuth de Google Workspace es la mitad que apenas se menciona. Ese es el camino de confianza que usó el atacante para llegar a Vercel.

• No fue una vulnerabilidad de Vercel. Fue un compromiso SaaS-to-SaaS a través de un grant OAuth, y una respuesta normal al estilo CVE no cierra el ciclo.

• A largo plazo, saque los secretos de las env vars y llévelos a un gestor de secretos en tiempo de ejecución. Exija MFA resistente a phishing a quien pueda instalar aplicaciones OAuth.

• Las auditorías mensuales de grants OAuth de terceros en su proveedor de identidad son ahora parte de la base mínima, no una mejora de madurez.

Qué comunicó Vercel exactamente

El resumen: una aplicación SaaS de terceros con acceso OAuth dentro del Google Workspace de Vercel fue comprometida, y el atacante utilizó ese límite de confianza para acceder a los valores de las variables de entorno de un subconjunto de proyectos de clientes. Vercel publicó un OAuth client ID como indicador de compromiso y pidió a todos los clientes que rotaran cualquier secreto almacenado como variable de entorno. Nada de esto implicó una vulnerabilidad en el propio código de Vercel. La superficie de ataque fue el grafo de confianza de identidad entre dos herramientas SaaS.

Eso importa para la forma de responder. Si la vulnerabilidad está en el código propio de la plataforma, se parchea, se rota lo que filtró y se sigue adelante. Si la vulnerabilidad está en el camino de confianza entre plataformas, la rotación es necesaria pero no cierra el agujero. También hay que revocar el grant que usó el atacante para entrar; de lo contrario, el próximo compromiso de esa misma herramienta reproducirá el mismo radio de explosión.

Si desea una segunda opinión sobre su configuración de Vercel antes de que se escriba el próximo post-mortem sobre usted, realizamos revisiones de seguridad sobre equipos Vercel, Google Workspaces y grants SaaS-to-SaaS.

Paso uno: rotar los secretos que realmente importan

Tratamos cada variable de entorno que pudiera otorgar acceso a cualquier sistema como comprometida por defecto. Esa es la suposición que exige la comunicación. A continuación figuran las categorías de secretos que reemitimos en los proyectos gestionados.

• Credenciales de base de datos. Cadenas de conexión, contraseñas de réplica de solo lectura y claves de rol de nivel admin en cada proyecto con backend de base de datos.

• Claves API de Resend para correo transaccional en cada proyecto que envíe mensajes de verificación, notificación o registro.

• Credenciales de Google APIs para integraciones de Workspace, Calendar, Drive y Analytics que se ejecutan en el servidor.

• Claves de AI Gateway incluyendo tokens de acceso a modelos, credenciales de proveedores y tokens de límite de velocidad para todo lo enrutado a través del gateway.

• Credenciales de integración de ingestión para endpoints de webhook, pipelines de eventos y cualquier sistema que traiga datos al proyecto desde el exterior.

Dos categorías que conviene comprobar dos veces: variables que terminan en `_URL` y que incluyen credenciales dentro de cadenas de conexión, y cualquier cosa etiquetada como `_TEST` o `_DEV` que resulte apuntar a producción. Rótelas junto con el resto. Un atacante que lee env vars no presta atención al identificador que usted eligió ni a lo que sugiere el nombre de la variable.

Paso dos: redesplegar (el detalle técnico que hace real la rotación)

Esta es la parte que más importa y que menos protagonismo recibe. Vercel aplica los cambios de variables de entorno en el momento de compilación y despliegue, no en tiempo de ejecución. Un proyecto que usted actualizó y dejó en marcha sigue ejecutando la compilación que desplegó ayer, que todavía tiene el secreto antiguo integrado en su entorno de ejecución. Usted rotó el panel, no el sistema.

Versión concreta: usted rota su clave API de Resend a las 10:14 y abre una nueva pestaña para revisar otra cosa. Una función intenta enviar un correo de verificación a las 10:17, llama a Resend con la clave antigua todavía integrada en su entorno desplegado, y Resend rechaza la solicitud. Su usuario no recibe el correo. Multiplique eso por cada función, cada cron y cada manejador de webhook que ejecuta la compilación antigua.

Para verificar su respuesta, abra la pestaña Deployments de cada proyecto y localice un despliegue con marca de tiempo posterior a su rotación. Si la fila superior muestra una marca de tiempo anterior al momento en que rotó, la rotación no llegó a ningún proceso en ejecución. El segundo paso explícito de nuestra respuesta fue un redespliegue forzado a producción en cada proyecto gestionado tras la rotación, antes de continuar.

Paso tres: revocar el grant OAuth de Google Workspace

Esta es la mitad de la respuesta que apenas se debatió en los hilos del fin de semana. El incidente se originó en Google Workspace. El atacante entró mediante una aplicación OAuth de terceros con un scope concedido dentro de Workspace, y luego pivotó hacia Vercel a través de un camino de confianza SaaS-to-SaaS. Si solo rotó en el lado de Vercel, la misma aplicación OAuth sigue ahí con el mismo scope, lista para ser explotada la próxima vez que sea comprometida.

La ruta en su consola de administración: admin.google.com, seguridad, controles de API, control de acceso de aplicaciones, aplicaciones de terceros. Busque el OAuth client ID que Vercel publicó como indicador. Revóquelo si está presente. Después haga lo más difícil: revise cada grant OAuth de la lista, confirme que cada scope fue intencional y revoque todo aquello para lo que no tenga una razón vigente de mantener.

Ejecutamos esta auditoría en cada Workspace que administramos. El indicador no estaba presente, y la mayoría de los grants tenían una finalidad empresarial legítima. Unos pocos no la tenían, y los revocamos. Desde entonces hemos adoptado una cadencia mensual: auditar los grants OAuth al inicio de cada mes y revocar todo lo que no se haya utilizado en 30 días.

Paso cuatro: los movimientos a largo plazo

La rotación y la revocación gestionaron la exposición inmediata. Los movimientos a largo plazo son los que evitan que el próximo incidente se convierta en una carrera contra el tiempo durante el fin de semana. Los estamos implementando en los proyectos gestionados durante las próximas semanas, y son los que recomendamos a cualquier equipo que opere con un stack intensivo en SaaS.

• Obtenga los secretos en tiempo de ejecución desde un gestor de secretos en lugar de integrarlos en env vars. La rotación se convierte en una actualización push, no en un redespliegue.

• Credenciales de corta duración para bases de datos y API donde el proveedor las admita. Validez de minutos, no de meses.

• Rotación programada para las credenciales que no pueden hacerse de corta duración. Dirigida por el calendario, no por incidentes.

• MFA resistente a phishing en cada cuenta de administrador que pueda instalar aplicaciones OAuth en su proveedor de identidad. Passkeys o tokens de hardware, nada basado en SMS.

• Auditorías mensuales de grants OAuth en Workspace, Microsoft 365 o el proveedor de identidad que utilice. El camino del atacante esta vez fue un grant OAuth; la próxima vez también lo será.

La mayoría de los equipos no tienen un responsable único para ninguno de estos puntos. Esa es la razón silenciosa por la que los incidentes siguen terminando con los mismos puntos en el post-mortem. Hable con nosotros sobre cómo webvise integra todo esto en el servicio de mantenimiento de cada proyecto gestionado.

Por qué esta brecha es diferente

El modelo de brecha para el que está diseñada la mayoría de los programas de seguridad: un atacante encuentra un CVE en un servidor que usted gestiona, lo explota y vuelca sus datos. La rotación, el parcheado y la monitorización del perímetro cubren ese modelo. El incidente del 19 de abril tiene una forma diferente.

Un atacante compromete una herramienta SaaS que su equipo autorizó, y luego aprovecha la relación de confianza entre esa herramienta y sus otras herramientas SaaS para acceder a datos que ninguna de las dos habría entregado a un desconocido. Su cuenta de Vercel no fue vulnerada directamente, ni tampoco su Google Workspace. Una tercera herramienta que alguien conectó meses atrás fue comprometida, y los scopes que usted concedió a esa herramienta propagaron el compromiso aguas abajo.

El modelo defensivo debe coincidir con el modelo de ataque. Eso significa tratar los grants OAuth como dependencias de producción, auditarlos con una cadencia fija y sacar los secretos de las variables de entorno donde un atacante con ese grant puede leerlos. Nuestros registros de auditoría resultaron limpios este fin de semana, pero eso es el resultado para este incidente concreto, no la prueba de que el modelo de respuesta sea a prueba de futuro.

Realizamos revisiones de seguridad sobre equipos Vercel, Google Workspaces y grafos de identidad SaaS-to-SaaS como parte de cada servicio gestionado en webvise. Si desea una opinión externa sobre su configuración antes de que el próximo comunicado llegue un fin de semana, inicie una conversación.