Brecha en Vercel: un ataque OAuth expone el riesgo oculto de las variables de entorno en la plataforma

• La brecha en la cadena de suministro de OAuth llevó al acceso a sistemas internos de Vercel y a la exposición de variables de entorno en un número limitado de proyectos de clientes
• El punto de partida fue la infección con Lumma Stealer de un empleado de Context.ai, y los tokens OAuth filtrados de Google Workspace se usaron para acceder a una cuenta de empleado de Vercel y a sistemas internos
• Los atacantes obtuvieron permisos para enumerar variables de entorno de proyectos de clientes, y en particular las variables marcadas como non-sensitive ampliaron la posibilidad de exponer credenciales de servicios aguas abajo
• Según lo que se ha hecho público, en al menos un caso hubo detección de una API key filtrada antes de la divulgación de Vercel, y la diferencia de tiempo entre la detección y la notificación surgió como un factor de riesgo clave
• Este incidente mostró que la combinación de relaciones de confianza OAuth y la forma en que la plataforma almacena variables de entorno puede llevar a la propagación de credenciales en toda la cadena de suministro

---

Implicaciones clave

• Se confirma el efecto amplificador de OAuth
  • La vulneración de una sola relación de confianza OAuth se expandió en cadena desde un proveedor hasta sistemas internos de Vercel
  • Incluso quedaron expuestas de forma limitada variables de entorno de proyectos de clientes sin relación directa con el proveedor comprometido
• Se plantea la posibilidad de actividad ofensiva acelerada por IA
  • El CEO relacionó públicamente la velocidad inusual de los atacantes con un posible refuerzo mediante IA
  • Sin embargo, esta evaluación no es una conclusión forense oficial, sino una declaración pública
• Se destaca la demora entre detección y divulgación
  • En al menos un reporte público de un cliente hay indicios de detección de una key filtrada 9 días antes de la divulgación de Vercel
  • En una brecha de plataforma, la demora entre detección y notificación se señala como un factor de riesgo importante
• Vinculación con un patrón más amplio de 2026
  • Junto con LiteLLM, Axios, Codecov y CircleCI, encaja en la tendencia de cadena de suministro que apunta a credenciales almacenadas por desarrolladores

Línea de tiempo del incidente

• Aproximadamente en febrero de 2026, un empleado de Context.ai fue infectado con Lumma Stealer, lo que provocó la filtración de credenciales corporativas, tokens de sesión y tokens OAuth
• Aproximadamente en marzo de 2026, los atacantes accedieron al entorno AWS de Context.ai y robaron tokens OAuth dirigidos a usuarios consumidores
  • Entre ellos, un token de Google Workspace de un empleado de Vercel
• En marzo de 2026, el token OAuth robado permitió acceder a la cuenta de Google Workspace de un empleado de Vercel
• De marzo a abril de 2026, tras moverse a sistemas internos de Vercel, comenzó la enumeración de variables de entorno de clientes
• Aproximadamente en abril de 2026, surgió la afirmación de que actores vinculados a ShinyHunters comenzaron a vender datos de Vercel
• El 10 de abril de 2026, un cliente de Vercel mencionó públicamente haber recibido una alerta de OpenAI sobre una API key filtrada
• El 19 de abril de 2026, Vercel publicó su aviso de seguridad y divulgó un hilo en X
• Después del 19 de abril de 2026, avanzaron las notificaciones a clientes, las guías para rotar credenciales y el despliegue de cambios en el dashboard
• Incluso con una permanencia relativamente corta de unos 2 meses, se confirmó la rapidez con la que se pasó de la infección de un proveedor tercero a la filtración de variables de entorno de clientes
• El período predeterminado de retención de logs de auditoría OAuth de Google Workspace es de 6 meses en muchos planes
  • Es probable que esta permanencia de unos 2 meses todavía quede dentro de esa ventana de retención
  • También se señaló que brechas similares de mayor duración podrían exceder el período de retención predeterminado

Cadena del ataque

• Etapa 1: brecha OAuth de un tercero

  • Context.ai tenía una aplicación OAuth de Google Workspace aprobada por un empleado de Vercel
  • El compromiso de esa aplicación se rastreó hasta la infección con Lumma Stealer de un empleado de Context.ai alrededor de febrero de 2026
  • Según reportes de Hudson Rock y CyberScoop, ese empleado se habría infectado tras descargar un script de exploit para un juego de Roblox
  • Con las credenciales robadas, los atacantes accedieron al entorno AWS de Context.ai y filtraron tokens OAuth para usuarios consumidores de Context AI Office Suite, lanzado en junio de 2025
  • Context.ai informó que detectó y detuvo el acceso no autorizado a su entorno AWS en marzo de 2026
  • Sin embargo, especificó que la filtración de los propios tokens OAuth no fue identificada hasta la investigación de Vercel
  • Las aplicaciones OAuth aprobadas tienen las siguientes características
    • No requieren la contraseña del usuario
    • Pueden seguir funcionando incluso después de un cambio de contraseña
    • Con frecuencia tienen amplios permisos sobre correo, Drive, Calendar y más
    • Rara vez son objeto de auditoría después de la aprobación inicial

• Etapa 2: toma de control de la cuenta de Workspace

  • El acceso a la aplicación OAuth comprometida permitió moverse a la cuenta de Google Workspace de un empleado de Vercel
  • Esto hizo posible obtener acceso al correo, a documentos internos en Google Drive, visibilidad sobre calendario y recursos conectados, y potencialmente a otros servicios enlazados por OAuth

• Etapa 3: acceso a sistemas internos

  • Desde la cuenta de Workspace comprometida hubo movimiento adicional hacia sistemas internos de Vercel
  • Rauch mencionó que la escalada avanzó mediante una serie de maniobras iniciadas desde la cuenta de Google Workspace comprometida de un colega en Vercel
  • Los métodos específicos de movimiento lateral no fueron divulgados
    • Integración con SSO
    • Credenciales recopiladas desde correo o Drive
    • Otras herramientas internas conectadas por OAuth
    • No se ha revelado cuál de estas opciones fue

