Австралийский центр кибербезопасности ACSC предупредил о глобальной кампании, в которой злоумышленники массово эксплуатируют уязвимости в CMS и плагинах, а затем ставят на сайты веб-шеллы. Для тех, у кого сайт компании до сих пор считается «просто витриной», новость неприятная: атаки на CMS снова работают как входная дверь не только к веб-серверу, но и дальше по инфраструктуре.
По данным BleepingComputer, под удар уже попали многие австралийские компании, прежде всего из сегмента малого и среднего бизнеса. В ACSC описывают схему без лишней драмы: атакующие сканируют сайты в поиске известных дыр, загружают веб-шелл и получают устойчивый доступ к скомпрометированному ресурсу. Дальше набор классический, но от этого не менее болезненный: кража учетных данных, размещение дополнительного вредоносного ПО, нарушение работы сервиса и попытки уйти глубже в сеть. Иными словами, речь не о дефейсе ради подросткового самолюбия, а о нормальной операционной модели для дальнейшего вторжения.
Самое полезное в этом предупреждении не общий тезис, а перечень конкретных точек входа. ACSC перечислил продукты и CVE, которые уже используются в кампании. В списке много WordPress-экосистемы: Simple File List с CVE-2025-34085 и CVE-2020-36847, WavePlayer с CVE-2025-12057, BerqWP с CVE-2025-7443, WPBookit с CVE-2025-7852, Ninja Forms с CVE-2026-0740, ThemeREX Addons с CVE-2026-1969, Breeze Cache с CVE-2026-3844, pay-uz с CVE-2026-31843, ACF Extended с CVE-2025-13486, Sneeit Framework с CVE-2025-6389, WPvivid Backup с CVE-2026-1357, Gravity Forms с CVE-2025-12352 и GutenKit/Hunk Companion, где, по оценке ACSC, вероятно используется CVE-2024-9234. Но WordPress в списке не одинок: отдельно названы Craft CMS с CVE-2025-32432, MaxSite CMS с CVE-2026-3395, MetInfo CMS с CVE-2026-29014 и Joomla JCE с CVE-2026-48907.
Это важный момент для разработчиков и IT-руководителей: атаки на CMS давно перестали быть историей только про «популярный WordPress». На практике страдает вся периферия вокруг контентных платформ: плагины, темы, дополнения, компоненты загрузки файлов, формы, кэширование, бэкапы. Там, где бизнес любит скорость запуска и удобство админки, обычно копится еще и технический долг. Лишний плагин «на всякий случай», забытый модуль, кастомная тема без владельца, отложенные обновления, доступ на запись в директории веб-сервера, резервные копии прямо в публичном контуре. В нормальные кварталы это просто раздражает архитектора. В такие недели это становится инцидентом.
Отдельно ACSC оговаривает, что кампанию может поддерживать ИИ. Агентство не приписывает атакующим какую-то магическую технологию и не строит апокалипсис вокруг трех букв, но мысль практичная: автоматизация помогает быстрее масштабировать поиск уязвимых сайтов и оперативнее встраивать свежие баги в поток эксплуатации. Для защитников это неприятная асимметрия. Пока одни компании согласуют окно на обновление плагина через две недели, другие уже получают автоматизированный перебор целей, где задержка в несколько дней превращается в достаточное условие для компрометации. В этом смысле ИИ здесь не герой сюжета, а ускоритель старой доброй гигиенической катастрофы.
Рекомендации ACSC звучат банально ровно до того момента, пока не открыть любой реальный реестр корпоративных сайтов. Агентство советует срочно ставить последние обновления для CMS, тем и плагинов, удалять неиспользуемые компоненты и по возможности включать автообновление. Из более инженерных мер названы перевод веб-директорий в режим только для чтения там, где это возможно, мониторинг несанкционированного создания файлов, ограничение доступа к чувствительным каталогам и блокировка неожиданных дочерних процессов на веб-сервере. Последний пункт особенно показателен: если веб-процесс внезапно начинает порождать то, чего он рождать не должен, спорить о приоритетах патч-менеджмента уже поздно.
Для русскоязычной IT-аудитории смысл новости не в том, что Австралия выпустила еще одно предупреждение. Смысл в том, что корпоративные сайты, промо-лендинги, кабинеты партнеров и региональные поддомены по-прежнему остаются самым недооцененным активом в контуре. Их часто отдают на аутсорс, редко инвентаризируют по-взрослому и почти никогда не подключают к тем же требованиям по телеметрии и контролю изменений, что внутренние бизнес-системы. А потом именно с них начинается неудобный разговор с безопасностью, эксплуатацией и руководством. Если у компании десятки веб-ресурсов на разных CMS, этот кейс стоит читать как повод не к переписке в чате, а к ревизии: что у нас опубликовано, кто за это отвечает, какие плагины стоят, где открыта запись, как отслеживаются новые файлы и кто вообще заметит веб-шелл до того, как он станет чьей-то точкой опоры.
Глобальные атаки на CMS вряд ли станут реже: слишком дешев вход, слишком много плохо обслуживаемых целей и слишком удобна экосистема плагинов, где один забытый модуль может оказаться короче всего пути к инциденту. Вопрос уже не в том, будут ли дальше массово эксплуатировать такие уязвимости, а в том, у кого сайт все еще числится маркетинговым активом, хотя для атакующего это давно часть инфраструктуры.