Имя плагина	Резервная защита
Тип уязвимости	Уязвимость обхода пути
Номер CVE	CVE-2026-4853
Срочность	Низкий
Дата публикации CVE	2026-04-17
Исходный URL-адрес	CVE-2026-4853

Критическая: Обход пути + Произвольное удаление каталогов в JetBackup / Backup Guard (CVE-2026-4853) — Что владельцам сайтов на WordPress нужно знать и как защитить себя

Опубликовано: 3. 17 апр, 2026
Затронутые плагины: JetBackup / Backup Guard (плагин slug: backup)
Уязвимые версии: <= 3.1.19.8
Исправленная версия: 3.1.20.3
CVE: CVE-2026-4853
Серьезность: Низкий (приоритет Patchstack: Низкий, CVSS: 4.9) — но не позволяйте себя обмануть: практическое воздействие может быть значительным, если злоумышленник получит или уже контролирует учетную запись администратора.

Как команда, стоящая за WP-Firewall, мы постоянно отслеживаем уязвимости WordPress и советуем владельцам сайтов, разработчикам и хостингам по прагматичным, приоритетным ответам. Эта уязвимость JetBackup/Backup Guard является аутентифицированным обходом пути, который позволяет пользователю уровня администратора удалять произвольные каталоги через поддельное значение в имя файла параметре (обычно отправляемом на конечную точку резервного копирования/удаления). Ошибка была ответственно раскрыта и исправлена в версии 3.1.20.3 — обновление является самым простым и эффективным способом устранения. Ниже мы разбираем технические детали, реалистичные сценарии рисков, стратегии обнаружения и смягчения, практические правила виртуального патчинга WAF, шаги реагирования на инциденты и рекомендации по долгосрочному укреплению, чтобы вы могли действовать быстро и уверенно.

Примечание: Этот совет написан для владельцев сайтов на WordPress, инженеров по безопасности и команд управляемого хостинга. Он включает в себя практические, защитные конфигурации и примеры кода, чтобы помочь вам быстро и безопасно смягчить проблему.

Краткое содержание (краткое)

Что: Обход пути в обработчике удаления резервной копии плагина через имя файла параметр. Аутентифицированный администратор может использовать последовательности обхода пути (../) для нацеливания на каталоги вне ожидаемых папок резервного копирования и инициировать удаление.
Кто подвержен риску: Сайты, использующие плагин на версиях <= 3.1.19.8.
Влияние: Произвольное удаление каталогов (файлы сайта, загрузки, резервные копии, журналы) — разрушительно, если будет использовано. Требует привилегий администратора для эксплуатации, поэтому атаки наиболее вероятны после компрометации или неправильного использования учетной записи администратора.
Немедленное решение: Обновите плагин до версии 3.1.20.3 или более поздней.
Временные меры смягчения: Примените правила WAF для блокировки полезных нагрузок обхода пути, ограничьте доступ к панели администратора для доверенных IP-адресов, отключите плагин или уязвимую конечную точку удаления до исправления, укрепите разрешения файлов и обеспечьте надежные резервные копии.

Как работает уязвимость (технический обзор, объяснение, не подлежащее эксплуатации)

На высоком уровне уязвимость возникает из-за недостаточной проверки и очистки пользовательского имя файла параметра, который плагин использует для построения путей файловой системы для удаления. Когда плагин строит путь, как:

/wp-content/plugins/backup/backup-files/

и он не может правильно нормализовать или ограничить имяФайла, противник может включить последовательности обхода пути, такие как ../../ в параметре. Если плагин затем передает этот сконструированный путь функциям удаления файловой системы, не проверяя, находится ли разрешенный путь в ожидаемом базовом каталоге, он может удалить произвольные каталоги или файлы.

Ключевые коренные причины, часто встречающиеся в этом классе ошибок:

Отсутствие проверки канонизации/realpath — плагин доверяет конкатенированному пути, не проверяя, что окончательный разрешенный путь находится в разрешенном каталоге.
Отсутствие проверки базового имени или белого списка — плагин принимает произвольные значения имени файла, а не ограничивается известными именами резервных копий.
Недостаточные проверки возможностей/nonce или отсутствие nonce на чувствительных конечных точках (хотя здесь атакующий должен быть администратором, поэтому возможность присутствует; предотвращение CSRF и чрезмерного использования привилегий все еще актуально).
Невозможность проверить существование файла/каталога и предотвратить удаление каталога (rmdir/unlink) для не резервируемых ресурсов.

