Исследователи Token Security показали цепочку из пяти шагов, которая теоретически позволяла добраться до приватных репозиториев Zapier и затем распространить вредоносный код через платформу. Для рынка, где облачные интеграции давно стали клеем между CRM, почтой, таблицами и внутренними сервисами, это плохая, но полезная новость: взлом все чаще начинается не с «супер-эксплойта», а с пары мелких архитектурных уступок.
Речь идет о низкокодовом сервисе автоматизации Zapier, где пользователи могут запускать собственные фрагменты кода на Python и JavaScript. Как пишет Dark Reading, команда Token Security в феврале 2026 года сообщила компании о найденной цепочке атаки по правилам responsible disclosure, а Zapier закрыла проблему меньше чем за неделю. Позже исследователи перепроверили исправления и подтвердили, что они работают.
Сценарий начинался с функции, которая для клиента выглядит вполне штатно: кодовый блок внутри автоматизации. Исследователи запустили в песочнице собственный код и выяснили, что среда работает поверх AWS Lambda. Снаружи это не выглядит сенсацией, но дальше началась классика облачной гигиены: в окружении не было «торчащих» секретов на виду, зато нашлась роль с чрезмерными правами. Ее ироничное имя — allow_nothing_role — не помогало: по факту роль позволяла больше, чем обещало название. Дополнительно исследователи увидели признаки того, что учетные данные не удалялись достаточно жестко после выполнения задач.
Следующий шаг оказался особенно показателен для тех, кто строит облачные интеграции на serverless-стеке. Команда написала Python-скрипт для извлечения секретов из памяти контейнера. В случае AWS Lambda токены и другие чувствительные данные не исчезают мгновенно после завершения выполнения: они могут оставаться в памяти, пока контейнер не будет переразвернут. Это не баг одной конкретной платформы автоматизации, а неприятная особенность эксплуатационной модели, с которой разработчики обязаны считаться. Если поверх нее положить лишние разрешения и неаккуратную работу с артефактами, получается уже не «теоретическая поверхность атаки», а очень практичный маршрут.
Где именно сломалась логика защиты
На третьем этапе исследователи использовали найденную роль, чтобы перечислить и запросить 1111 файлов из приватного репозитория Zapier. Среди них оказался файл с NPM-токеном публикации, который, по их словам, годился для всех пакетов. Два последних шага они описали, но не стали выполнять. Первый из них — внедрение post-install-скрипта в легитимный пакет, то есть фактически подготовка supply chain-атаки. Второй — доставка этого кода в браузеры всех аутентифицированных пользователей сервиса. По оценке Token Security, атакующий мог бы действовать от имени пользователя внутри Zapier: создавать и менять Zaps, таблицы, MCP-серверы, а также использовать уже подключенные интеграции со сторонними сервисами.
Именно здесь история перестает быть сюжетом только про один сервис автоматизации. Проблема не в том, что кто-то неудачно назвал IAM-роль, а в том, что современные облачные интеграции работают как густая сеть доверия между десятками систем. Один пользователь в Zapier может иметь доступ к Gmail, Google Drive, Salesforce и внутренним процессам компании. Если злоумышленник получает возможность «ехать» на существующей пользовательской сессии, он не обязан ломать каждую систему отдельно. Платформа автоматизации сама становится для него аккуратным, легитимным посредником.
Контекст у этой истории неприятно знакомый. Dark Reading напоминает, что 56% компаний до сих пор не имеют процесса для учета SaaS-to-SaaS-соединений и интеграций. В 2025 году группа UNC6395 уже крала данные из Salesforce-инстансов, злоупотребляя OAuth-токенами, связанными со сторонним приложением автоматизации продаж. В марте 2026-го Salesforce отдельно предупреждала клиентов о слишком широких разрешениях у guest-аккаунтов. Иными словами, рынок уже несколько лет получает один и тот же урок, но в разных обертках: неучтенные связи между сервисами и чрезмерные права оказываются опаснее, чем кажется на архитектурной схеме.
Что это значит для разработчиков и бизнеса
Для разработчиков здесь три прямых вывода. Во-первых, «песочница» без строгой изоляции и контроля привилегий — это не защита, а отсрочка инцидента. Во-вторых, non-human identities, сервисные роли, токены публикации и прочие машинные учетные записи нужно инвентаризировать не менее жестко, чем доступы сотрудников. В-третьих, serverless-среды нельзя рассматривать как магический слой безопасности только потому, что ими управляет облачный провайдер. Если секреты живут в памяти дольше, чем вы предполагаете, значит модель угроз уже изменилась, просто не все об этом догадались.
Для бизнеса мораль еще прозаичнее. Платформы автоматизации давно перестали быть «удобной штукой для no-code-команды». Это инфраструктурный слой, через который проходят данные, доступы и действия в критичных системах. Поэтому минимальные привилегии должны применяться не только к сотрудникам, но и к каждому подключению, OAuth-скоупу, сервисной роли и пакету, который может попасть в production-цепочку. Иначе облачные интеграции превращаются из ускорителя процессов в тихий канал бокового перемещения для атакующего.
История с Zapier закончилась хорошо именно потому, что исследователи остановились до финальных шагов, а вендор быстро закрыл дыру. Но сама логика атаки слишком универсальна, чтобы списать ее на частный случай. Чем больше в компании автоматизаций, агентных сценариев и связей между SaaS-сервисами, тем выше шанс, что следующий серьезный инцидент начнется не с zero-day, а с «несущественной» роли, забытого токена и одной удачной сессии пользователя.