Saltar al contenido principal

Vercel + Lovable Breaches: Cómo las herramientas de IA se convirtieron en el nuevo riesgo de la cadena de suministro de Web3

· 16 min de lectura
Dora Noda
Software Engineer

En una sola semana de abril de 2026, dos incidentes de SaaS aparentemente no relacionados chocaron de una manera que debería restablecer el modelo de amenazas de cada equipo de Web3. Vercel — la plataforma de despliegue bajo miles de interfaces de usuario de carteras y frontends de dApps — reveló que un atacante se había infiltrado en su entorno a través de una herramienta de productividad de IA comprometida llamada Context.ai. Días después, la plataforma de vibe-coding Lovable fue sorprendida filtrando código fuente, credenciales de bases de datos e historiales de chat de IA en miles de proyectos anteriores a noviembre de 2025 a través de un error de autorización no corregido. Las dos historias no comparten infraestructura común. Comparten algo peor: el mismo patrón de explosión, donde las herramientas de IA se convirtieron silenciosamente en identidades privilegiadas dentro de la cadena de herramientas de desarrollo — y Web3 heredó el riesgo sin haberlo valorado nunca.

Auditorías de contratos inteligentes, gobernanza multisig, firma con carteras de hardware — ninguna de estas defensas se encuentra en el camino que toma un atacante cuando compromete la canalización de construcción que entrega la interfaz de usuario de aprobación de transacciones de sus usuarios. Abril de 2026 hizo visible esa brecha. Si la industria lo trata como una llamada de atención o como otra pérdida absorbida depende de cómo se vea el próximo trimestre.

La cadena Vercel-Context: Un clic de OAuth, cientos de frontends

El informe de incidentes del 19 de abril de 2026 de Vercel se lee como un caso de libro de texto de expansión de OAuth. El ataque no comenzó en Vercel. Comenzó meses antes, en febrero de 2026, cuando un empleado de Context.ai instaló un truco de Roblox que portaba Lumma Stealer y perdió sus credenciales de Google Workspace, además de secretos para Supabase, Datadog y Authkit.

Eso por sí solo es una historia rutinaria de robo de credenciales. Lo que lo convirtió en un ataque a la cadena de suministro de múltiples organizaciones fue el alcance de OAuth. Al menos un empleado de Vercel se había registrado previamente en la "AI Office Suite" de Context.ai usando su cuenta corporativa de Google de Vercel y hizo clic en "Permitir todo" — otorgando a Context.ai permisos persistentes y amplios en todo el Google Workspace de Vercel. Cuando el atacante tomó el control de la aplicación OAuth de Context.ai, heredó esa confianza automáticamente. Desde allí, saltaron a la cuenta de Vercel Workspace del empleado, y luego a los entornos de Vercel donde enumeraron y descifraron variables de entorno no sensibles.

Un actor de amenazas llamado ShinyHunters puso a la venta la base de datos resultante en BreachForums por 2 millones de dólares. Vercel sostiene que las variables marcadas como "sensibles" permanecieron encriptadas y sin leer. Esa distinción importa menos que la pregunta: ¿cuántos proyectos de Web3 que se despliegan en Vercel marcaron realmente sus claves RPC, tokens de API y secretos de indexador como sensibles? La respuesta, a juzgar por la carrera por rotar las credenciales, fue: no todos ellos.

El DEX de Solana Orca confirmó que su frontend se ejecuta en Vercel y rotó todas las credenciales de despliegue como precaución. El CTO de Cork Protocol instó públicamente a los usuarios a pausar la interacción con las aplicaciones DeFi alojadas en Vercel hasta que los proyectos tuvieran tiempo de rotar. Los protocolos en cadena y los fondos de los usuarios no se vieron afectados directamente — pero el camino desde un despliegue de Vercel comprometido hasta una transacción maliciosa de "aprobación ilimitada" entregada a una cartera conectada no pasa por una auditoría de contrato inteligente. Omite cada defensa que Web3 ha construido.

Por qué la "seguridad del frontend" es la capa que Web3 olvidó auditar

Durante cinco años, la narrativa de seguridad dominante en el mundo cripto ha sido: "Los contratos inteligentes guardan los fondos, así que audita los contratos inteligentes". Eso tenía sentido cuando DeFi era pequeño y los frontends eran simples páginas estáticas en IPFS. No describe la industria actual, donde las interfaces de usuario de las carteras se envían desde Vercel, Netlify, Cloudflare Pages y AWS Amplify; donde las cargas útiles de firma se construyen en JavaScript que llega a través de CDN; y donde un solo paquete malicioso puede vaciar a los usuarios sin romper TLS.

