Защита Tutor LMS от SQL-инъекций//Опубликовано 2026-04-17//CVE-2026-6080

КОМАНДА БЕЗОПАСНОСТИ WP-FIREWALL

Tutor LMS Vulnerability

Имя плагина Tutor LMS
Тип уязвимости SQL-инъекция
Номер CVE 1. CVE-2026-6080
Срочность Высокий
Дата публикации CVE 2026-04-17
Исходный URL-адрес 1. CVE-2026-6080

2. Понимание и смягчение SQL-инъекции Tutor LMS <= 3.9.8 (CVE-2026-6080) — перспектива WP‑Firewall

3. 17 апреля 2026 года была раскрыта уязвимость, затрагивающая Tutor LMS (версии <= 3.9.8): аутентифицированная (администраторская) SQL-инъекция через параметр. параметр 4. Проблеме был присвоен CVE‑2026‑6080 и она была исправлена в Tutor LMS 3.9.9. Авторы патча оценили проблему по CVSS на уровне 7.6 — серьезный балл, обусловленный в первую очередь потенциальной возможностью манипуляции с базой данных — но контекст имеет значение: эксплуатация требует учетной записи с правами администратора.

5. Как команда, стоящая за WP‑Firewall (межсетевой экран веб-приложений WordPress и служба безопасности), мы рассматриваем этот тип проблемы через две призмы: (1) как это может быть использовано и каково реальное воздействие на владельцев сайтов, и (2) какие практические шаги вы можете предпринять немедленно для снижения рисков и укрепления вашего сайта. Ниже мы предоставляем техническое объяснение, индикаторы обнаружения, план реагирования, руководство по конфигурации WAF/виртуального патча (общие и независимые от поставщика) и рекомендации по предотвращению, ориентированные как на владельцев сайтов, так и на разработчиков плагинов.

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


Управляющее резюме

  • 7. Уязвимость: SQL-инъекция в Tutor LMS через аутентифицированный контролируемый администратором параметр параметр.
  • 8. Затронутые версии: Tutor LMS <= 3.9.8.
  • 9. Исправленная версия: Tutor LMS 3.9.9.
  • 10. CVE: CVE‑2026‑6080.
  • 11. Контекст риска: Требуются права администратора для вызова уязвимой функциональности. Это ограничивает массовую удаленную эксплуатацию, но любое компрометирование учетной записи администратора резко увеличивает поверхность атаки.
  • 12. Немедленные действия: Обновите до 3.9.9 (или более поздней версии). Если обновление не может быть применено немедленно, примените компенсирующие меры: виртуальное патчирование (WAF), ограничение доступа администратора, обеспечение строгой аутентификации и аудит журналов на предмет подозрительной активности.

13. Что такое SQL-инъекция и почему это важно

14. SQL-инъекция (SQLi) происходит, когда злоумышленник может манипулировать вводом в запрос к базе данных таким образом, что выполняются непреднамеренные SQL-команды. В зависимости от уязвимого запроса злоумышленник может читать конфиденциальные данные, изменять данные или даже изменять объекты схемы.

15. В этой уязвимости Tutor LMS конечная точка, доступная только для администраторов, принимала параметр, который использовался небезопасно в SQL-запросе. Поскольку это действие происходит в административном контексте, злоумышленники сначала должны получить учетные данные администратора или использовать сессию администратора. Хотя это требование снижает вероятность оппортунистической широкомасштабной эксплуатации, последствия остаются серьезными, если учетная запись администратора будет скомпрометирована или если злонамеренные инсайдеры злоупотребят своими привилегиями. параметр 16. Последствия включают (но не ограничиваются):.