Поскольку вызовы удаления могут быть рекурсивными, если обертка использует рекурсивные реализации rmdir, эффект может эскалироваться от удаления одного файла до стирания целых каталогов.

Сценарии эксплуатации и практическое воздействие

Хотя уязвимость требует привилегий администратора для активации, вот реалистичные способы, как этот недостаток может стать практической угрозой:

Компрометация учетных данных администратора: Фишинг, повторное использование паролей, утечка паролей или социальная инженерия могут предоставить атакующему учетную запись администратора. Как только они получают доступ к интерфейсу на уровне администратора, они могут создать запрос к уязвимой конечной точке для удаления каталогов сайта.
Злой администратор или угроза со стороны инсайдера: Непорядочный администратор или подрядчик с законным доступом могут злоупотребить этой функцией.
Цепные атаки: Атакующий, который уже контролирует плагин с низкими привилегиями или скомпрометированную тему, может эскалировать или переключиться на получение прав администратора в сочетании с другими уязвимостями. В таком многоступенчатом эксплойте возможность удаления увеличивает ущерб.

Потенциальное воздействие включает:

Удаление каталогов резервных копий и сохраненных резервных копий (отказ в восстановлении).
Удаление загрузок (изображений, медиа) и файлов wp-content (темы/плагины).
Удаление журналов и судебно-экспертных артефактов.
Удаление конфигурационных или пользовательских каталогов вне корневого веб-директория, если обход пути позволяет покинуть предполагаемую базовую директорию.
Нарушение работы сервиса и потеря данных, приводящие к простоям и затратам на восстановление.

Даже при “Низком” CVSS операционные расходы и репутационные последствия массовых событий удаления могут быть высокими — особенно для сайтов без недавних резервных копий или тестовых сред.

Список действий для немедленного выполнения (что делать прямо сейчас)

Если ваш сайт использует плагин JetBackup / Backup Guard и вы хостите или поддерживаете сайты на WordPress, немедленно следуйте этому приоритетному контрольному списку:

Обновите плагин до версии 3.1.20.3 или более поздней.
– Это окончательное решение. Сначала сделайте это на тестовой среде, затем на рабочей. Проверьте резервные копии/процессы восстановления после обновления.
Если вы не можете выполнить обновление немедленно:
– Отключите плагин или отключите функциональность удаления резервных копий до применения патча.
– Ограничьте доступ к /wp-admin/ и конечным точкам плагина для доверенных IP-адресов, где это возможно.
– Примените временные правила WAF (примеры и шаблоны ниже), чтобы блокировать запросы, содержащие шаблоны обхода пути в имя файла или аналогичных параметрах.
Поменяйте учетные данные администратора и включите 2FA для всех учетных записей администраторов.
Проверьте резервные копии сайта (вне сайта) и убедитесь, что у вас есть проверенный план восстановления перед внесением изменений.
Мониторьте журналы на предмет подозрительных запросов на удаление и внезапного удаления файлов.
Общайтесь с заинтересованными сторонами (владелец сайта, хостинг, операции) и подготовьте план реагирования на инциденты, если будут обнаружены неожиданные удаления.

Обнаружение: как обнаружить попытки или успешную эксплуатацию

Ищите следующие признаки в журналах доступа, журналах аудита и активности файловой системы:

HTTP-запросы, нацеленные на конечные точки плагина, которые обрабатывают резервное копирование или удаление файлов с параметрами запроса, такими как имяФайла, имя файла, файл, имя или тела POST, содержащие имена. Примеры подозрительных шаблонов запросов:
- filename=../../
- filename=....
- fileName=wp-contentuploads
Запросы с последовательностями обхода пути в любом параметре:
- ../
- ..\\
- URL-кодированные эквиваленты %2e%2e%2f или %2e%2e%5c
Внезапно отсутствующие файлы или директории в wp-content, uploads или резервной директории плагина.
Неожиданные события удаления файлов, наблюдаемые в инструментах мониторинга файловой системы, или всплески операций “удалить”.
Входы администратора с необычных IP-адресов / геолокаций, за которыми следуют запросы к конечным точкам резервного копирования.

Примеры правил обнаружения (высокий уровень):

