noticias

Hackearon Vercel a través de Context.ai: cómo un script de Roblox comprometió miles de proyectos en producción

noticias · 7 min de lectura

Hackearon Vercel a través de Context.ai: cómo un script de Roblox comprometió miles de proyectos en producción

Un empleado de Context.ai bajó scripts de Roblox infectados con Lumma Stealer, y la cadena de consecuencias llegó hasta los deploys de Vercel de devs en todo el mundo. Checklist de rotación urgente adentro.

Hackearon Vercel a través de Context.ai: cómo un script de Roblox comprometió miles de proyectos en producción

Imagínate que alguien en tu empresa decide bajarse un script de Roblox para hacer auto-farm. Típico. Lo que no es tan típico es que ese archivo infectado termine abriendo la puerta trasera de Vercel, la plataforma donde tú tienes tus proyectos en producción. Eso es exactamente lo que pasó, y se confirmó ayer.

El origen de todo: Roblox, Lumma y un error que costó millones

En febrero de 2026, un empleado de Context.ai, una empresa que ofrece una especie de suite de IA para oficina, anduvo buscando “Roblox auto-farm scripts” y ejecutores del juego. Descargó uno. Ese archivo traía Lumma Stealer, un infostealer de los más populares en el mercado negro ruso que lleva años siendo distribuido disfrazado de software crackeado, mods de juegos y, sí, cheats de Roblox.

El malware hizo lo suyo: cosechó todo lo que encontró en la máquina. Credenciales de Google Workspace, llaves de Supabase, acceso a Datadog, tokens de Authkit, y lo peor: la cuenta support@context.ai, que tenía acceso a prácticamente todo el workspace de la empresa. Según el análisis de Hudson Rock publicado por InfoStealers, este empleado tenía rol central dentro del equipo context-inc en Vercel, con acceso directo a paneles de variables de entorno, configuraciones de proyectos y logs de producción.

Lo más grueso: Hudson Rock tenía los datos comprometidos más de un mes antes de que el breach se hiciera público. Si alguien hubiera actuado rápido, toda la cadena se rompe ahí.

Cómo llegaron a Vercel: el pedo del OAuth con “Allow All”

Context.ai opera como una aplicación OAuth de Google Workspace. Aquí viene la parte que te va a tronar el cerebro: un empleado de Vercel se registró en Context.ai usando su cuenta corporativa de Google y le dio permisos de “Allow All” a la aplicación.

Eso, en lenguaje llano, significa que Context.ai podía hacer prácticamente lo que quisiera dentro del Google Workspace de ese empleado. Y como la configuración OAuth de Vercel a nivel empresa también era demasiado permisiva, los atacantes pudieron pivotar de “tengo las credenciales de un empleado de Context.ai” a “tengo acceso al Workspace de un empleado de Vercel” de forma casi automática. CyberScoop documentó la cadena completa del ataque, que pasó de infección en febrero hasta exfiltración activa hacia finales de marzo.

Esto no es un fallo técnico de Vercel per se. Es el clásico riesgo de la cadena de suministro: tu proveedor confía en otro proveedor, ese otro proveedor confía en un empleado que baja cheats de videojuegos, y de repente el problema es tuyo. Está una chimba cómo una decisión de cinco segundos puede desencadenar un incidente de $2 millones.

Vale la pena notar que este vector de ataque no es aislado. Si te preocupa la privacidad de tus cuentas de Google y qué apps tienes conectadas, ya habíamos explorado eso cuando Google quiso leer tu Gmail, tus fotos y tu historial con su Personal Intelligence: las apps de terceros con OAuth amplio son exactamente ese riesgo.

Qué se filtró (y qué no)

Aquí las malas y las buenas noticias:

Lo que sí quedó expuesto:

  • Variables de entorno no marcadas como “sensitive” de un subconjunto de clientes de Vercel
  • API keys, tokens de deployment y configuraciones de proyectos guardadas en esas variables
  • Código fuente, bases de datos a las que tenían acceso desde el workspace comprometido

Lo que Vercel dice que NO se tocó:

  • Variables marcadas como “sensitive” (están cifradas y Vercel confirma que no hay evidencia de acceso)
  • Paquetes de npm: Vercel coordinó con GitHub, Microsoft y Socket para validar que no hay compromiso ahí

