Vercel 2026: Cuando tu herramienta de IA le abre la puerta al atacante

TL;DR:

Un empleado de Vercel instaló una app de IA (Context.ai) con permisos OAuth de "Allow All" en su cuenta corporativa de Google Workspace — dos meses después, un atacante ya estaba dentro de la infraestructura de Vercel
Las variables de entorno no marcadas como sensitive se almacenaban en texto plano y eran accesibles vía API: API keys, URLs de bases de datos, tokens internos, todos expuestos
El atacante estuvo activo dos meses antes de que Vercel publicara su primer comunicado. Un cliente detectó su propia API key filtrada el 10 de abril; Vercel lo confirmó el 19
Esta no es una historia sobre Vercel siendo descuidado. Es una historia sobre el costo real de adoptar herramientas de IA sin un modelo de confianza

Dos meses.

El atacante estuvo dentro de la infraestructura de Vercel durante aproximadamente dos meses antes de que la empresa publicara su primer comunicado. Antes de que Vercel lo dijera públicamente, un cliente ya había recibido una alerta de OpenAI avisando que su API key había sido filtrada — una key que, según el propio cliente, solo existía en Vercel.

Spoiler: esto no empezó con un CVE. No fue un zero-day en Next.js. No fue una inyección SQL en el panel de control. Fue un empleado que instaló una herramienta de IA y le dio permisos que nunca debería haber tenido.

Bienvenidos al modelo de amenaza del ecosistema de IA en 2026.

La cadena de ataque: de un juego pirata a los secretos de producción

Reconstruyamos el timeline tal como lo documenta el informe de Vercel y análisis independientes de Trend Micro y BleepingComputer.

Febrero 2026: Un empleado de Context.ai — una plataforma de IA — descarga software desde un sitio de trucos de juegos. En ese software venía de regalo el troyano Lumma Stealer, un infostealer que lleva años siendo el preferido de grupos de amenaza persistente por su capacidad de exfiltrar credenciales almacenadas en el navegador, cookies de sesión y, específicamente, tokens OAuth.

El malware exfiltró los tokens de Google Workspace del empleado. Hasta ahí, el problema era de Context.ai.

Marzo 2026: Un empleado de Vercel había instalado la aplicación de IA Office Suite de Context.ai usando su cuenta corporativa de Google Workspace. El detalle que convierte esto en un desastre: cuando autorizó la app, seleccionó el scope "Allow All". Permisos máximos. Sin restricciones.

Con el token OAuth comprometido en Context.ai, el atacante heredó acceso total a la cuenta de Google Workspace del empleado de Vercel. Sin contraseña. Sin MFA. Solo un token que nadie había revocado.

Desde ahí, el adversario pivoteó hacia los sistemas internos de Vercel. Vercel describió al atacante como "altamente sofisticado" por su velocidad de movimiento y conocimiento previo del sistema.

Marzo - Abril 2026: El atacante enumera variables de entorno no marcadas como sensitive en un subconjunto de proyectos de clientes. En Vercel, esas variables se almacenaban en texto plano y eran accesibles vía la API de la plataforma para cualquier token válido con los permisos correctos.

API keys. URLs de bases de datos. Tokens internos. Todo en texto claro.

10 de abril: El cliente Andrey Z. recibe una alerta de OpenAI: una de sus API keys fue detectada como filtrada. La key solo existía como variable de entorno en Vercel. Señal de alarma que llegó antes de la divulgación oficial.

19 de abril: Vercel publica su boletín oficial. El CEO Guillermo Rauch confirma la cadena de ataque vía X (ex-Twitter). Mandiant es contratado para la respuesta forense.

El problema que nadie quería nombrar: secretos inseguros por defecto

Voy a ser directo, porque el informe de Trend Micro lo dice claramente y merece más atención de la que recibió.

En Vercel, las variables de entorno tienen dos modos: sensitive (cifradas, valor no recuperable via API) y... el resto. El resto se almacena en texto plano y puede ser leído por cualquier token con acceso al proyecto.

El diseño asumía que el usuario sabía distinguir qué era sensible y qué no. Spoiler: los usuarios no hacen eso. Nunca lo han hecho. API keys de OpenAI, credenciales de bases de datos, tokens de Stripe — todo termina en variables "ordinarias" porque es más cómodo, porque nadie se fija, porque siempre funcionó así.

El atacante no necesitó explotar una vulnerabilidad de código. Solo llamó a la API de Vercel con un token válido y preguntó cortésmente: ¿cuáles son los valores de estas variables? Y la API respondió.