17. Извлечение конфиденциальных данных из базы данных WordPress (пользователи, адреса электронной почты, прогресс курсов, метаданные платежей).

  • 18. Внедрение постоянного вредоносного контента в таблицы базы данных (содержимое постов, параметры), что позволяет дальнейшее злоупотребление.
  • 19. Создание новых административных пользователей или изменение существующих учетных записей, если запросы изменяют соответствующие таблицы.
  • Создание новых административных пользователей или изменение существующих учетных записей, если запросы изменяют соответствующие таблицы.
  • Латеральное движение и постоянство путем установки бэкдоров (вредоносные опции, измененные файлы плагинов/тем), которые выживают после обновлений плагинов, если не очищены.

Почему CVSS 7.6 — и что это на самом деле означает

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

Важные контекстуальные моменты:

  • Вектор атаки: Локальный к административным интерфейсам (не анонимный удаленный).
  • Требуемые привилегии: Администратор (требуются высокие привилегии).
  • Область: Эксплуатация может повлиять на конфиденциальность и целостность базы данных.
  • Реальный мир: Поскольку требуются административные привилегии, модель угроз в значительной степени касается скомпрометированных административных учетных записей, вредоносных администраторов или сайтов, где могут быть украдены административные сессии (например, через украденные куки, фишинг).

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


Как злоумышленники могут это эксплуатировать (на высоком уровне, без кода эксплуатации)

Поток атаки:

  1. Злоумышленник получает учетные данные администратора или перехватывает административную сессию (фишинг, подбор учетных данных, грубая сила, скомпрометированная локальная машина).
  2. Злоумышленник получает доступ к административной конечной точке, которая принимает параметр параметр (например, аналитику, отчеты или рутинные экспорты).
  3. The параметр параметр передается в SQL-запрос без достаточной параметризации или очистки. Сформированный ввод манипулирует выполнением SQL, чтобы раскрыть данные или изменить данные.
  4. Злоумышленник извлекает данные, устанавливает механизмы постоянства, создает новых администраторов или портит таблицы, чтобы скрыть следы.

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


Индикаторы компрометации (IoCs), на которые следует обратить внимание

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

  1. Журналы веб-сервера:
    • POST/GET запросы от административных пользователей к маршрутам администратора Tutor LMS, где параметр или другие параметры содержат необычные строки или более длинные, чем обычно, полезные нагрузки.
    • Запросы с повторяющимися попытками или вариациями параметров с одного IP.
  2. Журналы WordPress:
    • Внезапные изменения в учетных записях пользователей (новые администраторы создаются быстро).
    • Неожиданные сбросы паролей или изменения, или создание необычных учетных записей.
    • Изменения в wp_options которые выглядят подозрительно (неизвестные автозагружаемые параметры, добавленные записи плагинов/тем).
  3. Аномалии в базе данных:
    • Новые строки в критических таблицах (wp_users, wp_posts), где временные метки или содержимое не ожидались.
    • Неожиданные запросы SELECT, отражающие UNION против information_schema или длительные запросы.
  4. Поведение сайта:
    • Появление странных страниц, спамный контент, перенаправленные посетители.
    • Уведомления от вашего хостинга или инструментов сканирования о подозрительных изменениях файлов.
  5. Инструменты безопасности/сканирования:
    • Сканеры вредоносного ПО, помечающие измененные файлы плагинов/тем.
    • Повторяющиеся предупреждения, связанные с плагином Tutor LMS.

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


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