Совпадение запросов, где параметр называется без учета регистра, как имя файла, имяФайла, файл содержит \.\./ или %2e%2e%2f.
Совпадение тел POST, которые пытаются удалить или управлять резервными копиями, содержащими последовательности обхода.
Оповещение о rmdir или отсоединить ошибках в журналах сервера, соответствующих неожиданным путям вне разрешенной базовой директории.

Полезная команда оболочки для поиска недавно измененных/удаленных элементов (запустите от имени администратора, осторожно):

# Найти файлы в корне веб-сайта, измененные за последние 7 дней (при необходимости отрегулируйте)

Если у вас есть мониторинг целостности файлов (Tripwire, OSSEC и т.д.), используйте это, чтобы быстро находить удаления.

Виртуальное патчирование и правила WAF (практические сигнатуры, которые вы можете применить сейчас)

Веб-фаервол (WAF) может быть настроен для блокировки запросов, которые пытаются использовать обход пути. Ниже приведены безопасные, защитные шаблоны правил и практические примеры. Применяйте их для блокировки вредоносного ввода, а не для разрешающих правил, которые могут нарушить рабочие процессы администратора. Это защитные шаблоны — протестируйте их в режиме мониторинга перед блокировкой.

Важный: Настройте имена параметров в соответствии с конечными точками плагина и вашими шаблонами журналов. Уязвимый параметр обычно называется имяФайла (могут существовать варианты без учета регистра).

Пример правила в стиле ModSecurity (концептуально):

# Block requests where any argument named filename (case-insensitive) contains ../ or encoded variants
SecRule ARGS_NAMES|ARGS "@rx (?i:filename)" "phase:2,deny,log,msg:'Block possible Backup plugin path traversal attempt', \
 chain"
SecRule ARGS "@rx (\.\./|\.\.\\||)" "t:none,deny,status:403"

Nginx фрагмент location (блокировать строки запроса с ../ в имени файла):

if ($arg_filename ~* "\.\./|") {
 return 403;
}
# Repeat for $arg_fileName or other param names

Общие предложения WAF/наборов правил:

Блокировать любой запрос, где ARGS содержит закодированные символы обхода пути и где запрос нацелен на конечную точку удаления плагина (например, /wp-admin/admin-ajax.php?action=backup_delete или специфический для плагина ajax маршрут).
Обнаруживать и блокировать полезные нагрузки с нулевыми байтами или закодированные символы обхода Unicode.
Совмещать обнаружение шаблонов с ограничениями по скорости и ограничениями доступа к административной панели.
Логировать заблокированные события с полными заголовками и телом запроса для судебного анализа.

Держать правила консервативными, чтобы избежать ложных срабатываний; рассмотреть возможность перевода их в режим блокировки только после мониторинга в течение одного-двух дней.

Пример безопасного кода для усиления безопасности для авторов плагинов / команд разработчиков

Если вы поддерживаете пользовательскую интеграцию или патч, убедитесь, что серверная сторона использует канонизацию и строго соблюдает разрешенные базовые директории и белые списки. Ниже приведен безопасный шаблон для PHP в контексте WordPress (санитизация имени файла и проверка реального пути).

Важный: это защитный пример кода для иллюстрации безопасной обработки; авторам плагинов следует адаптировать, санировать и тестировать перед развертыванием.

<?php

Ключевые проверки, иллюстрирующие:

Проверка прав (текущий_пользователь_может)
Проверка nonce
Использование basename() или строгий белый список для предотвращения разделителей пути
Использование реальный путь для канонизации и проверки префикса, обеспечивающей, что цель находится в разрешенной директории

Меры смягчения на уровне хоста, которые вы можете применить сейчас

Если вы хост или управляете сервером, примените следующие дополнительные шаги по усилению безопасности:

Ограничьте доступ к административной области для доверенных IP-адресов через правила брандмауэра или списки доступа веб-сервера (где это возможно).
Использовать open_basedir ограничить процессы PHP допустимыми директориями.
Настроить права доступа к файлам так, чтобы пользователь веб-сервера не мог удалять произвольные системные файлы (учитывайте потребности плагинов и резервного копирования).
Используйте профили SELinux или AppArmor для изоляции процессов WordPress и ограничения доступа к файлам.
Включите аудит на уровне процессов (auditd), чтобы фиксировать удаления файлов процессами PHP для судебно-медицинского анализа.
Используйте резервные копии вне сайта (хранящиеся вне веб-сервера), чтобы гарантировать безопасное восстановление, даже если резервные копии на уровне сайта были удалены.

