Incidente de seguridad de Vercel (abril de 2026): qué deben hacer los desarrolladores con las variables de entorno expuestas

Vercel afirma que contactó directamente con los clientes afectados y recomendó rotar las credenciales de inmediato. Su actualización del 22 de abril añade que una revisión ampliada encontró un pequeño número de cuentas comprometidas adicionales, a las que también se notificó. En primer lugar, confirme qué direcciones reciben los mensajes de Vercel (propietarios del equipo, contactos de facturación).

Pero Vercel presenta los pasos siguientes como buenas prácticas que debe seguir en cualquier caso. No haber recibido noticias de Vercel no es motivo para no hacer nada.

Vercel le pide que trate como potencialmente expuestas las variables de entorno no marcadas como sensibles (claves de API, tokens, credenciales de bases de datos, claves de firma y similares) y que las rote con prioridad.

En la tabla de variables de entorno del panel, cada variable lleva la etiqueta Config (el valor puede mostrarse tras guardarlo) o Secret (el valor no puede mostrarse tras guardarlo). Los secretos que aparecen con la etiqueta Config son hoy su lista de trabajo. Revise también las variables compartidas a nivel de equipo, además de las variables de proyecto.

La documentación de Vercel indica este orden para rotar sin tiempo de inactividad:

1. En el servicio de terceros (proveedor de base de datos o de API), emita una nueva credencial y mantenga la anterior por ahora
2. Actualice la variable de entorno de Vercel
3. Vuelva a desplegar (en el caso de una variable a nivel de equipo, todos los proyectos que la usen)
4. Tras comprobar que funciona, invalide la credencial anterior

Editar solo la variable deja los despliegues en ejecución con el valor antiguo, y solo el paso 4 hace inútil el valor filtrado.

Guarde los nuevos valores que creó como Secrets (solo escritura). En su boletín, Vercel afirma que la función sensible protege los valores secretos para que no puedan leerse en el futuro.

A 30 de septiembre de 2026, la documentación indica que el valor de un Secret se oculta tras guardarlo y se cambia proporcionando un nuevo valor, y que los Secrets, antes limitados a Production y Preview, ahora también se permiten en Development. Consulte más adelante en este artículo la comparación sobre qué debe ir en cada categoría.

Vercel señala claramente que eliminar sus proyectos o su cuenta no basta para eliminar el riesgo, porque un secreto filtrado sigue siendo válido en la base de datos o la API a la que da acceso. Si está limpiando proyectos antiguos o dejando Vercel, invalide primero las claves en el proveedor y después elimine.

Vercel recomienda revisar el registro de actividad de su cuenta y de sus entornos (en el panel o mediante la CLI) en busca de actividad sospechosa, e investigar los despliegues recientes por si hay algo inesperado o con aspecto sospechoso. Indica que se elimine cualquier despliegue en cuestión. Use el mismo registro para buscar indicios de que alguien vio valores de variables de entorno.

Vercel recomienda establecer Deployment Protection en Standard como mínimo y, si usa tokens de Deployment Protection, rotarlos. La documentación de Vercel describe Standard como la opción recomendada para la mayoría de los proyectos: protege las URL de vista previa y por despliegue, mientras que las URL de producción actuales siguen siendo públicas.

Vercel recomienda la autenticación multifactor con una aplicación de autenticación o una passkey. Por qué estas opciones son mejores que los SMS se explica en Cómo elegir la autenticación multifactor.

Vercel publicó el identificador de la aplicación OAuth de Google Workspace de la herramienta de IA y recomienda que los administradores de Google Workspace y los propietarios de cuentas de Google comprueben de inmediato si se usa esa aplicación.

Según Vercel, esa aplicación OAuth fue objeto de un compromiso más amplio, que podría afectar a cientos de usuarios en muchas organizaciones, por lo que las organizaciones que no usan Vercel también podrían estar afectadas. Obtenga el identificador del boletín de Vercel, enlazado en las fuentes de más abajo.

La página de ayuda para administradores de Google "Controlar qué aplicaciones acceden a los datos de Google Workspace" indica que la consola de administración muestra qué aplicaciones han accedido a los datos de la organización, qué usuarios las autorizaron y los ámbitos de OAuth que solicitó cada aplicación.

Extraiga la lista y marque las aplicaciones que nadie sabe explicar y las que tienen ámbitos que pueden leer todo Drive o Gmail.

La misma página indica que cada aplicación puede configurarse como Trusted (de confianza), Limited (limitada), Specific Google data (datos específicos de Google) o Blocked (bloqueada). Restrinja las aplicaciones que decida mantener a solo los datos que necesitan, y bloquee el resto.

Puede establecer una política de la organización que determine si los usuarios pueden autorizar aplicaciones de terceros que el administrador no haya configurado. Permitir solo las aplicaciones que solicitan información básica de inicio de sesión pone una revisión del administrador antes de cada nueva herramienta de IA.

En Gmail y Drive también puede restringir individualmente los ámbitos de alto riesgo, como enviar correos o eliminar archivos.

Esta es una sugerencia de este sitio. En este incidente, la cuenta de Google a la que estaba conectada una herramienta de IA se convirtió en la vía de acceso a una cuenta de Vercel. Las personas con derechos de administrador en producción o en alojamiento deberían considerar no conectar herramientas de IA de prueba a la cuenta con la que inician sesión allí. Si una herramienta debe conectarse, use una cuenta separada con acceso restringido a los datos de negocio.