Атака на CDN затронула WordPress-плагины OptinMonster, TrustPulse и PushEngage, а у самого заметного из них, OptinMonster, заявлена база как минимум в 1,2 млн сайтов. Для разработчиков, владельцев интернет-магазинов и команд, которые привыкли доверять «официальному» JavaScript с внешних доменов, это неприятное напоминание: supply-chain атака больше не экзотика для npm и PyPI, она давно пришла в WordPress.
По данным BleepingComputer, злоумышленники скомпрометировали цепочку доставки скриптов через CDN компании Awesome Motive. В пятницу, 12 июня 2026 года, вредоносный JavaScript раздавался пользователям OptinMonster и TrustPulse в промежутке с 22:17 до 22:42 UTC. Для PushEngage инъекция продержалась дольше: до 19:02 UTC в субботу, 13 июня. Формально окно атаки короткое, но в таких историях проблема не в минутах раздачи, а в том, что последствия остаются на сайтах куда дольше, чем живет вредоносный файл на CDN.
Сценарий заражения был рассчитан не на обычного посетителя, а на администратора WordPress. Малварь срабатывала, когда админ открывал страницу зараженного сайта, забирала authentication tokens и nonces, после чего создавала поддельную учетную запись администратора. Дальше включалась уже знакомая механика закрепления: на сайт ставился скрытый backdoor-плагин, а данные отправлялись на домен, маскирующийся под сервис Tidio. По сути, компрометация внешнего скрипта превращалась в полный захват WordPress-инстанса: с веб-шеллом, удаленным доступом и возможностью исполнять произвольный PHP-код.
Отдельно неприятно то, как именно маскировался вредоносный плагин. По наблюдениям Sansec, оператор менял вывеску, но не логику: ранее бэкдор распространялся как Content Delivery Helper с идентификатором content-delivery-helper и версией 2.7.1, а затем как Database Optimizer с идентификатором database-optimizer и версией 2.9.4. Для админов WordPress это не новость, но хороший повод вспомнить старое правило: если на продакшене внезапно появился «полезный системный плагин», который никто не ставил, он почти наверняка не про оптимизацию базы.
Awesome Motive объяснила инцидент компрометацией сервера в своей среде через известную уязвимость в плагине UpdraftPlus. Этот сервер, по заявлению компании, не был связан с продакшн-инфраструктурой и системами хранения данных, зато на нем лежали учетные данные от CDN-аккаунта. Этого хватило: похитив CDN API key, атакующие подменили JavaScript-файлы, которые сайты загружали напрямую с доменов Awesome Motive. В списке затронутых файлов названы три адреса для OptinMonster — a.omappapi.com/app/js/api.min.js, a.opmnstr.com/app/js/api.min.js и a.optnmstr.com/app/js/api.min.js, а также a.trstplse.com/app/js/api.min.js для TrustPulse. Компания заявила, что уже устранила проблему на маркетинговом сайте, перенесла его на новый сервер и перевыпустила все credentials, включая ключ CDN API. При этом она отдельно подчеркивает: серверы приложений, исходный код и системы с данными аккаунтов OptinMonster и TrustPulse якобы не были взломаны.
Для рынка это важный нюанс. Мы снова видим не «лобовой» взлом основного продукта, а обходной путь через менее критичный контур, где хранились секреты, достаточные для атаки на цепочку поставки. И это как раз тот случай, который часто выпадает из приоритетов. Маркетинговый сайт, вспомогательный сервер, CDN-ключ, пара JavaScript-файлов на внешнем домене — по отдельности все выглядит второстепенно. В сумме получается компрометация тысяч сайтов с очень неприятным уровнем доступа. Если вы отвечаете за безопасность веб-продукта, история читается как короткая лекция о том, почему сегментация инфраструктуры без сегментации секретов работает не до конца.
Практический вывод для команд, которые используют WordPress в проде или для контентных проектов, довольно прямой. Если сайт мог подгружать затронутые скрипты в момент атаки на CDN, недостаточно просто обновить плагины и успокоиться. Нужно проверить, не появились ли на сайте посторонние админ-аккаунты developer_api1 или шаблонные dev_xxxxxx, просмотреть каталог wp-content/plugins на предмет скрытых или незнакомых расширений, прогнать серверное malware-сканирование и сменить чувствительные секреты: пароли админов, API-ключи, учетные данные базы данных и WordPress security salts. Иначе можно получить классическую иллюзию восстановления: зараженный JavaScript уже убрали, а доступ злоумышленника на сайте остался.
Для бизнеса тут тоже нет ничего академического. OptinMonster и родственные ему сервисы часто живут на коммерческих сайтах, лендингах, в e-commerce и воронках сбора лидов. Компрометация такого уровня означает не только риск дефейса или простоя, но и потенциальную подмену контента, внедрение дополнительной малвари, кражу сессий и удар по рекламным бюджетам. В экосистеме, где внешние скрипты подключаются почти автоматически, атака на CDN становится проблемой не только security-команды, но и маркетинга, продукта и тех, кто считает стоимость привлечения пользователя.
Самый неудобный вопрос после этого инцидента звучит просто: сколько еще внешних зависимостей на сайте считаются «безопасными по умолчанию» только потому, что они давно там лежат и никого не беспокоят. Атака на CDN в WordPress-стеке показывает, что следующая точка входа для злоумышленника может оказаться не в коде приложения и не в ядре CMS, а в сервисе рядом, который годами считался технической мебелью.