Реакция на инциденты: если вы подозреваете эксплуатацию

Если вы считаете, что ваш сайт был скомпрометирован через эту уязвимость (или любую другую), выполните следующие шаги:

Немедленно изолируйте сайт (выключите его или включите режим обслуживания), чтобы остановить дальнейший ущерб.
Сохраните журналы и судебно-медицинские данные сервера — скопируйте журналы доступа, журналы ошибок и любые журналы приложений в отдельное, неизменяемое хранилище.
Восстановите из известной хорошей резервной копии, хранящейся вне сайта (не в резервных копиях, управляемых плагинами, если вы подозреваете удаление).
Смените все учетные данные для учетных записей администратора и любых API-ключей, токенов или учетных данных базы данных, которые могли быть раскрыты.
Принудительно сбросьте пароли для пользователей с привилегированными ролями и включите 2FA.
Проверьте наличие дополнительных задних дверей, подозрительных cron-задач, новых администраторов или измененных файлов плагинов/тем.
Переустановите ядро WordPress и все плагины/темы из официальных источников после очистки или восстановите полностью проверенную резервную копию.
Если у вас нет экспертизы, обратитесь к специалисту по реагированию на инциденты безопасности или к надежному управляемому провайдеру WordPress и поделитесь судебно-медицинскими артефактами.

Практические примеры правил WAF (больше)

Ниже приведены несколько примеров защитных правил для различных сред. Пожалуйста, проверьте эти правила в безопасной тестовой среде перед применением в производственной.

Общая блокировка на символы перехода в имяФайла аргументе (концептуально):
- Условие: Запрос содержит имя параметра, соответствующее (?i:файл(Имя)?) и значение соответствует паттернам перехода.
- Действие: Блокировать и записывать в журнал.
Ограничить специфическое для плагина действие AJAX (если плагин использует admin-ajax):
- Блокировать любые вызовы admin-ajax с действие=резервное_копирование_удалить если запрос не исходит от разрешенных IP-адресов или не содержит действительный nonce сайта.
Блокировать закодированный переход:
- Обнаруживать как сырые (../) так и URL-кодированные последовательности (%2e%2e%2f, /) и варианты Unicode.
Ограничение частоты:
- Ограничьте разрушительные действия (удаление конечных точек) до низкого числа в минуту на учетную запись администратора или IP-адрес.

Зачем обновлять, даже если CVSS выглядит “низким”?

CVSS — это один из факторов, но реальный риск зависит от контекста. Эта уязвимость требует прав администратора — это снижает риск удаленной анонимной эксплуатации — но на практике многие сайты не имеют строгой гигиены учетных записей администраторов. Учетные записи администраторов часто компрометируются из-за повторного использования учетных данных, слабых паролей или фишинга. Как только злоумышленник получает доступ администратора, возможность удаленного удаления каталогов может быть катастрофической.

Также учтите:

Злоумышленники могут связывать уязвимости. Небольшая начальная точка + эта возможность удаления = серьезный ущерб.
Удаление резервных файлов устраняет ваш путь к восстановлению.
Репутационные и восстановительные расходы могут затмить первоначальную метку “Низкой” серьезности.

Поэтому рассматривайте это как риск высокого приоритета, если вы хостите производственные сайты или множество клиентов.

Примеры запросов мониторинга и оповещений

Оповестите, когда пользователь-администратор выполняет вызов удаления, нацеленный на конечные точки плагина с ../ в параметрах.
Оповестите, когда большое количество файлов удаляется из wp-контент/загрузки или папок резервных копий плагина.
Ежедневный дайджест: список удалений файлов, инициированных процессами PHP-FPM в webroot.

Пример простого loggrep для поиска подозрительных запросов (Apache/Nginx):

# Look for traversal patterns in access logs
grep -E "(filename|fileName|file)=.*(\.\./|)" /var/log/nginx/access.log | tail -n 200

После патча: проверьте и подтвердите

После обновления плагина до 3.1.20.3 (или позже) подтвердите:

