Перейти к основному контенту

Взломы Vercel + Lovable: как инструменты ИИ стали новым риском в цепочке поставок Web3

· 14 мин чтения
Dora Noda
Dora Noda
Software Engineer

Всего за одну неделю апреля 2026 года произошли два на первый взгляд не связанных между собой инцидента в сфере SaaS, которые должны заставить каждую команду Web3 пересмотреть свою модель угроз. Vercel — платформа развертывания, на которой работают тысячи интерфейсов кошельков и фронтендов dApp — сообщила, что злоумышленник проник в её среду через скомпрометированный ИИ-инструмент для повышения продуктивности под названием Context.ai. Спустя несколько дней платформа для «вайб-кодинга» Lovable была поймана на утечке исходного кода, учетных данных баз данных и историй чатов ИИ в тысячах проектов, созданных до ноября 2025 года, из-за неисправленной ошибки авторизации. У этих двух историй нет общей инфраструктуры. Их объединяет нечто худшее: одинаковый паттерн распространения атаки, при котором ИИ-инструменты незаметно стали привилегированными идентификаторами внутри цепочки инструментов разработки — и Web3 унаследовал этот риск, так и не включив его в свою оценку безопасности.

Аудиты смарт-контрактов, мультисиг-управление, подписание транзакций аппаратными кошельками — ни одна из этих защитных мер не стоит на пути злоумышленника, когда он компрометирует конвейер сборки (build pipeline), поставляющий пользовательский интерфейс для подтверждения транзакций. Апрель 2026 года сделал этот пробел очевидным. Станет ли это для индустрии тревожным звонком или просто очередным принятым убытком, зависит от того, как будет выглядеть следующий квартал.

Цепочка Vercel-Context: один клик OAuth, сотни фронтендов​

Отчет об инциденте Vercel от 19 апреля 2026 года выглядит как классический пример бесконтрольного разрастания OAuth (OAuth sprawl). Атака началась не в Vercel. Она началась несколькими месяцами ранее, в феврале 2026 года, когда сотрудник Context.ai установил чит для Roblox, содержащий стилер Lumma, и потерял свои учетные данные Google Workspace, а также секреты для Supabase, Datadog и Authkit.

Само по себе это обычная история кражи учетных данных. Что превратило её в атаку на цепочку поставок, затронувшую множество организаций, так это область действия (scope) OAuth. Как минимум один сотрудник Vercel ранее зарегистрировался в «AI Office Suite» от Context.ai, используя корпоративный аккаунт Google в Vercel, и нажал «Разрешить всё» (Allow All) — предоставив Context.ai постоянные и широкие разрешения во всем Google Workspace компании Vercel. Когда злоумышленник захватил OAuth-приложение Context.ai, он автоматически унаследовал это доверие. Оттуда он перешел в аккаунт Workspace сотрудника Vercel, а затем в среды Vercel, где перечислил и расшифровал нечувствительные переменные окружения.

Хакер под псевдонимом ShinyHunters выставил полученную базу данных на продажу на BreachForums за $ 2 миллиона. Vercel утверждает, что переменные, помеченные как «чувствительные», остались зашифрованными и не были прочитаны. Это различие имеет меньшее значение, чем вопрос: сколько проектов Web3, развернутых на Vercel, на самом деле пометили свои RPC-ключи, API-токены и секреты индексаторов как чувствительные? Судя по спешной ротации учетных данных, ответ таков: далеко не все.

DEX на базе Solana Orca подтвердила, что её фронтенд работает на Vercel, и в качестве меры предосторожности провела ротацию всех учетных данных для деплоя. CTO Cork Protocol публично призвал пользователей приостановить взаимодействие с DeFi-приложениями, размещенными на Vercel, пока проекты не успеют обновить ключи. Ончейн-протоколы и средства пользователей не пострадали напрямую, но путь от скомпрометированного деплоя на Vercel до вредоносной транзакции «approve unlimited» (разрешить неограниченный доступ), предъявляемой подключенному кошельку, не проходит через аудит смарт-контракта. Он обходит все защитные барьеры, выстроенные в Web3.

Почему «безопасность фронтенда» — это уровень, который Web3 забыл проаудитировать​

В течение пяти лет доминирующим нарративом безопасности в криптоиндустрии было: «Смарт-контракты хранят средства, поэтому аудируйте смарт-контракты». Это имело смысл, когда сектор DeFi был небольшим, а фронтенды представляли собой простые статические страницы на IPFS. Но это не описывает сегодняшнюю индустрию, где интерфейсы кошельков поставляются через Vercel, Netlify, Cloudflare Pages и AWS Amplify; где полезная нагрузка для подписи (signing payloads) формируется на JavaScript, поступающем через CDN; и где один вредоносный бандл может опустошить кошельки пользователей, не нарушая работу TLS.