• Etapa 4: enumeración de variables de entorno

  • Los atacantes lograron acceso a sistemas internos de Vercel con permisos suficientes para enumerar variables de entorno de proyectos de clientes
  • Vercel ofrece una función para marcar variables de entorno de clientes como “non-sensitive”
  • Según las declaraciones públicas, no todas las variables de entorno de clientes estaban protegidas de la misma manera, y la enumeración de las variables sin marca de sensibilidad permitió obtener acceso adicional

• Etapa 5: posible abuso de servicios aguas abajo

  • Las variables de entorno expuestas suelen incluir credenciales de servicios aguas abajo
  • Según el reporte público de Andrey Zagoruiko del 19 de abril de 2026, el 10 de abril recibió una alerta de OpenAI sobre una key filtrada
  • Según la afirmación del reportante, esa key no existía fuera de Vercel
  • Esto plantea la posibilidad de que al menos una credencial expuesta haya sido detectada externamente antes de la divulgación de Vercel

El vacío de 9 días antes de la divulgación

• En una respuesta del hilo de X de Guillermo Rauch del 19 de abril, el cliente Andrey Zagoruiko reveló públicamente que recibió una alerta de OpenAI sobre una key filtrada el 10 de abril de 2026
• La detección de credenciales filtradas por parte de OpenAI normalmente se activa cuando se encuentran en ubicaciones públicas como GitHub, sitios de paste y similares
• En el artículo se evalúa que la ruta que va desde una variable de entorno en Vercel hasta una alerta de OpenAI no es simple
• Por fechas, existe una ventana de 9 días entre la evidencia pública más temprana de exposición y la divulgación de Vercel

• Lo que significa y lo que no significa este vacío de 9 días

  • Se trata de un único reporte público y no de un resultado forense confirmado
  • No debe interpretarse como prueba de que Vercel ya conocía la brecha el 10 de abril
  • Aun así, sí tiene valor como indicio de que al menos una credencial fue detectada externamente antes de la notificación para rotar secretos enviada a clientes

• Implicaciones para cada parte interesada

  • Reguladores
    • Bajo el GDPR, el reloj de notificación de 72 horas comienza cuando el responsable del tratamiento toma conocimiento de la brecha
    • El momento en que Vercel tuvo conocimiento se perfila como un punto público de discusión
  • Auditores
    • Quienes evalúan SOC 2 e ISO 27001 pueden revisar la demora entre detección y notificación como evidencia de monitoreo continuo
  • Clientes
    • No se puede asumir que la ventana de exposición comenzó el 19 de abril
    • El artículo plantea que pudo haber explotación activa desde antes
  • Las alertas de credenciales filtradas emitidas por proveedores ganan importancia como canal de alerta temprana
  • Se incluyen ejemplos como OpenAI, Anthropic, GitHub, AWS y Stripe

Actividad de ataque acelerada por IA

• Guillermo Rauch dijo en X el 19 de abril de 2026 que sospecha firmemente que el grupo atacante es altamente sofisticado y que estuvo considerablemente acelerado por IA.
• El artículo trata esta afirmación como una evaluación en registro público del CEO de la plataforma afectada y menciona la necesidad de una revisión cautelosa.

• Indicios que podrían esperarse en la evidencia forense

  • Velocidad de enumeración por encima del ritmo manual
    • Parte de esto puede explicarse solo con scripting.
    • El reconocimiento basado en LLM puede paralelizar la exploración de esquemas, el sondeo de endpoints y el reconocimiento de formatos de credenciales.
  • Construcción de consultas con conciencia contextual
    • Consultas que parecen conocer la terminología propia de Vercel, los slugs de proyecto, los nombres de objetivos de despliegue y las convenciones de nombres de env vars, incluso sin reconocimiento previo evidente.
  • Adaptabilidad en la respuesta a errores
    • El cambio de estrategia después de errores de API y rate limits es más flexible que en scripts estáticos.
  • Productos de ingeniería social con apariencia localizada
    • Señuelos de phishing, mensajes de commit y tickets de soporte con una calidad más cercana al contexto local que una traducción o plantilla.

• Importancia más allá del incidente de Vercel

  • Independientemente de si esta evaluación se sostiene en la investigación forense formal, la categoría de operaciones de ataque reforzadas por IA ya no es mera especulación.
  • En su anuncio de abril de 2026, Microsoft documentó casos de device-code phishing impulsado por IA, generación dinámica de código, señuelos hiperpersonalizados y orquestación automatizada de backend.
  • Se advierte que las líneas base de telemetría ajustadas a parámetros de velocidad humana pueden producir false negatives frente a operadores acelerados por IA.

• Implicaciones para la ingeniería de detección

  • Si se comprimen la enumeración y el movimiento lateral, las reglas tradicionales basadas en permanencia y umbrales de velocidad podrían generar menos alertas de las debidas.
  • Se plantea la necesidad de revisar lo siguiente:
    • velocidad de enumeración de recursos únicos por sesión
    • curva de recuperación de éxito frente a errores
    • diversidad de patrones de consulta en periodos cortos

Vulnerabilidad clave en el diseño de variables de entorno

• El aspecto más crítico del artículo no es el vector de acceso inicial en sí, sino el modelo de sensibilidad de variables de entorno de Vercel.

• Cómo funcionaban en ese momento las variables de entorno de Vercel

  • Los proyectos inyectan variables de entorno en funciones serverless y en el proceso de build.
  • Existe una bandera de sensitive por variable.
  • El valor por defecto es non-sensitive.
  • sensitive debe activarse explícitamente.
  • Las variables non-sensitive se muestran en el dashboard.
  • Las variables sensitive se enmascaran después de crearse.
  • El acceso vía API interna es posible para non-sensitive; en sensitive está restringido.
  • Según declaraciones públicas, el almacenamiento cifrado no se aplicaba a non-sensitive; para sensitive sí se aplicaba junto con restricciones adicionales.
  • En esta brecha, aquello a lo que pudieron acceder los atacantes estaba marcado como non-sensitive.