Если вы управляете одним или несколькими сайтами WordPress с Tutor LMS, примите эти немедленные меры.

  1. Обновление плагина
    • Основное смягчение: обновите Tutor LMS до версии 3.9.9 или более поздней как можно скорее.
  2. Если вы не можете обновить немедленно: примените компенсирующие меры
    • Виртуальное патчирование через WAF: разверните правила WAF для блокировки подозрительных полезных нагрузок, нацеленных на параметр параметр и другие конечные точки администратора (см. руководство WAF ниже).
    • Ограничьте доступ: ограничьте доступ администратора по IP (если возможно) или через VPN для страниц администратора.
    • Отключите плагин (временно): если уязвимая функциональность не требуется, рассмотрите возможность отключения плагина Tutor LMS до применения патча.
    • Уменьшите привилегии: проведите аудит учетных записей администраторов — удалите неиспользуемых администраторов и измените учетные данные для всех активных администраторов.
  3. Укрепите аутентификацию.
    • Используйте надежные пароли и уникальные учетные данные.
    • Реализуйте двухфакторную аутентификацию (2FA) для всех учетных записей администраторов.
    • Рассмотрите возможность единого входа или другой аутентификации на уровне предприятия для крупных организаций.
  4. Аудит и мониторинг
    • Просмотрите журналы веб-сервера и журналы активности WordPress на предмет подозрительных запросов администраторов.
    • Проведите полное сканирование сайта на наличие вредоносного ПО и целостности (файлы и база данных).
    • Проверьте недавние изменения в файлах ядра, плагинов и тем.
  5. Ротация учетных данных
    • Если есть подозрение на компрометацию, измените учетные данные базы данных (и храните их безопасно), ключи API и пароли администраторов.
    • Обновите любые сохраненные соединения (внешние сервисы), которые используют учетные данные сайта.
  6. Резервные копии
    • Убедитесь, что у вас есть недавние чистые резервные копии. Если вы подозреваете компрометацию, изолируйте резервные копии, созданные до предполагаемого времени компрометации.
  7. Уведомите соответствующие стороны.
    • Информируйте провайдера хостинга, контакт по безопасности и заинтересованные стороны по мере необходимости.

Рекомендации по смягчению, специфичные для WP‑Firewall.

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

  1. Виртуальное патчирование (блокировка по параметру).
    • Блокируйте или проверяйте параметр параметр на конечных точках администратора Tutor LMS. Разрешайте только безопасные форматы даты (например, YYYY-MM-DD) и отклоняйте все, что содержит ключевые слова SQL или специальные символы, кроме цифр, дефисов и косых черт.
    • Примените строгий лимит длины (например, 10–20 символов) для ввода даты.
    • Отклоняйте ввод, содержащий процентное кодирование одинарных кавычек, точек с запятой или комментариев, типичных для SQL-пayload.
  2. Блокировка на основе шаблонов.
    • Блокируйте запросы, содержащие мета-символы SQL или ключевые слова в параметрах запроса, которые не должны их содержать.
    • Ограничьте частоту повторных попыток изменения параметров с одного и того же IP.
  3. Аутентификация и проверки возможностей
    • Обеспечить доступ к административным конечным точкам только для проверенных администраторских сессий и известных диапазонов IP-адресов администраторов, где это возможно.
    • Мониторить администраторские сессии, используемые из новых географических местоположений.
  4. Обнаружение аномалий
    • Мониторить всплески времени выполнения запросов к базе данных или новые долгосрочные запросы, исходящие от конечных точек плагинов.
  5. Шаблон виртуального патча (псевдозакон)
    • Следующее является независимым от поставщика концептуальным правилом WAF, которое вы можете сопоставить с вашим WAF:
      • Цель: Запросы к административным маршрутам, содержащим ‘/tutor/’ или известные конечные точки администратора Tutor LMS.
      • Условие A: Параметр параметр присутствует и не соответствует регулярному выражению ^\d{4}(-\d{2}(-\d{2})?)?$ (разрешить yyyy или yyyy-mm или yyyy-mm-dd).
      • Условие B: Параметр содержит символы, отличные от 0-9, -, / (блокировать).
      • Условие C: Параметр содержит SQL-ключевые слова (без учета регистра): SELECT, UNION, INFORMATION_SCHEMA, DROP (блокировать).
      • Действие: Заблокировать запрос и записать полные заголовки/полезную нагрузку для судебного анализа.
    • Примечание: Не применяйте слишком широкие блокировки SQL-ключевых слов к конечным точкам, ориентированным на пользователей, где законный текстовый ввод может содержать эти слова. Ограничьте это административными/специфическими конечными точками плагинов.
  6. Виртуальное патчирование через положительную фильтрацию (белый список)
    • Где это возможно, предпочитайте белые списки (разрешайте только строгий формат даты) вместо черных списков. Белые списки более устойчивы к уклонению.
  7. Рекомендации по усилению безопасности, которые WP‑Firewall будет применять или помогать с ними:
    • Примените 2FA ко всем учетным записям администраторов.
    • Защитите wp-login и wp-admin, используя дополнительный контроль доступа (ограничение IP или капча).
    • Включите частые автоматические сканирования и проверки целостности файлов.
    • Авто-блокировка IP-адресов с повторяющейся подозрительной активностью администратора.

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