История компрометаций фронтендов в Web3 коротка, но достаточно болезненна, чтобы сделать выводы:

  • Август 2022 года, Slope Wallet: Неправильно настроенная интеграция Sentry незаметно передавала данные закрытых ключей пользователей мобильного кошелька Slope сервису мониторинга приложений. Злоумышленник вывел $ 4,1 млн из 9 231 кошелька примерно за четыре часа. «Уязвимостью» оказался обычный инструмент телеметрии с избыточным доступом — в точности как в сценарии с разрастанием OAuth.
  • Декабрь 2023 года, Ledger Connect Kit: Бывший сотрудник Ledger стал жертвой фишинга и лишился токена сессии NPM, что позволило обойти двухфакторную аутентификацию (2FA). Злоумышленник внедрил вредоносный код для кражи средств из кошельков в версии @ledgerhq/connect-kit 1.1.5–1.1.7. Пакет был доступен в течение пяти часов, активно выводил средства в течение двух и затронул более 100 фронтендов dApp. Было украдено около $ 600 тысяч — сумма невелика лишь потому, что атаку быстро обнаружили.
  • Июль 2024 года, захват DNS Squarespace: Ошибка миграции при создании учетных записей доменов в Squarespace позволила злоумышленникам регистрировать административные адреса электронной почты для доменов, перенесенных из Google Domains, без подтверждения почты. Фронтенды Compound и Celer Network были перенаправлены на дрейнеры кошельков. Decrypt сообщил, что более 220 протоколов DeFi оставались под угрозой в течение нескольких недель после этого.

У каждого из этих инцидентов общая структура: был скомпрометирован неблокчейн-слой стека — телеметрия, реестр пакетов, DNS — и аудиту смарт-контракта здесь нечего было сказать. Апрель 2026 года добавил в этот список два новых слоя: ИИ-инструменты для продуктивности, выступающие в роли OAuth-идентификаторов (Vercel) и ИИ-платформы для кодинга, хранящие код и учетные данные клиентов (Lovable).

Ошибка BOLA в Lovable: 48 дней, 8 миллионов пользователей и «преднамеренное поведение»​

Пока Vercel восстанавливал радиус поражения после инцидента с OAuth, Lovable — платформа для вайб-кодинга с оценкой в 6,6 млрд долларов и восемью миллионами пользователей — раскрыла подробности собственного инцидента. Уязвимостью оказалась ошибка Broken Object Level Authorization (BOLA): API-эндпоинт раскрывал данные пользователей без проверки прав владения. Бесплатного аккаунта и пяти вызовов API было достаточно, чтобы прочитать профили других пользователей, исходный код проектов и учетные данные баз данных, встроенные в этот код.

Сообщается, что ошибка была закрыта триажерами HackerOne за 48 дней до раскрытия информации, поскольку открытые данные находились под флагом «public», значение которого, как позже признали в Lovable, было «неясным». В течение этого окна каждый проект на платформе, созданный до ноября 2025 года, был доступен. История чатов с ИИ, исходный код клиентов и встроенные в него учетные данные — для баз данных, платежных API и, да, RPC-эндпоинтов блокчейна — могли быть пересчитаны любым, кто готов написать скрипт для вызова.

Первоначальный ответ Lovable в X — отрицание какой-либо «утечки данных» и переименование инцидента в «преднамеренное поведение» — это та часть, которая должна больше всего беспокоить разработчиков Web3. Это сигнализирует о том, что операционные допущения платформ для ИИ-кодинга еще не впитали в себя модель угроз, которую унаследовали их пользователи. Когда Web3-команда использует Lovable для создания фронтенда, учетные данные, внедренные во время прототипирования, не исчезают. Они живут на платформе, индексируются, извлекаются и, по состоянию на апрель 2026 года — в течение как минимум 48 дней — были доступны любому пользователю с бесплатным аккаунтом.

Множитель разрастания OAuth: почему «просто ротации ключей» недостаточно​

Оба инцидента восходят к одной и той же первопричине: ИИ-инструментам предоставляются постоянные области доступа (scopes) OAuth для нескольких приложений внутри организаций, которые не ведут учет того, какие доступы каким приложениям были предоставлены. Недавние данные по корпоративному сектору подчеркивают масштаб проблемы: 98% организаций сообщают о несанкционированном использовании ИИ, а среднее предприятие сейчас использует более 830 приложений, при этом 61% работает без официального ИТ-контроля. Когда ИИ-инструмент скомпрометирован, каждое когда-либо предоставленное ему разрешение OAuth становится частью досягаемости злоумышленника.

Постмортем инцидента с Vercel от Push Security формулирует это прямо: атака удалась, потому что модель идентификации Vercel относилась к стороннему ИИ-приложению так же, как к сотруднику. Не было никакого ограничения прав доступа в духе «этому инструменту разрешено читать календари, но не перечислять переменные окружения». Это не специфический провал Vercel. Это состояние по умолчанию почти для каждого арендатора Google Workspace, Microsoft 365 и Okta, который интегрировал ИИ-помощников за последние 18 месяцев.

