По последним данным статистики (данные W3Techs за 2025 год), в настоящий момент 43,1% сайтов в интернете работают на CMS Wordpress. Это самая массовая система управления содержимым. Этот факт автоматически делает эту CMS приоритетной целью для злоумышленников: широкое использование CMS дает возможности для массовых воспроизводимых атак при обнаружении любой уязвимости.
По статистике Wordfence за 2024 год, количество обнаруженных уязвимостей в плагинах и темах выросло на 68% год к году. Причём Wordfence фиксирует, что значимая доля уязвимостей длительное время остаётся непропатченной — в том числе из-за заброшенных расширений, которые администраторы нередко продолжают держать активными.
В практической жизни это выглядит очень просто: сегодня вы честно обновили ядро и главные плагины, а завтра выходит критический баг в каком-нибудь маленьком заброшенном модуле, модуль тихо продолжает работать, делая сайт уязвимым.
Под катом мы поговорим о WPScan — инструменте, которому, на мой взгляд, уделено незаслуженно мало внимания на Хабре — всего две статьи за все время, да еще в трёх-четырёх этот инструмент упоминается вскользь. Помимо освещения практического использования самого сканера, мы разберём куда более фундаментальные вопросы: как обстоит вопрос с уязвимостями в WP и как вообще строить процесс управления уязвимостями.
Введение. Ландшафт угроз и контекст
Пожалуй, начнем c контекста.
Любая уязвимость — это дефект или слабая точка в программном обеспечении, которую злоумышленник может использовать для нарушения конфиденциальности, целостности или доступности системы. В контексте WordPress это может быть всё: от XSS (чаще всего, 23% от общего числа уязвимостей), SQL-Injection (частенько) до RCE (редко, но тоже бывает). Поэтому регулярное обновление ядра и плагинов — это не «оптимизация», а жизненно важный элемент защиты. В целом, ситуация с уязвимостями в WP не сильно отличается от ситуации любого другого веб-приложения (с поправкой на массовость и открытость). В этом можно убедиться, посмотрев в базу данных уязвимостей Wordfence.
Варианты действий при обнаружении уязвимости на вашей инсталляции Wordpress тоже стандартны:
Применение исправлений (патчей) / Обновление системы. Это наиболее распространенный и эффективный способ устранения уязвимости. Он включает установку официальных обновлений от поставщика программного обеспечения, которые исправляют основную причину уязвимости.
Реализация временных мер по минимизации риска. Если немедленное применение патча невозможно (например, из-за необходимости тестирования или отсутствия готового исправления), можно использовать временные меры, чтобы усложнить эксплуатацию уязвимости. Они могут включать изменение конфигурации системы, отключение определенных функций или сервисов, ограничение сетевого доступа или, на худой конец, более пристальный мониторинг.
Отказ от эксплуатации сервиса или службы. Применяется, если использование двух предыдущих вариантов невозможно по каким-либо причинам.
Обновление, компенсирующие меры или вывод из эксплуатации — вот и всё, по большому счету. Да, в процессе обновления в энтерпрайзных средах учитываются ряд параметров: «трендовость» уязвимости, рейтинг CVSS, наличие эксплойта, вектор атаки (Attack Vector, AV) и т.д., но в сухом остатке — если публичный ресурс не обновляется, он рано или поздно будет скомпрометирован. К инсталляциям WP это относится в полной степени. Почему?
Рядовой Wordpress-сайт — это публичный ресурс в полном смысле этого слова, выставленный белым адресом в интернет и доступный из любой его точки по 443 (80). Интернет сегодня — место автоматизированных атак, где боты сканируют миллионы сайтов ежедневно, находя и эксплуатируя уязвимости без чьего-то ручного участия. В этом отчете Cloudflare есть весьма занимательная цитата:
«В четвёртом квартале 2024 года 98% HTTP-запросов к пути /wp-admin/ были частью DDoS-атак.»
Автоматизированные атаки не выбирают жертву по имени — они выбирают уязвимость. Таким образом, от такой атаки не застрахован ни любительский проект, ни веб-ресурс крупной организации.
Надо отметить, что вопреки расхожему мнению, Wordpress — это давно удел не только любительский: корпоративные истории среднего размера тоже достаточно часто крутятся именно на WP.
Так же как и везде, в компрометации веб-ресурсов на WP в большинстве случаев работает экономический принцип: «Если стоимость взлома ресурса выше выгоды от его компрометации, ресурс взламывать не будут».
Wordpress ломают постоянно, потому что:
стоимость взлома WordPress-сайта минимальна (эксплойты публичны, импланты типовые, процесс автоматизируется);
выгода — измеримая и стабильная (SEO-фарминг, фишинг, внедрение вредоносного JS, аренда «зомби-сайтов» спамерами, распространение вредоносов, создание фейковых магазинов);
поверхность атаки огромна (как уже писали выше, более 40% сайтов в мире используют WP, 99% из них — в публичной эксплуатации);
многие уязвимости в плагинах остаются не пропатченными месяцами. Пользователи чаще всего не понимают саму концепцию уязвимости и для чего требуются обновления. Многие WordPress инсталляции, например, подняты фрилансерами за небольшие деньги (или вообще бесплатно) и отданы в эксплуатацию без какой-либо поддержки.
Всё это делает экономически обоснованным даже взлом заброшенного лендинга в одну страницу. Если Wordpress-сайт является сервисом с серьезной посещаемостью — корпоративный сайт, СМИ и т.д. — всё становится ещё интересней.
Важно понимать, почему большинство уязвимостей возникает в плагинах, а не в ядре. Ядро WordPress развивается централизованно, проходит строгие код-ревью, аудит аппсеков и в целом весьма зрелое с точки зрения безопасности. Плагинов же — десятки тысяч. Фактически, это просто куски кода, которые разработаны разными авторами, с разным уровнем квалификации и с разной частотой обновлений.
Просто обновлять все плагины и темы — недостаточно. Обновления решают лишь те проблемы, о которых разработчики уже знают и которые уже исправлены. Но большинство успешных взломов WordPress происходит до момента обновления: то есть когда уязвимость только появилась, уже используется в автоматизированных атаках, но ещё не получила патч. Именно это «окно возможностей» и эксплуатируют ботнеты: по данным Wordfence, задержка между публикацией новой уязвимости и первыми массовыми атаками иногда составляет часы, а не недели.
Кроме того, администратор часто вообще не знает реального состояния сайта: какие плагины активны, какие давно несовместимы, какие темы оставлены на случай «как-нибудь позже удалим», какие компоненты видны злоумышленнику. WordPress этого не показывает в дашборде. Атака же начинается именно с этого — с перечня поверхностей и точек входа. Вот здесь и помогает WPScan: он определяет версии плагинов, тем и ядра, сверяет их с базой уязвимостей, показывает слабые места и даёт понять, где обновление критично, а где можно подождать, потому что риска нет.
Основная часть. Что такое WPScan и как использовать
Откуда вообще появился WPScan?
WPScan создали в 2011 — и, вероятно, он оказался весьма кстати. WordPress стремительно наращивал долю рынка, а инструментов для анализа его безопасности… почти не было. В ноябре 2021 года компания WPScan, к тому времени обладавшая собственной базой данных с более чем 23 000 уязвимостей, была приобретена Automattic, материнской компанией WordPress.
Что он умеет делать?
Сразу надо сказать, что WPScan — это не чистый сетевой сканер в том смысле, что и Nmap. WPScan — это L7 инструмент. Он не проверяет порты и не ищет сетевые уязвимости. Его цель — анализировать именно WordPress: структуру файлов, версии ядра, темы, плагины и соответствующие им уязвимости. С помощью WPScan можно решать несколько важных задач:
Определение WordPress. Инструмент проверяет структуру директорий и характерные ответы для определения версии инсталляции (и WP ли это вообще).
Перечисление компонентов. WPScan выявляет установленные плагины и темы, включая неактивные, но всё ещё лежащие в wp-content/. Также определяется версия ядра и список авторов (если это возможно по публичным данным).
Сопоставление с базой уязвимостей. То, о чем мы говорили выше. При наличии API-ключа WPScan отправляет данные на сервер и получает актуальные сведения о CVE, уровнях критичности и условиях эксплуатации. Без API-ключа эта часть работает ограниченно.
Состояние WP Cron.
Состояние XML-RPC.
Перечисление имен пользователей.
Найти пользователей со слабыми паролями (используется брутфорс).
Поиск данных экспорта из wp-config.php.
Как использовать?
Чтобы запустить установку, нужно ввести команду gem install wpscan (Rubi gem) или docker pull wpscanteam/wpscan (репо Docker). Также можно использовать Kali Linux, в которой WPScan предустановлен.
Базовая команда для проверки сайта выглядит так:
wpscan --url https://example.com \
--enumerate ap,at,u \
--api-token YOUR_API_KEY
Что происходит:
ap (All Plugins) — перечисляет все плагины.
at (All Themes) — перечисляет все темы.
u (Users) — перечисляет пользователей.
--api-token — ваш API-токен для доступа к базе уязвимостей WPScan. Токен позволяет получать сведения об известных уязвимостях. Без него WPScan будет работать, но без полной информации. WPScan не хранит всю базу локально — он запрашивает описание уязвимостей через API, и именно поэтому токен критичен. Бесплатного тарифа (25 запросов) обычно достаточно для ежедневного анализа одного сайта.
Сразу после запуска WPScan проверяет актуальность базы данных уязвимостей и при необходимости предлагает произвести обновление.
После выполнения команды в шелле будет примерно такой вывод:
Что он означает:
Interesting Finding — это не уязвимости. Пока это просто список того, что было замечено.
Раздел Headers на скриншоте — это вообще то, что и так сервер отдаёт любому браузеру при запросе. Но информация из этого раздела может быть использована для понимания, что это за сайт и как он используется. Например, WPScan сообщает, что в файле robots.txt в открытом доступе перечислены директории, связанные с WooCommerce.
Секция «[+] XML-RPC enabled» сообщает, что XML-RPC — стандартный компонент WordPress — включен. Сам по себе он не опасен, но в ряде сценариев может использоваться как точка входа.
[+] WordPress readme found сообщает, что файл README сайта публично доступен. После обнаружения его можно достать через wget или curl, но если там не содержатся чувствительные данные, достаточно безопасен. Обычно используется для определения версии Wordpress.
И все в таком духе. В примерах выше нет ни одной уязвимости. Самое интересное — это строки определения темы:
Theme: phlox
Latest Version: 2.17.7 (up to date)
up to date в данном случае означает, что у этой версии нет известных уязвимостей. WPScan определил тему, версию и проверил её состояние по базе. Если WPScan находит известную ему уязвимость, она попадает в раздел [+] Vulnerabilities.
Сканирование можно настроить определённым образом: более тихим или более агрессивным, широким или узким — в зависимости от задачи. Как и у традиционных сетевых сканеров, массовые запросы во время сканирования часто становятся причиной блокировки со стороны WAF. Поэтому в условиях «дикой природы» атакующий обычно заинтересован в том, чтобы сканировать цель максимально тихо и точечно. Для этого в WPScan можно использовать флаги --plugins-only и режим обнаружения passive. Например, --plugins-detection passive — тихий режим для определения версии плагинов, без агрессивных запросов. Документация рекомендует пассивный режим, чтобы обеспечить минимальную нагрузку на сервер.
По умолчанию во всех проверках используется режим mixed. При необходимости можно выставить как passive для большей тишины, так и aggressive, если стандартная проверка не дает результата.
Например, опция --wp-version-detection aggressive запускает агрессивный режим проверки версии ядра. Это полезно, если версия ядра скрыта или удалены метатеги.
Подробнее о различных настройках WPScan можно прочитать в документации на Гитхабе. В дополнение к ней здесь можно остановиться на некоторых неочевидных вещах.
Опция --random-user-agent, которая призвана помочь с обходом простых WAF, работает не так хорошо, как хотелось бы. В консоли WAF адрес-источник сканирования, вероятнее всего, все равно будет светиться, как новогодняя елка.
Но для защитников, это, безусловно, хорошая новость.
Весьма полезна опция --proxy, позволяющая направить трафик через прокси-сервер (например, Burp Suite) для аудита, чтобы понять глубже, какие запросы делает WPScan.
Чтобы избежать бана по rate-limit, используйте флаги --throttle и --max-threads. Да, длительность сканирования увеличится, но в конечном итоге сбор информации будет более эффективен. При флаге –throttle WPscan автоматически ставит --max-threads 1 и начинает делать заданную паузу между запросами.
wpscan --url https://example.com --throttle 500 --api-token XXX
Здесь пауза между запросами составит 500 миллисекунд.
Если стоит задача сканировать dev-инфраструктуру, то там часто только самоподписанные сертификаты. В этом случае требуется использовать команду --disable-tls-checks.
Место WPScan в процессе управления уязвимостями
Да, можно просканить сайт WPScan один раз, так сказать, просто поиграться. Но вообще-то у WPScan есть конкретное место в процессе обеспечения безопасности. В обычных условиях администратор получает информацию об уязвимости в лучшем случае после того, как обновление вышло, и в админке WP появится соответствующее предложение об обновлении. Но большинство взломов совершается до выхода официальных патчей. Не говоря уже о том, что при специфике плагинов WP-патч вообще может не появиться. Прямо сейчас, во время написания этой статьи (4 декабря) на Wordfence висит карточка RCE-уязвимости с CVSS 9.8. У плагина 5 176 скачиваний, время выхода последнего обновления — 3 года назад. Уязвимость опубликована почти месяц назад. Скорее всего, патча не будет, и это значит, что сайты с этим плагином будут экстремально уязвимы до тех пор, пока не примут меры самостоятельно.
Если бы администратор уязвимого сайта запустил WPScan, он бы показал: «Holiday Class Post Calendar — версия 7.1 — уязвимость RCE» . Это позволило ему вам принять решение: удалить плагин или использовать компенсирующие меры – например, сделать более строгие настройки на WAF.
Заключение
WordPress остаётся крупнейшей CMS в мире, и именно его массовость делает его удобной целью для автоматизированных атак. Поскольку WordPress не имеет встроенной подсистемы управления уязвимостями, панель плагинов не говорит ничего об уязвимостях явным образом, а отключённые плагины все еще опасны — такое решение крайне полезно для обеспечения безопасности сайта. Самое важное – он позволяет действовать проактивно, узнавая об уязвимостях плагина до выхода исправления, а также смотреть на конфигурацию WP «снаружи», глазами атакующего.