Руководство по реагированию на инциденты (пошаговое)

Если вы подозреваете эксплуатацию или подтвердили её, следуйте этой эскалированной процедуре.

  1. Содержать
    • Отключите сайт или переведите его в режим обслуживания, если данные являются конфиденциальными.
    • Временно отключите уязвимый плагин (Tutor LMS), если это возможно и безопасно для ваших пользователей.
    • Блокируйте подозреваемые IP-адреса атакующих на брандмауэре.
  2. Сохраняйте доказательства
    • Сохраняйте журналы веб-сервера и базы данных — создавайте безопасные копии.
    • Захватите снимок памяти, если хост это поддерживает и инцидент серьезный.
  3. Расследовать
    • Ищите в журналах доступ к административным конечным точкам и аномалиям в момент подозреваемой эксплуатации.
    • Ищите созданных/измененных администраторов, неожиданные записи в базе данных или новые запланированные задачи.
    • Сканируйте файлы на наличие недавно измененных или новых PHP-файлов, подозрительного кода или веб-оболочек.
  4. Искоренить
    • Удалите задние двери и подозрительные файлы.
    • Очистите или восстановите скомпрометированные компоненты из надежных источников и повторно примените обновления безопасности.
    • Смените все учетные данные для администраторов, учетных записей базы данных и любых токенов.
  5. Восстанавливаться
    • Восстановите из известных хороших резервных копий, если это необходимо.
    • Повторно применяйте обновления и повторно включайте плагины только после проверки состояния.
  6. Проведите обзор и отчет
    • Проведите послеследственный обзор, чтобы определить коренную причину, временные рамки и влияние.
    • Документируйте извлеченные уроки и улучшайте контроль за обнаружением и предотвращением.
  7. Уведомить заинтересованных лиц
    • В зависимости от юридических или контрактных обязательств, информируйте клиентов и регулирующие органы, если данные пользователей были раскрыты.

Обнаружение и мониторинг — практические запросы и поиски

