Hackearon Vercel: cómo un empleado con un juego de Roblox desató una brecha de $2M

⏱️ Lectura: 11 min

El 19 de abril de 2026, la plataforma de despliegue Vercel — la empresa detrás de Next.js y usada por miles de proyectos web — publicó un boletín de seguridad confirmando que sufrió una brecha. Lo extraordinario no es solo el ataque, sino cómo empezó: un empleado de una empresa de terceros descargando trampas para un juego de Roblox en febrero. Desde ahí, la cadena llegó hasta robar variables de entorno de clientes en producción dos meses después.

📑 En este artículo

1. Resumen de los hechos (cronología verificada)
2. El punto de entrada: un juego de Roblox
3. El pivote: «Allow All» en Google Workspace
4. Qué accedieron — y qué NO — en Vercel
5. IOC publicado e indicadores técnicos
6. La venta en BreachForums: ShinyHunters niega
7. Clientes afectados confirmados públicamente
8. Respuesta coordinada
9. El patrón histórico: no es la primera vez
10. Qué hacer si sos cliente de Vercel
11. Lecciones para cualquier equipo con Google Workspace
12. Contexto de negocio: el momento no podría ser peor
13. Preguntas frecuentes
    1. ¿Mis variables de entorno marcadas como «sensitive» están a salvo?
    2. ¿Debería dejar de usar Vercel?
    3. ¿Los paquetes npm de Vercel fueron comprometidos?
    4. ¿Hay un CVE?
    5. ¿Cuándo sabremos el número exacto de clientes afectados?
14. Referencias
    1. 📚 Artículos relacionados

Este artículo documenta la cronología verificada, el vector técnico, el alcance real, la respuesta coordinada y por qué este incidente encaja en un patrón repetido de ataques supply-chain sobre OAuth en Google Workspace.

Resumen de los hechos (cronología verificada)

• Febrero 2026: Un empleado de Context.ai descarga «auto-farm scripts» y ejecutores de exploits para Roblox. El instalador venía con Lumma Stealer, un infostealer comercial. El malware exfiltra credenciales de Google Workspace, claves de Supabase, Datadog, Authkit y la cuenta [email protected]. Fuente forense: Hudson Rock / InfoStealers.
• Marzo 2026: Context.ai detecta acceso no autorizado a su entorno AWS y elimina una extensión de Chrome sospechosa el 27 de marzo.
• 19 abril 2026, 11:04 AM PST: Vercel publica el primer indicador de compromiso (IOC) en su base de conocimiento.
• 19 abril 2026, 6:01 PM PST: Vercel atribuye el origen al compromiso de Context.ai.
• 19 abril 2026: Un actor que dice ser «ShinyHunters» anuncia venta de datos de Vercel por $2 millones USD en un dominio recién surgido de BreachForums.
• 20 abril 2026, 10:59 AM PST: Vercel aclara que es un compromiso de credenciales, no una vulnerabilidad de software.
• 20 abril 2026, 5:32 PM PST: Vercel confirma que los paquetes npm no fueron comprometidos.

Fuente principal: boletín oficial de Vercel.

El punto de entrada: un juego de Roblox

Según la investigación forense de Hudson Rock confirmada por OX Security, el «paciente cero» fue un empleado de Context.ai que descargó scripts de auto-farm y ejecutores de exploits para Roblox. Estos son modificaciones no oficiales del juego, conocidas en el underground como vector frecuente de distribución de malware.

El instalador traía adjunto Lumma Stealer (también conocido como LummaC2), un infostealer comercial en modalidad malware-as-a-service. Según la advertencia oficial CISA AA25-141b y el análisis técnico de Microsoft Security, Lumma:

• Exfiltra credenciales almacenadas en navegadores, cookies, formularios de autocompletado y datos de extensiones 2FA.
• Ataca wallets de criptomonedas: MetaMask, Binance, Ethereum.
• Scrapea memoria de Chromium vía la API interna CookieMonster para volcar cookies de sesión activas.
• Vectores conocidos en 2025–2026: CAPTCHAs falsos (ClickFix), malvertising, Telegram, payloads hospedados en GitHub, software pirata y trampas de videojuegos.

El pivote: «Allow All» en Google Workspace

El paso crítico: un empleado de Vercel, usando su cuenta corporativa de Google Workspace, se registró en el «AI Office Suite» de Context.ai y concedió permisos OAuth «Allow All«. Según las declaraciones recogidas por Cybernews y Tom’s Hardware, esto habilitó al atacante a secuestrar la cuenta de Google Workspace del empleado una vez que Context.ai fue comprometida.

¿Cómo es posible que un solo OAuth conceda tanto? En Google Workspace, los administradores pueden marcar aplicaciones OAuth como «Trusted» (confiables) — una configuración que, según la ayuda oficial de Google Workspace, otorga acceso a todos los scopes OAuth incluyendo los restringidos (Gmail, Drive, Calendar, APIs de administración), y los scopes ni siquiera aparecen en la pantalla de consentimiento del usuario.

