El 19 de abril de 2026, Vercel divulgó un incidente de seguridad originado en una aplicación OAuth de terceros comprometida dentro de su Google Workspace. La respuesta se ejecutó en cada proyecto Vercel gestionado por webvise antes de que terminara el fin de semana, y los registros de auditoría, tanto en Vercel como en los Google Workspaces administrados, salieron limpios. No se trató de una vulnerabilidad en el código propio de Vercel. Fue una brecha en la cadena de suministro SaaS a SaaS a través de un límite de confianza OAuth, y su naturaleza cambia el aspecto que debe tener una respuesta adecuada.
Rotar los secretos en el panel de Vercel cubre aproximadamente la mitad de la respuesta. La otra mitad reside en Google Workspace, y la mayoría de los análisis publicados no la abordan.
Usted leyó la divulgación y cambió todas las claves que pudo encontrar. Es el primer movimiento correcto. Este artículo recorre lo que se ejecutó de extremo a extremo: el detalle técnico que hace que la rotación afecte a las funciones en ejecución, y por qué la naturaleza de esta brecha debe cambiar el aspecto de su plan de respuesta la próxima vez.
- Rotar las variables de entorno en Vercel actualiza la configuración, no las instancias de funciones en ejecución; redespliégue para propagar el cambio. Los valores solo tienen efecto en el siguiente despliegue.
- La auditoría OAuth en Google Workspace es la mitad que apenas se menciona. Esa es la ruta de confianza que el atacante utilizó para llegar a Vercel.
- No fue una vulnerabilidad de Vercel. Fue una brecha SaaS a SaaS a través de un permiso OAuth, y una respuesta estándar al estilo CVE no cierra el ciclo.
- A largo plazo, saque los secretos de las variables de entorno y llévelos a un gestor de secretos en tiempo de ejecución. Requiera MFA resistente al phishing en toda cuenta que pueda instalar aplicaciones OAuth.
- Las auditorías mensuales de permisos OAuth en su proveedor de identidad son ahora parte de la línea base, no una mejora opcional.
Qué divulgó Vercel exactamente
En síntesis: una aplicación SaaS de terceros con acceso OAuth dentro del Google Workspace de Vercel fue comprometida, y el atacante usó ese límite de confianza para acceder a los valores de las variables de entorno en un subconjunto de proyectos de clientes. Vercel publicó un ID de cliente OAuth como indicador de compromiso y pidió a todos los clientes rotar cualquier secreto almacenado como variable de entorno. Nada de esto implicó una vulnerabilidad en el código propio de Vercel. La superficie de ataque fue el grafo de confianza de identidad entre dos herramientas SaaS.
Eso importa para la forma en que se responde. Si la vulnerabilidad está en el código propio de la plataforma, se parchea, se rotan los datos que filtraron y se continúa. Si la vulnerabilidad reside en la ruta de confianza entre plataformas, la rotación es necesaria pero no cierra el agujero. También hay que revocar el permiso que el atacante usó como punto de entrada, o el próximo compromiso de esa misma herramienta repetirá el mismo radio de explosión.
Si desea una segunda revisión de su configuración de Vercel antes del próximo incidente, webvise realiza revisiones de seguridad en equipos de Vercel, Google Workspaces y permisos SaaS a SaaS.
Paso uno: rotar los secretos que realmente importan
Toda variable de entorno capaz de otorgar acceso a cualquier recurso se trató como comprometida por defecto. Esa es la suposición que exige la divulgación. A continuación se indican las categorías de secretos que se reemitieron en los proyectos gestionados.
- Credenciales de base de datos. Cadenas de conexión, contraseñas de réplicas de solo lectura y claves de roles con privilegios de administrador en cada proyecto con base de datos.
- Claves de API de Resend para correo electrónico transaccional en cada proyecto que envía mensajes de verificación, notificación o registro.
- Credenciales de API de Google para integraciones con Workspace, Calendar, Drive y Analytics que se ejecutan en el lado del servidor.
- Claves de AI Gateway, incluidos tokens de acceso a modelos, credenciales de proveedores y tokens de límite de tasa para cualquier solicitud enrutada a través del gateway.
- Credenciales de integración de ingesta para endpoints de webhook, pipelines de eventos y cualquier fuente que traiga datos al proyecto desde el exterior.
Dos categorías que conviene revisar con detenimiento: variables que terminan en `_URL` y embeben credenciales dentro de la cadena de conexión, y cualquier cosa etiquetada `_TEST` o `_DEV` que apunte en realidad a producción. Rótenlas junto con el resto. Un atacante que lee variables de entorno no distingue por el nombre de la variable ni por el entorno que usted eligió.
Paso dos: redesplegar (el detalle técnico que hace real la rotación)
Es el paso que la mayoría de las listas de respuesta trata de forma superficial. Vercel aplica los cambios en las variables de entorno en el momento de la compilación y el despliegue, no en tiempo de ejecución. Un proyecto actualizado y dejado sin redesplegar sigue ejecutando la compilación publicada el día anterior, con el secreto antiguo integrado en su entorno de ejecución. Se rotó el panel, no el sistema.
Un ejemplo concreto: se rota la clave de API de Resend a las 10:14 y se abre una nueva pestaña para revisar otra cosa. A las 10:17, una función intenta enviar un correo de verificación, llama a Resend con la clave antigua todavía integrada en su entorno desplegado, y Resend rechaza la solicitud. El usuario no recibe su correo. Multiplique eso por cada función, cada cron y cada handler de webhook que aún ejecuta la compilación antigua.
| Qué hizo | Qué cambió | Qué sigue ejecutando el secreto antiguo |
|---|---|---|
| Rotar la variable de entorno solo en el panel | El valor en el panel | Cada función en ejecución, trabajo cron e instancia de middleware |
| Rotar y redesplegar producción | La compilación y el entorno de ejecución de producción | Compilaciones de preview, ramas de PR y staging |
| Rotar y redesplegar todos los entornos | Todas las compilaciones y entornos de ejecución | Ninguno, una vez que los despliegues están activos |
Para verificar la respuesta, abra la pestaña Deployments de cada proyecto y localice un despliegue con marca de tiempo posterior a la rotación. Si la fila superior muestra una marca anterior al momento de la rotación, esta no llegó a ningún proceso en ejecución. El segundo paso explícito de la respuesta fue un redespliegue forzado a producción en cada proyecto gestionado, inmediatamente después de la rotación.
Paso tres: revocar el permiso OAuth en Google Workspace
Esta es la mitad de la respuesta que apenas se discutió durante el fin de semana. El incidente se originó en Google Workspace. El atacante entró a través de una aplicación OAuth de terceros con un permiso concedido dentro de Workspace y luego pivotó hacia Vercel mediante una ruta de confianza SaaS a SaaS. Si solo se rotó en el lado de Vercel, la misma aplicación OAuth sigue ahí con el mismo permiso, lista para ser abusada la próxima vez que se comprometa.
La ruta en la consola de administración: admin.google.com, seguridad, controles de API, control de acceso de aplicaciones, aplicaciones de terceros. Busque el ID de cliente OAuth que Vercel publicó como indicador de compromiso. Revóquelo si está presente. Luego haga lo más difícil: revise cada otro permiso OAuth de la lista, confirme que cada alcance fue intencional y revoque todo aquello para lo que no tenga una razón vigente.
Esta auditoría se ejecutó en cada Workspace administrado. El indicador no estaba presente y la mayoría de los permisos tenían una finalidad empresarial legítima. Algunos no la tenían y fueron revocados. Desde entonces se adoptó una cadencia mensual: auditorías mensuales de permisos OAuth al inicio de cada mes, revocación de todo lo no utilizado en 30 días.
Paso cuatro: los movimientos a largo plazo
La rotación y la revocación resolvieron la exposición inmediata. Los movimientos a largo plazo son los que evitan que el próximo incidente se convierta en una carrera de fin de semana. Estos cambios se están incorporando a los proyectos gestionados en las próximas semanas, y son lo que se recomienda a cualquier equipo que opere un stack con muchos servicios SaaS.
- Obtener los secretos en tiempo de ejecución desde un gestor de secretos en lugar de integrarlos en variables de entorno. La rotación se convierte en un push, no en un redespliegue.
- Credenciales de corta duración para bases de datos y APIs donde el proveedor lo soporte. Validez de minutos, no de meses.
- Rotación programada para las credenciales que no pueden tener duración corta. Dirigida por el calendario, no por incidentes.
- MFA resistente al phishing en todas las cuentas de administrador que puedan instalar aplicaciones OAuth en su proveedor de identidad. Passkeys o tokens de hardware, nada basado en SMS.
- Auditorías mensuales de permisos OAuth en Workspace, Microsoft 365 o el proveedor de identidad que utilice. La ruta del atacante fue un permiso OAuth esta vez; también lo será la próxima.
Muchos equipos carecen de un responsable único asignado para estas tareas; esa brecha reaparece en los informes de post-mortem de incidentes. Póngase en contacto para saber cómo webvise integra estas prácticas en el soporte de mantenimiento para proyectos gestionados.
Por qué esta brecha es diferente
El modelo defensivo debe corresponderse con el modelo de ataque. Eso significa tratar los permisos OAuth como dependencias de producción, auditarlos de forma programada y sacar los secretos de las variables de entorno, donde un atacante con ese permiso puede leerlos. Los registros de auditoría salieron limpios este fin de semana. Es el resultado concreto de este incidente, aunque el modelo de respuesta requiere revisión periódica.
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 habría entregado a un extraño. La cuenta de Vercel no fue vulnerada directamente, ni tampoco Google Workspace. Una tercera herramienta que alguien conectó meses atrás fue comprometida, y los alcances concedidos a esa herramienta propagaron el compromiso hacia abajo en la cadena.
Trate esto como un ritmo operativo, no como una limpieza puntual.
Las revisiones de seguridad en equipos de Vercel, Google Workspaces y grafos de identidad SaaS a SaaS forman parte de cada compromiso gestionado en webvise. Para una segunda revisión de su configuración de Vercel antes del próximo incidente, póngase en contacto.
Las prácticas de webvise están alineadas con las normas ISO 27001 e ISO 42001.