Ниже приведены безопасные, практические поиски, которые помогут вам обнаружить подозрительную активность. Это советы общего характера, а не конкретные индикаторы C2:

  • Ищите в журналах доступа веб-сервера запросы к административным маршрутам с дата= или аналогичными параметрами. Сортируйте по частоте и аномалиям.
  • В журналах активности WordPress проверьте:
    • Создание новых пользователей с ролью администратора за короткий промежуток времени.
    • Запросы на сброс пароля и изменения электронной почты для учетных записей администраторов.
  • Мониторьте журналы запросов к базе данных (или временно включите общий лог запросов) и ищите:
    • Запросы, которые содержат ключевые слова, такие как INFORMATION_SCHEMA, UNION или /* — они часто присутствуют в попытках SQLi.
    • Долгосрочные и новые типы запросов к таблицам, содержащим конфиденциальные данные.
  • Используйте мониторинг целостности файлов, чтобы обнаружить измененные файлы плагинов или тем (сравните с контрольными суммами оригинального пакета).

Если эти проверки указывают на потенциальное нарушение, эскалируйте к плану реагирования на инциденты выше.


Как разработчики плагинов должны были предотвратить это

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

  1. Санитация данных и параметризация
    • Всегда используйте параметризованные запросы (для WordPress используйте $wpdb->prepare или подготовленные выражения с использованием абстракции базы данных).
    • Избегайте конкатенации необработанного ввода в SQL-строки.
  2. Валидация ввода
    • Используйте строгую санитацию и валидацию ввода, особенно для параметров, которые должны следовать известному формату (например, используйте регулярные выражения или функции санитации WP).
    • Используйте схему REST API WordPress для определения и обеспечения типов параметров.
  3. Проверки возможностей
    • Проверьте возможности пользователя с помощью проверок возможностей (например, current_user_can()) перед выполнением чувствительных запросов.
    • Убедитесь, что действия, выполняемые в администраторских контекстах, требуют минимально необходимых привилегий.
  4. Нонсы и защита от CSRF
    • Защитите администраторские действия и AJAX конечные точки с помощью правильных nonce и проверок возможностей.
  5. Ведение журнала и мониторинг
    • Записывайте подозрительные или неправильно сформированные попытки ввода для проверки.
    • Избегайте чрезмерного ведения журналов чувствительных данных (защищайте конфиденциальность пользователей).
  6. Проверка безопасности и фуззинг
    • Включите тестирование безопасности в процесс выпуска (статический анализ, динамическое сканирование, фуззинг пользовательских вводов).

Долгосрочные профилактические меры для владельцев сайтов

  • Поддерживайте строгий жизненный цикл плагинов: удаляйте неиспользуемые плагины и обновляйте все.
  • Ограничьте количество администраторов: используйте роли с минимально необходимыми возможностями для повседневных задач.
  • Применяйте 2FA и строгие политики паролей для всех учетных записей на уровне администратора.
  • Включите автоматические резервные копии, хранящиеся вне сайта, и регулярно проверяйте восстановление.
  • Используйте тестовые среды для проверки обновлений плагинов перед развертыванием в производственной среде.
  • Запланируйте периодические проверки безопасности и моделирование угроз, особенно если ваш сайт обрабатывает платежи, данные студентов или личную информацию.
  • Храните руководство по инцидентам безопасности и контакты (поддержка хостинга, специалисты по безопасности).

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

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

Более того, защитники могут предотвратить злоумышленников от установления постоянства с самого начала, закрывая известные уязвимые векторы и применяя компенсирующие меры.


Примеры соображений правил WAF (практические, независимые от поставщика)

  • Ограничьте правило только конечными точками администратора Tutor LMS (уменьшите количество ложных срабатываний).
  • Включите в белый список действительные параметр форматы по отдельности (например, yyyy, yyyy-mm, yyyy-mm-dd).
  • Отклонять или очищать любые данные, которые включают:
    • Single quotes (‘), double dashes (–), semicolons (;), URL‑encoded single quotes (%27) — specifically when they appear in the параметр параметр.
    • SQL-ключевых словах (INFORMATION_SCHEMA, UNION, SELECT, DROP) в параметрах, которые не должны их содержать.
    • Чрезмерная длина, превышающая ожидаемый размер токена.
  • Логировать заблокированные запросы и отправлять уведомление администратору сайта для проверки.
  • Добавить временные правила, которые увеличивают чувствительность в периоды высокого риска (например, высокопрофильные запуски).

Помните: наиболее надежный подход — это белый список допустимых форматов, а не черный список.


Контрольный список проверки после смягчения

  • Tutor LMS обновлен до версии 3.9.9 или более поздней во всех средах.
  • Правила WAF были развернуты и протестированы (проверьте, что они не блокируют законную деятельность администратора).
  • Учетные записи администраторов имеют включенную 2FA и неиспользуемые администраторы удалены.
  • Учетные данные базы данных были изменены, если подозревалось нарушение.
  • Проверки целостности файлов не показывают несанкционированных изменений.
  • Резервные копии известны как хорошие, и восстановление было протестировано.
  • Мониторинг/уведомление о аномалиях конечной точки администратора работает.

Сценарии из реальной жизни и рекомендации

  • Малые сайты (один администратор, низкий трафик): Быстро обновите плагин, включите 2FA и выполните сканирование на наличие вредоносных программ/целостности файлов. Рассмотрите возможность использования управляемых бесплатных защит WP‑Firewall во время патча.
  • Сайты среднего размера (несколько администраторов, платные курсы): Согласуйте окно обслуживания, обновите плагин на мультисайтовых экземплярах, если используется, смените учетные данные и проведите тщательный аудит базы данных и учетных записей пользователей.
  • Корпоративный (пользовательские интеграции, интеграторы LMS): Включите реагирование на инциденты, отключите сайт при необходимости, сохраните журналы и примените виртуальное патчирование на периметре, одновременно развертывая исправления разработчиков в разных средах.

Практическое, дружелюбное слово от WP‑Firewall

Мы знаем, что безопасность — это не второстепенный вопрос — это операционная работа, которая должна вписываться в ваши окна обновлений, бизнес-графики и обязательства перед клиентами. Уязвимости, такие как SQLi Tutor LMS, подчеркивают, почему важны многослойные защиты и операционная готовность. Часто обновляйте свои плагины, ограничивайте доступ администраторов и используйте сильные периметральные защиты, чтобы выиграть время, когда требуются срочные патчи.


Начните защищать свой сайт сегодня — план WP‑Firewall Basic (Бесплатный)

Заголовок: Быстро защитите ваш WordPress с помощью WP‑Firewall Basic (Бесплатно)

Если вы хотите немедленной, бесплатной защиты, пока вы координируете обновления и усиление безопасности, план WP‑Firewall Basic (Бесплатно) предоставляет вам основные возможности безопасности без сложности. Бесплатный план включает управляемый брандмауэр, защиту веб-приложений (WAF), неограниченную пропускную способность, сканер вредоносных программ и смягчение рисков OWASP Top 10 — практический первый уровень защиты от уязвимостей, таких как SQL-инъекция Tutor LMS. Зарегистрируйтесь и быстро запустите защитные правила и сканирование: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

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


Заключительные мысли

CVE‑2026‑6080 является ясным напоминанием о том, что даже уязвимости, доступные только администраторам, могут иметь значительные последствия. Самое быстрое и чистое решение — обновить плагин до версии 3.9.9 или выше. Если вы не можете обновить немедленно, примените виртуальное патчирование, ограничьте доступ администраторов, укрепите аутентификацию и следите за журналами на предмет подозрительной активности. Сочетайте это с долгосрочными практиками — строгой гигиеной плагинов, ограниченными ролями администраторов и непрерывным мониторингом — и вы значительно снизите риск компрометации.

Если вам нужна помощь в реализации виртуальных патчей, тонкой настройке правил WAF или проведении аудита инцидентов, команда WP‑Firewall готова помочь. Безопасность — это командный вид спорта: своевременное обнаружение, быстрое сдерживание и последующее усиление важнее, чем любое одноразовое решение.


Приложение — быстрый справочник

  • Затронуты: Tutor LMS <= 3.9.8
  • Исправлено: Tutor LMS 3.9.9+
  • CVE: CVE‑2026‑6080
  • CVSS: 7.6
  • Необходимые привилегии: Администратор (аутентифицированный)
  • Немедленные действия: Обновите плагин до 3.9.9+, включите 2FA, примените правило WAF для белого списка параметр форматы, проверьте учетные записи администраторов и журналы.

Если хотите, WP‑Firewall может предоставить короткий, индивидуальный контрольный список для вашего сайта (предложения по усилению IP, примеры индивидуальных правил WAF для вашего хостинга и поэтапный план обновления). Просто дайте нам знать, в какой среде вы работаете (один WP, мультисайт, управляемый хостинг), и мы подготовим краткий план действий.


wordpress security update banner

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

Подпишитесь, чтобы каждую неделю получать обновления безопасности WordPress на свой почтовый ящик.

Мы не спамим! Читайте наши политика конфиденциальности для получения более подробной информации.