Vercel fue hackeado (abril 2026): El plan de emergencia de 60 minutos que todo desarrollador debe ejecutar hoy

El 19 de abril de 2026, Vercel confirmó que atacantes comprometieron una herramienta de IA de terceros (Context.ai), secuestraron la cuenta de Google Workspace de un empleado de Vercel y leyeron variables de entorno que no estaban marcadas como "sensibles" en un subconjunto limitado de proyectos de clientes. Si has desplegado algo en Vercel en los últimos 30 días, debes asumir que una de tus variables de entorno puede que ya esté en manos ajenas — y necesitas actuar rápido.

La verdad incómoda: la mayoría de los vibe-coders despliegan valores de .env directamente desde una plantilla sin tocar nunca el interruptor "Sensible". Esa es exactamente la categoría de variables que el atacante leyó. Este plan te guía a través de los próximos 60 minutos — qué verificar, qué rotar y cómo reforzar tu stack para que la próxima brecha de plataforma no tumbe tu aplicación.

TL;DR: Lo que debes hacer en los próximos 60 minutos

Si no lees nada más, haz estas seis cosas ahora mismo:

1. Pausa los auto-despliegues en tus ramas de producción.
2. Ejecuta vercel env pull y busca en la salida patrones de secretos (sk_live_, AKIA, ghp_, eyJ).
3. Rota cada clave API almacenada como variable de entorno no sensible — empieza por las claves de pago, base de datos, autenticación y proveedor en la nube.
4. Vuelve a agregar los secretos rotados usando el interruptor "Sensible" de Vercel y vuelve a desplegar.
5. Abre tu registro de actividad de Vercel para el período del 1 al 20 de abril y marca cualquier despliegue, inicio de sesión o evento de token que no reconozcas.
6. Revisa el registro de auditoría de tu organización en GitHub para el mismo período — nuevos PATs, claves de despliegue o cambios en workflows.

A continuación encontrarás el desglose completo, con los comandos, patrones y el orden de rotación que necesitas.

Lo que realmente ocurrió en la brecha de Vercel de abril 2026

Vercel reveló el 19 de abril de 2026 que un atacante comprometió Context.ai, una herramienta de productividad de IA de terceros utilizada por un empleado de Vercel. Desde ahí, el atacante tomó el control de la cuenta de Google Workspace del empleado, pivotó hacia el entorno interno de Vercel y accedió a las variables de entorno que no estaban marcadas como "sensibles".

Las variables marcadas como "sensibles" usan una ruta de lectura cifrada separada, y Vercel afirma que no hay evidencia de que estas hayan sido expuestas. Todo lo demás — variables de entorno comunes que almacenan claves API, URLs de bases de datos, secretos JWT — era legible. Una publicación en un foro de ciberdelincuencia afirma estar vendiendo datos de Vercel por 2 millones de dólares, aunque Vercel no ha confirmado la exfiltración. En cualquier caso, la medida prudente es asumir una compromisión a efectos de rotación, aunque Vercel no te haya enviado un correo directamente.

La empresa calificó al atacante como "altamente sofisticado basándose en su velocidad operacional y conocimiento detallado de los sistemas de Vercel." Traducción: no era un script kiddie — toma el reloj en serio.

¿Estás afectado? Cómo verificarlo en 5 minutos

Respuesta corta: si usas Vercel y no has sido riguroso con el interruptor "Sensible", trátate como afectado. Aquí está el triaje de 5 minutos:

• Abre el registro de actividad de Vercel y filtra desde el 1 de abril de 2026 hasta ahora. Busca inicios de sesión desconocidos, creaciones de tokens o despliegues.
• Ve a Google Workspace Admin → Seguridad → Controles de API y busca el indicador de compromisión publicado: el ID de cliente OAuth 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com. Si está autorizado, revócalo inmediatamente.
• Comprueba si alguien en tu equipo ha iniciado sesión alguna vez en Context.ai usando Google SSO. Si es así, trata sus cuentas como de mayor riesgo.
• Mira la pestaña Variables de entorno de tu proyecto en Vercel. Cuenta cuántas NO están marcadas como "Sensible". Cada una de ellas está en el radio de impacto.

