| Имя плагина | hiWeb Миграция Простая |
|---|---|
| Тип уязвимости | Межсайтовый скриптинг (XSS) |
| Номер CVE | CVE-2026-2425 |
| Срочность | Середина |
| Дата публикации CVE | 2026-06-02 |
| Исходный URL-адрес | CVE-2026-2425 |
Срочно: Отраженная XSS у hiWeb Migration Simple (≤ 2.0.0.1) — Что владельцам сайтов на WordPress нужно сделать сейчас
Автор: Команда безопасности WP-Firewall
Дата: 2026-06-02
Теги: WordPress, Уязвимость, XSS, WAF, Безопасность
Краткое резюме: В плагине WordPress “hiWeb Migration Simple” версии <= 2.0.0.1 была обнаружена уязвимость отраженного межсайтового скриптинга (XSS) (CVE-2026-2425). Она может быть использована неаутентифицированными злоумышленниками и имеет среднюю степень серьезности (CVSS 7.1). Хотя для эксплуатации требуется взаимодействие с пользователем (клик по созданной ссылке или посещение вредоносной страницы), последствия могут включать кражу сессий для администраторов, несанкционированные действия и манипуляции с контентом на уровне сайта. В отсутствие официального патча от поставщика на момент сообщения, настоятельно рекомендуется немедленное смягчение и виртуальное патчирование через WAF.
Оглавление
- Обзор: что произошло
- Что такое отраженный XSS и почему это важно для WordPress
- Техническое резюме этой уязвимости (CVE-2026-2425)
- Сценарии угроз и реальное воздействие
- Как определить, затронуты ли вы или подвергаетесь атаке
- 12. Примите эти меры прямо сейчас, чтобы уменьшить риски, ожидая официального исправления:
- Промежуточные и долгосрочные решения (руководство для разработчиков)
- Примеры правил WAF и стратегии виртуального патчирования
- Контрольный список реагирования на инциденты: если вы подозреваете компрометацию
- Контрольный список по укреплению безопасности для сайтов на WordPress
- Как WP‑Firewall защищает ваш сайт (управляемый WAF и виртуальное патчирование)
- Начните защищать свой сайт сегодня (бесплатный план WP‑Firewall)
- Заключительные заметки и ресурсы
Обзор: что произошло
2 июня 2026 года была публично раскрыта уязвимость отраженного XSS, затрагивающая плагин WordPress “hiWeb Migration Simple” (версии до и включая 2.0.0.1) и присвоен CVE‑2026‑2425. Уязвимость позволяет злоумышленнику создать URL, который включает вредоносные скрипты, отражаемые плагином и выполняемые в контексте браузера жертвы. Уязвимость может быть использована неаутентифицированными злоумышленниками, но требует взаимодействия с пользователем — обычно администратор или другой привилегированный пользователь должен кликнуть по созданной ссылке или посетить страницу, контролируемую злоумышленником.
Хотя отраженный XSS не является проблемой выполнения кода на стороне сервера, он остается крайне опасным в WordPress, поскольку может быть связан с другими атаками (кража сессий, выполнение действий от имени администратора, внедрение задних дверей или распространение вредоносного ПО). Учитывая относительно высокий балл CVSS и широкое использование плагинов в различных хостинговых средах, владельцы сайтов должны рассматривать это как высокоприоритетное для смягчения до тех пор, пока не станет доступен официальный патч от поставщика.
Что такое отраженный XSS и почему это важно для WordPress
Отраженный XSS возникает, когда веб-приложение (или плагин) принимает вводимые пользователем данные — обычно из параметров URL или форм — и включает их в HTTP-ответ без надлежащего кодирования или очистки. Когда ответ содержит скриптируемый контент и браузер жертвы выполняет его, злоумышленник может запускать JavaScript в контексте сессии аутентифицированного пользователя.
Почему это важно для WordPress:
- Роль администратора WordPress имеет мощные возможности. Если полезная нагрузка отраженного XSS выполняется в контексте администратора, злоумышленник может потенциально украсть куки или нонсы, выполнять административные задачи через поддельные запросы или создавать вредоносные посты/плагины.
- На сайтах WordPress часто установлено много сторонних плагинов и тем; один уязвимый плагин является привлекательным вектором для массовой компрометации.
- Отраженный XSS может быть использован как трамплин для постоянной компрометации (например, злоумышленник использует XSS для установки задней двери).
Несмотря на то, что уязвимость требует взаимодействия с пользователем, злоумышленники регулярно используют фишинг, социальную инженерию или автоматизированные массовые рассылки/комментарии с созданными URL, чтобы заманить администраторов сайтов к клику. Из-за этого отраженный XSS должен быть смягчен незамедлительно.
Техническое резюме этой уязвимости (CVE‑2026‑2425)
- Класс уязвимости: Отраженный межсайтовый скриптинг (XSS)
- Затронутое программное обеспечение: Плагин WordPress “hiWeb Migration Simple”
- Уязвимые версии: <= 2.0.0.1
- CVE: CVE‑2026‑2425
- Репортер: исследователь безопасности, известный как “san6051 (COFFSec)”
- Необходимые привилегии: Неаутентифицированный (посетитель может предоставить подготовленный ввод)
- Взаимодействие с пользователем: Требуется (жертва должна кликнуть на вредоносную ссылку или посетить подготовленную страницу)
- Базовый балл CVSS v3.1: 7.1 (Средний)
- Статус патча (на момент отчета): Официальный патч недоступен
- Типичный вектор атаки: подготовленный URL или ввод формы, содержащий JavaScript, который плагин отражает в выводе страницы без надлежащего кодирования
Важный: Уязвимость отраженная, а не сохраненная. Это означает, что вредоносный скрипт появляется только в ответе, исходящем от подготовленного запроса. Но это все равно позволяет атакам, нацеленным на аутентифицированных пользователей, которые обрабатывают этот запрос (например, сотрудники администраторов, кликающие по ссылкам в электронной почте).
Сценарии угроз и реальное воздействие
Вот вероятные сценарии атак, которые злоумышленники могут использовать, если уязвимость не будет устранена:
- Фишинг или целенаправленная социальная инженерия против администраторов сайта
Злоумышленник подготавливает URL, содержащий полезную нагрузку, и отправляет его администратору сайта (например, по электронной почте, в чате или комментарии). Если администратор нажимает на ссылку, будучи в системе, внедренный скрипт может выполняться с его привилегиями сессии. - Массовые попытки эксплуатации
Автоматизированные сканеры ищут в интернете наличие плагина и пытаются использовать общие шаблоны отраженного XSS. Любой администратор, который случайно нажмет на вредоносно сформированный результат поиска или ссылку, может пострадать. - Кража сессий и захват аккаунта
Злоумышленник может эксфильтровать куки или токены аутентификации (если они неправильно настроены) и попытаться захватить сессию администратора. Куки с флагом HTTPOnly уменьшают риск прямой кражи, но XSS все равно может использовать потоки на основе DOM для выполнения действий с использованием административных nonce или путем выполнения запросов. - Внедрение вредоносных действий администратора
Скрипт может отправлять аутентифицированные запросы (через AJAX или POST формы), пока сессия администратора активна. Это может привести к изменениям в параметрах сайта, загрузке плагинов/тем, созданию пользователей или внедрению задних дверей. - Ущерб репутации и SEO
Злоумышленники могут внедрять спам, рекламу или перенаправления, что приводит к штрафам SEO, внесению в черные списки или потере доверия посетителей.
Учитывая эти возможные последствия, отраженный XSS должен быть быстро устранен, даже если эксплуатация требует клика.
Как определить, затронуты ли вы или являетесь целью
Обнаружение - это комбинация автоматического сканирования и ручного обзора.
- Определите, установлен ли плагин и уязвим ли он
На странице плагинов админки WordPress найдите “hiWeb Migration Simple” и подтвердите номер версии. Если он <= 2.0.0.1, считайте его уязвимым. - Веб-сервер и журналы доступа
Look for GET requests that include suspicious query strings with script-like content or unusual parameters. Examples: requests with encoded characters like %3Cscript or high rates of unusual URLs targeting plugin endpoints.
Проверьте заголовки referer на наличие фишинговых страниц или внешних рефереров. - Логи консоли браузера (если вы можете воспроизвести)
При попытке воспроизвести подозреваемую отраженную нагрузку в безопасной тестовой среде наблюдайте, отображается ли нагрузка и выполняется ли она. Не тестируйте на рабочем сайте с живыми пользователями. - Инструменты сканирования сайта
Используйте авторитетный сканер для обнаружения отражения XSS в конечных точках плагина. Тем не менее, сканеры могут генерировать ложные срабатывания; всегда проверяйте вручную на копии, не предназначенной для производства. - Проверки файловой системы и базы данных (чтобы исключить постоянный компромисс)
Хотя это проблема отражения (непостоянная), злоумышленники часто сочетают XSS с установками задних дверей. Используйте сканер вредоносного ПО для поиска измененных основных файлов, неизвестных плагинов/тем или подозрительных администраторов. - Активность учетной записи администратора
Проверьте журналы пользователей, недавние изменения и редактирование постов, чтобы убедиться, что не было несанкционированных изменений.
Если вы обнаружите индикаторы эксплуатации (неожиданные изменения, подозрительные действия администраторов), предположите компрометацию и следуйте разделу «Ответ на инциденты» ниже.
12. Примите эти меры прямо сейчас, чтобы уменьшить риски, ожидая официального исправления:
Если ваш сайт использует уязвимый плагин и вы не можете немедленно применить официальный патч (или он еще не доступен), выполните следующие немедленные шаги, в порядке от быстрого воздействия к более постоянной защите:
- Удалите или деактивируйте плагин (самый быстрый и безопасный способ)
Если вы не строго нуждаетесь в плагине, немедленно деактивируйте и удалите его. Устранение поверхности атаки - это самое быстрое смягчение. - Ограничьте доступ к конечным точкам плагина
Если вы должны оставить плагин активным (для функциональности), ограничьте доступ к его административным страницам через белый список IP или ограничив доступ к аутентифицированным ролям администраторов за слоем контроля доступа (например, HTTP-аутентификация для wp-admin или страниц администрирования плагина). - Примените виртуальный патч веб-приложения (WAF)
Разверните правила WAF, которые блокируют запросы, содержащие теги скриптов или подозрительные шаблоны ввода в параметрах запроса и формах. Управляемый WAF может быстро внедрять целевые правила и снижать количество ложных срабатываний. - Укрепить доступ администратора
Применяйте строгие административные меры: используйте надежные пароли, включите двухфакторную аутентификацию (2FA) для всех административных учетных записей и ограничьте количество пользователей с правами администратора. - Очищайте исходящий HTML на административных экранах.
Если у вас есть ресурсы разработчика, перехватывайте и очищайте конкретные пути вывода, которые использует плагин. Кодируйте вывод и фильтруйте опасные символы. - Политика безопасности контента (CSP)
Используйте ограничительную CSP на маршрутах wp-admin, чтобы предотвратить выполнение встроенных скриптов и ограничить разрешенные источники скриптов. Обратите внимание, что CSP необходимо реализовывать осторожно, чтобы не нарушить законную функциональность администратора. - Мониторинг и оповещение
Увеличьте мониторинг административных конечных точек и настройте оповещения о необычных запросах или изменениях. - Сообщите вашей команде
Уведомите администраторов и сотрудников быть осторожными с ссылками и вложениями в электронных письмах, пока плагин присутствует и уязвим.
Промежуточные и долгосрочные решения (руководство для разработчиков)
Если вы поддерживаете сайт или разрабатываете плагины/темы, стремитесь к лучшим практикам безопасного кодирования для предотвращения XSS:
- Кодирование вывода, а не фильтрация ввода.
Для отраженного XSS правильный подход — применять контекстно-зависимое кодирование вывода. Используйте функции экранирования, соответствующие контексту:- Контекст HTML: экранируйте с помощью
esc_html() - Контекст атрибута: экранируйте с помощью
esc_attr() - JavaScript контекст: используйте
wp_json_encode()или подходов кодирования JSON. - Контекст URL: используйте
esc_url()
- Контекст HTML: экранируйте с помощью
- Избегайте вывода необработанных данных строки запроса.
Никогда не выводите сырые$_GET/$_POSTзначения напрямую. Используйте строгую валидацию и экранирование. - Используйте nonce WordPress и проверки прав.
Проверьте возможности (текущий_пользователь_может()) и nonce для административных действий, чтобы предотвратить CSRF и действия на основе аутентифицированного XSS. - Дизайн с минимальными привилегиями
Убедитесь, что страницы администратора плагина и конечные точки AJAX разрешают доступ только пользователям с соответствующими правами. - Очищайте богатый контент.
Когда плагины принимают богатый текст, полагайтесь на KSES или аналогичные библиотеки для удаления опасных тегов или атрибутов. - Добавьте модульные и интеграционные тесты
Включите автоматизированные тесты, которые подтверждают, что ни один пользовательский HTML или скрипт не появляется неочищенным в ответах. - Ответственное раскрытие и механизмы обновления
Предоставьте четкие пути обновления и уведомления о безопасности в плагинах, чтобы администраторы могли получать своевременные исправления.
Если вы автор плагина, приоритизируйте выпуск исправленной версии плагина, которая правильно кодирует вывод, и, желательно, верните исправления для широко используемых старых веток.
Примеры правил WAF и стратегии виртуального патчирования
В ситуациях, когда патч от поставщика еще не существует, виртуальная патчинг через WAF или управляемый брандмауэр является самым безопасным путем при сохранении функциональности. Ниже приведены образцы концептуальных правил — не рассматривайте их как исчерпывающие. Реализуйте и тестируйте осторожно, чтобы избежать блокировки легитимного трафика.
Важное примечание: Избегайте слишком широких правил (например, блокировка всех параметров запроса с помощью “”), так как многие легитимные клиенты или интеграции могут использовать закодированный контент. Используйте целевые правила для известных уязвимых конечных точек.
- Концептуальное правило ModSecurity для обнаружения общих отраженных XSS-шаблонов в строках запроса
# Пример ModSecurity (концептуальный) - настройте и протестируйте перед использованием"
- Ограничьте вредоносные символы только в конкретных конечных точках плагина
# Only apply to plugin admin endpoint /wp-admin/admin.php?page=hiweb-migration
SecRule REQUEST_URI "@contains /wp-admin/admin.php" "phase:1,chain,id:100002,pass,ctl:ruleRemoveById=981176"
SecRule ARGS "page=hiweb-migration" "chain"
SecRule ARGS "(%3Cscript|<script|on\w+\s*=|document\.cookie|window\.location)" "deny,status:403,msg:'Reflected XSS pattern in hiWeb Migration Simple endpoint'"
- Блокируйте закодированные полезные нагрузки с высокой энтропией или подозрительные кодировки
- Многие атакующие полезные нагрузки имеют необычные кодировки и повторяющуюся процентную кодировку. Обнаруживайте и блокируйте очень длинные параметры запроса с множеством закодированных символов или подозрительных последовательностей.
- Сначала используйте положительные правила (белый список)
- Если конечные точки плагина ожидают небольшой набор параметров/значений, обеспечьте белый список приемлемых шаблонов и типов для этих параметров.
- Добавьте ограничение скорости и проверки репутации IP
- В сочетании с правилами контента, ограничения скорости (например, 5 попыток в минуту на IP на конечных точках плагина) могут снизить автоматизированное массовое сканирование.
- Ведение журнала и оповещение
- Убедитесь, что заблокированные события регистрируются с достаточным контекстом (IP клиента, пользовательский агент, URL запроса) и интегрируйте с вашим SIEM/мониторингом.
Если вы используете управляемый/хостинг WAF-сервис, проверьте виртуальный патч в тестовой среде перед развертыванием в производственной среде. Предоставьте варианты отката в случае ложных срабатываний.
Контрольный список реагирования на инциденты: если вы подозреваете компрометацию
Если вы видите признаки эксплуатации, следуйте организованному ответу:
- Содержать
Временно отключите уязвимый плагин или активируйте режим обслуживания.
Если возможно, блокируйте IP-адреса атакующих и известных вредоносных агентов через брандмауэр. - Сохраняйте доказательства
Сделайте копию журналов (веб-сервера, приложения, WAF) для судебного анализа.
Создайте снимок файлов сайта и базы данных перед внесением изменений. - Искоренить
Удалите вредоносных пользователей, задние двери или внедренный код.
Замените измененные файлы ядра/плагинов/тем на чистые версии из официальных источников. - Восстанавливаться
Восстановите данные из чистой резервной копии, если она доступна.
Смените все пароли администраторов и FTP/хостинга, API-ключи и токены. - Обзор после инцидента
Проверьте, как злоумышленник получил доступ.
Укрепите контроль, чтобы сделать подобные эксплуатации более сложными в будущем. - Уведомить заинтересованных лиц
Проинформируйте членов команды и, если необходимо, клиентов, которые могли быть затронуты. - Монитор
Поддерживайте повышенный мониторинг подозрительного трафика и любого повторного появления внедренного контента.
Если вы не уверены в глубине нарушения, привлеките профессиональную команду по реагированию на инциденты с опытом работы с WordPress.
Контрольный список по укреплению безопасности для сайтов WordPress (практические шаги)
Выполняйте это в рамках регулярного обслуживания безопасности сайта:
- Поддерживайте ядро WordPress, темы и плагины в актуальном состоянии.
- Ограничьте количество администраторов. Используйте специфические роли с ограниченными правами, где это возможно.
- Используйте двухфакторную аутентификацию (2FA) для всех учетных записей администраторов.
- Применяйте надежные пароли и периодически меняйте их.
- Регулярно создавайте резервные копии файлов сайта и базы данных (храните резервные копии вне сайта).
- Запускайте запланированные сканирования на вредоносное ПО и проверки целостности файлов.
- Укрепите wp-config.php (переместите в не корневую папку веба, где это возможно, установите правильные разрешения на файлы).
- Отключите XML-RPC, если он не нужен.
- Реализуйте принцип наименьших привилегий в разрешениях на файлы (избегайте 777).
- Используйте безопасный транспорт (TLS/HTTPS) с заголовком HSTS для страниц администратора.
- Установите куки на HTTPOnly и SameSite=strict, где это возможно.
- Используйте политику безопасности контента (CSP) для административных страниц, чтобы ограничить выполнение встроенных скриптов.
- Используйте веб-приложение брандмауэр с возможностями виртуального патча для быстрого смягчения.
Ни одно отдельное средство не является универсальным решением — многослойная защита снижает общий риск.
Как WP‑Firewall защищает ваш сайт
В WP‑Firewall мы применяем подход защиты в глубину, адаптированный для WordPress. Пока разработчики и владельцы сайтов занимаются исправлением кода, наш управляемый брандмауэр и услуги обеспечивают быструю, практическую защиту, предназначенную для снижения риска, пока вы исправляете или заменяете уязвимые компоненты.
Ключевые меры защиты, которые мы применяем и которые непосредственно относятся к сценариям отраженного XSS:
- Управляемый брандмауэр веб-приложений (WAF)
Мы развертываем целевые виртуальные патчи для известных уязвимостей и быстро блокируем известные схемы эксплуатации на границе, прежде чем запросы достигнут вашего сайта. - Правила с учетом контекста
Правила WAF применяются выборочно к уязвимым конечным точкам плагинов, чтобы минимизировать ложные срабатывания и избежать нарушения легитимного трафика. - Сканирование на наличие вредоносного ПО и мониторинг контента.
Непрерывное сканирование тем, плагинов и загрузок для обнаружения подозрительных изменений или внедренного кода. - Контроль поведения и ограничения по скорости
Блокирует массовое сканирование и методы грубой силы, которые часто предшествуют попыткам эксплуатации. - Уведомление и отчетность о инцидентах
Немедленные уведомления о заблокированных атаках, а также журналы и контекст для судебно-медицинского анализа. - Рекомендации по лучшим практикам безопасности
Наша команда помогает клиентам приоритизировать исправление, усиление и восстановление.
Если вы предпочитаете не удалять необходимый плагин немедленно, управляемый WAF с виртуальным патчем дает вам возможность исправить без отключения вашего сайта.
Начните защищать свой сайт сегодня с бесплатного плана WP‑Firewall
Если вы хотите немедленную базовую защиту, пока проверяете патчи или удаляете уязвимые плагины, наш базовый бесплатный план — отличный способ начать. Он предоставляет основные меры защиты, которые блокируют распространенные методы атак и снижают вашу уязвимость во время инцидентов, таких как раскрытие простого XSS при миграции hiWeb.
- Базовый (бесплатно): Основная защита — управляемый брандмауэр, неограниченная пропускная способность, WAF, сканер вредоносного ПО и смягчение рисков OWASP Top 10.
- Стандарт ($50/год): Все базовые функции плюс автоматическое удаление вредоносного ПО и возможность заносить в черный/белый список до 20 IP-адресов.
- Pro ($299/год): Добавляет ежемесячные отчеты по безопасности, автоматическую виртуальную патчинг уязвимостей и доступ к премиум-дополнениям, таким как выделенный менеджер аккаунта и управляемая служба безопасности.
Начните с бесплатного плана WP‑Firewall сейчас и получите немедленную защиту, пока вы планируете свои меры по устранению: https://my.wp-firewall.com/buy/wp-firewall-free-plan/
(Если вам нужна поддержка для тестирования виртуальных патчей или настройки целевых правил для плагина hiWeb, наша команда может помочь с быстрой разверткой и настройкой, чтобы минимизировать сбои в бизнесе.)
Контрольный список разработчика: изменения, которые необходимо внести в код уязвимого плагина
Если вы поддерживаете или разрабатываете плагин, который был признан уязвимым, выполните следующие конкретные шаги:
- Определите уязвимые точки выхода
Найдите места, где вы выводите пользовательский ввод в ответах (особенно на страницах администратора и конечных точках AJAX). - Применяйте кодирование вывода в зависимости от контекста
Для содержимого HTML-тела: используйтеesc_html()
Для значений атрибутов: используйтеesc_attr()
Для URL-адресов: используйтеesc_url_raw()/esc_url()
Для данных JavaScript: используйтеwp_json_encode()и встроенный JS, безопасно предоставленный в виде структурированных данных - Проверяйте и нормализуйте вводимые данные
Определите ожидаемые типы и значения данных. Отклоняйте или очищайте ввод, который не соответствует строгой схеме. - Используйте проверки возможностей и нонсы
Подтвердите, что вызывающий пользователь может выполнять запрашиваемые действия; используйтеcheck_admin_referer()илиwp_verify_nonce()соответственно. - Предоставьте уведомление о безопасности и график выпуска
Четко сообщайте пользователям о проблеме, затронутых версиях и рекомендуемых шагах по устранению. - Поощряйте быстрые обновления через WordPress.org или прямые каналы обновления
Убедитесь, что исправленный плагин распространяется через стандартные каналы обновления, чтобы администраторы автоматически получали обновление.
Часто задаваемые вопросы (FAQ)
В: Если отраженный XSS требует клика пользователя, является ли это низким риском?
А: Не обязательно. Администраторы или редакторы могут стать целью фишинга, и один клик может привести к краже сессии, изменениям на сайте или установке вредоносного ПО. Рассматривайте это как средний-высокий операционный риск.
В: Может ли политика безопасности контента полностью предотвратить XSS?
А: CSP является мощной мерой смягчения, но должна быть правильно настроена. Она снижает влияние XSS, но не является заменой правильному кодированию и экранированию вывода.
В: Могу ли я оставить плагин и полагаться на брандмауэр?
А: Да, управляемый WAF с виртуальным патчингом может быть эффективной временной мерой. Однако лучшее решение — установить патч от поставщика или заменить плагин, как только появится безопасная альтернатива.
В: Как скоро мне следует действовать?
А: Действуйте немедленно. Окно для атакующих широко: автоматизированные сканеры и оппортунистические атакующие часто используют известные уязвимости плагинов в течение нескольких часов после раскрытия.
Заключительные замечания и рекомендуемые дальнейшие шаги
- Проверьте ваш сайт на наличие “hiWeb Migration Simple”. Если установлен и версия <= 2.0.0.1, примите немедленные меры.
- Если можете, удалите или деактивируйте плагин, пока не станет доступна безопасная версия. Если не можете, примените строгие контроль доступа + виртуальный патчинг WAF.
- Укрепите защиту администраторов (2FA, надежные пароли, ограниченное количество пользователей).
- Увеличьте мониторинг и сделайте резервные копии перед внесением изменений.
- Рассмотрите возможность использования управляемого WAF-сервиса для быстрого применения виртуальных патчей, пока готовятся исправления от разработчиков.
Безопасность — это командная работа. Разработчики должны исправлять код; администраторы должны управлять уязвимостями; а службы безопасности (такие как WP‑Firewall) могут помочь сократить окно риска с помощью виртуального патчинга и управляемых правил. Если вам нужна помощь в получении немедленной защиты или помощь с индивидуальными правилами WAF, наша команда в WP‑Firewall готова помочь.
Берегите себя — и действуйте быстро.
— Команда безопасности WP‑Firewall
