Guía de Respuesta al Incidente de Vercel Abril 2026
Última actualización: 20 de abril de 2026 a las 12:07 p. m. AEST/Brisbane - (v2 — incorpora la actualización del CEO de Vercel del 20 de abril)
¿Qué ocurrió?
Vercel reveló el 19 de abril de 2026 que un atacante obtuvo acceso no autorizado a sistemas internos. Aquí está el anuncio oficial:
El 20 de abril, el CEO de Vercel, Guillermo Rauch, publicó una actualización detallada confirmando la vía de acceso inicial: un empleado de Vercel utilizó una plataforma de IA llamada Context.ai, que a su vez fue vulnerada; desde allí, el atacante se movió hacia la cuenta de Google Workspace del empleado y escaló hacia los entornos de Vercel. Las variables de entorno están cifradas en reposo, pero el atacante pudo enumerar las variables no marcadas como "sensibles". Vercel describe al atacante como altamente sofisticado y probablemente acelerado por IA. Google Mandiant está involucrado en la respuesta. Vercel afirma que Next.js, Turbopack y sus proyectos de código abierto siguen siendo seguros.
Aquí está la sección importante de indicadores de compromiso de ese aviso de seguridad:
Bastante escaso en detalles. ¡Ni siquiera te dicen dónde buscar ese único IOC de Google! Como cliente de Vercel, estoy bastante decepcionado con este nivel de detalle. ¡Ayúdame a entender qué buscar! ¡Dime a dónde ir para saber si he sido comprometido o no!
Ante la falta de detalles de Vercel, hemos creado este documento
Si ejecutas cargas de trabajo en Vercel, asume lo siguiente hasta que se demuestre lo contrario:
- Las variables de entorno no marcadas como "sensibles" en cualquier proyecto de Vercel dentro de la ventana de exposición pueden haber sido legibles.
- Cualquier credencial enviada a Vercel mediante el panel de control o la CLI
vercel env que no se haya rotado es un pasivo permanente.
- Los tokens dentro de las rutas de integración de Vercel ↔ GitHub y Vercel ↔ Linear pueden haber sido accesibles.
- No recibirás una señal clara de "estás afectado / no estás afectado" rápidamente. Rota primero, luego investiga.
Esta distinción es importante para las comunicaciones ejecutivas y para no sobrerreaccionar (o subreaccionar).
Confirmado por Vercel (boletín + actualización del CEO del 20 de abril)
- Acceso no autorizado a ciertos sistemas internos de Vercel.
- Vector de acceso inicial: Context.ai, una plataforma de IA utilizada por un empleado de Vercel, fue vulnerada. El atacante usó ese punto de apoyo para comprometer la cuenta de Google Workspace del empleado en Vercel, luego escaló desde allí hacia los entornos de Vercel.
- Las variables de entorno del cliente están cifradas en reposo. Las variables designadas como "no sensibles" eran, sin embargo, enumerables por el atacante una vez dentro.
- El impacto en el cliente se describe como "bastante limitado"; Vercel ha contactado directamente a los clientes sobre los que tiene preocupaciones.
- Next.js, Turbopack y los proyectos de código abierto de Vercel han sido analizados y se cree que siguen siendo seguros (es decir, no hay artefacto malicioso en la ruta de publicación de esos proyectos según la declaración de Vercel del 20 de abril).
- El atacante se describe como altamente sofisticado y probablemente significativamente acelerado por IA.
- Socios de respuesta: Google Mandiant está activamente involucrado; firmas externas de IR, colegas de la industria y fuerzas del orden están implicados.
- Vercel se ha comunicado con Context.ai para ayudar a comprender el alcance completo.
- Vercel ha implementado mejoras en la interfaz de usuario: página de resumen de variables de entorno, gestión mejorada de variables de entorno sensibles.
Reportado / atribuido por terceros y el atacante (no confirmado por Vercel)
- Las integraciones de Linear y GitHub se vieron afectadas de manera desproporcionada (reportes de la comunidad, notablemente Theo Browne en X).
- Datos listados para la venta en BreachForums: base de datos interna, cuentas de empleados, tokens de GitHub, tokens de npm, fragmentos de código fuente, marcas de tiempo de actividad — ofrecidos por ~2 millones de dólares.
- El actor se identifica como ShinyHunters; otros actores históricamente vinculados a ese apodo han negado su participación.
- Clases específicas de datos de clientes exfiltradas más allá de lo que Vercel ha confirmado directamente con los clientes.
Trata los informes no confirmados como plausibles y procesables para tu propio triaje, pero no los cites como hechos en comunicaciones con clientes o reguladores hasta que Vercel los corrobore o tengas evidencia independiente. La brecha entre "variables de entorno enumerables" (confirmado por Rauch) y "tokens de npm + GitHub a la venta en BreachForums" (afirmación del atacante) es la brecha que más importa para el riesgo de la cadena de suministro: asume lo peor para fines de rotación, ciñete a la versión confirmada para comunicaciones.
Alcance: quién necesita ejecutar este manual
Urgencia máxima — recibiste contacto directo de Vercel, o se aplica alguno de los siguientes casos:
- Tienes (o tenías) una integración de Vercel ↔ GitHub con alcance de escritura en el repositorio.
- Tienes (o tenías) una integración de Vercel ↔ Linear.
- Almacenas secretos no cifrados (no marcados como sensibles) como variables de entorno de Vercel.
- Publicas paquetes npm desde CI/CD que se ejecuta en o a través de la infraestructura de Vercel.
Urgencia estándar — cualquier equipo con proyectos activos de Vercel, incluso sitios de marketing. Los sitios de marketing a menudo contienen claves de API de CMS, tokens de analítica y webhooks de formularios que pivotan hacia sistemas más sensibles.
Hazlo igualmente — incluso si tus proyectos fueron eliminados antes del incidente. La cuestión es si los secretos residieron alguna vez en Vercel en una forma legible, no si el proyecto sigue ahí.
Pregunta paralela: ¿tu organización está expuesta directamente a Context.ai?
La actualización del 20 de abril menciona a Context.ai como el proveedor upstream vulnerado. Si alguien en tu organización usa Context.ai independientemente de Vercel — para inteligencia de reuniones, gestión del conocimiento, enriquecimiento de CRM o cualquier otro flujo de trabajo — puedes tener tu propia ventana de exposición directa separada del incidente de Vercel.
Ejecuta estas comprobaciones en paralelo:
- Consulta tu SSO / IdP (Okta, Entra, Google Workspace) para cualquier usuario que se haya autenticado en Context.ai o en una aplicación OAuth relacionada con Context.
- Busca en la consola de administración de Google Workspace → Seguridad → Registros de acceso a aplicaciones OAuth para
context.ai o IDs de aplicación asociados.
- Revisa las herramientas de gestión de gastos corporativos / SaaS para suscripciones a Context.ai.
- Revisa qué ámbitos de OAuth se concedieron — los ámbitos de lectura de Gmail, Calendario, Drive y directorio de Workspace son de alto impacto.
Si encuentras uso de Context.ai en tu entorno, revoca las concesiones de OAuth, rota cualquier credencial que haya pasado por los flujos de trabajo de Context.ai y monitorea las cuentas de Google Workspace de los usuarios afectados para los mismos indicadores de compromiso que Vercel describe haber visto en la cuenta de su empleado. Comunícate con Context.ai directamente para obtener tus propios detalles del incidente; Vercel ha declarado públicamente que está coordinando con Context para ayudar a otras organizaciones afectadas.
Fase 0: Detener la hemorragia (primeros 60 minutos)
Dos objetivos: evitar nuevos daños, preservar evidencia.
-
Congela los despliegues. Pausa los despliegues automáticos en las ramas de producción. Quieres evitar que se publique un build modificado por el atacante y quieres evitar que el registro de auditoría se llene de actividad.
-
Desactiva la aplicación de GitHub de Vercel. Si tienes instalada la aplicación de GitHub de Vercel, cosa que tendrás si estás haciendo despliegues automáticos a Vercel cuando envías nuevo código a GitHub. Puedes encontrar tus aplicaciones de GitHub instaladas en https://github.com/organizations/<GitHub-Organization>/settings/installations
-
Identifica qué acceso tiene la aplicación de GitHub. Haz clic en el botón de configuración de arriba y audita a qué repositorios tenía acceso la aplicación de Vercel. Esto te dice en qué debes centrarte ahora mismo. Ve a GitHub → Organización → Configuración → Aplicaciones de GitHub → Vercel. Revisa:
- Acceso a repositorios (todos los repos frente a seleccionados)
- Permisos concedidos
- Fecha de instalación y quién la instaló
- Captura una instantánea del registro de auditoría de Vercel para tu equipo. Expórtalo o captura la pantalla inmediatamente. La ventana de retención es limitada y la interfaz de usuario no expone todo. Consíguelo antes de comenzar a hacer cambios que contaminarán el registro. Puedes encontrarlo en https://vercel.com/activity-log
- Habilita "Observability Plus". Esta es una función adicional de pago de Vercel, y es malo que tenga que sugerirte que la habilites y PAGUES por ella, pero en este caso creo que es lo mejor que puedes hacer durante la respuesta a incidentes. Ciertamente no estoy contento con ello, pero lo he habilitado simplemente porque guarda los registros de auditoría por más tiempo que el valor predeterminado, que es MUY corto.
- Inventario de la amplitud de la exposición. Para cada equipo/cuenta de Vercel que controles, enumera:
- Proyectos y sus repositorios Git vinculados
- Integraciones conectadas (aplicación de GitHub, Linear, Slack, integraciones del marketplace)
- Miembros del equipo y sus roles
- Tokens de acceso personal / tokens de API emitidos bajo el equipo
- Deploy hooks
- Revisa el registro de auditoría de la organización de GitHub. Busca durante la ventana de exposición (de forma conservadora, del 1 al 15 de abril de 2026 hasta el presente). Filtra por:
repo.add_member, repo.add_topicorg.invite_member, org.add_memberintegration_installation, integration_installation.repositories_addedprotected_branch.destroy,
No hagas anuncios ni rotes secretos todavía. Primero quieres la instantánea.
Fase 1: Comprobar indicadores de compromiso (IOC)
Los detalles del anuncio de Vercel son bastante escasos:
Por lo que podemos deducir, sugieren que vayas a la Consola de Administración de Google Workspace y busques esta aplicación de googleusercontent.com. Aquí te explicamos cómo encontrarla en la consola:
-
En la consola de administración de Workspace, ve a Seguridad > Control de acceso y datos > Controles de API y busca las aplicaciones a las que se ha accedido y las pendientes.
-
Luego busca en las diferentes listas el IOC que aparentemente es una aplicación OAuth: 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com
-
Si lo encuentras, elimínalo inmediatamente y consulta a un socio de respuesta a incidentes. Esto está por encima de mi nivel de responsabilidad.
Fase 2: Rotación de credenciales
La rotación es la acción de mayor valor. Hazlo en orden de prioridad para que, si te interrumpen, lo más peligroso ya haya sido manejado.
Lo que tienes que rotar depende de lo que tus entornos de GitHub y Vercel tengan expuesto. Comienza con los PAT de GitHub, etc., y ve hacia afuera usando esta guía.
Niveles de prioridad
Nivel 0 — Rotar hoy, antes que cualquier otra cosa:
- Rota inmediatamente todos los PAT de GitHub y elimina cualquier sesión existente. Tokens de Acceso Personal, o PAT. Hay dos tipos de PAT:
- Rota inmediatamente cualquier variable de entorno de Vercel que sea sensible: http://vercel.com/all-env-vars
Nivel 1 — Rotar hoy, dependiendo de lo que tengas expuesto en tus aplicaciones:
- Claves secretas de procesadores de pago (Stripe, Adyen, Braintree, etc.)
- Secretos de firma de autenticación (
AUTH_SECRET / NEXTAUTH_SECRET de NextAuth, claves de firma JWT, claves de cookies de sesión, tokens CSRF)
- Cadenas de conexión a bases de datos con acceso de escritura (
DATABASE_URL, URLs directas de Postgres/MySQL, URIs de Mongo, Redis con autenticación)
- Claves de proveedor de nube de alcance amplio o raíz (claves de acceso IAM de AWS, JSON de cuenta de servicio de GCP, secretos de cliente de Azure)
- Secretos de firma de webhooks (Stripe, GitHub, Slack — rota y actualiza la configuración del remitente)
Nivel 2 — Rotar esta semana:
- Claves de API de SaaS de terceros (analítica, proveedores de correo electrónico, SMS, CRM)
- Secretos de cliente OAuth para aplicaciones que posees
- Credenciales SMTP
- Claves de cifrado para criptografía a nivel de aplicación (rota con un aumento de versión de clave, no con un reemplazo directo)
- Claves de purga de CDN, claves de servicio de imágenes
- Claves de proveedores de feature flags
Nivel 3 — Rotar cuando sea conveniente, pero aún así rotar:
- Tokens de analítica de solo lectura
- DSNs de Sentry / logging (nota: la rotación de DSN no es crítica si estás de acuerdo con una pequeña ventana de eventos perdidos)
- Claves públicas y claves anónimas (aún así rotar — pueden revelar la existencia del proyecto y, a veces, permitir la enumeración)
Errores comunes en el orden de operaciones
- Las claves de firma de sesión invalidan todas las sesiones activas al rotar. Planifica un evento de cierre de sesión forzado. Comunícalo.
- Los secretos de webhook deben rotarse en ambos extremos. Actualiza primero el remitente (Stripe, GitHub) para que envíe con el nuevo secreto, luego tu receptor para que lo verifique. O soporta ambos temporalmente.
- Credenciales de base de datos: crea primero el nuevo usuario, despliega, luego revoca el antiguo. No hagas un reemplazo directo o causarás una interrupción.
- Claves de AWS — si estás rotando las claves de acceso de un usuario IAM, crea la segunda clave, realiza el despliegue, luego elimina la primera. No las "desactives" y esperes.
- Re-despliega después de los cambios en las variables de entorno. Las variables de entorno de Vercel se incorporan en tiempo de compilación para muchas configuraciones de frameworks. Un cambio de variable de entorno sin un nuevo despliegue no se aplica completamente.
- Revisa también tus secretos de CI. Si un secreto se reflejó en GitHub Actions, CircleCI o similar, rota el reflejo.
No olvides estos olvidos comunes
.env.local enviado a un repositorio privado (sigue siendo un problema — el código fuente puede haber sido exfiltrado)- Secretos en entornos de vista previa/desarrollo de Vercel, no solo en producción
- Secretos almacenados como variables de entorno compartidas a nivel de equipo de Vercel
- Deploy hooks (rótalos; son desencadenantes completos de despliegue)
- Tokens de acceso personal de Vercel emitidos bajo tu cuenta
- Tokens de Acceso Personal de GitHub que autorizaron la instalación de la aplicación de Vercel en GitHub (separados de la aplicación en sí)
Fase 3: Búsqueda a nivel de repositorio
Para los repositorios que estaban conectados a Vercel:
- Compara el HEAD de
main/master con la etiqueta/commit que sabes que es bueno antes de la ventana del incidente.
- Busca cambios en:
package.json → scripts (especialmente postinstall, prepare, preinstall)package-lock.json / pnpm-lock.yaml / yarn.lock — adiciones de dependencias inesperadas o aumentos de versión.github/workflows/*.yml — nuevos workflows, nuevos pasos run:, nuevos uses: con SHAs no fijadosvercel.json — cambios en el comando de build, nuevas reescrituras/redirecciones que podrían exfiltrar tráfico
Si publicas paquetes npm desde estos repositorios
Aquí es donde un compromiso inicial de Vercel podría convertirse en un evento de cadena de suministro. Incluso si no usas Vercel para publicar, si un atacante obtuvo tu token de GitHub y tu workflow de publicación usa ese token:
- Revisa el historial de publicaciones de
npm: npm view <pkg> time --json para versiones inesperadas.
- Compara el tarball de cada versión reciente con la etiqueta git de la que dice provenir. Los atacantes publican desde una etiqueta que no coincide con lo que está en el registro.
- Audita el uso de
NPM_TOKEN en los workflows — rota el token, revisa quién tenía acceso.
- Verifica si se han añadido nuevos mantenedores a tus paquetes:
npm owner ls <pkg>.
- Si mantienes algo significativo, busca la ejecución de scripts post-install en el tarball — descomprímelo e inspecciónalo.
Si encuentras evidencia de una publicación no autorizada, repórtala a la seguridad de npm ([email protected]) y considera presentarla en OSV.dev. Marca la versión mala como obsoleta; no la elimines (la eliminación tiene límite de tiempo y rompe a los consumidores posteriores).
Nota sobre los paquetes propiedad de Vercel específicamente: La actualización de Vercel del 20 de abril afirma que Next.js, Turbopack y sus proyectos de código abierto han sido analizados y se cree que son seguros. Esa es la afirmación de Vercel sobre su ruta de publicación — aún así debes auditar tus paquetes como se indica arriba. Si consumes Next.js o Turbopack, no necesitas fijarte a una versión anterior al incidente como precaución según la información actual, pero monitorea el boletín de Vercel para cambios en esa postura.
Fase 4: Revisión de la integración con Linear
Si tu equipo usa la integración de Vercel ↔ Linear:
- Revisa el registro de auditoría de Linear (Configuración del espacio de trabajo → Seguridad → Registro de auditoría) para la ventana de exposición.
- Busca:
- Nuevas claves de API emitidas
- Nuevas integraciones añadidas
- Comentarios publicados por cuentas de servicio
- Cambios en los destinos de los webhooks
- Invitaciones a miembros
- Vistas/exportaciones de datos de incidencias (la integración tiene acceso de lectura a las incidencias, que a menudo contienen nombres de clientes, detalles de errores y, a veces, credenciales copiadas en los tickets)
- Preocupación específica: las incidencias de Linear frecuentemente contienen secretos copiados de la depuración de desarrolladores. Busca en tu espacio de trabajo de Linear patrones comunes de fuga (
AKIA, sk_live_, ghp_, ghs_, npm_, eyJ, ----BEGIN). Cualquier cosa encontrada debe ser rotada.
Fase 5: Revisión de registros de sistemas posteriores
Rotar credenciales invalida la persistencia del atacante en la mayoría de los casos, pero es posible que ya hayan utilizado el acceso. Revisa los consumidores de tus secretos rotados en busca de signos de uso durante la ventana de exposición.
Ventanas para revisar
Usa 1 de abril de 2026 hasta ahora como límite inferior conservador. El incidente se reveló el 19 de abril, pero el acceso inicial es anterior a la revelación. Si Vercel publica una fecha más específica, la ajustaremos en consecuencia.
Qué consultar
- AWS CloudTrail — llamadas API inusuales desde claves IAM comprometidas, especialmente ráfagas de
GetObject contra buckets de S3, CreateUser, AttachUserPolicy, inicios de sesión en la consola desde nuevos ASN/países.
- Registros de auditoría de bases de datos —
SELECT * inusual en tablas sensibles, exportaciones grandes, conexiones desde direcciones IP de origen inesperadas.
- Registros de Stripe / pagos — creación inusual de clientes, creación de transferencias, creación de claves de API.
- Registros del proveedor de autenticación (Auth0, Clerk, Cognito, Firebase) — inicios de sesión de viaje imposible, restablecimientos de contraseña activados para usuarios administradores, nuevos registros de aplicaciones.
- Proveedor de correo electrónico (SendGrid, Postmark, etc.) — campañas salientes inesperadas, nuevas claves de API, cambios de identidad del remitente.
- GitHub — clonaciones, creaciones de forks, nuevas claves SSH en cuentas de usuario con acceso al repositorio.
Primitivas útiles para la caza de IOC
Pega cualquier nombre de host o IP controlada por el atacante publicada por Vercel o socios de IR en:
- Registros de acceso HTTP de tu frontend (los atacantes a veces hacen pruebas previas para confirmar el acceso antes de actuar).
- Registros de DNS — resolución saliente de dominios inusuales desde tus servidores.
- Proxy saliente / registros de flujo de VPC.
Hasta la fecha de publicación, Vercel no ha publicado ningún IOC. Monitorea el boletín de Vercel y los informes de firmas de IR conocidas para obtener actualizaciones.
Fase 6: Detección de compromiso persistente
La persistencia del atacante después de una brecha a nivel de plataforma comúnmente toma estas formas. Busca activamente cada una:1. Nuevos miembros del equipo o colaboradores en tu equipo de Vercel, organización de GitHub, espacio de trabajo de Linear o cuentas en la nube. Fechados dentro de la ventana de exposición.
2. Nuevas autorizaciones OAuth en proveedores SSO conectados (Google Workspace, Okta, Entra ID) para las cuentas de tus desarrolladores.
3. Configuración CI/CD modificada — flujos de trabajo que ahora se comunican con un servidor externo, nuevos runners autoalojados, nuevos secretos con nombres inocuos.
4. Despliegues inesperados en Vercel — revisa el historial de despliegues en busca de aquellos que no puedas asociar a un commit conocido de un autor conocido.
5. Indicadores de reverse shell en registros de funciones serverless — blobs en base64 que se escriben/ejecutan, conexiones salientes inusuales desde Edge/Serverless Functions.
6. Desviación de DNS — nuevos subdominios, cambios CNAME, redirecciones añadidas mediante vercel.json o la configuración del framework.
7. Cambios de autenticación — MFA desactivado, códigos de recuperación regenerados, contraseña cambiada sin acción del usuario.
Comunicaciones
Internas
Designar un comandante de incidentes. Reunión diaria mínima mientras la rotación esté en marcha. Documento de fuente única de verdad para «qué hemos rotado, qué está pendiente, qué hemos encontrado». Mantener fuera de Linear si Linear está dentro del alcance del incidente — usar un canal alternativo.
Cara al cliente
Consultar con asesoría legal. Los umbrales de notificación varían, pero:
- GDPR: 72 horas para violaciones notificables que afecten a residentes de la UE.
- Australia (régimen de Violaciones de Datos Notificables, OAIC): notificar tan pronto como sea posible cuando sea probable un daño grave.
- EE.UU.: estado por estado; algunos estados tienen ventanas de 30 a 60 días, otros exigen notificación inmediata para clases de datos específicas.
- California (CCPA): obligaciones específicas si la información personal de residentes de California está en el alcance.
- Clientes SOC 2 / ISO 27001: las cláusulas contractuales de notificación a menudo exigen un aviso más temprano que los mínimos regulatorios. Lean sus MSAs.
Si no tienes evidencia de fuga de datos de tus sistemas, es posible que aún no tengas una obligación de notificación — pero «usamos Vercel y Vercel tuvo un incidente» por sí solo normalmente no es suficiente para activar la notificación a menos que datos sensibles estuvieran materialmente en riesgo. Documenta tu razonamiento.
Declaraciones preparadas
Redacta estas antes de que las necesites:
- Reunión general interna
- Aviso para clientes
- Plantilla de notificación al regulador
- Actualización de la página de estado (si es pública)
Higiene de atribución pública
No replantees las afirmaciones del atacante como hechos. Enlaza al boletín de Vercel como fuente principal. Deja que Vercel caracterice su propio incidente — tú estás en tu terreno caracterizando tu propia exposición.
Fortalecimiento a medio plazo (post-incidente)
Este incidente saca a la luz problemas estructurales que vale la pena corregir incluso si resultas no estar afectado.
- Migrar todos los secretos a la funcionalidad de variable de entorno sensible de Vercel. Conviértelo en el valor predeterminado del equipo. Capacita a los desarrolladores para marcarlos al crearlos.
- Adoptar credenciales de corta duración cuando sea posible. Usar la federación OIDC de GitHub a AWS/GCP/Azure en lugar de claves de acceso de larga duración reflejadas en las variables de entorno de Vercel. Usar administradores de secretos nativos de la nube (AWS Secrets Manager, GCP Secret Manager) accedidos en tiempo de ejecución en lugar de variables de entorno incluidas.
- Inventariar aplicaciones OAuth de terceros conectadas a tu Google Workspace, Microsoft 365, organización de GitHub y equipo de Vercel. El IAV de Vercel fue Context.ai — una plataforma de IA integrada mediante OAuth en la cuenta de Google Workspace de un empleado. La misma clase de riesgo existe en toda organización que haya aprobado liberalmente integraciones de SaaS y herramientas de IA, y el listón de «qué se aprueba» ha bajado considerablemente en la fiebre del oro de las herramientas de IA de los últimos 18 meses. Acciones concretas:
- Obtén el informe de aplicaciones OAuth de tu Google Workspace (Consola de administración → Seguridad → Controles de API → Control de acceso de aplicaciones). Revisa cada aplicación con alcances sensibles (
gmail.readonly, calendar, drive, admin.directory).
- Haz lo mismo para Microsoft 365 (Entra ID → Aplicaciones empresariales).
- Instituye revisiones trimestrales. Exige la aprobación de seguridad para nuevas concesiones OAuth que conlleven alcances sensibles.
- Considera restringir la instalación de aplicaciones OAuth a una lista blanca en lugar de aprobación por parte del usuario.
- Principio de mínimo privilegio en el alcance de la GitHub App. Si Vercel no necesita acceso a todos los repos de la organización, restringir a los repos que realmente despliega.
- Rotación de ganchos de despliegue como rutina. Trimestral.
- Construir un escaneo de secretos en tu pre-commit y CI. Trufflehog, gitleaks o equivalente. Escanear retrospectivamente el historial del repositorio en busca de cualquier cosa que pueda haber sido confirmada y luego rotada — asume que lo que una vez fue confirmado todavía está en algún clon.
Referencias
Registro de cambios
- 2026-04-20 (v2) — Actualizado tras la declaración del 20 de abril del CEO de Vercel, Guillermo Rauch. Se promovieron varios elementos de «reportado» a «confirmado»: Context.ai nombrado como el proveedor upstream vulnerado, la cuenta de Google Workspace de un empleado de Vercel como el pivote, enumeración de variables de entorno no sensibles como el movimiento lateral dentro de la plataforma. Se añadió alcance paralelo para exposición directa de Context.ai. Se añadió la declaración de Vercel de que Next.js, Turbopack y los proyectos OSS permanecen seguros. Se añadió la contratación de Mandiant. Se fortaleció la recomendación de inventario de aplicaciones OAuth.
- 2026-04-20 (v1) — Versión inicial. Basada en el boletín de Vercel del 2026-04-19 y reportes públicos contemporáneos. Actualizar a medida que Vercel publique detalles adicionales, IOCs o una ventana de exposición más estrecha.
opensourcemalware/vercel-april2026-incident-response
