| Имя плагина | Система поддержки тикетов WooCommerce |
|---|---|
| Тип уязвимости | Произвольное удаление файла |
| Номер CVE | CVE-2026-32522 |
| Срочность | Высокий |
| Дата публикации CVE | 2026-03-22 |
| Исходный URL-адрес | CVE-2026-32522 |
Срочно: Произвольное удаление файлов в плагине “Система поддержки тикетов WooCommerce” (< 18.5) — что владельцы сайтов на WordPress должны сделать прямо сейчас
20 марта 2026 года было опубликовано публичное уведомление о неаутентифицированное произвольное удаление файла уязвимости, затрагивающей плагин Системы поддержки тикетов WooCommerce (версии до 18.5). Проблема отслеживается как CVE-2026-32522 и имеет высокий уровень серьезности (CVSS 8.6). Уязвимость позволяет злоумышленнику удалять файлы на веб-сервере без аутентификации — возможность, которую злоумышленники любят, потому что она может сломать сайты, удалить судебные следы или очистить журналы, чтобы скрыть последующую активность.
Если вы используете WordPress и этот плагин (или управляете сайтами для клиентов), отнеситесь к этому как к критически важному. Этот пост объясняет, с точки зрения безопасности WordPress и поставщика веб-приложений брандмауэра (WAF), что такое уязвимость, как ее можно использовать в больших масштабах, как обнаружить возможную эксплуатацию и практические меры по смягчению — включая немедленное виртуальное исправление и долгосрочные шаги по укреплению, которые вы можете применить уже сегодня.
Примечание: этот пост написан с точки зрения команды безопасности WP‑Firewall с практическими, экспертными рекомендациями. Он не включает код эксплуатации или пошаговые инструкции, которые могли бы помочь злоумышленникам.
Краткое резюме (TL;DR)
- Уязвимость: Произвольное удаление файлов (без аутентификации).
- Затронутые версии: версии плагина < 18.5.
- Исправленная версия: 18.5 (обновите немедленно).
- Риск: Высокий (CVSS 8.6). Злоумышленники могут удалять основные файлы, ресурсы плагинов/тем, загрузки или другие файлы, доступные через веб — потенциально выводя сайты из строя или удаляя улики.
- Немедленно рекомендуемые действия:
- Обновите плагин до версии 18.5 или выше на всех сайтах.
- Если обновление невозможно немедленно, отключите плагин до исправления.
- Примените виртуальное исправление на основе WAF, чтобы заблокировать попытки эксплуатации (мы предоставляем рекомендуемые стратегии правил ниже).
- Проверьте журналы и резервные копии, подготовьте реагирование на инциденты, если вы обнаружите подозрительные удаления.
- Если ваш сайт управляется агентством или хостингом, немедленно сообщите им.
Что означает “произвольное удаление файлов” в этом контексте
“Произвольное удаление файлов” относится к уязвимости, при которой злоумышленник может заставить приложение удалить файлы, выбранные злоумышленником. В плагинах WordPress это обычно происходит, когда:
- Плагин открывает функцию удаления файлов на стороне сервера (например, unlink(), rm, удаление файловой системы), которая принимает имя файла/путь, предоставленные пользователем.
- Функция не имеет надлежащего контроля доступа (нет аутентификации, авторизации или проверки прав).
- Ввод недостаточно проверяется или очищается, что позволяет выполнять обход каталогов или использовать абсолютные пути.
- Плагин не проверяет, находится ли целевой файл в ожидаемом каталоге (отсутствуют проверки канонизации).
Поскольку уязвимость в этом уведомлении описана как “неаутентифицированная”, злоумышленнику не нужны действительные учетные данные WordPress для инициирования удаления — вероятность массовой эксплуатации высока.
Вероятная коренная причина (техническая, но краткая)
Основываясь на характеристиках уведомления, коренная причина почти наверняка заключается в публичной конечной точке или AJAX-действии, которое выполняет удаление файла с использованием параметра имени файла/пути, предоставленного через HTTP (GET/POST). Код на стороне сервера, вероятно:
- Открывает действие (например, через admin-ajax.php или пользовательскую конечную точку), которое вызывает процедуру удаления.
- Принимает параметр, такой как
файл,имя файла,путь, илиидентификатор_вложения(или даже закодированное значение). - Не проверяет, аутентифицирован ли пользователь и/или авторизован.
- Не нормализует путь, чтобы убедиться, что он находится в разрешенном каталоге (например, папка загрузки плагина).
- Не применяет белый список разрешенных имен файлов или расширений.
Эта комбинация дает злоумышленникам возможность удалять произвольные файлы, часто через строки обхода каталогов или абсолютные пути.
Что могут сделать злоумышленники (реалистичные сценарии атак)
- Удалить основные файлы WordPress (например, wp-config.php, основные PHP файлы), чтобы сломать сайт, вызвав простой.
- Удалить файлы плагинов или тем, чтобы отключить средства безопасности или задние двери.
- Стереть журналы или судебные артефакты (например, журналы доступа/ошибок, журналы плагинов), что усложняет обнаружение.
- Стереть медиа/загрузки (изображения, счета, резервные копии, хранящиеся в корне веб-сайта) — что приводит к потере данных.
- Изменить файлы сайта для подготовки к дальнейшим атакам (например, отключить защиту, затем загрузить заднюю дверь).
- Совместить удаление с программами-вымогателями или тактиками вымогательства: сломать сайт и потребовать оплату.
Поскольку уязвимость не требует аутентификации и легко автоматизируется, злоумышленники часто сканируют веб для поиска уязвимых плагинов и отправляют запросы на удаление в большом количестве.
Кто находится в зоне риска?
- Любой сайт WordPress с версией плагина WooCommerce Support Ticket System ниже 18.5.
- Агентства или хосты, управляющие несколькими установками WordPress, где используется плагин.
- Сайты с недостаточными резервными копиями или низким уровнем разделения между файловым хранилищем и веб-сервером.
Даже сайт с низким трафиком может стать целью — злоумышленники не заботятся о трафике, они ищут уязвимое программное обеспечение.
Немедленные действия (первые 60–120 минут)
- Обновите плагин до версии 18.5 или выше (рекомендуется)
Это правильное и постоянное решение. Примените обновления к рабочим и тестовым сайтам как можно скорее. - Если вы не можете обновить немедленно: отключите плагин
Перейдите в админку плагинов WordPress и деактивируйте плагин. Если вы используете WP‑CLI:wp плагин деактивировать
- Включите WAF/виртуальное патчирование, чтобы остановить попытки эксплуатации
Если у вас есть WAF (управляемый или на уровне плагина), активируйте правила, которые блокируют запросы к уязвимым конечным точкам и подозрительным полезным нагрузкам (мы предоставляем стратегии правил ниже). - Сделайте свежую резервную копию сейчас
Экспортируйте полную резервную копию (файлы + БД) перед тем, как делать что-либо еще. Если сайт показывает признаки компрометации, этот снимок критически важен для расследования и восстановления. - Ищите в логах подозрительную активность
Ищите в логах доступа POST/GET запросы к конечным точкам, специфичным для плагина, действиям admin-ajax.php или параметрам, которые выглядят как команды на удаление. Если вы видите такие запросы от неизвестных IP, рассматривайте это как потенциальную эксплуатацию и эскалируйте. - Свяжитесь с вашим хостинг-провайдером или разработчиком если вы не контролируете среду. Поделитесь CVE и попросите их помочь с локализацией и патчированием.
Обнаружение: что искать в журналах и телеметрии
Настройте поиск в логах Apache/Nginx/Cloudfront, логах WAF и логах WordPress для следующих паттернов (примеры концептуально развиты — адаптируйте под ваши логи):
- HTTP-запросы к путям плагина:
- /wp-content/plugins/woocommerce-support-ticket-system/*
- /wp-content/plugins//ajax.php или конечные точки с очевидными терминами “ticket”, “delete”, “attachment”
- HTTP-запросы к admin-ajax.php с подозрительными именами действий:
- admin-ajax.php?action=… (ищите действия, которые намекают на удаление вложений, тикетов или файлов)
- Параметры, содержащие токены обхода пути:
%2e%2e%2fили../или абсолютные пути к файлам (например,./etc/passwdили/home/.../wp-config.php) в запросе/теле
- Запросы, которые пытаются удалить типичные файлы WordPress:
- Запросы с параметрами, содержащими
wp-config.php,wp-config,wp-контент/загрузки, имена файлов плагинов/тем
- Запросы с параметрами, содержащими
- Внезапное увеличение ответов 200/204 на конечные точки, связанные с удалением
- Неожиданные всплески в 4xx/5xx за короткий промежуток времени, особенно от одних и тех же IP
Пример (идея запроса журнала — адаптируйте под свою платформу):
- Ищите admin-ajax.php и слаг плагина вместе:
grep "admin-ajax.php" access.log | grep "woocommerce-support-ticket-system"
- Ищите подозрительные параметры:
grep -E "(%2e%2e%2f|\.\./|wp-config|wp-content/uploads|/etc/passwd)" access.log
Если вы найдете совпадения за последние 24–72 часа, рассматривайте сайт как возможно скомпрометированный и следуйте шагам реагирования на инциденты ниже.
Рекомендуемые стратегии WAF / виртуального патчинга (примените сейчас)
Если вы управляете WAF WP‑Firewall или любым другим веб-приложением, реализуйте многослойные правила для снижения риска эксплуатации до обновления плагина:
- Заблокируйте доступ к публичным конечным точкам плагина
- Если плагин открывает конкретный PHP или конечный путь, заблокируйте прямой HTTP доступ к этому пути для неаутентифицированных клиентов.
- Например, заблокируйте GET/POST запросы к /wp-content/plugins/woocommerce-support-ticket-system/*, кроме известных IP-адресов администраторов.
- Заблокируйте неаутентифицированные действия удаления.
- Отказывайте в запросах к admin-ajax.php или REST конечным точкам, которые включают параметры или значения действия, используемые плагином для выполнения удалений, если запрос не аутентифицирован (например, имеет действительный WP nonce или cookie).
- Предотвращайте обход каталогов / подозрительные шаблоны имен файлов.
- Заблокируйте запросы, где любой параметр имени файла содержит.
../,%2e%2e%2f, или абсолютные шаблоны путей. - Заблокируйте попытки ссылаться на чувствительные имена файлов: wp-config.php, .htaccess, .env.
- Заблокируйте запросы, где любой параметр имени файла содержит.
- Ограничьте скорость и создайте отпечатки шаблонов запросов.
- Применяйте ограничения скорости на конечных точках, которые удаляют файлы, чтобы замедлить автоматизированную массовую эксплуатацию.
- Используйте поведенческие эвристики: множественные попытки удаления за короткие промежутки времени, много разных имен файлов, один и тот же user-agent на разных сайтах.
- Позитивный подход с подстановочными знаками для валидации параметров.
- Если возможно, разрешайте только параметры удаления, которые соответствуют безопасному белому списку (например, числовые идентификаторы вложений). Заблокируйте нечисловые или необычно длинные значения, которые указывают на использование пути.
- Ведение журнала и оповещение
- Записывайте заблокированные попытки с полным контекстом запроса и предупреждайте о повторных срабатываниях.
Пример концептуальной логики правила WAF (абстрактное и безопасное):
- Правило A: Если путь запроса соответствует plugin-delete-endpoint И (нет действительного аутентификационного cookie ИЛИ отсутствует WP nonce) → ЗАБЛОКИРОВАТЬ и ЗАПИСАТЬ.
- Правило B: Если тело запроса или параметр запроса содержит.
../или%2e%2e%2fИЛИ ссылается на.wp-config.phpили/.env→ ЗАБЛОКИРОВАТЬ и ЗАПИСАТЬ. - Правило C: Ограничьте скорость запросов к конечной точке до N запросов в минуту на IP; если превышено → ЗАБЛОКИРОВАТЬ и предупредить.
Важный: При создании правил сначала тестируйте в режиме только мониторинга, чтобы избежать ложных срабатываний, которые могут заблокировать администраторов. Затем переходите к блокировке для подтвержденных вредоносных паттернов.
Примеры соображений WAF для сред WordPress
- Защитите admin-ajax.php: Многие плагины неправильно используют admin-ajax.php для AJAX-действий и не обеспечивают контроль доступа. Блокируйте или ограничивайте POST-запросы к admin-ajax.php, где
действиепараметр соответствует действиям уязвимого плагина. - Защитите папки плагинов: Используйте правила WAF и серверные контролы, чтобы предотвратить прямой доступ к специфическим для плагина точкам входа PHP.
- Блокируйте прямые API удаления файлов от неаутентифицированных источников: Общее правило: отказывайте в HTTP-методах и конечных точках, которые пытаются удалить файлы, если запрос не аутентифицирован и не авторизован.
Как укрепить ваш сервер и среду WordPress (практические шаги)
- Укрепление файловой системы
- Ограничьте права доступа к файловой системе. Критические файлы (wp-config.php, .htaccess) должны быть доступны только для записи владельцу и не должны быть записываемыми пользователем веб-сервера, когда это возможно (например, chmod 400/440 для wp-config.php).
- Избегайте предоставления пользователю веб-сервера рекурсивного доступа на запись ко всему каталогу wp-content. Ограничьте права на запись только для папки uploads, где это необходимо.
- Храните резервные копии и архивы вне корневого каталога веб-сервера.
- Принцип наименьших привилегий
- Запускайте процессы PHP с пользователем, который имеет доступ только к необходимым каталогам.
- Используйте разделение на уровне ОС между учетными записями пользователей для сайтов при хостинге нескольких сайтов.
- Правила веб-сервера
- Используйте .htaccess или правила конфигурации сервера, чтобы запретить прямое выполнение PHP в определенных каталогах (например, uploads) и запретить доступ к известным чувствительным файлам.
- Если плагин открывает файл, который не должен быть публичным, ограничьте его через конфигурации сервера.
- Лучшие практики WordPress
- Регулярно обновляйте ядро WordPress, темы и плагины.
- Минимизируйте след плагина: удалите неиспользуемые плагины и оставляйте плагины только в том случае, если они активно поддерживаются.
- Обеспечьте двухфакторную аутентификацию для административных учетных записей.
- Резервные копии и хранение
- Поддерживайте регулярные автоматизированные резервные копии, хранящиеся вне сервера, и неизменяемые копии, где это возможно.
- Регулярно тестируйте восстановление.
Если вы подозреваете эксплойт — реагирование на инциденты и восстановление.
- Изолировать сайт
- Если возможно, переведите сайт в режим обслуживания или заблокируйте публичный трафик, пока вы проводите расследование.
- Сохраняйте доказательства
- Сделайте снимок сервера (файлы и БД) перед дальнейшим устранением.
- Соберите журналы веб-сервера и приложения, журналы WAF и журналы доступа за период подозреваемого события.
- Проверьте на отсутствие/измененные файлы
- Сравните текущий список файлов с известной хорошей резервной копией или манифестом контрольных сумм. Обратите внимание на wp-config.php, файлы плагинов/тем, загрузки и любые файлы с недавними временными метками изменения.
- Восстановите из чистой резервной копии
- Если важные файлы отсутствуют и у вас есть чистая резервная копия, восстановите сайт в известное хорошее состояние. Не восстанавливайте резервные копии, которые могут быть уже скомпрометированы.
- Повернуть учетные данные
- Измените все административные пароли WordPress, учетные данные базы данных, ключи API и любые другие секреты, которые могли быть раскрыты или использованы.
- Просканируйте на наличие задних дверей
- Используйте сканер вредоносных программ для поиска PHP-задних дверей или веб-оболочек. Очистите или замените зараженные файлы.
- Повторно примените обновления и усиление безопасности.
- Обновите уязвимый плагин до исправленной версии, повторно включите только после подтверждения, что задние двери не остались.
- Восстановите защиту WAF и продолжайте строгий мониторинг.
- Уведомить заинтересованных лиц
- Уведомите затронутых пользователей, хостов или клиентов в соответствии с вашей политикой уведомления и юридическими требованиями.
Мониторинг и постоянное обнаружение после устранения
- Сохраняйте правила WAF (или в режиме мониторинга/оповещения) даже после патча.
- Установите оповещения для:
- Новые 404 или 500 во время рутинных сканирований сайта.
- Изменения файловой системы: неожиданные события удаления/изменения файлов в wp-content, загрузках и корне.
- Повторные попытки доступа к заблокированным конечным точкам.
- Реализуйте мониторинг целостности файлов (FIM) для обнаружения внезапных удалений или несанкционированных изменений.
Если вы разработчик: избегайте этих распространенных ошибок (контрольный список безопасного кодирования)
- Никогда не выполняйте операции удаления файловой системы напрямую на пользовательском вводе без канонизации и проверок в белом списке.
- Проверяйте и канонизируйте пути с использованием серверных API; убедитесь, что целевой файл находится в разрешенной директории перед удалением.
- Требуйте аутентификации и проверяйте возможности (например,
current_user_can('удалить_посты')или пользовательские возможности) для любых разрушительных действий. - Используйте нонсы или токен-ориентированную проверку для изменяющих состояние AJAX/конечных точек и проверяйте их на сервере.
- Избегайте раскрытия общих конечных точек, которые принимают произвольные имена файлов; предпочитайте числовые идентификаторы, которые сервер разрешает в безопасный путь к файлу.
- Записывайте удаления и включайте контекст пользователя или запроса для аудита; не подавляйте важные журналы, относящиеся к безопасности.
Как WP‑Firewall помогает (виртуальное патчирование, мониторинг и помощь в восстановлении)
В WP‑Firewall мы рассматриваем уязвимости подобным образом с многоуровневым подходом:
- Быстрое виртуальное патчирование
Мы создаем индивидуальные правила WAF, которые блокируют конкретные векторы эксплуатации (подозрительные параметры, шаблоны доступа к конечным точкам и попытки обхода директорий), чтобы сайты оставались защищенными до тех пор, пока их можно будет обновить. Виртуальные патчи развертываются централизованно и могут смягчить массовые сканирующие кампании. - Поведенческие защиты
Ограничение скорости, отпечатки запросов и обнаружение аномалий снижают успех автоматизированных попыток эксплуатации. Даже если конечная точка существует, схемы злоупотребления выявляются и смягчаются. - Мониторинг целостности файлов и руководство по восстановлению
Наши инструменты могут помочь обнаружить отсутствующие файлы и аномальные изменения файлов и предоставить пошаговое руководство по восстановлению или восстановлению из резервной копии. - Поддержка инцидентов
Если вы подозреваете компрометацию, наши процессы поддержки и сценарии инцидентов проведут вас через локализацию, сбор доказательств и чистое восстановление.
Если у вас нет управляемого WAF перед вашим сайтом WordPress, неаутентифицированная уязвимость, подобная этой, может быть быстро использована автоматизированными инструментами сканирования. Виртуальные патчи обеспечивают немедленную защиту до установки исправления на уровне кода.
Практические меры по смягчению, не относящиеся к WAF, которые вы можете применить, если не можете обновить сейчас
- Деактивировать плагин: самым безопасным краткосрочным решением является деактивация плагина до тех пор, пока вы не сможете его обновить.
- Ограничьте доступ к файлам плагина.: добавьте серверные правила, запрещающие публичный доступ к PHP-входным точкам плагина. Например, запретите запросы к конкретному PHP-файлу плагина, если запрос не поступает от известного IP-администратора. (Предостережение: будьте осторожны с ограничениями IP, если у администраторов динамические IP.)
- Укрепить разрешения на файлы: сделайте чувствительные файлы только для чтения, где это возможно. Но тщательно протестируйте, так как некоторые плагины законно требуют доступа на запись.
- Используйте серверные белые списки: если плагин предлагает фильтры/хуки для переопределения поведения удаления (некоторые плагины это делают), добавьте пользовательский код, чтобы запретить запросы на удаление, если они не соответствуют строгим проверкам (например, разрешайте удаление только для вошедших в систему пользователей с определенной возможностью).
Долгосрочные программные рекомендации для хостов и операторов сайтов
- Поддерживайте работающий WAF или защиту на краю, которые могут быстро развертывать обновления правил на сайтах клиентов.
- Предлагайте автоматическое обновление для плагинов, в которых есть исправления безопасности, желательно с тестированием на канареечном окружении и откатом.
- Обеспечьте снимки целостности файлов для каждого сайта и быстрые рабочие процессы восстановления, которые не требуют полного восстановления сервера.
- Обучайте клиентов гигиене безопасности плагинов: удаляйте неиспользуемые плагины, предпочитайте активно поддерживаемые плагины, тестируйте обновления на тестовом окружении.
Плейбук обнаружения: запросы и оповещения, которые вы можете реализовать сегодня
Добавьте эти идеи обнаружения в ваш стек мониторинга (elk, splunk, облачные логи, логи хостинга):
- Оповещайте, когда любой запрос к /wp-content/plugins/woocommerce-support-ticket-system/* приводит к HTTP 200 для действия удаления.
- Оповещайте, когда admin-ajax.php получает POST-запросы, содержащие подозрительные
действиезначения (или параметры тела), связанные с процедурами удаления. - Оповещайте о запросах, которые содержат
../,%2e%2e%2f, абсолютные пути или чувствительные имена файлов в запросе или теле запроса. - Запланируйте ежедневную проверку, сравнивая текущий манифест файлов с последним известным манифестом; оповещайте о любых неожиданных удалениях.
Часто задаваемые вопросы
В: Если мой сайт был атакован, но злоумышленник только удалил файлы плагинов, восстановит ли WordPress?
А: Если файлы плагинов удалены, вы обычно можете переустановить плагин и восстановить настройки из резервных копий. Но если критические файлы (например, wp-config.php или пользовательские загрузки) были удалены или задние двери были установлены до удаления, сайт может находиться в более сложном состоянии. Всегда проводите полное сканирование целостности после восстановления.
В: Могут ли одни только разрешения файловой системы предотвратить это?
А: Правильные разрешения снижают риск, но не являются надежными. Уязвимый плагин, работающий под пользователем веб-сервера, все равно может удалить файлы, к которым пользователь веб-сервера может записывать. Защита в глубину (обновления + WAF + резервные копии + разрешения) — правильный подход.
В: Будет ли достаточно просто отключить доступ к admin-ajax.php?
А: Не всегда. Некоторые плагины зависят от admin-ajax для законной функциональности. Полная блокировка admin-ajax может сломать функции. Предпочтительны целевые правила WAF, которые блокируют только вредоносные шаблоны или конечные точки.
Финальный контрольный список — немедленный список дел для каждого владельца сайта WordPress
- Определите все сайты, которые используют плагин WooCommerce Support Ticket System.
- Немедленно обновите каждую установку до версии 18.5 или выше.
- Если вы не можете обновить немедленно, деактивируйте плагин.
- Примените правила WAF или виртуальное патчирование, чтобы заблокировать конечные точки удаления и попытки обхода директорий.
- Сделайте полный резервный копию (файлы + БД) сейчас и сохраните вне сервера.
- Проверьте журналы на наличие подозрительных попыток удаления и индикаторов, описанных ранее.
- Запустите сканирование целостности файлов/вредоносного ПО и ищите задние двери, если будет обнаружена подозрительная активность.
- Ужесточите разрешения на файлы, ограничьте доступ к конфиденциальным файлам и внедрите ведение журнала.
- Настройте постоянный мониторинг и оповещение для вышеуказанных паттернов.
Начните защищать свой сайт с помощью WP‑Firewall (бесплатный план)
Начните защищать свой сайт с помощью WP‑Firewall Basic (бесплатный) плана
Если вы хотите немедленной защиты с простым процессом подключения, базовый (бесплатный) план WP‑Firewall предоставляет основные управляемые защиты, которые помогают остановить массовые кампании эксплуатации, такие как эта, пока вы исправляете:
- Основная защита: управляемый брандмауэр, неограниченная пропускная способность, WAF на уровне приложений.
- Сканер вредоносного ПО и непрерывное смягчение рисков OWASP Top 10.
- Быстрое виртуальное патчирование для блокировки известных векторов эксплуатации до применения исправлений на уровне кода.
Зарегистрируйтесь на бесплатный план и получите набор управляемых правил WAF, защищающих ваши сайты WordPress немедленно:
https://my.wp-firewall.com/buy/wp-firewall-free-plan/
(Если вам нужна автоматизированная удаление вредоносного ПО, управление белыми/черными списками или автоматическое виртуальное патчирование для агентства или нескольких сайтов, платные планы включают эти возможности и имеют цены для агентств и предприятий.)
Заключительные мысли
Уязвимости произвольного удаления файлов являются одним из более разрушительных классов ошибок веб-приложений, поскольку они напрямую нацелены на целостность и доступность вашего сайта. Решение этих проблем требует скорости: обновите плагин до 18.5 сейчас, и если вы не можете сделать это немедленно, примените виртуальные патчи и изолируйте уязвимую конечную точку.
В WP‑Firewall мы рекомендуем многослойный подход: исправления кода + виртуальные патчи WAF + ужесточение сервера + резервные копии + мониторинг. Эта комбинация предотвращает быстрое использование уязвимости злоумышленниками и дает вам время для применения постоянного исправления.
Если вам нужна помощь в реализации правил WAF, сканировании сайтов на наличие индикаторов компрометации или проведении реагирования на инциденты, команда WP‑Firewall может помочь. Защитите свои сайты сейчас и рассматривайте безопасность плагинов как непрерывную операционную задачу, а не как одноразовую задачу.