• Decisión de diseño determinante

  • La bandera sensitive está desactivada por defecto.
  • Cualquier DATABASE_URL, API_KEY, STRIPE_SECRET_KEY o AWS_SECRET_ACCESS_KEY que los desarrolladores no activaran explícitamente se almacenaba sin cifrar dentro del modelo de acceso interno de Vercel.
  • Se evalúa que un control de seguridad que exige opt-in explícito por cada secreto, sin protección base ni guardrails por defecto, tiene una baja tasa de adopción real.

• Respuesta de Vercel

  • Se confirmó el despliegue de mejoras en la página de resumen de variables de entorno y en la UI de creación y gestión de variables sensibles.
  • Hubo mejoras en visibilidad, pero al momento de redactarse esto el valor por defecto no había cambiado.
  • Sigue siendo necesario el opt-in por variable.
  • Si se cambiará el valor predeterminado sigue siendo una pregunta abierta públicamente.

• Comparación con la industria

  • La industria se está moviendo hacia almacenes de secretos dedicados como Vault, AWS Secrets Manager, Doppler e Infisical.
  • Se considera que este incidente respalda la elección de una arquitectura de gestión de secretos dedicada frente al enfoque basado en variables de entorno de Vercel.
  • Según la tabla comparativa:
    • Vercel usa non-sensitive por defecto y no tiene detección automática.
    • AWS SSM Parameter Store soporta SecureString.
    • HashiCorp Vault ofrece cifrado para todos los secretos y ACL.
    • GitHub Actions enmascara en logs todos los secretos.
    • Netlify usa un esquema de variables de entorno con toggle de secret.

Credential fan-out y riesgo aguas abajo

• Credential fan-out es el fenómeno por el cual una sola brecha en una plataforma expone en cascada todos los servicios aguas abajo que se autentican con credenciales almacenadas en esa plataforma.
• Resumen de elementos que suelen estar en las variables de entorno de proyectos de Vercel y su impacto aguas abajo
  • Bases de datos
    • DATABASE_URL, POSTGRES_PASSWORD
    • Posible acceso completo a los datos
  • Nube
    • AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY
    • Posible compromiso de la cuenta cloud
  • Pagos
    • STRIPE_SECRET_KEY, STRIPE_WEBHOOK_SECRET
    • Riesgo sobre datos financieros y fraude de reembolsos
  • Autenticación
    • AUTH0_SECRET, NEXTAUTH_SECRET
    • Posibilidad de falsificación de sesiones y toma de cuentas
  • Envío de correo
    • SENDGRID_API_KEY, POSTMARK_TOKEN
    • Posibilidad de phishing usando dominios de confianza
  • Monitoreo
    • DATADOG_API_KEY, SENTRY_DSN
    • Posible manipulación de telemetría
  • Código fuente y paquetes
    • GITHUB_TOKEN, NPM_TOKEN
    • Posible inyección en la cadena de suministro
  • AI/ML
    • OPENAI_API_KEY, ANTHROPIC_API_KEY
    • Posible abuso de API y generación de costos
• Un solo proyecto de Vercel normalmente incluye entre 10 y 30 variables de entorno.
• A escala organizacional, un portafolio de 50 proyectos puede implicar entre 500 y 1,500 credenciales dentro de la plataforma.
• Aunque se dice que en este incidente solo se accedió a algunos proyectos de clientes, cada credencial expuesta puede convertirse en un punto de salto hacia otro sistema.
• El artículo define este punto no como un simple incidente de confidencialidad en la plataforma, sino como un efecto multiplicador que se expande por toda la cadena de suministro de software.

Relaciones de confianza OAuth y evasión de defensas perimetrales

• Una intrusión basada en OAuth evita muchos controles diseñados para detectar y bloquear ataques tradicionales basados en credenciales.
• El artículo incluye una mención de aproximadamente 22 meses, pero en la corrección superior se aclara que el tiempo de permanencia fue de alrededor de 2 meses.
• Se describe que los controles defensivos de los que dependen los equipos de seguridad en la columna izquierda se vuelven irrelevantes o ya se consideran cumplidos en una ruta de compromiso mediante una app OAuth.
• Debido a esta asimetría, la gobernanza de OAuth está surgiendo como un dominio de seguridad separado de IAM.

• La gobernanza de OAuth es una función de riesgo de proveedores

  • Muchas organizaciones tratan la aprobación de OAuth como un tema de autoservicio para desarrolladores.
  • Se limitan a aprobar herramientas necesarias por empleado y a una revisión central mínima.
  • Este incidente se presenta como fundamento para tratar las apps OAuth aprobadas como proveedores terceros con acceso persistente.
  • Se requiere revisión de proveedores, reautorización periódica y monitoreo de uso anómalo.

Afirmaciones del actor de amenazas y atribución

• Se parte de la premisa de que las afirmaciones de actores de amenazas en foros clandestinos son inherentemente poco confiables.
• La información aquí se organiza no como hechos confirmados, sino con fines de reconocimiento y seguimiento.

• Afirmación de vínculo con ShinyHunters

  • Un usuario de BreachForums afirmó estar vinculado con ShinyHunters y dijo poseer datos de Vercel.
  • Elementos de datos supuestamente obtenidos
    • alrededor de 580 registros de empleados
    • repositorios de código fuente
    • claves API y tokens internos
    • tokens de GitHub y NPM
    • comunicaciones internas
    • acceso al workspace de Linear
  • Todas las cifras y el alcance anteriores están sin verificar.

• Factores que dificultan la atribución

  • Miembros conocidos de ShinyHunters negaron su participación ante BleepingComputer.
  • Existe la afirmación de que se exigió un rescate de 2 millones de dólares por Telegram.
  • La marca ShinyHunters ha sido usada por múltiples actores, o por actores no relacionados, desde la campaña original.
  • El aviso de seguridad de Vercel no menciona esas afirmaciones del foro.
  • El hilo de Rauch aborda la cadena de ataque, pero no trata directamente la publicación del foro.