Si recibiste un correo de Vercel que empieza con "We identified a security incident affecting your account" — estás en el grupo de impactados confirmados. Ve directamente a la sección de rotación y empieza AHORA.

El plan de respuesta de emergencia de 60 minutos

El orden está determinado por el radio de impacto. No omitas pasos — cada uno desbloquea el siguiente.

Paso 1: Congelar el entorno (primeros 10 minutos)

Detén el sangrado antes de comenzar el análisis forense:

• Pausa los auto-despliegues en las ramas main/production (Panel de Vercel → Proyecto → Configuración → Git).
• Deshabilita temporalmente la Vercel GitHub App en github.com/organizations/<tu-org>/settings/installations si sospechas una compromisión más profunda.
• Exporta tu registro de auditoría de Vercel a CSV y guárdalo localmente. Lo necesitarás si esto se convierte en un incidente notificable según el RGPD.
• Activa Observability Plus (incluso una semana de prueba) para conservar registros extendidos.

Este es el paso de "preservar evidencia". Rotar antes de hacer un snapshot del registro destruye tu línea de tiempo.

Paso 2: Obtener las variables de entorno y escanearlas en busca de secretos

Abre tu terminal y ejecuta:

vercel link
vercel env pull .env.vercel-audit

Luego escanea la salida. La forma más rápida es la CLI de GitGuardian:

ggshield secret scan path .env.vercel-audit

Si no quieres instalar nada, usa grep con estos patrones — detectan el 80% de los secretos filtrados en archivos de entorno:

grep -E "AKIA[0-9A-Z]{16}|sk_live_[0-9a-zA-Z]{24}|ghp_[0-9a-zA-Z]{36}|ghs_[0-9a-zA-Z]{36}|npm_[0-9a-zA-Z]{36}|eyJ[a-zA-Z0-9_-]+|-----BEGIN" .env.vercel-audit

Cada coincidencia es un candidato a rotación. Cada secreto sin coincidencia que sigue siendo una credencial (URLs de bases de datos, contraseñas de Redis, claves de firma de webhooks) también es un candidato a rotación — grep solo captura lo obvio.

Paso 3: Rotar secretos en orden de prioridad (no alfabético)

Aquí es donde la mayoría de los equipos se equivocan. Rotan 40 secretos en orden aleatorio, una clave de sesión invalida todos los inicios de sesión activos y los tickets de soporte explotan. Hazlo por niveles:

Nivel 0 — Rotar en los próximos 30 minutos:

• Todos los Personal Access Tokens de GitHub (detallados y clásicos)
• Todos los tokens de env vars sensibles de Vercel existentes
• Tokens de Deployment Protection

Nivel 1 — Rotar hoy:

• Claves secretas de procesadores de pago (Stripe sk_live_, Adyen, Braintree)
• AUTH_SECRET, NEXTAUTH_SECRET, claves de firma JWT, cookies de sesión
• Cadenas de conexión de bases de datos con acceso de escritura (DATABASE_URL, Mongo, Redis)
• Claves de proveedores cloud (AWS IAM, cuentas de servicio de GCP, secretos de cliente de Azure)
• Secretos de firma de webhooks (actualizar en el remitente Y en el receptor)

Nivel 2 — Rotar esta semana:

• Claves SaaS de terceros (correo, SMS, analíticas, CRM)
• Secretos de cliente OAuth
• Credenciales SMTP, claves CDN

Nivel 3 — Rotar cuando sea conveniente:

• Tokens de analíticas de solo lectura, DSNs de Sentry, claves públicas/anónimas

Orden crítico de operaciones:

• Para bases de datos: crea el nuevo usuario antes de revocar el antiguo, o dejarás el sitio fuera de línea durante la rotación.
• Para claves de sesión: planifica un evento de cierre de sesión — todas las sesiones activas quedarán invalidadas.
• Para webhooks: actualiza ambos lados en la misma ventana de despliegue.
• Vuelve a desplegar después de cada cambio en variables de entorno. Vercel incorpora los valores en el momento de la construcción, no en tiempo de ejecución.

