Voy a ser directo: Vercel acaba de revelar una de las brechas de supply chain más instructivas que vimos en años, y la causa raíz no fue un zero-day, un firewall mal configurado ni una cadena de exploits sofisticada. Fue un empleado otorgando permisos OAuth “Allow All” a una pequeña herramienta de productividad con IA. Ese solo clic escaló hasta comprometer entornos internos completos, exponer credenciales de clientes y generar una demanda de $2M de rescate por parte de un actor que opera bajo la marca ShinyHunters en BreachForums.
Si desplegás en Vercel — o si tu equipo usa herramientas de IA conectadas a tu Google Workspace — esta es la historia que necesitás entender ahora mismo.
La Kill Chain: De Cheats de Roblox a Brecha Enterprise
La forensia pinta un cuadro notablemente detallado, y cada eslabón de esta cadena vale la pena examinar.
Paso 1 — El infostealer. En febrero de 2026, un empleado de Context.ai descargó scripts de auto-farm de Roblox y exploits de juegos en lo que parece haber sido una máquina de trabajo. Esas descargas traían un payload de Lumma stealer. El malware cosechó credenciales corporativas de Google Workspace, Supabase, Datadog y Authkit — el toolkit completo de alguien con acceso de nivel admin en Context.ai.
Paso 2 — El pivoteo a tokens OAuth. Context.ai es una plataforma de IA empresarial que también ofrecía un producto consumer llamado “AI Office Suite” — un workspace para construir presentaciones y documentos con agentes de IA. Ese suite se conectaba a las cuentas de Google Workspace de los usuarios vía OAuth. Cuando los atacantes comprometieron el entorno AWS de Context.ai (detectado en marzo de 2026), también obtuvieron tokens OAuth de usuarios consumer de ese suite.
Paso 3 — La conexión con Vercel. Vercel nunca fue cliente de Context.ai. Pero al menos un empleado de Vercel se había registrado en el AI Office Suite usando su cuenta enterprise de Google y otorgó permisos “Allow All”. Ese solo grant de OAuth le dio a los atacantes un camino directo al Google Workspace de Vercel — y de ahí, a los entornos de Vercel.
Paso 4 — Enumeración de variables de entorno. Vercel distingue entre variables de entorno “sensitive” (encriptadas en reposo, ilegibles) y estándar. El atacante enumeró las variables no sensibles, que — a pesar del nombre — contenían API keys, tokens, credenciales de bases de datos y signing keys que los clientes no habían marcado como sensibles. Vercel describe al atacante como “altamente sofisticado” con conocimiento profundo de sus sistemas y velocidad operacional notable.
Paso 5 — El rescate. Un threat actor que dice pertenecer a ShinyHunters publicó en BreachForums ofreciendo el supuesto dataset — access keys, código fuente, bases de datos internas, tokens de GitHub, tokens de NPM y 580 registros de empleados — por $2 millones empezando con $500K en Bitcoin. Actores vinculados a ShinyHunters negaron participación en esta brecha específica, así que la atribución sigue siendo incierta.
Lo Que CrowdStrike No Vio
Hay una capa incómoda acá. Context.ai contrató a CrowdStrike después del incidente de AWS en marzo. CrowdStrike investigó y Context.ai cerró el entorno afectado. Pero el compromiso de tokens OAuth no se identificó en ese momento — recién salió a la luz cuando Vercel le proporcionó información adicional a Context.ai el 19 de abril. La inteligencia de cibercrimen de Hudson Rock había flaggeado la infección de infostealer del empleado de Context.ai más de un mes antes de la divulgación de Vercel. Si esa exposición de credenciales se hubiera detectado y revocado inmediatamente, toda esta cascada de supply chain podría haberse prevenido.
Tres Fallas, No Una
The Register lo puso bien: todos los actores en esta historia cometieron errores.
Context.ai tenía un empleado cuya máquina fue comprometida por un Lumma stealer entregado a través de descargas de exploits de juegos — sugiriendo seguridad de endpoint débil y ningún monitoreo efectivo de credenciales.
La investigación de CrowdStrike parece haber pasado por alto el compromiso de tokens OAuth durante la revisión forense inicial, detectándolo recién después de que Vercel sacó a la luz la conexión semanas más tarde.
Vercel no restringió los grants de scope OAuth en su Google Workspace enterprise. Un empleado individual pudo otorgar permisos “Allow All” a una herramienta de IA externa — una configuración que nunca debería haber sido posible bajo un Workspace correctamente gobernado.
Qué Deberías Hacer Ahora Mismo
Si tu equipo despliega en Vercel o usa herramientas de IA conectadas a Google Workspace, estas son las acciones inmediatas:
Chequeá el IOC. Andá a tu Google Admin Console → Security → Access and Data Control → API Controls → Manage Third-Party App Access. Buscá este OAuth Client ID: 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com. Si aparece, revocalo inmediatamente y empezá tu protocolo de incident response.
Rotá tus secrets de Vercel. Revisá todas las variables de entorno. Cualquier cosa almacenada como “non-sensitive” que en realidad contenga API keys, tokens o credenciales de base de datos debería rotarse ahora y re-marcarse como sensitive. Vercel liberó nuevas funciones en el dashboard para facilitar esto.
Auditá tus grants de OAuth. Listá cada app de terceros conectada al Google Workspace de tu organización. Para cada una, preguntate: ¿esta app necesita estos scopes? ¿El grant fue revisado? ¿Podés restringirlo a read-only o scopes específicos? Si sos admin, considerá configurar Google Workspace para requerir aprobación de admin para grants OAuth de scope alto.
Revisá tu clasificación de env vars. La distinción entre “sensitive” y “non-sensitive” en Vercel no es cosmética — determina la encriptación en reposo. Si venías siendo perezoso con marcar variables como sensitive, esta brecha es la razón para arreglar eso hoy.
La Lección Más Grande
Esta no es solo una historia de Vercel. Es una historia sobre la superficie de ataque creciente que crean las herramientas de IA que piden acceso OAuth a tu workspace. Cada popup de “Conectar a Google Drive,” “Acceder a tu Gmail,” “Permitir todos los permisos” es un potencial camino de movimiento lateral para un atacante. Y la mayoría de las organizaciones no gobiernan esos grants en absoluto.
El playbook de 2024 era “tené cuidado con qué paquetes npm instalás.” El playbook de 2026 necesita agregar: “tené el mismo cuidado con qué herramientas de IA conectás a tus cuentas enterprise — y bloqueá los scopes cuando lo hagas.”
Una descarga de cheats de Roblox. Un grant de OAuth sin revisar. Una exposición de credenciales sin monitorear. Eso es todo lo que hizo falta.
La investigación de Vercel sigue en curso. Si surgen detalles adicionales, actualizaremos este artículo. Si desplegás en Vercel, chequeá tus variables de entorno hoy — no esperes.