• Postura de Vercel sobre la ruta de liberación en la cadena de suministro

  • Rauch analizó la cadena de suministro de Next.js, Turbopack y varios proyectos de código abierto, y señaló a la comunidad que son seguros.
  • Al momento de escribir esto, la verificación independiente sigue en curso.
  • Se recomienda que las organizaciones que usan Next.js, Turbopack y otros proyectos open source de Vercel sigan revisando señales de integridad de paquetes como checksums, firmas y provenance attestation.
  • Dado que no existe verificación independiente de los datos afirmados en el foro, es necesario tratarlos como información no confirmada.
  • Se considera que la cadena de ataque basada en OAuth descrita por Vercel basta por sí sola para sustentar técnicamente el incidente, sin que sea condición necesaria el alcance de acceso mucho más amplio afirmado por el usuario del foro.

Mapeo a MITRE ATT&CK

• La cadena de ataque confirmada se mapea de forma natural a técnicas MITRE ATT&CK existentes.
• Elementos del mapeo
  • Initial Access / Trusted Relationship / T1199
    • La app OAuth de Context.ai se utilizó como tercero de confianza.
  • Persistence / Application Access Token / T1550.001
    • El token OAuth persistió incluso después del cambio de contraseña.
  • Credential Access / Valid Accounts / T1078
    • Credenciales comprometidas del Workspace de un empleado.
  • Discovery / Account Discovery / T1087
    • Enumeración de sistemas internos y proyectos.
  • Credential Access / Unsecured Credentials: Credentials in Files / T1552.001
    • Posible acceso a variables de entorno no sensibles.
  • Lateral Movement / Valid Accounts: Cloud Accounts / T1078.004
    • Posible uso de credenciales expuestas de la nube.
  • Collection / Data from Information Repositories / T1213
    • Enumeración de variables de entorno en todos los proyectos.
• En este mapeo, el punto de detección más valioso es el tramo donde se pasa del acceso de una aplicación OAuth al acceso a sistemas internos.
• Las organizaciones deben monitorear comportamientos anómalos de apps OAuth que acceden a recursos fuera del alcance esperado o desde rangos de IP no previstos.

Asedio a la cadena de suministro: LiteLLM, Axios, Vercel

• El incidente de Vercel no es un caso aislado, sino que se ubica dentro de una oleada de ataques a la cadena de suministro concentrada entre marzo y abril de 2026.
• El artículo señala que esto podría ser una campaña coordinada o, más probablemente, el resultado de que varios atacantes descubrieran al mismo tiempo la misma debilidad estructural: los límites de confianza entre repositorios de paquetes, CI/CD, proveedores OAuth y plataformas de despliegue.

• 24 de marzo de 2026: compromiso de la cadena de suministro de LiteLLM en PyPI

  • Se publicaron los paquetes maliciosos de PyPI litellm 1.82.7 y 1.82.8.
  • Se usaron credenciales de despliegue de CI/CD robadas del escáner de vulnerabilidades Trivy de Aqua Security.
  • LiteLLM es un proxy de LLM con alrededor de 3.4 millones de descargas diarias.
  • El backdoor de tres etapas apuntó a más de 50 tipos de credenciales en los principales proveedores de nube.
  • Incluyó persistencia mediante Kubernetes DaemonSet.
  • El tiempo de permanencia antes de su detección y eliminación fue de unos 40 minutos a 3 horas.
  • El CVE relacionado es CVE-2026-33634.

• 31 de marzo de 2026: compromiso de la cadena de suministro de Axios en npm

  • El paquete npm axios tiene entre 70 y 100 millones de descargas semanales.
  • Tras el secuestro de una cuenta de mantenedor, se distribuyeron las versiones maliciosas 1.14.1 y 0.30.4.
  • Se inyectó la dependencia plain-crypto-js@4.2.1, que incluía un RAT multiplataforma.
  • Se detectó que 135 endpoints infectados se comunicaron con el C2 del atacante.
  • El tiempo de permanencia fue de 2 a 3 horas.
  • Microsoft atribuyó este ataque al actor patrocinado por Corea del Norte Sapphire Sleet.

• Patrones convergentes

  • 3 ataques en 3 semanas
  • vectores distintos
  • el objetivo común fueron las credenciales y secretos que los desarrolladores guardan en la toolchain
  • El resumen en tabla presenta lo siguiente:
    • LiteLLM: robo de credenciales de CI/CD → PyPI, credenciales de desarrollador y claves API, 40 minutos a 3 horas
    • Axios: secuestro de cuenta de mantenedor → npm, RAT en estación de trabajo de desarrollador, 2 a 3 horas
    • Vercel: compromiso de app OAuth → plataforma, variables de entorno de clientes, en la tabla figura cerca de 22 meses, pero en la corrección superior y en el texto se ajusta a cerca de 2 meses

Patrones comunes con brechas previas en plataformas

• La brecha de Vercel se conecta con un patrón recurrente en el que un compromiso a nivel de plataforma expone secretos de clientes.

• Compromiso de Codecov Bash Uploader, enero-abril de 2021

  • El atacante modificó el script Bash Uploader para filtrar variables de entorno de entornos CI de clientes.
  • Pasó inadvertido durante unos 2 meses.
  • Más de 29 mil clientes se vieron potencialmente afectados, incluidos Twitch, HashiCorp y Confluent.
  • La similitud con Vercel es la exposición de variables de entorno de clientes mediante un compromiso de la plataforma.

• Incidente de seguridad de CircleCI, enero de 2023

  • Malware en un dispositivo personal robó un token de sesión SSO de un empleado.
  • Tras acceder a sistemas internos, se filtraron secretos de clientes y claves de cifrado.
  • CircleCI recomendó a todos los clientes rotar todos los secretos almacenados en la plataforma.
  • La estructura es casi idéntica a la de Vercel
    • compromiso de cuenta de empleado
    • acceso a sistemas internos
    • filtración de secretos de clientes

• Ataque a credenciales de clientes de Snowflake, mayo-junio de 2024

  • UNC5537 usó credenciales obtenidas con infostealer y cuentas sin MFA aplicado.
  • Más de 165 organizaciones se vieron afectadas.
  • Incluye a Ticketmaster, Santander Bank y AT&T.

• Compromiso del sistema de soporte de Okta, octubre de 2023

  • Se accedió al sistema de gestión de casos de soporte al cliente con credenciales robadas.
  • Se revisaron tokens de sesión dentro de archivos HAR.
  • Entre los clientes afectados estuvieron Cloudflare, 1Password y BeyondTrust.