Vercel lo reconoce textualmente: «Las configuraciones internas de OAuth de Vercel aparentemente permitieron esta acción y concedieron estos permisos amplios en el Google Workspace enterprise de Vercel» (citado por Trend Micro). Es decir: el allowlist administrativo estaba demasiado permisivo, no fue un default de Google.

Qué accedieron — y qué NO — en Vercel

El boletín oficial de Vercel es preciso al delimitar el alcance:

«Las variables de entorno no sensibles almacenadas en Vercel (aquellas que se descifran a texto plano) fueron comprometidas. Las variables de entorno marcadas como ‘sensitive’ en Vercel se almacenan de manera que previene su lectura, y no fueron expuestas.»

También no comprometidos: paquetes npm, Next.js, Turbopack, código fuente de los productos open-source de Vercel. CEO Guillermo Rauch instruyó a los clientes directamente: «roten cualquier llave o credencial en sus deployments marcada como ‘non-sensitive’» (citado por TechCrunch).

Vercel caracterizó al atacante como «altamente sofisticado» basándose en «velocidad y conocimiento detallado de los sistemas de Vercel» (vía Trend Micro).

IOC publicado e indicadores técnicos

Vercel publicó un solo IOC público:

• OAuth App ID malicioso: 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com (BleepingComputer).
• No hay CVE asignado: este es un compromiso de credenciales, no una vulnerabilidad de software.

La venta en BreachForums: ShinyHunters niega

El 19 de abril, un actor publicó en un dominio recién surgido de BreachForums la venta del «paquete Vercel» por $2 millones USD. Según BleepingComputer, el lote incluiría:

• Access keys y source code;
• Datos de bases de datos;
• Múltiples cuentas de empleados con acceso a deployments internos;
• API keys (incluyendo algunos tokens de npm y GitHub);
• Archivo de 580 registros de empleados Vercel (nombres, emails, estado de cuenta, timestamps);
• Capturas de pantalla del dashboard Enterprise.

El actor se identifica como «ShinyHunters» — uno de los grupos de ransomware/leak más conocidos de los últimos años. Pero la respuesta del grupo verdadero, vía Hackread, fue contundente: «BreachForums ha sido operado por muchos falsos, pero no por nosotros después del incautamiento del FBI el 10 de octubre de 2025. Nosotros (el grupo ShinyHunters real) tampoco operamos en ninguna plataforma Telegram o foro de leaks.»

Austin Larsen, de Google Threat Intelligence, evaluó públicamente al vendedor como «likely an imposter» (Security Boulevard). La procedencia real de los datos a la venta no está verificada.

Clientes afectados confirmados públicamente

Vercel habla de «un subset limitado de clientes» pero no ha publicado número exacto. TechCrunch reporta que Vercel dijo que el ataque «podría afectar a cientos de usuarios en muchas organizaciones».

Al 20 de abril, la única empresa que confirmó haberse visto afectada en primera persona es Orca, un exchange descentralizado en Solana. Su frontend se hospeda en Vercel; rotaron todas las credenciales de deployment y confirmaron que el protocolo on-chain y los fondos de usuarios no se vieron afectados (Blockhead, CoinDesk).

MEXC News mencionó que Jupiter habría tomado «pasos preventivos», pero sin declaración oficial de Jupiter localizable. Ningún cliente no-crypto ha hecho disclosure público al cierre de esta edición.

Respuesta coordinada

Vercel contrató a Mandiant (Google Cloud) como IR externo y coordinó con GitHub, Microsoft, npm y Socket para verificar que no hubo tampering en paquetes distribuidos. La cobertura de Help Net Security confirma que Vercel notificó a fuerzas de la ley, aunque no se ha nombrado agencia específica.

Producto: las variables sensibles en Vercel ahora vienen con el flag «on» por default. Cambios en los defaults de OAuth no han sido publicados.

El patrón histórico: no es la primera vez

El ataque a Vercel encaja con precisión en un patrón de ataques OAuth supply-chain que se ha repetido en los últimos cuatro años:

Fecha	Incidente	Mecanismo
Abr 2022	Heroku + Travis-CI	OAuth tokens de GitHub robados; clonaron docenas de repos privados.
Ene 2023	CircleCI	Infostealer en endpoint de ingeniero; hijack de session token; exfiltración de OAuth tokens, env vars y llaves SSH.
Oct 2023	Okta support system	Service account comprometida; leak de HAR files de clientes con session tokens; Cloudflare y 1Password como follow-on.
Ene 2024	Microsoft «Midnight Blizzard»	Abuso de legacy OAuth test app para auto-concederse rol full_access_as_app en M365 Exchange.
Abr 2026	Vercel / Context.ai	Infostealer → OAuth app sobre-permisionada → robo de env-vars.