Функциональность удаления плагина по-прежнему работает как ожидалось для законных резервных файлов, но не может выходить за пределы назначенного каталога.
Не возникает неожиданных ошибок в потоках резервного копирования/восстановления.
Проведите контролируемый тест: попытайтесь запросить удаление с полезной нагрузкой обхода (в тестовой среде) и подтвердите, что оно отклоняется и/или регистрируется.
Повторно активируйте любые временные правила WAF только после подтверждения, что плагин исправлен; сохраняйте правила обнаружения для оповещения о необычной активности.

Хронология и ответственное раскрытие (кратко)

Эта уязвимость была выявлена и сообщена поставщику до публичного раскрытия. Поставщик выпустил патч в версии 3.1.20.3. CVE-2026-4853 был назначен для отслеживания проблемы. Мы всегда рекомендуем обновляться до исправленной версии как основное средство устранения.

Практический пример: что администратор хостинга должен сделать за 15–60 минут

Если вы администратор хостинга или владелец сайта, который проснулся с этим уведомлением, вот краткий план действий на первые 60 минут:

0–10 мин:

Определите затронутые сайты (плагин установлен и версия <= 3.1.19.8).
Проинформируйте заинтересованные стороны (владельцы сайтов, операционные службы).

10–30 мин:

Если обновление возможно немедленно, обновите плагин на тестовом и затем на рабочем сервере.
Если вы не можете обновить, отключите плагин и/или ограничьте доступ к административным конечным точкам через белый список IP.

30–60 мин:

Примените временные правила WAF для блокировки паттернов обхода путей против конечных точек плагина.
Смените учетные данные администратора и включите 2FA.
Убедитесь, что резервные копии вне сайта целы, и сделайте дополнительную ручную резервную копию, если это возможно.

Заключительные заметки — балансировка срочности и безопасности

Обновите до версии 3.1.20.3 или более поздней, как только сможете. Если вы не можете обновить немедленно, используйте описанные выше многоуровневые меры: виртуальное патчирование WAF, ограничения IP, отключение плагина или прекращение возможностей удаления до применения патча. Всегда убедитесь, что вы протестировали резервные копии вне сайта перед внесением масштабных изменений в устранение.

Мы понимаем, что обновления иногда могут нарушать совместимость. Вот почему хосты и агентские команды нуждаются в предсказуемых, протестированных рабочих процессах для обновлений плагинов, экстренных виртуальных патчей и практик восстановления. Если вы управляете многими сайтами на WordPress, автоматизация и централизованное управление для обновлений, правил WAF и резервных копий значительно сократят время реакции.

Начните защищать свой сайт с бесплатного плана WPFirewall

Если вы хотите быстрый и практичный способ добавить защитный слой, пока вы обрабатываете обновления плагинов, рассмотрите возможность начала с нашего бесплатного плана WPFirewall. Он предоставляет основные защиты, которые помогают блокировать попытки эксплуатации и отслеживать подозрительное поведение, пока вы устанавливаете патчи:

Базовый (бесплатно) — Основная защита: управляемый брандмауэр, неограниченная пропускная способность, WAF, сканер вредоносного ПО и смягчение рисков OWASP Top 10.
Стандарт — Все основные функции плюс автоматическое удаление вредоносного ПО и возможность заносить в черный/белый список до 20 IP-адресов.
Профи — Все стандартные функции плюс ежемесячные отчеты по безопасности, автоматическое виртуальное патчирование уязвимостей и доступ к премиум-дополнениям: выделенный менеджер аккаунта, оптимизация безопасности, токен поддержки WP, управляемый сервис WP и управляемый сервис безопасности.

Посмотрите детали плана и зарегистрируйтесь здесь: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

Заключение: что мы рекомендуем, в порядке

Немедленно обновите JetBackup / Backup Guard до версии 3.1.20.3 или более поздней.
Если вы не можете обновить мгновенно, примените правила WAF для блокировки обхода пути в имя файла/имяФайла параметрах и ограничьте доступ администратора.
Смените учетные данные администратора, включите 2FA и проверьте список пользователей-администраторов на наличие неизвестных аккаунтов.
Проверьте резервные копии вне сайта и протестируйте восстановление.
Укрепите настройки сервера (open_basedir, SELinux/AppArmor, строгие разрешения) и рассмотрите возможности виртуального патчирования для будущего быстрого смягчения.
Ведите журнал, мониторинг и контрольный список реагирования на инциденты, чтобы вы могли быстро действовать, если что-то подозрительное произойдет.