# Lo que el atacante hizo (simplificado):
curl -s -H "Authorization: Bearer $TOKEN_COMPROMETIDO" \
  "https://api.vercel.com/v11/projects/$PROJECT_ID/env" | jq .

# Lo que obtuvo:
# {
#   "key": "OPENAI_API_KEY",
#   "value": "sk-...",
#   "sensitive": false
# }

Después del incidente, Vercel cambió el comportamiento por defecto: las nuevas variables de entorno ahora se marcan como sensitive automáticamente. Bien. Pero como siempre: la arquitectura segura llegó después del incidente, no antes.

60 días: el problema del tiempo de permanencia

El dwell time — el tiempo que un atacante permanece dentro de un sistema sin ser detectado — es uno de los indicadores más críticos en un incidente de seguridad. El promedio global ronda los 16 días según el informe M-Trends de Mandiant. El atacante de Vercel estuvo aproximadamente 60 días.

¿Por qué tanto tiempo?

Porque la enumeración de variables de entorno parece tráfico normal. No hay una shell reversa. No hay lateral movement obvio. Hay llamadas a la API de gestión de proyectos, que es exactamente lo que hacen herramientas legítimas todo el tiempo. El patrón anómalo — velocidad y volumen de enumeración — fue lo que eventualmente levantó alertas internas. Pero para entonces el daño ya estaba hecho.

Esto es lo que hace especialmente peligroso este vector: no activa los detectores tradicionales. No hay malware ejecutándose en los servidores de Vercel. No hay exfiltración masiva de archivos. Solo un token OAuth válido llamando a endpoints de API legítimos, leyendo datos que estaban ahí, esperando ser leídos.

In the real world, la detección tardía no es una falla de las herramientas de monitoreo. Es una consecuencia directa de diseñar sistemas donde el acceso legítimo y el acceso malicioso son indistinguibles.

La trampa del "Allow All": OAuth como vector de ataque persistente

Necesito detenerme aquí porque esto es el corazón del problema, y es un problema que se va a repetir.

El ecosistema de herramientas de IA en 2026 funciona así: instalas una herramienta, te pide permisos de OAuth sobre tu cuenta de Google (o GitHub, o Slack), haces clic en "Allow" sin leer los scopes, y sigues con tu vida. La herramienta funciona. Todo está bien.

Hasta que no lo está.

El problema con OAuth no es el protocolo en sí — está bien diseñado. El problema es cómo los humanos interactúan con él y cómo las aplicaciones de terceros solicitan permisos. "Allow All" no debería existir como opción en un entorno corporativo. Los scopes mínimos necesarios para la función de la app es lo que debería pedirse, y es lo que los equipos de seguridad deberían exigir como prerequisito de aprobación.

Pero vivimos en un mundo donde los empleados instalan herramientas de IA con la misma filosofía con la que instalan apps de productividad en sus teléfonos personales: fast, useful, no questions asked.

El resultado: cada app de IA conectada a una cuenta corporativa es un vector de ataque potencialmente persistente. Si esa app es comprometida, si su proveedor tiene una brecha, si un empleado de esa empresa cae en un phishing o descarga software de un sitio de trucos de juegos — ese token OAuth sigue siendo válido. El atacante hereda todo lo que la app tenía autorizado.

Zero trust no termina en tu perímetro. Termina en todos los terceros que tienen tokens con acceso a tus sistemas.

El costo real de "moverse rápido con IA"

Aquí viene la parte incómoda.

Context.ai, la plataforma que fue el punto de entrada, es una herramienta de IA para equipos. Útil. Bien valorada. Adoptada por un empleado de Vercel que quería ser más productivo. Eso es exactamente lo que se supone que debe pasar en una empresa moderna.

El problema no es que se usó IA. El problema es que se usó IA sin evaluar el modelo de riesgo de esa integración.

La presión por adoptar herramientas de IA en 2025-2026 es real y tiene nombre: competitividad. Los equipos que no usan IA se quedan atrás. Los managers exigen adopción. Los empleados buscan herramientas que los hagan más productivos. Y en ese contexto, pedir que se complete un cuestionario de seguridad antes de instalar una app de IA parece un obstáculo burocrático, no una medida razonable.

Pero la cadena de suministro de SaaS/IA es el nuevo supply chain attack. Cada herramienta de terceros que tiene acceso OAuth a sistemas corporativos es un eslabón. Y los atacantes lo saben.

