Исследователи воспользовались этим, прочитав /proc/self/mem и применив четыре регулярных выражения к доступным для чтения областям памяти. Так им удалось восстановить действующие STS-токены сессии AWS для роли IAM, связанной с функцией Lambda, полностью обойдя песочницу .
Восстановленная роль AWS называлась allow_nothing_role (роль «ничего не разрешено»), что вводило в заблуждение. На самом деле она обладала четырьмя разрешениями для сервиса Elastic Container Registry (ECR): ecr:DescribeRepositories, ecr:ListImages, ecr:BatchGetImage и ecr:GetDownloadUrlForLayer. Этих четырёх прав оказалось достаточно, чтобы выгружать образы контейнеров напрямую через API AWS, вообще не запрашивая токен аутентификации Docker-реестра. С их помощью исследователи перечислили 1111 продуктовых репозиториев и выгрузили образы контейнеров, используя API для получения слоёв .
Внутри одного из выгруженных образов контейнера исследователи обнаружили токен для публикации в NPM-реестре, который утёк в историю конфигурации образа. Токен был передан в процесс сборки через инструкцию Dockerfile ARG, которая навсегда сериализуется в неизменяемое поле history[] образа. Это означало, что токен мог извлечь любой, кто получал доступ к образу .
Найденный NPM-токен обладал тремя критическими свойствами: action: writename: nullbypass_2fa: truezapier-platform-core, zapier-platform-cli и zapier-design-system. Флаг bypass_2fa: true.
Самым критическим пакетом в цепочке оказался zapier-design-system — он загружается в каждой аутентифицированной сессии на сайте zapier.com. Исследователи подтвердили путь его загрузки через инструменты разработчика браузера и остановились на этом этапе — вредоносный пакет они не публиковали .
Если бы злоумышленник опубликовал отравленную версию, при следующем обновлении на сайте zapier.com выполнился бы контролируемый атакующим JavaScript внутри аутентифицированной сессии. С такой позиции атакующий мог бы создавать Zaps, таблицы и MCP-серверы, а также управлять существующими интеграциями через платформу от лица аутентифицированных пользователей. OAuth-токены и API-ключи подключённых сервисов остаются на серверной стороне и не были бы напрямую доступны в браузере, однако операционный ущерб мог бы оказаться крайне серьёзным .
Token Security направила отчёт 12 февраля 2026 года. Уже через четыре дня специалисты Zapier провели первичную оценку, отозвали скомпрометированный NPM-токен и ужесточили роль AWS. К 5 марта 2026 года устранение проблемы было подтверждено как полностью завершённое. Компания сообщила, что не обнаружила доказательств эксплуатации уязвимости в реальной среде .
Исследователи получили максимальное вознаграждение по программе в размере $3000, а Zapier обязалась пересмотреть «потолок» выплат при следующем аудите программы .
Важно отметить: это разглашение исследовательских данных — не то же самое, что реальная атака на цепочку поставок через NPM-аккаунт Zapier, произошедшая 24 ноября 2025 года. Тогда червь Shai Hulud 2.0 скомпрометировал учётную запись и заразил 425 пакетов .
Яир Балилти, руководитель группы исследований безопасности Token Security, сформулировал ключевой вывод:
«Каждое звено цепочки было известным паттерном. Сама уязвимость заключалась в их композиции, а композиция — это ровно то, что проваливается между командами. Песочница Lambda, ECR и IAM, токен GitLab CI, публикация в NPM, браузер — каждым из этих компонентов владеет своя группа, и каждая из них может посмотреть на свой кусок и резонно заключить, что всё в порядке. Риск проявляется лишь тогда, когда отслеживаешь путь сквозь все эти компоненты»
.
Вывод: ни одна отдельная команда не «владела» уязвимостью. Команда песочницы Lambda не видела проблемы в возможности чтения памяти — предполагалось, что токен в любом случае находится вне её периметра. Команда IAM видела роль с правами только на чтение ECR. CI/CD-команда передала NPM-токен как сборочный аргумент. Команда NPM управляла токеном с правами на запись. Команда браузерного интерфейса загружала дизайн-системный пакет. Каждое решение по отдельности было рациональным — но цепочка, выстроенная через все пять систем, оказалась катастрофической .
Это наглядно показывает: проверки идентификации и доступа должны отслеживать векторы атак через границы систем, а не аудировать разрешения каждого компонента изолированно. Организациям необходимы кросс-командные проверки безопасности, которые изучают, каким образом безобидные на первый взгляд конфигурации объединяются в опасные цепочки атак при взаимодействии систем .
Comments
0 comments