Hace unos días Vercel confirmó una brecha de seguridad. La cobertura mediática la presentó como “un empleado cuya cuenta de Google Workspace fue comprometida”. Técnicamente es correcto aunque incompleto.
La historia real es más interesante, y mucho más incómoda para todos nosotros.
Lo que pasó, de verdad
Un empleado de Vercel se registró en Context.ai, una herramienta de IA para equipos, usando su cuenta corporativa. Al conectarla, hizo algo que todos hemos hecho alguna vez: aceptó los permisos de OAuth sin leerlos demasiado. En este caso, “Allow All”.
Hasta aquí, nada fuera de lo normal.
Lo que nadie sabía es que meses antes, en febrero, un empleado de Context.ai había descargado cheats para Roblox. Los cheats son scripts que permiten hacer trampas en videojuegos. Algo que, a priori, no tiene nada que ver con una brecha de seguridad corporativa.
Pero esos scripts contenían Lumma Stealer, un infostealer que robó las credenciales del empleado en silencio. Con esas credenciales, el atacante accedió al entorno AWS de Context.ai y obtuvo algo muy valioso: los tokens OAuth de sus usuarios.
¿Qué es un token OAuth? Sin entrar en tecnicismos, es una cadena de caracteres que actúa como una llave. Le dice a un sistema “este tercero tiene permiso para acceder a los datos de este usuario”. No es una contraseña, pero funciona igual de bien para entrar.
Y el empleado de Vercel era uno de esos usuarios.
Con ese token en su poder, el atacante accedió al Google Workspace corporativo de Vercel, y desde ahí a entornos de clientes y variables de entorno no marcadas como sensibles.
Nadie hackeó a Vercel directamente. Nadie explotó una vulnerabilidad en su código. Entraron por la puerta que el propio empleado había abierto, con buenas intenciones, hace tiempo.
Y esto es lo crítico. No hablo de Vercel. Hablo del modus operandi.
Muchas veces creemos que nuestra web, empresa o servicio está protegido de ataques externos, y nos cuidamos en salud para que así sea. Pero a veces el vector de ataque no proviene de aquello que no dejamos pasar. A veces proviene de aquello que sí dejamos pasar.
Imagina tu casa con un portero en la puerta. Ese portero tiene una lista de personas autorizadas: familiares, amigos, personas de confianza. Todo lo que no esté en esa lista no pasa. La analogía parece sencilla. Cualquier persona con malas intenciones se queda fuera, porque el portero tiene órdenes estrictas.
Pero ¿qué ocurre si el problema te lo trae alguien de quien sí te fías?
Ese fue el caso.
El problema real: OAuth es invisible
OAuth tiene una propiedad que lo hace peligroso en contextos corporativos: una vez configurado, desaparece del radar.
Cuando un desarrollador conecta una herramienta al workspace de la empresa, el flujo es:
- Click en “Conectar con Google”
- Pantalla de permisos (que nadie lee)
- “Aceptar”
- Listo, funciona
Y ahí se queda. Para siempre. Sin fecha de expiración por defecto. Sin ninguna revisión periódica. Sin que nadie en el equipo de seguridad sepa que existe.
Si hoy mismo entras a tu cuenta de Google y vas a myaccount.google.com/connections, probablemente vas a encontrar aplicaciones que ni recuerdas haber autorizado. Algunas con acceso a Gmail. Otras a Drive. Algunas con permisos de lectura y escritura sobre todo.
Cada una de esas conexiones es una superficie de ataque que no está en tu mapa. Y son conexiones que tú aceptaste.
Por eso es importante revisar quién y qué aplicaciones tienen acceso a tus datos. A esto yo lo llamo un detox digital. Es un proceso que intento hacer anualmente. Tedioso, pesado y cansado, sí. Pero nada mejor que tener la conciencia tranquila de saber que solo accede a tus datos quien tú decides.
El vector que nadie mira: Ataque a la cadena de suministro
El modelo mental de seguridad que tenemos interiorizado sigue siendo aunque necesario, insuficiente: credenciales que cumplan una serie de dígitos, signos, letras, etc. que no se repitan, que incluya MFA (Autenticación Multi Factor), mantener actualizados nuestros dispositivos y sistemas. Todo eso es correcto. Y necesario. Sin embargo, es insuficiente cuando el vector de ataque, rompe cualquier esquema previsto hasta ahora.
OAuth rompe ese modelo por diseño. La amenaza no viene de que alguien adivine tu contraseña ni de que explote una CVE en tu infraestructura por no tener tus sistemas actualizados. Viene de que uno de los cientos de servicios SaaS que usa tu equipo sufra una brecha, y ese servicio tenga tokens válidos para entrar en tus sistemas.
No necesitas atacar a Vercel. Atacas a Context.ai, que tiene acceso a Vercel. Eso es un ataque a la cadena de suministro.
O atacas al plugin de Notion que el equipo de producto conectó hace seis meses. O la herramienta de analytics que alguien probó en una prueba de concepto y nunca desconectó. O el servicio de automatización que un desarrollador autorizó desde su cuenta personal de trabajo.
El atacante no necesita explotar nada sofisticado. Solo necesita encontrar el eslabón más débil en la cadena de confianza transitiva que se ha construido.
Por qué esto va a empeorar
La adopción de herramientas de IA en entornos corporativos está acelerando exactamente este problema. Cada nueva herramienta de “IA para equipos” pide acceso a tu calendario, tu email, tus documentos, tu Slack. Y la propuesta de valor es real: cuanto más acceso tiene, más útil es.
El empleado de Vercel no hizo nada extraño. Probó una herramienta de IA que prometía ser útil y la conectó con su cuenta de trabajo. Eso es lo que hace todo el mundo. Eso es lo que yo hago. Probablemente lo que tú también haces.
El problema no es el comportamiento individual. Es que las organizaciones no tienen visibilidad ni control sobre la suma de esos comportamientos individuales.
Qué se puede hacer
No hay solución perfecta, pero sí hay puntos de partida concretos:
Inventario de integraciones OAuth. Si no sabes qué aplicaciones tienen acceso a tus sistemas, no puedes protegerlos. Google Workspace, Microsoft 365 y la mayoría de plataformas SaaS tienen consolas de administración donde puedes ver y revocar accesos de terceros. La mayoría de equipos nunca las miran.
Política de autorización. Definir qué aplicaciones pueden conectarse a recursos corporativos, con qué permisos y con qué proceso de aprobación. No para bloquearlo todo, sino para tener visibilidad. Una autorización informal sigue siendo mejor que ninguna.
Principio de mínimo privilegio aplicado a OAuth. Si una herramienta pide acceso de lectura y escritura a todo el Drive cuando solo necesita leer un directorio específico, ahí hay un problema. Los scopes de OAuth son granulares por diseño; hay que usarlos.
Tokens con expiración y revisión periódica. Algunas plataformas permiten configurar la caducidad de los tokens de terceros. No es la norma, pero cuando está disponible, hay que activarlo.
Monitorización de accesos de terceros. Los logs de acceso de tu Google Workspace o Microsoft 365 registran qué aplicaciones acceden a qué recursos.
Conclusión
El incidente de Vercel no es una historia sobre un empleado descuidado ni sobre una herramienta de IA insegura. Es una historia sobre cómo la superficie de ataque de las organizaciones modernas se extiende mucho más allá de sus propios sistemas.
Cada integración OAuth es una decisión de confianza. Y las decisiones de confianza tienen consecuencias que no siempre son visibles hasta que alguien las explota.
La pregunta que vale la pena hacerse hoy no es “¿tenemos nuestros sistemas parcheados?”. Es: “¿sabemos quién tiene acceso a nuestros sistemas a través de los sistemas de otros?”
Probablemente la respuesta sea no. Y eso es un problema que ningún parche puede resolver. Pero sí uno que se puede vigilar, si sabes dónde mirar.
Si quieres seguir mirando en la dirección correcta, tengo una newsletter para ti. Sin cadencia fija, sin relleno. Solo escribo cuando tengo algo que vale la pena leer. Puedes suscribirte aquí abajo, totalmente gratis.
Nos vemos en la red.
Álvaro (aka. BlackSheep4)