• Resumen del patrón

  • acceso inicial mediante una relación de confianza o credenciales
  • movimiento lateral hacia sistemas internos
  • filtración de secretos de clientes
  • el alcance del objetivo varía desde algunos blancos hasta toda la plataforma
  • La tabla organiza por incidente el vector inicial, los activos expuestos y el retraso de detección.
    • Codecov: cerca de 2 meses
    • Okta: varias semanas
    • CircleCI: varias semanas
    • Snowflake: varios meses
    • Vercel: cerca de 2 meses

Lo que todavía no se ha revelado

• Aunque hay mucha cobertura pública y declaraciones de ejecutivos, siguen existiendo vacíos clave.
• Preguntas no resueltas en el registro público
  • cuándo detectó por primera vez Vercel la actividad anómala
  • por qué hubo una diferencia de 9 días entre la evidencia más temprana de abuso de credenciales divulgada y la revelación pública
  • cantidad de clientes afectados
    • Rauch lo describió como “quite limited”, pero no reveló una cifra concreta
  • si la afirmación en el foro de ShinyHunters proviene o no del mismo atacante
  • el estado actual de Context.ai y si hubo notificación a clientes aguas abajo
  • el alcance total del acceso interno en Vercel
    • no se ha revelado la cantidad de equipos, proyectos ni variables de entorno afectadas
    • tampoco está confirmado si hubo acceso a otros sistemas internos además de las variables de entorno de clientes
• El artículo subraya que, para un análisis riguroso, es necesario reconocer explícitamente no solo lo que se sabe, sino también lo que no se ha hecho público.

Guía de detección y hunting

• Acciones inmediatas para clientes de Vercel

  • Es necesario auditar todas las variables de entorno de los proyectos
  • El artículo incluye los siguientes ejemplos de CLI
    • vercel env ls --environment production
    • vercel env ls --environment preview
    • vercel env ls --environment development
  • Como la CLI actualmente no expone directamente el indicador sensitive, es necesario verificarlo en el dashboard o por API

• Búsqueda de uso no autorizado de credenciales expuestas

  • Buscar en logs de auditoría del proveedor de nube
    • AWS CloudTrail
      • Filtrar eventSource incluyendo sts.amazonaws.com, iam.amazonaws.com, s3.amazonaws.com
      • Buscar userIdentity.accessKeyId que coincida con la access key de Vercel que fue rotada y estaba almacenada
      • Detectar sourceIPAddress fuera de los CIDR conocidos de la organización, python-requests, curl, Go-http-client y cadenas de automatización de userAgent no familiares
      • El período debe ser desde febrero de 2026 hasta la fecha
    • GCP Audit Logs
      • Buscar protoPayload.authenticationInfo.principalEmail de la cuenta de servicio que usa la clave almacenada en Vercel
      • callerIp fuera de los rangos conocidos
      • Revisar métodos como storage.objects.get, compute.instances.list, iam.serviceAccountKeys.create
    • Azure Activity Logs
      • Filtrar por el ID de aplicación o service principal que estaba en las env vars de Vercel
      • callerIpAddress fuera del rango esperado
      • Priorizar la revisión de Microsoft.Storage/storageAccounts/listKeys, Microsoft.Compute/virtualMachines/write, Microsoft.Authorization/roleAssignments/write
  • Buscar en logs de acceso a bases de datos
    • Todas las bases de datos cuyas cadenas de conexión estaban en variables de entorno de Vercel
    • Analizar toda la ventana de febrero a abril de 2026
    • Verificar IP fuera de rangos de salida conocidos, como Vercel edge IP, VPN u oficina
    • Detectar conexiones que usen credenciales expuestas fuera de las ventanas normales de despliegue
    • En PostgreSQL, pg_stat_activity, log_connections
    • En MySQL, general log o audit plugin
    • En MongoDB Atlas, eventos DATA_EXPLORER y CONNECT del Project Activity Feed
  • Buscar en logs de procesadores de pago
    • Stripe Dashboard → Developers → Logs
    • source_ip fuera de los servidores esperados
    • /v1/charges, /v1/transfers, /v1/payouts, /v1/customers
    • Revisar logs equivalentes en Braintree y Adyen
    • Priorizar claves API guardadas como env vars non-sensitive que aún no hayan sido rotadas
    • Revisar también envíos inesperados en logs de servicios de correo
  • Es necesario revisar alertas de fuga involuntaria de credenciales enviadas por OpenAI, Anthropic, GitHub, AWS, Stripe y otros

• Se requieren rotación y redespliegue al mismo tiempo

  • Según la documentación de Vercel, rotar variables de entorno por sí solo no invalida los valores de credenciales ya existentes en despliegues anteriores
  • Los despliegues previos siguen usando las credenciales anteriores hasta que se vuelvan a desplegar
  • Por lo tanto, toda rotación requiere redespliegue de todos los entornos que usaron esa variable o desactivación explícita de despliegues anteriores
  • La prioridad es en este orden
    • Credenciales del proveedor de nube
    • Cadenas de conexión a bases de datos
    • Claves de procesadores de pago
    • Secretos de autenticación
    • Claves API de terceros
    • Tokens de monitoreo y logging

• Respuesta preventiva para equipos de seguridad

  • Revisar todas las apps OAuth aprobadas en Google Workspace Admin Console → Security → API Controls → Third-party app access
  • Marcar apps con scopes amplios como Drive, Gmail, Calendar
  • Investigar apps de proveedores sin una relación comercial activa
  • Monitorear uso de tokens OAuth desde rangos IP no esperados
  • Es necesario buscar el OAuth Client ID malicioso conocido
    • 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com

Lógica de detección SIEM

• Indicadores anómalos en aplicaciones OAuth, etapas 1~2

  • Alertar de inmediato ante eventos de refresh de token o autorización asociados con el OAuth Client ID malicioso conocido
  • Contrastar eventos de concesión de permisos de scopes amplios, como acceso total al correo, lectura/escritura en Drive y acceso al calendario, contra la lista actual de proveedores
  • Las apps que ya no tengan uso comercial deben ser revocadas
  • Si el uso de tokens de apps OAuth aprobadas ocurre desde IP fuera de los rangos CIDR esperados de la empresa y del proveedor, se debe investigar

