Взлом Apify вынудил чешскую платформу для веб-скрейпинга и браузерной автоматизации отозвать часть клиентских API-токенов, паролей прокси и внешних OAuth-подключений. Несанкционированный доступ продолжался 9 и 10 ноября 2026 года, а обнаружили его 11 ноября в 12:13 UTC; для разработчиков и компаний это очередное напоминание, что ключи интеграций и второй фактор — такие же активы, как пароль от облака.
По данным BleepingComputer, злоумышленник получил доступ к части внутренних систем Apify. Компания заявила, что остановила доступ атакующего, начала расследование и не нашла признаков компрометации данных аккаунтов, хранящихся на платформе. Это важная оговорка, но не индульгенция: при инциденте с внутренней инфраструктурой проверять нужно не только базы данных, но и всё, чем пользователи подключаются к сервису.
Apify уже сбросила активные сессии, перевыпустила критичные внутренние секреты и приступила к ротации API-токенов. В уведомлениях, которые видел BleepingComputer, говорится о замене затронутых Apify API tokens и паролей Apify Proxy. Для команд, у которых эти значения лежат в CI/CD, переменных окружения, секрет-хранилищах или скриптах выгрузки, это означает вполне прикладную работу: обновить секреты, перезапустить джобы и убедиться, что ночной сбор данных не превратился в тихую очередь ошибок.
Отдельная мера — отзыв OAuth-соединений со сторонними сервисами, включая GitHub. Apify объясняет решение осторожностью: затронутым пользователям обещают прислать письмо, когда подключение можно будет восстановить безопасно. Такой шаг болезненнее, чем простая смена токена: интеграции перестают работать сразу, а владельцам проектов приходится заново выдавать права. Зато компания сокращает риск, что скомпрометированное внутреннее окружение использует уже выданные доверенные сессии как обходной путь.
Почему компания просит сбросить второй фактор
Часть клиентов получила отдельное предупреждение о возможной компрометации кодов двухфакторной аутентификации. Пароли, по словам Apify, остаются в безопасности, однако пользователям рекомендуют заново настроить 2FA через консоль сервиса. Формулировка важна: речь не о массовом подтверждённом захвате аккаунтов, а о превентивной мере для тех, чьи данные второго фактора могли оказаться в зоне риска.
Для пользователей это не повод ограничиться нажатием кнопки сброса. После повторной настройки 2FA стоит проверить список активных сессий, журналы входов и права подключённых приложений, особенно если доступ к Apify разделяют несколько команд. Если API-токен был встроен в репозиторий, конфигурацию агента или старый сценарий автоматизации, его замена должна сопровождаться поиском прежнего значения во всех контурах. Новый ключ в панели сервиса мало помогает, если продакшен продолжает отправлять запросы со старым.
Apify — не нишевой сервис для пары энтузиастов. Платформа помогает разработчикам собирать данные с сайтов, поисковой выдачи и социальных сетей, а также автоматизировать работу браузера. На фоне бума генеративного ИИ спрос на такие инструменты вырос: компании используют собранные данные для мониторинга, аналитики, каталогов и задач, связанных с ИИ. Apify сообщает о 80 000 клиентах; среди названных самой компанией — Microsoft, Samsung, T-Mobile, Accenture, Siemens, Европейская комиссия и Roche.
Именно поэтому взлом Apify интересен шире сообщества веб-скрейпинга. Сервисы автоматизации часто занимают незаметное, но критичное место в технологическом стеке: они получают доступ к прокси, API, репозиториям, расписаниям задач и выгружаемым данным. Даже если данные аккаунтов не затронуты, инцидент вокруг секретов способен остановить пайплайны, нарушить отчётность и открыть дорогу к смежным системам через забытые интеграции.
Что проверить российским командам
Российским разработчикам и продуктовым командам, использующим Apify напрямую или через подрядчиков, стоит отнестись к письмам платформы как к задаче с приоритетом выше обычного обновления зависимости. Нужен короткий аудит: какие токены и пароли Apify используются, где они хранятся, какие GitHub- или другие OAuth-интеграции были подключены, какие процессы зависят от прокси. Полезно заранее назначить владельца каждого секрета — иначе после ротации начинается знакомая игра «у кого был доступ к этой переменной в старом проекте».
Для руководителей разработки здесь есть и организационный вывод. Автоматическая ротация секретов, централизованное хранилище ключей и минимальные права для интеграций обычно кажутся инфраструктурной гигиеной, которую можно отложить до следующего квартала. Инциденты у внешних поставщиков быстро превращают эту гигиену в стоимость простоя. Чем меньше сервисных ключей живёт в репозиториях, чатах и локальных файлах сотрудников, тем короче и дешевле будет реакция на чужой взлом.
Apify пока не раскрыла технический путь проникновения и полный масштаб затронутых систем. Главный вопрос теперь не только в том, подтвердится ли отсутствие доступа к пользовательским данным, но и насколько прозрачно сервис объяснит причину инцидента после расследования. Для рынка автоматизации это ещё один тест: клиентам нужны не только удобные API для сбора данных, но и понятный сценарий, что происходит с их ключами и интеграциями в первые часы после атаки.