Для Web3-команд это означает, что ротация ключей после взлома уровня Vercel необходима, но недостаточна. Вектор атаки — избыточные привилегии OAuth для ИИ-инструментов — сохраняется у каждого SaaS-провайдера в цепочке поставок. Команда, которая сменила учетные данные для развертывания Vercel в апреле, но все еще использует ИИ-приложение для заметок со встреч с полным доступом к Google Drive, находится в одной инфекции инфостилером от того же результата.

Как выглядит по-настоящему защищенный Web3-фронтенд​

Сегодня существует несколько защитных паттернов, которые, будучи объединенными, нейтрализовали бы инциденты уровня Vercel и Lovable. Ни один из них в настоящее время не является обязательным.

Хеши Subresource Integrity (SRI) для бандлов интерфейса кошельков. SRI — это рекомендация W3C, которая позволяет браузерам проверять соответствие полученного ресурса криптографическому хешу перед его выполнением. Если развертывание Vercel изменяется после публикации хеша целостности — скажем, злоумышленником, который проник в конвейер сборки — браузер отказывается его загружать. SRI существует с 2016 года и тривиально поддерживается. Почти ни один Web3-фронтенд не использует его для своих основных бандлов, потому что они меняются при каждом деплое, и кто-то должен управлять ротацией хешей.

Ончейн-манифесты фронтенда. Записи contenthash в ENS и CID в IPFS позволяют проекту закрепить в блокчейне утверждение: «это канонический фронтенд для протокола X». Кошелек, который сверяется с манифестом перед загрузкой интерфейса, может обнаружить, когда предоставленный бандл не соответствует опубликованному CID. EIP-2477 исследовал это для метаданных токенов, и та же идея применима к фронтендам dApp. Сегодня внедрение сосредоточено в проектах, которые уже поставляются только через IPFS — развертывание Uniswap в IPFS является очевидным примером — и отсутствует везде в остальных местах.

Симуляция транзакций на стороне клиента. Кошельки, такие как Rabby и Wallet Guard, симулируют каждую транзакцию перед подписанием и показывают пользователю реальное движение активов. Это не предотвратило бы запуск логики кражи средств в Ledger Connect Kit, но дало бы пользователям шанс увидеть сообщение «это переведет весь ваш баланс USDC на адрес 0xunknown» перед нажатием кнопки подтверждения. Популярность этого решения растет, но оно внедряется на уровне кошельков, а не протоколов.

Дисплеи аппаратных кошельков «что видишь, то и подписываешь». Устройства вроде Ledger Stax и Keystone разбирают данные вызова (calldata) и отображают человекочитаемое намерение на экране устройства, побеждая фишинг на уровне интерфейса. Это работает только тогда, когда у контракта опубликована схема «чистой подписи» (clear-signing). У большинства контрактов ее нет.

Общая закономерность для всех четырех методов защиты: они существуют, они работают, но они не развернуты по умолчанию. Они требуют инженерного времени, которое конкурирует с выпуском новых функций продукта, а худший сценарий, который они предотвращают — массовая кража средств — до апреля 2026 года случался в основном с «другими людьми».

Вопрос переломного момента​

Исторически сложилось так, что Web3 требовалась потеря пользовательских средств на сумму более 50 млн $, чтобы внедрить новые защитные стандарты по умолчанию. Аудиты стали обязательным условием после взлома DAO в 2016 году. Мультисиг-управление превратилось из опционального в обязательное после эксплойтов Ronin и Wormhole в 2022 году. Аппаратные кошельки стали нормой после краха Mt. Gox и десятков компрометаций бирж.

Двойной взлом в апреле 2026 года не привел к потере 50 млн $. Злоумышленник Vercel получил «выплату» в виде переменных окружения, а не пользовательских средств. Утечка Lovable обнажила исходный код, а не подписанные транзакции. Оба случая были предупредительными выстрелами — эквивалентом раскрытия уязвимости без её эксплуатации, за исключением того, что уязвимости крылись в самих доверительных отношениях, а не в каком-либо исправимом коде.

Вопрос следующего квартала заключается в том, оценят ли разработчики Web3 это предупреждение правильно или будут ждать реальных убытков. Безопасность фронтенда — SRI, ончейн-манифесты, симуляция транзакций, понятное подписание (clear signing) — имеет ту же форму, что и аудиты смарт-контрактов в 2017 году: технически доступны, культурно опциональны, но вот-вот будут переклассифицированы в очевидно необходимые. Разница лишь в том, что цену за урок платят пользователи, а не протоколы.

Команды, которые сделают шаг первыми, возьмут на себя квартальные инженерные расходы. Команды, которые будут ждать, возьмут на себя всё, во что им обойдется первый взлом класса Vercel на 50+ млн $ в виде оттока пользователей, регуляторных рисков и постмортемов, которые они будут писать месяцами.

BlockEden.xyz управляет продакшн-инфраструктурой RPC и индексации в 12+ блокчейнах с изоляцией окружения, API-ключами с ограниченной областью действия и инструментами ротации, разработанными для команд, которые относятся к безопасности фронтенда как к первоочередной задаче. Стройте на инфраструктуре, которая исходит из того, что цепочка поставок враждебна.

Источники​

Share on Twitter