El incidente Vercel combina el patrón CircleCI (infostealer en endpoint de empleado → abuso de session OAuth → exfil de env-vars) con el patrón Midnight Blizzard (OAuth app sobre-privilegiada marcada como «Trusted» en Workspace). Los allowlists de «Allow All» / Trusted en Google Workspace son un primitivo de abuso recurrente.

Qué hacer si sos cliente de Vercel

Los pasos oficiales del boletín de Vercel, complementados con recomendaciones de Trend Micro:

1. Rotar todas las variables de entorno no sensibles inmediatamente. Usá vercel env pull para inventariar qué tenés localmente.
2. Revisar activity logs. Si ves deployments no reconocidos tras marzo, investigá.
3. Habilitar MFA en todas las cuentas del equipo que tengan acceso al proyecto.
4. Deployment Protection mínimo en «Standard». Si usabas tokens de Deployment Protection, rotalos.
5. Rotar upstream primero: antes de rotar la llave en Vercel, rotá en el proveedor origen (Supabase, Stripe, AWS) para que el atacante no use la llave vieja mientras actualizás.

Lecciones para cualquier equipo con Google Workspace

La brecha de Vercel es un recordatorio doloroso de tres principios que los equipos de seguridad ya conocen pero que rara vez enforzean:

1. Cada «Sign in with Google» a una app de terceros es una superficie de ataque supply-chain. Si esa app se compromete, el atacante no tiene que hackearte a vos: usa el token OAuth que ya le diste.
2. «Allow All» / Trusted app en Google Workspace Admin debería estar prohibido por política. Los admins deberían exigir scope-by-scope review antes de autorizar cualquier app, especialmente si la cuenta corporativa tiene acceso a Drive, Gmail o APIs de Admin.
3. Infostealers como Lumma siguen siendo el #1 vector de credential theft en 2026. Endpoint protection + bloqueo de downloads de software pirata + alertas sobre cookies de sesión robadas deberían ser obligatorias.

Contexto de negocio: el momento no podría ser peor

Vercel cerró su Series F en septiembre 2025 por $300 millones co-liderada por Accel con GIC, valuando la empresa en $9.3 mil millones USD — un step-up de ~3x sobre la Series E de mayo 2024 que la había valuado en $3.25B (blog de Vercel).

Fortune y Startup Fortune reportan que Vercel está en pista IPO, y la brecha aterriza «exactamente cuando necesita proyectar estabilidad» (Startup Fortune). El sentiment en el thread de Hacker News es crítico pero no de éxodo: «Cuando un OAuth token puede comprometer dev tools, pipeline CI, secretos y deployment simultáneamente, algo arquitectónico salió mal». Hasta el cierre de este artículo, ningún cliente grande ha anunciado migración.

Preguntas frecuentes

¿Mis variables de entorno marcadas como «sensitive» están a salvo?

Según Vercel, sí. Las variables marcadas como «sensitive» se almacenan de manera que previene su lectura y no fueron expuestas. Solo las variables no sensibles (plaintext) de un subset limitado de clientes fueron comprometidas.

¿Debería dejar de usar Vercel?

La decisión es tuya, pero el incidente — por doloroso que sea — fue manejado con disclosure público rápido, atribución clara, contratación de Mandiant y coordinación con otros proveedores. Es más una señal de madurez en respuesta que de negligencia sistémica. Dicho esto, si tu caso de uso es ultra-sensible (salud, finanzas reguladas), revisá si las «sensitive env vars» de Vercel cumplen con tu compliance.

¿Los paquetes npm de Vercel fueron comprometidos?

No. Vercel coordinó con npm y Socket para verificar que ni vercel, ni Next.js, ni Turbopack, ni ningún paquete publicado fue tampered.

¿Hay un CVE?

No. Este no es un bug de software: es un compromiso de credenciales vía OAuth supply-chain.

¿Cuándo sabremos el número exacto de clientes afectados?

Vercel contactó directamente a los clientes afectados. Mientras tanto, el lenguaje público es «un subset limitado» con referencia periodística a «cientos de usuarios en muchas organizaciones».

Referencias

• Vercel Knowledge Base — April 2026 Security Incident (disclosure oficial)
• TechCrunch — Zack Whittaker, 2026-04-20
• BleepingComputer — Lawrence Abrams, 2026-04-19
• SecurityWeek — Next.js Creator Vercel Hacked
• The Hacker News — Breach tied to Context.ai hack
• Help Net Security — Zeljka Zorz
• CoinDesk — crypto rotation + Orca
• OX Security — research technical
• Trend Micro — OAuth supply-chain analysis
• Hudson Rock / InfoStealers — forensics
• Hackread — ShinyHunters denial
• Security Boulevard — Google TI imposter assessment
• Cybernews — OAuth compromise detail
• Tom’s Hardware — Unrestricted Google Workspace access
• CISA Advisory AA25-141b — Lumma Stealer
• Microsoft Security — Lumma technical breakdown
• Google Workspace Help — Trusted app configuration
• Vercel Series F — $9.3B valuation
• Startup Fortune — IPO context
• Hacker News — thread principal (175 pts)