• Acceso a sistemas internos y movimiento lateral, etapa 3

  • Eventos extraños de autenticación SSO/SAML
    • Cuando una cuenta comprometida de Workspace inicia sesión en aplicaciones internas desde una IP, región o huella de dispositivo nunca antes vista
  • Recolección de credenciales basada en correo y Drive
    • Búsquedas masivas de palabras clave como API key, secret, token, password, .env
    • Acceso a repositorios compartidos de credenciales, runbooks de ingeniería y documentación de infraestructura
    • Creación de reglas de reenvío de correo
  • Acceso a herramientas internas conectadas por OAuth
    • Creación de sesiones o actividad de API en Slack, Jira, GitHub, dashboards internos y otros, desde horarios o infraestructura inusuales
  • Intentos de escalación de privilegios
    • Incorporación a nuevos grupos o roles
    • Acceso a consolas de administración que no se usaban
    • Monitorear llamadas a la Directory API de Google Workspace, cambios de delegación e intentos de enumerar tokens OAuth de otros usuarios

• Enumeración de variables de entorno, etapa 4

  • Detectar patrones anormales de volumen y frecuencia en llamadas del tipo env read, list o decrypt en los logs de auditoría del equipo de Vercel
  • Primero es necesario establecer una línea base de los momentos normales de build de CI/CD
  • Luego alertar sobre accesos cuyo volumen, momento o principal de origen se salgan de esa línea base
  • Prestar atención a accesos desde cuentas de usuario en lugar de service accounts, y a accesos desde cuentas que normalmente no interactuaban con el proyecto

• Abuso de credenciales downstream, etapa 5

  • Revisar logs de todos los servicios objetivo de credenciales almacenadas como variables de entorno non-sensitive de Vercel durante la ventana de febrero a abril de 2026
  • En AWS, buscar en CloudTrail usando el access key ID específico
  • En GCP y Azure, buscar en logs de auditoría por cuenta de servicio o ID de aplicación
  • Para APIs SaaS como Stripe, OpenAI, Anthropic, SendGrid y Twilio, verificar en dashboards o logs de API si hubo uso desde IP desconocidas o en horarios inactivos
  • Cualquier uso que no pueda atribuirse a la infraestructura propia debe tratarse de inmediato como una credencial comprometida, y requiere rotación e investigación de actividad

• Alertas de fuga de credenciales de terceros

  • Es necesario monitorear alertas automáticas de escaneo de secretos, como GitHub secret scanning partner program, AWS compromised key detection, OpenAI, Anthropic, Stripe y Google Cloud
  • Las alertas sobre claves que existían solo en la plataforma de despliegue no deben tratarse como simples advertencias de higiene, sino como un indicador de compromiso de la plataforma

Procedimientos manuales de threat hunting

• Búsqueda manual en Google Workspace Admin Console

  • Admin Console → Reports → Audit and Investigation → OAuth Log Events
  • Application Name = Context.ai o Client ID = 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com
  • El período abarca desde febrero de 2026 hasta la fecha actual
  • Si hay resultados, se requiere revocar permisos e investigar el incidente de inmediato

• Revisión de apps OAuth de terceros con scopes amplios

  • Admin Console → Security → API Controls → Third-party app access → Manage Google Services
  • Ordenar las apps con App access = Unrestricted
  • Puntos de verificación para cada app
    • Si existe una relación activa con el proveedor
    • La justificación de negocio de los scopes
    • La fecha de uso más reciente
  • Las apps sin uso durante más de 90 días deben revocarse

Recomendaciones de defensa

• Acciones inmediatas, 0~48 horas

  • Rotar todas las variables de entorno de Vercel no marcadas como sensitive
  • Volver a desplegar todos los entornos después de la rotación
  • Activar la marca sensitive en todas las variables de entorno que contengan credenciales, tokens, keys y secrets
  • Auditar las aprobaciones de apps OAuth en la consola de administración de Google Workspace o Microsoft Entra
  • Revocar el acceso de apps que ya no se usan activamente
  • Revisar los logs de acceso de todos los servicios que usaron credenciales almacenadas en variables de entorno de Vercel, desde febrero de 2026 hasta hoy

• Refuerzo de corto plazo, 1~4 semanas

  • Migrar al uso de gestores de secretos dedicados como HashiCorp Vault, AWS Secrets Manager, Doppler o Infisical
  • Usar inyección en tiempo de ejecución en lugar de almacenamiento en variables de entorno de la plataforma
  • Donde sea compatible, eliminar credenciales de largo plazo con autenticación basada en OIDC
  • Implementar monitoreo de apps OAuth
    • Nudge Security, Grip Security, Valence Security o las funciones nativas de administración de Google Workspace
  • Establecer automatización para la rotación de credenciales
    • Se propone un ciclo de 30~90 días
  • Incluir las aprobaciones OAuth en el inventario de riesgo de terceros, al igual que los proveedores bajo contrato

• Cambios estructurales, 1~6 meses

  • Adoptar una postura de Zero Trust para las variables de entorno
    • Asumir que cualquier secreto almacenado en la plataforma de despliegue puede quedar expuesto si la plataforma es comprometida
  • Aplicar scopes de mínimo privilegio
    • Privilegios mínimos para cuentas de base de datos
    • Limitar el alcance operativo de las API keys
    • En credenciales cloud, usar credenciales temporales basadas en roles en lugar de access keys de largo plazo
  • Realizar revisiones de seguridad de terceros y reevaluaciones periódicas para todas las apps OAuth e integraciones que accedan al sistema de identidad corporativo
  • Incluir las plataformas PaaS en el inventario de SBOM/ASPM
    • Deben tratarse no como servicios externos, sino como una dependencia crítica de la cadena de suministro