El 19 de abril a las 02:02 AM ET (23:02/11:02 PM PT del 18 de abril) fue publicado el listing en BreachForums. Para las 6 PM Vercel ya había publicado el origen. El 20 de abril confirmaron que npm estaba limpio.

ShinyHunters en el chat (o alguien haciéndose pasar por ellos)

En BreachForums apareció una oferta: la base de datos interna de Vercel, cuentas de empleados, tokens de GitHub y NPM. Precio pedido: $2 millones de dólares. El post lo firmó alguien usando el nombre de ShinyHunters, el mismo grupo detrás de varios breaches recientes.

Pero Google Threat Intelligence metió el freno: según ellos, es probable que sea un impostor usando el nombre establecido para inflar su credibilidad en el mercado. Actores previamente vinculados a ShinyHunters también lo negaron. Las afirmaciones no han sido verificadas de forma independiente.

De todas formas, que sea o no ShinyHunters no cambia que el breach es real y que TechCrunch confirmó que Vercel admitió el incidente.

Si usas Vercel: el checklist que tienes que hacer ahorita

Si tienes proyectos en producción en Vercel, esto no es opcional. Hazlo hoy:

Inmediato (los próximos 30 minutos):

  1. Entra a tu proyecto en Vercel y ve a Settings > Environment Variables
  2. Rota TODAS las variables que NO están marcadas como “Sensitive” y que contengan keys reales: base de datos, servicios de pago, APIs de terceros
  3. Rota también tus Deployment Protection Tokens
  4. Activa MFA en tu cuenta de Vercel si no la tienes, preferiblemente con passkey o app autenticadora (no SMS)

Auditoría OAuth (esta semana sin falta):

  1. Entra a myaccount.google.com/permissions o la consola de tu Google Workspace empresarial
  2. Revisa TODAS las apps conectadas con permisos amplios
  3. Revoca acceso a cualquier herramienta que ya no uses activamente
  4. Nunca más des permisos de “Allow All” a ninguna app: solo los scopes exactos que necesita
  5. Establece re-autenticación obligatoria para operaciones sensibles

Hardening a largo plazo:

  • Marca todas tus variables de entorno como “Sensitive” por default, no solo las obvias
  • Usa un gestor de secretos real (HashiCorp Vault, AWS Secrets Manager) para prod
  • Despliega EDR en las máquinas de todos los que tienen acceso a infraestructura de producción
  • Prohíbe a nivel de política corporativa que se descarguen ejecutables y archivos comprimidos de fuentes no verificadas en máquinas con acceso a prod

Este último punto suena a “obvio”, pero ahí está el problema: un desarrollador de una empresa de IA bajó un executor de Roblox en su computadora de trabajo. Y si usas herramientas de IA para programar como Claude Code o Cursor con acceso a tu codebase, que esas herramientas tengan OAuth bien configurado también es parte del riesgo que hay que tomar en serio.

Lo que esto nos enseña como devs

El punto real de este hack no es que Vercel falló. Es que la cadena de confianza en los servicios modernos de desarrollo está llena de puntos ciegos. Conectas una herramienta de IA a tu workspace, esa herramienta conecta con otras, y de repente un empleado en una empresa que ni conocías decide bajarse un cheat de juego en su laptop del trabajo.

Los ataques de supply chain llevan años en aumento porque es más fácil comprometer a un proveedor pequeño que atacar directamente a la empresa grande. Context.ai no es Vercel. Pero estaba conectada a Vercel con permisos que nunca debieron ser tan amplios.

La buena noticia: si sigues el checklist de arriba y marcas tus variables como sensibles, este tipo de ataques no llegan tan lejos. El cifrado funciona. El problema fue que no todo estaba cifrado.

¿Tú tienes variables en Vercel sin el flag de “sensitive”? Ahora sería buen momento para revisarlo. Cuéntame en los comentarios si encontraste algo raro en tu auditoría OAuth.

Fuentes

Comentarios

No te pierdas ningún post

Recibe lo nuevo de Al Chile Tech directo en tu correo. Sin spam.

También te puede interesar