Paso 4: Volver a agregar todo como "Sensible"

Cuando vuelvas a poner los nuevos valores, activa el interruptor "Sensible" en cada uno de ellos. Los valores sensibles usan una ruta cifrada separada y, según el propio boletín de Vercel, no quedaron expuestos en este incidente. Este es el cambio de un clic que habría protegido a la mayoría de los clientes afectados.

Paso 5: Auditar tu repositorio en busca de cambios no deseados

Compara HEAD en tu rama principal con un commit que se sabe que estaba bien antes del 1 de abril. Céntrate en:

• Scripts de package.json — especialmente postinstall, prepare, preinstall
• Archivos de bloqueo (package-lock.json, pnpm-lock.yaml) en busca de nuevas dependencias inesperadas
• .github/workflows/*.yml en busca de nuevos workflows o actions sin versión fija
• vercel.json en busca de cambios en comandos de construcción o redirecciones sospechosas
• next.config.js en busca de nuevas cabeceras o redirecciones a dominios desconocidos

Si publicas paquetes npm, también ejecuta npm view <pkg> time --json y verifica que nada se haya publicado sin tu autoría.

Paso 6: Investigar sistemas posteriores

Los atacantes no se detienen en las variables de entorno — las usan. Consulta tus sistemas posteriores para el período desde el 1 de abril:

• AWS CloudTrail: CreateUser, AttachUserPolicy inesperados, ráfagas de GetObject en S3, inicios de sesión desde nuevas IPs.
• Registros de auditoría de bases de datos: consultas grandes SELECT *, exportaciones, conexiones desde regiones inusuales.
• Stripe / Adyen: nuevas claves API, reembolsos sospechosos, creaciones de clientes desde ubicaciones extrañas.
• Proveedor de autenticación: inicios de sesión de viaje imposible, restablecimientos de contraseña no autorizados, nuevas aplicaciones OAuth.

Cualquier resultado aquí convierte esto de un ejercicio de rotación en un incidente real — escala y considera tus obligaciones de notificación (RGPD: 72 horas).

Lo que los "vibe-coders" pasan por alto: la superficie de ataque oculta

Si aprendiste a programar con herramientas de IA — usando herramientas como Claude Code, Cursor o Copilot — probablemente desplegaste tu primera app en Vercel antes de haber leído jamás un documento de seguridad. Eso está bien. Pero hay cuatro trampas ocultas que golpean a los vibe-coders más duramente que a los desarrolladores experimentados:

1. La trampa de NEXT_PUBLIC_. Todo con el prefijo NEXT_PUBLIC_ se incluye en el JavaScript del cliente. Si pusiste una clave API ahí "solo para probar", ya era pública antes de la brecha. Escanea tu salida de construcción: grep -rE "sk_|AKIA|eyJ" .next/static/.
2. La filtración de Linear / Slack. Si tu equipo pega secretos en issues de Linear o hilos de Slack "solo un momento", esos secretos están en registros de terceros. Revisa tu registro de auditoría de Linear y busca los mismos patrones regex.
3. La suposición de .env.local en repositorio privado. Los repositorios privados no son privados si tu Vercel GitHub App fue comprometida. Cada archivo .env.* commiteado está en el radio de impacto.
4. Despliegues de vista previa con secretos de producción. La mayoría de los vibe-coders reutilizan las variables de entorno de producción para los entornos de vista previa. Eso duplica tu superficie de ataque. Sepáralos.

Este es el aburrido trabajo de infraestructura que las herramientas de codificación con IA omiten. La solución no es dejar de usar IA — es combinar la velocidad de la IA con una base de seguridad. Si todavía estás averiguando dónde vive tu app, nuestra comparativa Vercel vs. Netlify y el análisis Railway vs. Render vs. Fly.io son buenos puntos de partida.

Cómo reforzar tu stack para que la próxima brecha no te queme

Las brechas de plataforma son un cuándo, no un si. Esta es la base que toda aplicación en producción debería tener antes del lunes:

• Por defecto, marcar cada nueva variable de entorno como "Sensible" en Vercel. Conviértelo en el hábito de tu equipo.
• Usar credenciales de corta duración. Sustituye las claves de AWS/GCP de larga duración por la federación de GitHub OIDC — tu proveedor cloud confía directamente en la identidad de CI, sin secreto de larga duración que pueda filtrarse.
• Instalar escaneo de secretos pre-commit (gitleaks, Trufflehog). Evita que los secretos entren al repositorio desde el principio.
• Restringir tu GitHub App a repositorios específicos, no a toda la organización.
• Revisión trimestral de apps OAuth en Google Workspace, Microsoft 365, GitHub y Vercel. Elimina todo lo que no reconozcas.
• **Ejecutar escaneos de secretos como **hook de Claude Code — cumplimiento determinista pre-commit incluso cuando la IA lo olvida.
• Fijar tu versión de Next.js y monitorear avisos. Vercel es el principal responsable de Next.js, por lo que los incidentes aquí tienen efecto en cascada.
• Segmentar tus secretos de backend. Si usas Supabase o Firebase, utiliza la seguridad a nivel de fila y las claves de rol de servicio con moderación — una clave de servicio filtrada es una compromisión total de la base de datos.

¿Necesitas ayuda para asegurar tu stack? Así es como Techsy encaja

El discurso honesto: la mayoría de los equipos pequeños no tienen un ingeniero de seguridad, y leer un plan de respuesta a incidentes de 60 pasos a las 2 de la mañana no es cómo nadie quiere pasar su lunes.

En Techsy, hemos ejecutado respuesta a incidentes y refuerzo de plataformas para más de 40 aplicaciones Next.js y Node.js en producción durante los últimos dos años. Para el incidente de Vercel específicamente, ofrecemos:

• Respuesta de emergencia de 72 horas — Ejecutamos la rotación de Nivel 0/Nivel 1, escaneamos tus variables de entorno contra más de 200 firmas de secretos y auditamos tus registros de Vercel, GitHub y cloud de extremo a extremo. Tiempo de entrega típico: un día laborable.
• Auditoría de refuerzo de plataforma — Migración a variables sensibles, rotación de credenciales OIDC, escaneo de secretos pre-commit, alcance de la GitHub App y un runbook escrito para que tu yo futuro sepa qué hacer durante la próxima brecha.
• DevSecOps continuo — Revisiones trimestrales de OAuth, escaneo continuo de secretos y simulacros de incidentes para que "a nosotros no nos va a pasar" sea una afirmación que puedas respaldar.

Somos ingenieros, no un proveedor de seguridad de casillas a marcar. Si ahora mismo estás en pánico, contacta para una llamada de triaje gratuita de 30 minutos — te diremos honestamente si nos necesitas o si puedes manejarlo con el plan anterior.

Preguntas frecuentes

¿El hack de Vercel está confirmado o es solo un rumor?

Confirmado. Vercel publicó un boletín de seguridad oficial el 19 de abril de 2026, reconociendo acceso no autorizado a través de una herramienta de IA de terceros comprometida (Context.ai) y una cuenta de Google Workspace de un empleado secuestrada. Las variables de entorno no marcadas como "sensibles" fueron accedidas. Una publicación separada en BreachForums afirma estar vendiendo los datos por 2 millones de dólares; esa parte no está verificada.

No recibí un correo de Vercel. ¿Estoy seguro?

Probablemente, pero "probablemente" no es una postura de seguridad. Vercel dijo que contactó al subconjunto limitado de clientes con impacto confirmado. Si tu correo no llegó, tu riesgo es menor — pero todas las variables de entorno no sensibles en la plataforma de Vercel estaban en el radio de impacto. Haz el triaje de 10 minutos de todos modos.

¿Cuál es la diferencia entre variables de entorno "sensibles" y regulares en Vercel?

Las variables de entorno "sensibles" usan una ruta de lectura cifrada separada y no se pueden ver en el panel después de su creación. Las variables de entorno regulares son legibles por cualquiera con acceso al proyecto (incluyendo, en este incidente, al atacante). La solución es gratuita y tarda un clic por variable.

¿Debo rotar TODOS mis secretos, o solo los que están en Vercel?

Rota cada secreto almacenado en una variable de entorno de Vercel no sensible. Si usaste la misma clave en otro lugar (un antipatrón común), rótala en todos lados. No olvides .env.local en los despliegues de vista previa, sistemas de CI como GitHub Actions y cualquier referencia pegada en Linear o Slack.

¿Cómo escaneo mis variables de entorno en busca de secretos reales rápidamente?

Ejecuta vercel env pull .env.audit luego ggshield secret scan path .env.audit. Si no puedes instalar GitGuardian, usa el comando grep de una sola línea del Paso 2 del plan — detecta claves de AWS, claves de Stripe, tokens de GitHub, tokens de npm, JWTs y bloques PEM.

¿Debería cambiarme de Vercel después de este incidente?

No solo por este incidente. La respuesta de Vercel — IoC público, línea de tiempo, guía de rotación — ha sido razonablemente transparente. Cada plataforma tendrá una brecha eventualmente. Lo que importa es si has diseñado para ello: variables sensibles por defecto, credenciales de corta duración, entornos segmentados. Si estás evaluando alternativas de todos modos, nuestros artículos Vercel vs. Netlify y Railway vs. Render vs. Fly.io analizan las compensaciones.

¿Cuánto tiempo tengo para notificar a los clientes si estoy afectado?

El RGPD te da 72 horas desde el momento en que tienes conocimiento de una brecha notificable. California (CCPA) tiene disparadores específicos por clase de datos. Los contratos SOC 2/ISO 27001 suelen requerir una notificación más temprana que los reguladores. Si tienes clientes de pago y confirmas la exfiltración de sus datos, asume que estás bajo un reloj de 72 horas y consulta asesoría legal antes de enviar cualquier cosa.

¿Pueden las aplicaciones Next.js verse afectadas por esto aunque no esté en Vercel?

El incidente es específico de la plataforma Vercel. Next.js en sí, alojado en otro lugar, no se ve afectado por el mecanismo de la brecha. Pero si usaste los mismos patrones de variables de entorno NEXT_PUBLIC_ que accidentalmente exponen secretos, esos problemas viajan con tu código independientemente del host. Audita tu salida de construcción de todos modos.

¿Cuál es la corrección de un clic que habría evitado la mayor parte del daño?

Marcar cada variable de entorno que contiene credenciales como "Sensible" en Vercel desde el primer día. Es una casilla de verificación en el panel. En este incidente, las variables sensibles NO fueron accedidas — solo las regulares. Esa es la corrección, y cuesta cero dólares y aproximadamente cinco minutos por proyecto.

¿Cómo me aseguro de que mi equipo nunca vuelva a enviar un secreto sin marcar?

Tres capas: (1) escaneo de secretos pre-commit con gitleaks, (2) una verificación de CI que falla si se agrega una variable de entorno sin el flag sensitive: true a través de la API de Vercel, y (3) un hook de Claude Code que ejecuta el escáner en cada edición. Defensa en profundidad — cualquiera de las tres detecta el 80%, las tres juntas ~99%.

La conclusión

La brecha de Vercel de abril 2026 es grave, pero superable — si te mueves en los próximos 60 minutos. Congela los despliegues, obtén tus variables de entorno, ejecuta el grep, rota por niveles, vuelve a agregar como sensibles y rastrea los sistemas posteriores. Ese es todo el plan.

Las brechas de plataforma exponen cuánto dependemos de los valores predeterminados. La mayoría de los equipos que salieron perjudicados aquí no hicieron nada malo — simplemente dejaron el interruptor "Sensible" sin marcar porque nadie les dijo que importaba. Esa es la lección real para los vibe-coders: el código generado por IA se despliega rápido, pero los valores predeterminados de seguridad no vienen con la generación.

Si quieres un segundo par de ojos en tu stack, o prefieres no ejecutar este plan solo a las 2 de la mañana, reserva una llamada de triaje gratuita con el equipo de Techsy. De lo contrario — buena suerte, actúa rápido y marca esas variables como sensibles.