• Monitoreo recomendado

  • Auditar el Client ID de OAuth anterior en Google Workspace Admin Console
  • Monitorear llamadas API inesperadas env.read y env.list en los logs de auditoría de Vercel
  • Revisar en CloudTrail, GCP Audit Logs y Azure Activity Logs si hubo uso desde IP o user agents no esperados de credenciales almacenadas en variables de entorno de Vercel entre febrero y abril de 2026
  • Si LiteLLM o Axios están en el árbol de dependencias, monitorear también los IOC mencionados en cada aviso
  • Vigilar alertas de credenciales filtradas involuntariamente de los principales proveedores de API durante el período de exposición

Impacto regulatorio y de compliance

• Las organizaciones que podrían haber sufrido exposición de credenciales por esta brecha deben evaluar las siguientes obligaciones

• GDPR

  • Si las credenciales expuestas permitieron acceder a sistemas con datos personales de la UE, el reloj de notificación de 72 horas podría comenzar desde el momento en que se confirmó la exposición
  • La notificación de OpenAI del 10 de abril plantea la posibilidad de que, para algunas organizaciones, el momento de conocimiento haya sido anterior a la divulgación pública del 19 de abril

• CCPA/CPRA

  • La exposición de credenciales que otorguen acceso a datos de consumidores puede activar obligaciones de notificación

• PCI DSS

  • La exposición de credenciales de procesamiento de pagos, como Stripe, Braintree o Adyen, puede requerir procedimientos de respuesta a incidentes e investigación forense

• SOC 2

  • Es necesario reflejar en la evidencia de monitoreo continuo los registros del incidente, las acciones de rotación de credenciales y los controles actualizados

• SEC Cybersecurity Rules 8-K

  • Las empresas públicas que determinen materialidad tienen obligación de divulgar en 4 días hábiles
  • El artículo señala que, aunque todavía podría no saberse si hubo uso no autorizado real, muchos marcos regulatorios pueden operar con base en la exposición en sí, no en la confirmación de explotación

Indicadores de compromiso

• IoC confirmados

  • OAuth Client ID
    • 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com
    • Valor vinculado a la aplicación OAuth comprometida de Context.ai

[GN⁺]

Comentarios en Hacker News

• Esto me recuerda que cuando Vercel lanzó por primera vez la UI de variables de entorno, ni siquiera existía la opción sensitive. Tardaron más de casi 2 años en agregar esa función. La discusión relacionada quedó en GitHub discussion y en el Vercel changelog

  • Incluso si en la UI le pones el flag sensitive, eso no cambia el runtime. En el momento en que entra a process.env durante el build, cualquier dependencia que quiera husmear puede leerlo. El verdadero problema es la estructura de meter todos los secretos en una sola bolsa de env y entregársela completa a la herramienta de build. Cloudflare con scoped bindings o Fly ya los separan, y me parece que otras plataformas van lentas en esto
  • Creo que sensitive no significa que no se pueda leer, sino más bien no mostrarlo en la UI. Si en una action function o en un route devuelves props un poco de más, se puede filtrar fácilmente. Para prevenir este tipo de problemas, al final hay que cifrar los valores de entorno con claves propias y, como no hay buenas herramientas de aislamiento, hasta parece viable hacer el rodeo de dejar algunos secretos baked-in en el código. El atacante no solo tendría que leer los valores de entorno, sino también descargar el resultado del build y encontrar la clave de descifrado, así que la barrera sube un poco. No es ideal, pero como parche temporal parece que podría funcionar

• Que hayan caído así de esta manera realmente se siente como un incidente vergonzoso. Según lo citado, resulta especialmente bochornoso que la infección con Lumma Stealer haya empezado cuando un empleado de Context.ai descargó un Roblox exploit script

• La parte donde el CEO atribuyó públicamente la rapidez del atacante a técnicas de ataque aceleradas por IA me parece, francamente, casi sin sustento. Por eso también siento que la información útil que realmente se revela es poca

  • Últimamente me da la impresión cínica de que la IA ya está sacudiendo hasta el mercado de las excusas absurdas, y que la prensa las repite sin verificarlas
  • Por otro lado, esto me hizo recordar que las soluciones vibe coded solían recomendar Vercel con mucha frecuencia. Me da una vibra parecida a la vieja fiebre de recomendar Axios

• A mí la explicación de Stage 2 no me quedó clara. Si la app de ContextAI pidió permisos para Google mail, drive y calendar a la vez, me parece excesivo. No es una empresa tan pequeña como para creer que alguien aceptó correr eso fuera de su propio entorno. Pero al leer la publicación de actualización de seguridad de Context.ai, parece más bien que un empleado de Vercel, por decisión personal, permitió acceso a todo su Google Workspace

• Todavía no me queda claro cómo funcionó exactamente toda esta secuencia. Me pregunto si el OAuth token del que hablan es el token que recibes después de Sign in with Google. Normalmente pensaría que eso queda ligado al client id y client secret de una Google App específica. Incluso si el atacante conocía el OAuth token del usuario y la información del cliente, entiendo cómo podría acceder a Drive y similares, pero no me cuadra cómo eso terminó en un login al control plane de Vercel. Me pregunto si al final encontraron credenciales dentro de Google Drive

  • Siento que el informe no deja eso claro. Por eso hasta dan ganas de sospechar que hubo algún error todavía más bochornoso y lo están ocultando. Tal vez era una contraseña guardada en Drive o Gmail, o quizá, como sugirió otro comentario, un passwordless login link
  • Una vez que terminas el flujo de OAuth, al final recibes un session token, y con eso puedes hacer llamadas a la API. Parece que ese es el punto clave de la explicación. Es muy probable que el token emitido también tuviera permisos para acceder al inbox de la víctima, y el atacante habría leído correos para obtener contraseñas de un solo uso, magic links u otra información sensible
  • Yo también estoy confundido. Me pregunto si lo que realmente se comprometió fue la app OAuth de Context.ai, y si por eso el atacante obtuvo exactamente la misma visibilidad sobre todos los workspaces de clientes que veía Context.ai. Pero entonces también me pregunto por qué toda la responsabilidad parece concentrarse en un solo empleado. Al final, lo clave parece ser si ese empleado de Vercel autorizó a Context.ai a leer todo el workspace de Vercel

