Lo que pasó
Esta semana Vercel — una plataforma donde muchos desarrolladores desplegamos buena parte de nuestros proyectos — confirmó un preocupante incidente de seguridad.
No fue un fallo técnico ni una caída del servicio. Fue una brecha de seguridad: alguien accedió a sistemas internos de Vercel sin autorización.
El origen no fue por un problema interno dentro de Vercel directamente. Un empleado usaba una herramienta de IA de terceros llamada Context.ai, y esa herramienta fue comprometida. A través de ella, el atacante tomó el control de la cuenta de Google Workspace del empleado, y desde ahí accedió a ciertos entornos dentro de Vercel.
¿Qué se comprometió exactamente?
Las variables de entorno, archivos que guardan información como contraseñas a bases de datos o a servicios externos o APIs, que no estaban marcadas como "sensitive" — es decir, las que Vercel almacena en texto plano legible.
Las variables marcadas como sensitive están cifradas de forma que ni siquiera Vercel puede leerlas, y según la investigación, esas no fueron vulneradas.
¿Afecta a mis proyectos o a los de mis clientes?
Revisé el estado de cada proyecto que tengo en producción en Vercel. Roté las credenciales que correspondía rotar, migré las variables relevantes a almacenamiento sensitive, y verifiqué que no hubiera actividad anómala en ninguno de los servicios conectados.
No tengo evidencia de que ninguno de los proyectos que desarrollo haya sido afectado. Si lo hubiera, me pondría en contacto directo con el cliente involucrado — no lo mencionaría de pasada en un blog.
Lo que hace mal Vercel en esto — y lo que hace bien
Lo que hace mal: que la opción por defecto para las variables de entorno no sea "sensitive". Durante años, si un desarrollador creaba una variable sin marcarla explícitamente, quedaba almacenada en texto plano. Eso es una decisión de diseño que tendría que haber sido distinta desde el principio.
Lo que hace bien: comunicó el incidente con rapidez, contrató firmas de seguridad externas como Mandiant, coordinó con GitHub, Microsoft y npm para confirmar que ningún paquete fue comprometido, y ya cambió el comportamiento por defecto para que las nuevas variables sean sensitive a menos que el desarrollador decida lo contrario.
No es suficiente haber actuado rápido después, pero es mejor que no actuar nunca.
¿Qué aprendizaje queda?
Este incidente no es único de Vercel. Es un ejemplo de lo que se llama un ataque de cadena de suministro: el objetivo no fue atacado directamente, sino a través de una herramienta de terceros de confianza.
La lección no es "no uses Vercel" — es que cualquier herramienta externa que conectas a tus sistemas es una superficie de riesgo. Eso incluye herramientas de IA, plugins, integraciones OAuth, y cualquier servicio al que le das acceso a tu cuenta.
Como desarrollador, esto refuerza algo que ya practico: revisar quién tiene acceso a qué, reducir permisos al mínimo necesario, y no asumir que porque algo "funciona" también está bien configurado desde el punto de vista de seguridad.
Me tomo en serio tu seguridad y la de tus proyectos tanto como la mía propia. Si confías en mí para una aplicación que desees desarrollar, siempre velaré por cuidar y honrar esa confianza.
Si tienes un proyecto en Vercel y quieres saber si tus variables están correctamente configuradas, escríbeme. Es una revisión rápida, y vale la pena hacerla.