La historia de los compromisos de frontend en Web3 es corta pero lo suficientemente costosa como para extrapolar:

  • Agosto de 2022, Slope Wallet: Una integración de Sentry mal configurada transmitió silenciosamente material de claves privadas de los usuarios de la cartera móvil Slope a un servicio de monitoreo de aplicaciones. Un atacante drenó 4,1 millones de dólares en 9.231 carteras en aproximadamente cuatro horas. La "vulnerabilidad" era una herramienta de telemetría rutinaria con demasiado acceso — exactamente el mismo patrón de expansión de OAuth.
  • Diciembre de 2023, Ledger Connect Kit: Un ex empleado de Ledger fue víctima de phishing para obtener su token de sesión de NPM, omitiendo la autenticación de dos factores (2FA). El atacante publicó una carga útil maliciosa para drenar carteras como las versiones 1.1.5–1.1.7 de @ledgerhq/connect-kit. El paquete estuvo activo durante cinco horas, drenando activamente durante dos, y llegó a más de 100 frontends de dApps. Se robaron aproximadamente 600.000 dólares — una cifra pequeña solo porque alguien lo detectó rápido.
  • Julio de 2024, secuestro de DNS de Squarespace: Un fallo de migración en la creación de cuentas de dominio de Squarespace permitió a los atacantes registrar correos electrónicos de administrador para dominios que se habían trasladado desde Google Domains sin verificación de correo electrónico. Los frontends de Compound y Celer Network fueron redirigidos a drenadores de carteras. Decrypt informó que más de 220 protocolos DeFi permanecieron en riesgo durante semanas después.

Cada uno de estos incidentes comparte una forma: se comprometió una capa de la pila que no es de blockchain — telemetría, registro de paquetes, DNS — y la auditoría del contrato inteligente no tuvo nada que decir al respecto. Abril de 2026 añadió dos nuevas capas a esa lista: herramientas de productividad de IA que actúan como identidades OAuth (Vercel) y plataformas de codificación de IA que almacenan código y credenciales de clientes (Lovable).

El error BOLA de Lovable: 48 días, 8 millones de usuarios y "comportamiento intencionado"

Mientras Vercel reconstruía su radio de explosión de OAuth, Lovable — una plataforma de "vibe-coding" con una valoración de 6.600 millones de dólares y ocho millones de usuarios — revelaba su propio incidente. La vulnerabilidad era un fallo de Autorización a Nivel de Objeto Roto (BOLA): un endpoint de la API exponía datos de usuarios sin validación de propiedad. Una cuenta gratuita más cinco llamadas a la API eran suficientes para leer los perfiles de otros usuarios, el código fuente de los proyectos y las credenciales de bases de datos integradas en ese código fuente.

Según se informa, el error fue cerrado por los triagers de HackerOne 48 días antes de su divulgación porque los datos expuestos se encontraban bajo una etiqueta "pública" cuyo significado Lovable admitió más tarde que era "poco claro". Durante ese período, todos los proyectos anteriores a noviembre de 2025 en la plataforma eran accesibles. Los historiales de chat de IA, el código fuente de los clientes y las credenciales que dicho código fuente integraba — para bases de datos, API de pago y, sí, endpoints RPC de blockchain — eran enumerables por cualquiera que estuviera dispuesto a programar la llamada.

La respuesta inicial de Lovable en X — negando cualquier "brecha de datos" y reformulando la exposición como "comportamiento intencionado" — es la parte que más debería preocupar a los constructores de Web3. Indica que las suposiciones operativas de las plataformas de codificación por IA aún no han absorbido el modelo de amenazas que sus usuarios han heredado. Cuando un equipo de Web3 utiliza Lovable para estructurar un frontend, las credenciales integradas durante el prototipado no desaparecen. Viven en la plataforma, indexadas, recuperables y, a partir de abril de 2026 — durante al menos 48 días —, accesibles para cualquiera con una cuenta gratuita.

El multiplicador de la dispersión de OAuth: por qué "simplemente rotar las claves" no es suficiente

Ambos incidentes se remontan a la misma causa raíz: se están otorgando a las herramientas de IA alcances (scopes) de OAuth persistentes y para múltiples aplicaciones dentro de organizaciones que no tienen un inventario de qué alcances se otorgaron a qué aplicaciones. Datos recientes de empresas subrayan la magnitud: el 98 % de las organizaciones informan de un uso de IA no autorizado, y la empresa promedio ahora ejecuta más de 830 aplicaciones, con un 61 % operando fuera de la supervisión formal de TI. Cuando una herramienta de IA se ve comprometida, cada permiso de OAuth otorgado se convierte en parte del alcance del atacante.

El post-mortem de Push Security sobre el incidente de Vercel lo plantea sin rodeos: el ataque tuvo éxito porque el modelo de identidad de Vercel trató a una aplicación de IA de terceros de la misma manera que trató a un empleado. No hubo una reducción del alcance (scope-down) para decir: "esta herramienta tiene permitido leer calendarios, no enumerar variables de entorno". Eso no es un fallo específico de Vercel. Es el estado predeterminado de casi todos los inquilinos de Google Workspace, Microsoft 365 y Okta que han integrado asistentes de IA en los últimos 18 meses.