Если вам нужна помощь в реализации правил WAF, сканировании на наличие индикаторов компрометации или применении безопасных виртуальных патчей на нескольких сайтах, команда WPFirewall может помочь. Мы предоставляем управляемую защиту, которая интегрирует подписи WAF, виртуальное патчирование и непрерывный мониторинг, чтобы вы могли сосредоточиться на управлении своим сайтом, а не на поиске экстренных патчей.

Берегите себя, и, пожалуйста, свяжитесь с нами, если вам нужна помощь в аудите затронутых сайтов или внедрении защитных правил.

Критическая уязвимость обхода пути в Backup Guard//Опубликовано 2026-04-17//CVE-2026-4853

Критическая: Обход пути + Произвольное удаление каталогов в JetBackup / Backup Guard (CVE-2026-4853) — Что владельцам сайтов на WordPress нужно знать и как защитить себя

Краткое содержание (краткое)

Как работает уязвимость (технический обзор, объяснение, не подлежащее эксплуатации)

Сценарии эксплуатации и практическое воздействие

Список действий для немедленного выполнения (что делать прямо сейчас)

Обнаружение: как обнаружить попытки или успешную эксплуатацию

Виртуальное патчирование и правила WAF (практические сигнатуры, которые вы можете применить сейчас)

Пример безопасного кода для усиления безопасности для авторов плагинов / команд разработчиков

Меры смягчения на уровне хоста, которые вы можете применить сейчас

Реакция на инциденты: если вы подозреваете эксплуатацию

Рекомендации на долгосрочную перспективу и лучшие практики

Практические примеры правил WAF (больше)

Зачем обновлять, даже если CVSS выглядит “низким”?

Примеры запросов мониторинга и оповещений

После патча: проверьте и подтвердите

Хронология и ответственное раскрытие (кратко)

Практический пример: что администратор хостинга должен сделать за 15–60 минут

0–10 мин:

10–30 мин:

30–60 мин:

Заключительные заметки — балансировка срочности и безопасности

Начните защищать свой сайт с бесплатного плана WPFirewall

Заключение: что мы рекомендуем, в порядке

Получайте WP Security Weekly бесплатно 👋
Зарегистрируйтесь сейчас!!

Свяжитесь с нами, чтобы запланировать бесплатную консультацию по безопасности WordPress.

Критическая уязвимость обхода пути в Backup Guard//Опубликовано 2026-04-17//CVE-2026-4853

Критическая: Обход пути + Произвольное удаление каталогов в JetBackup / Backup Guard (CVE-2026-4853) — Что владельцам сайтов на WordPress нужно знать и как защитить себя

Краткое содержание (краткое)

Как работает уязвимость (технический обзор, объяснение, не подлежащее эксплуатации)

Сценарии эксплуатации и практическое воздействие

Список действий для немедленного выполнения (что делать прямо сейчас)

Обнаружение: как обнаружить попытки или успешную эксплуатацию

Виртуальное патчирование и правила WAF (практические сигнатуры, которые вы можете применить сейчас)

Пример безопасного кода для усиления безопасности для авторов плагинов / команд разработчиков

Меры смягчения на уровне хоста, которые вы можете применить сейчас

Реакция на инциденты: если вы подозреваете эксплуатацию

Рекомендации на долгосрочную перспективу и лучшие практики

Практические примеры правил WAF (больше)

Зачем обновлять, даже если CVSS выглядит “низким”?

Примеры запросов мониторинга и оповещений

После патча: проверьте и подтвердите

Хронология и ответственное раскрытие (кратко)

Практический пример: что администратор хостинга должен сделать за 15–60 минут

0–10 мин:

10–30 мин:

30–60 мин:

Заключительные заметки — балансировка срочности и безопасности

Начните защищать свой сайт с бесплатного плана WP­Firewall

Заключение: что мы рекомендуем, в порядке

Получайте WP Security Weekly бесплатно 👋Зарегистрируйтесь сейчас!!

Свяжитесь с нами, чтобы запланировать бесплатную консультацию по безопасности WordPress.

Начните защищать свой сайт с бесплатного плана WPFirewall

Получайте WP Security Weekly бесплатно 👋
Зарегистрируйтесь сейчас!!