• Coincido con la idea de que “hay que tratar las apps OAuth como si fueran vendors de terceros, eliminar secretos de plataforma de larga duración y diseñar asumiendo un provider-side compromise”, pero también siento que diseñar asumiendo una intrusión del proveedor es realmente difícil. Al final, la confianza es el punto de partida del sistema

  • Como nosotros en nuestro SaaS también estamos pensando cómo manejar apps OAuth, esto me parece un problema muy difícil. Incluso me pregunto si existe algún marketplace que lo resuelva bien. Después del incidente de Salesloft, Cloudflare propuso proxyear todo el tráfico OAuth y API de terceros a través de ellos mismos, pero eso también se siente como mover el vector de amenaza a otro lugar. Más allá de lo básico —minimizar scopes, acortar expiraciones, rotar client secrets— no tengo claro qué más se puede hacer. Tal vez un allowlist de IPs de origen por cliente
  • Viendo casos así, también me hace pensar que mucho de lo que se ha dicho hasta ahora sobre zero-trust era en buena parte retórica de marketing. Si de verdad fuera security by design, desde el principio habría que incorporar el supuesto de que un ataque a la cadena de suministro puede comprometer por completo a un proveedor superior

• Creo que en adelante vamos a ver muchísimos más incidentes así. Tanto en grandes empresas como en firmas pequeñas, toda la economía de IT apenas está empezando a recibir con retraso la deuda de riesgo acumulada por experimentar ampliamente con herramientas de IA. Por eso, más que como “AI-enabled tradecraft”, yo lo leo como el resultado de que el liderazgo de las empresas presionó a toda la organización a instalar y probar herramientas de IA en nombre de la velocidad. Este tipo de ataque en sí es demasiado común, y casi cualquier empresa que no tenga un allowlist obligatorio de instalaciones de IA está expuesta. Si le preguntas al equipo de IT cuántas herramientas tipo Context hay instaladas entre entornos locales y SaaS, seguramente sean bastantes. El problema es que estas herramientas en la práctica acceden a casi todo, y que todavía faltan entre 18 y 24 meses para que despeguen de verdad los vendors de seguridad o los ecosistemas de RBAC capaces de controlarlas. Vercel parece un canario en la mina de carbón, y dudo mucho que Context haya sido el único objetivo. Me parece un vector de amenaza conocido pero ignorado, donde si cae uno pueden empezar a salir muchos más en cadena. Los próximos 6 meses podrían ser especialmente duros; todos deberían estar auditando ahora mismo sus instalaciones de IA, o al menos empezar a hacerlo, y los atacantes se moverán usando los accesos que ya tienen antes de que se los bloqueen. Como referencia, soy responsable de seguridad en la industria tech

  • Yo también llevo años diciendo que vamos a ver muchas incidentes de seguridad extraños en las noticias
  • Yo también lo veo así. Siento que estamos entrando en una época bastante interesante

• Al ver el resumen de que “la relación de confianza OAuth terminó exponiendo toda la plataforma, el CEO culpó a la IA por la velocidad del ataque y además hay dudas sobre la demora entre detección y divulgación”, me parece que el fallo central visible es bastante típico. Había una cuenta de usuario con privilegios excesivos, y quizá había más cuentas parecidas. También parece bastante posible que no hubiera 2FA ni ZeroTrust, o que estuvieran muy limitados. En general, mi impresión es que la higiene de seguridad no era buena

  • Da la impresión de que de ahora en adelante culpar a la IA se va a volver una excusa universal para incidentes de seguridad, parecida a cuando un sitio se cae y de inmediato le echan la culpa a un DDoS

• Hay un punto que mucha gente pasa por alto. En Vercel, aunque rotes las variables de entorno, los deploys anteriores no se invalidan automáticamente, así que un deploy viejo sigue corriendo con credenciales antiguas hasta que lo vuelves a desplegar o lo borras. Entonces, aunque hayas rotado las claves después del aviso, si no rehiciste todos los deploys, es posible que los valores filtrados sigan vivos. Y también creo que hay que revisar sí o sí los consentimientos OAuth en Google Workspace. Si vas a Admin Console > Security > API Controls > Third-party app access, hay una buena probabilidad de que una app aprobada hace 2 años para una demo todavía tenga acceso total a mail y Drive

  • Nosotros por eso mantenemos varias cuentas de Google separadas. Pero muchas organizaciones no pueden hacerlo por el costo por usuario en Google Workspace. En un trabajo anterior yo también intenté que esos consentimientos OAuth se dieran con una cuenta separada y no con la cuenta principal, pero no lo logré
  • Normalmente, cuando se habla de credential rotation, uno asume que incluye invalidar las credenciales anteriores. Casi nunca he oído de un enfoque donde solo generas las nuevas y dejas vivas las viejas
  • Esa frase del informe también me confundió bastante. El hecho de que un deploy viejo use un env var antiguo no determina por sí mismo si esa credencial sigue siendo válida o no. Esto me parece más un footgun que afecta disponibilidad que un problema de confidencialidad. También me resultó rara la parte del informe sobre “Environment variable enumeration (Stage 4)”. En particular, cuando dice “observar si el acceso a variables de entorno ocurre desde una user account y no desde una service account, o desde una cuenta que normalmente no interactuaba con el proyecto”, me dio una sensación extraña: ¿de verdad la gente está sacando credenciales de los env vars de Vercel para usarlas en otros sistemas?
  • Los preview deploys me parecen todavía más graves. Se crea uno por cada PR con las mismas env vars, y nadie los limpia. Aunque rotes la clave y vuelvas a desplegar producción, podrían quedar cientos de previews zombi con los valores viejos
  • Al hacer una rotación, por supuesto también habría que expirar las variables anteriores

• Algunos detalles de este informe, especialmente la línea de tiempo que empieza desde 2024~2025, me parecieron cosas que no vi ampliamente reportadas en otros lados. Por ejemplo: “a finales de 2024 e inicios de 2025 el atacante pivotó desde el acceso OAuth de Context.ai hacia la cuenta de Google Workspace de un empleado de Vercel”, o “entre inicios y mediados de 2025 empezó el acceso a sistemas internos de Vercel y la enumeración de variables de entorno de clientes”. Me pregunto de dónde salieron esas fechas

  • En mi opinión, todas esas fechas son inventadas, y probablemente sean una hallucination