Vercel guardaba sus secretos en texto plano y lo llamaba una funcionalidad
Un atacante pasó de una herramienta de IA comprometida, a través de una cuenta de Google, a la infraestructura de Vercel y descifró todas las variables de entorno que no se hubieran marcado manualmente como «sensitive». La brecha duró dos meses antes de que alguien se percatara.
Vercel sufrió una brecha de seguridad. El atacante permaneció en el interior aproximadamente dos meses antes de ser detectado. Enumeró y descifró variables de entorno de clientes — claves de API, contraseñas de bases de datos, claves de firma, tokens — de todos los proyectos que no utilizaban el indicador opcional «sensitive» de Vercel.
La cadena de ataque: se comprometió una herramienta de IA de terceros llamada Context.ai. El atacante utilizó ese punto de apoyo para hacerse con la cuenta de Google Workspace de un empleado de Vercel. Desde allí, pivotó hacia los sistemas internos de Vercel. Después empezó a leer secretos.
Según se indica, los datos se ofrecen ahora en BreachForums por 2 millones de dólares.
La casilla «sensitive» que no era el valor predeterminado
Ahora viene lo que importa.
Vercel tiene dos tipos de variables de entorno. Las normales, que están «cifradas en reposo» pero que los sistemas de Vercel pueden descifrar y leer. Y las «sensitive», que emplean un cifrado adicional que, según Vercel, impide incluso el acceso interno.
El atacante podía leer todas las normales. Solo las «sensitive» estaban protegidas.
El problema: «sensitive» era opcional. No era el valor predeterminado. Todo desarrollador que definiera DATABASE_URL o STRIPE_SECRET_KEY o JWT_SIGNING_KEY sin marcar una casilla — y eso incluye a la mayoría — tenía esos valores almacenados en un formato que un atacante con acceso interno podía descifrar.
La recomendación de Vercel tras la brecha: «Active la función de variables de entorno sensibles para el almacenamiento cifrado». Traducción: el cifrado que usted asumía que protegía sus secretos en realidad no los protegía de nosotros, ni de nadie que entrara en nuestros sistemas.
Dos meses de permanencia en el sistema
El compromiso inicial se produjo en febrero de 2026. Vercel publicó su primer boletín de seguridad el 19 de abril. Eso supone unos dos meses de acceso de un atacante a los sistemas internos.
El propio equipo de seguridad de Vercel describió al atacante como «muy sofisticado, a juzgar por su velocidad operativa y su profundo conocimiento de la superficie de la API de producto de Vercel». Cuando la empresa que aloja su infraestructura afirma que el atacante entendía sus sistemas mejor de lo esperado, eso debería hacerle reflexionar.
Durante esos dos meses, el atacante tuvo tiempo de enumerar todas las variables de entorno accesibles en los proyectos de clientes afectados. Tiempo para exfiltrar. Tiempo para vender.
La cadena de suministro de OAuth
El punto de entrada ni siquiera era el código propio de Vercel. Un empleado de Vercel autorizó Context.ai — una herramienta de productividad basada en IA — mediante Google OAuth. Cuando Context.ai fue comprometida, el atacante heredó todos los permisos que concedía esa autorización OAuth.
Se trata de un patrón que se repite una y otra vez. Las organizaciones refuerzan cuidadosamente su autenticación principal y después entregan tokens de OAuth a herramientas de terceros que tienen su propia postura de seguridad, a menudo más débil. Basta con que se comprometa una aplicación de la cadena para que el atacante herede el acceso de su empleado.
El ID de la aplicación OAuth comprometida es público: 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com. Si su organización autorizó esta aplicación, revóquelo ahora.
Qué debe hacer
Si despliega en Vercel:
- Rote inmediatamente todas las variables de entorno: no espere a determinar si usted estaba «afectado»
- Active el indicador «sensitive» en todas las variables de entorno a partir de ahora
- Audite los permisos de aplicaciones OAuth de Google Workspace y revoque todo lo que no utilice activamente
- Revise los registros de despliegue de Vercel en busca de cambios inesperados entre febrero y abril de 2026
- Compruebe los servicios posteriores (bases de datos, procesadores de pagos, APIs) en busca de accesos no autorizados mediante las credenciales que se almacenaban en Vercel
La lección real
La arquitectura de Vercel almacenaba los secretos de los clientes de tal forma que un acceso interno podía descifrarlos. Ofrecían una opción más fuerte, pero no la convirtieron en el valor predeterminado. Durante dos meses, nadie se percató de que un atacante leía esos secretos.
Este es el problema de la seguridad del tipo «fíe de nosotros». Vercel cifraba sus variables de entorno en reposo: técnicamente es cierto. Pero las claves de descifrado las tenían ellos. Cuando sus sistemas se vieron comprometidos, también lo estuvieron sus secretos.
La alternativa es una arquitectura de conocimiento cero, en la que el proveedor del servicio matemáticamente no puede descifrar sus datos. No «decide no hacerlo»: no puede. Ningún nivel de compromiso interno, ningún empleado deshonesto, ningún atacante sofisticado que permanezca dos meses en su infraestructura puede leer aquello para lo que el servidor nunca tuvo las claves de descifrado.
Vercel pide a sus clientes que marquen una casilla para optar por un cifrado real. La pregunta que merece una respuesta: ¿por qué no fue esa la única opción desde el principio?