Para los equipos de Web3, la implicación es que rotar las claves después de una brecha del nivel de Vercel es necesario pero no suficiente. El vector de ataque — concesiones de OAuth con exceso de privilegios a herramientas de IA — persiste en todos los proveedores de SaaS de la cadena de suministro. Un equipo que rotó las credenciales de despliegue de Vercel en abril pero que aún tiene una aplicación de notas de reuniones con IA con acceso total a Drive está a una infección por infostealer de distancia del mismo resultado.

Cómo es un frontend de Web3 realmente defendido

Existen hoy en día un puñado de patrones defensivos que, si se combinaran, habrían neutralizado los incidentes de nivel Vercel y Lovable. Ninguno es obligatorio actualmente.

Hashes de Integridad de Subrecursos (SRI) para los paquetes de UI de billeteras. SRI es una recomendación del W3C que permite a los navegadores verificar que un recurso obtenido coincida con un hash criptográfico antes de ejecutarlo. Si un despliegue de Vercel se modifica después de que se publique el hash de integridad — por ejemplo, por un atacante que entró en el pipeline de construcción —, el navegador se niega a cargarlo. SRI existe desde 2016 y es compatible de forma trivial. Casi ningún frontend de Web3 lo utiliza para sus paquetes principales, porque estos cambian en cada despliegue y alguien tiene que gestionar la rotación de hashes.

Manifiestos de frontend on-chain. Los registros contenthash de ENS y los CID de IPFS permiten que un proyecto ancle "este es el frontend canónico para el protocolo X" en la cadena. Una billetera que consulte el manifiesto antes de cargar la interfaz de usuario puede detectar cuándo el paquete servido no coincide con el CID publicado. El EIP-2477 exploró esto para los metadatos de tokens y la misma idea se generaliza a los frontends de dApps. La adopción hoy se concentra en proyectos que ya se envían solo por IPFS — el despliegue de IPFS de Uniswap es el ejemplo obvio — y está ausente en todos los demás lugares.

Simulación de transacciones en el lado del cliente. Billeteras como Rabby y Wallet Guard simulan cada transacción antes de firmarla y muestran el movimiento real de activos al usuario. Esto no habría evitado que se ejecutara la lógica de drenaje del atacante del Ledger Connect Kit, pero habría dado a los usuarios la oportunidad de ver "esto transfiere todo su saldo de USDC a 0xdesconocido" antes de hacer clic en confirmar. La adopción está aumentando, pero sigue siendo billetera por billetera, no protocolo por protocolo.

Pantallas de billeteras de hardware "lo que ves es lo que firmas". Dispositivos como Ledger Stax y Keystone analizan los calldata y renderizan la intención legible por humanos en la pantalla del dispositivo, derrotando el phishing en la capa de la interfaz de usuario. Esto solo funciona cuando el contrato tiene un esquema de firma clara (clear-signing) publicado. La mayoría de los contratos no lo tienen.

El patrón en las cuatro defensas: existen, funcionan y no se despliegan por defecto. Cuestan un tiempo de ingeniería que compite con el lanzamiento de funciones del producto, y el peor de los casos que previenen — un drenaje importante — hasta abril de 2026, les ha sucedido principalmente a "otras personas".

La cuestión de la inflexión

Web3 ha requerido históricamente una pérdida de fondos de usuarios de más de $50 millones para adoptar nuevos estándares defensivos por defecto. Las auditorías se convirtieron en un requisito mínimo tras el hack de The DAO en 2016. La gobernanza multifirma (multisig) pasó de ser opcional a obligatoria tras los exploits de Ronin y Wormhole en 2022. Las carteras de hardware se normalizaron después de Mt. Gox y decenas de brechas en intercambios.

Las brechas gemelas de abril de 2026 no produjeron una pérdida de $50 millones. Al atacante de Vercel se le pagó en variables de entorno, no en fondos de usuarios. La exposición de Lovable sacó a la luz código fuente, no transacciones firmadas. Ambos fueron disparos de advertencia — el equivalente a una divulgación de vulnerabilidad sin explotación, excepto que las vulnerabilidades estaban en las propias relaciones de confianza, no en ninguna base de código corregible.

La pregunta para el próximo trimestre es si los desarrolladores de Web3 valoran la advertencia correctamente o esperan al evento de pérdida. La seguridad del frontend — SRI, manifiestos on-chain, simulación de transacciones, firma clara — tiene la misma forma que las auditorías de contratos inteligentes en 2017: técnicamente disponibles, culturalmente opcionales, a punto de ser reclasificadas como obviamente necesarias. La diferencia es que el costo de la lección lo pagan los usuarios, no los protocolos.

Los equipos que se muevan primero absorberán un trimestre de costo de ingeniería. Los equipos que esperen absorberán lo que sea que el primer drenaje de clase Vercel de más de $50 millones les cueste en usuarios, exposición regulatoria y los informes post-mortem que estarán escribiendo durante meses.


BlockEden.xyz opera infraestructura de RPC e indexación en producción en más de 12 blockchains, con aislamiento de entornos, claves API con permisos específicos y herramientas de rotación diseñadas para equipos que tratan la seguridad del frontend como una prioridad de primer nivel. Construya sobre una infraestructura que asume que la cadena de suministro es hostil.

Fuentes