El incidente de Vercel no es un caso excepcional. Es un preview. La superficie de ataque del ecosistema de IA solo va a crecer.

Qué hacer ahora: checklist pragmático

No voy a darte una lista de 47 buenas prácticas que nadie va a leer. Te doy lo que realmente importa:

1. Audita tus integraciones OAuth corporativas hoy

En Google Workspace, ve a Admin Console → Security → API controls → App access control. Filtra por aplicaciones de terceros. Revoca todo lo que no esté explícitamente aprobado. Si no sabes para qué sirve una app, revócala.

Para el incidente de Vercel, el OAuth Client ID comprometido fue 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj. Si lo ves en tu consola, revócalo.

2. Marca tus variables de entorno como sensitive

En Vercel, todas las variables que contengan secretos deben marcarse como sensitive. La UI ahora lo hace por defecto para variables nuevas, pero revisa las existentes:

# Lista tus variables actuales
vercel env ls --environment=production

# Para variables no-sensitive con secretos, recréalas
vercel env rm NOMBRE_VARIABLE production
vercel env add NOMBRE_VARIABLE production
# Marcar como sensitive en el prompt

3. MFA en todo, sin excepciones

Habilita autenticación multifactor en Vercel, Google Workspace y todos los repositorios asociados. El token OAuth comprometido fue suficiente para bypassear la autenticación de contraseña, pero un segundo factor correctamente implementado añade una capa de fricción que importa.

4. Principio de mínimo privilegio para integraciones

Cuando autorices una app de terceros, revisa los scopes que solicita. Si pide "Allow All" y no puedes justificar por qué necesita acceso total, no la autorices. Si el vendor no ofrece scopes granulares, considera si realmente necesitas esa integración.

5. Monitorea alertas de credenciales filtradas

Servicios como HaveIBeenPwned, las alertas de secretos de GitHub, y las notificaciones de leaked credentials de OpenAI y otros proveedores son señales de inteligencia reales. El cliente Andrey Z. supo que algo estaba mal el 10 de abril porque OpenAI le avisó. Esas alertas tienen que estar configuradas y tienen que ir a alguien que las lea y actúe.

La respuesta de Vercel: lo que hicieron bien

Para ser justos — y en seguridad ser justo importa — Vercel manejó la divulgación de manera ejemplar según SecurityWeek y otros analistas.

Contrataron a Mandiant el mismo día. Notificaron a las autoridades. Publicaron IOCs (Indicators of Compromise) en su boletín. Comunicaron directamente a los clientes potencialmente afectados sin esperar a tener todos los detalles. Publicaron cuatro actualizaciones entre el 19 y el 23 de abril refinando la información a medida que la investigación avanzaba.

Cambiaron el comportamiento por defecto de las variables de entorno para que sean sensitive going forward. Auditaron que npm, Next.js, Turbopack y el resto de sus paquetes no fueron comprometidos (GitHub y npm confirmaron que no hubo cambios no autorizados).

También encontraron un pequeño número adicional de cuentas afectadas independientemente del incidente principal — posiblemente vía ingeniería social o malware separado — y lo reportaron el 22-23 de abril con la misma transparencia.

¿Dónde falló Vercel? En no haber diseñado con sensitive como default desde el principio, y en el tiempo de detección. Pero esos son fallos de diseño comunes que muchas plataformas comparten. La respuesta post-incidente fue sólida.

Lo que este incidente nos dice sobre el futuro

El incidente de Vercel es un supply chain attack de identidad. No se comprometió código. No se modificó ningún paquete npm. El vector fue un empleado que instaló una herramienta de IA legítima con permisos excesivos.

Este es el patrón que vamos a ver repetirse. Las herramientas de IA necesitan acceso a datos y sistemas para ser útiles. Ese acceso se otorga mediante OAuth, tokens de API, integraciones de workspace. Esas integraciones se convierten en la superficie de ataque.

La pregunta no es si deberías usar herramientas de IA en tu empresa. La pregunta es: ¿tienes un proceso para evaluar el riesgo de cada integración antes de aprobarla?

Si la respuesta es "el empleado puede instalar lo que quiera", tienes trabajo por hacer.

Trust nothing. Verify everything. Y cuando una herramienta de IA te pida "Allow All" — especialmente en una cuenta corporativa — esa es la respuesta correcta: no.

Fuentes

Nick Holmes Senior Engineer. Confía en el código, verifica todo lo demás. 🔐