Уязвимость произвольной загрузки файлов в Auto Thumbnailer//Опубликовано 2026-02-03//CVE-2025-12154

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

Auto Thumbnailer Vulnerability

Имя плагина Авто миниатюратор
Тип уязвимости Произвольная загрузка файлов
Номер CVE CVE-2025-12154
Срочность Критический
Дата публикации CVE 2026-02-03
Исходный URL-адрес CVE-2025-12154

CVE-2025-12154 — Произвольная загрузка файлов в Авто миниятюратор (<= 1.0): Что владельцы сайтов WordPress должны сделать прямо сейчас

3 февраля 2026 года была опубликована критическая уязвимость произвольной загрузки файлов, затрагивающая плагин Авто миниятюратор WordPress (версии <= 1.0) (CVE-2025-12154). Уязвимость позволяет аутентифицированному пользователю с правами уровня Участник (или выше) загружать произвольные файлы в файловую систему сайта, что может быстро привести к удаленному выполнению кода (RCE), бэкдорам и полной компрометации сайта.

Этот совет написан командой безопасности WP‑Firewall. Ниже вы найдете четкое, практическое разбиение: как уязвимость работает на высоком уровне, реальное воздействие, шаги по обнаружению, немедленные меры, которые вы можете применить (ручные и на основе WAF), рекомендуемое долгосрочное укрепление и руководство по реагированию на инциденты, адаптированное для сайтов WordPress и администраторов.

Примечание: если вы используете Авто миниятюратор и ваша установленная версия <= 1.0, рассматривайте это как срочное, даже если у вас нет немедленных признаков компрометации. Нападающему нужна только учетная запись Участника (или учетная запись, которую можно повысить до Участника), чтобы злоупотребить этой проблемой.


Краткое резюме (TL;DR)

  • Затронутое программное обеспечение: Авто миниятюратор (плагин WordPress), версии <= 1.0.
  • Уязвимость: Произвольная загрузка файлов для аутентифицированных пользователей (Участник+) с потенциальным удаленным выполнением кода.
  • CVE: CVE-2025-12154.
  • Дата раскрытия: 3 фев 2026.
  • Предварительные условия эксплуатации: Учетная запись Участника (или выше) на целевом сайте WordPress (или учетная запись, которую можно повысить до Участника).
  • Степень серьезности: Высокая — произвольная загрузка файлов является высокорисковым вектором, поскольку она позволяет веб-оболочкам/бэкдорам.
  • Немедленные действия: Отключите плагин, удалите подозрительные загрузки, запретите выполнение в директории загрузок, заблокируйте уязвимые конечные точки с помощью вашего WAF, проведите аудит учетных записей участников, измените учетные данные и выполните полное сканирование на наличие вредоносных программ и проверку целостности.

Почему это важно: произвольная загрузка файлов — это быстрый путь к захвату

Уязвимости произвольной загрузки файлов являются одними из самых серьезных проблем для веб-приложений. Когда плагин позволяет записывать данные файлов в доступные через веб директории без строгой проверки (типа файла, MIME-типа, расширения, проверки содержимого) и без надежных проверок возможностей, злоумышленники могут размещать PHP веб-оболочки и затем вызывать их через HTTP для выполнения кода на сервере.

Даже если конечная точка плагина предназначена для изображений или миниатюр, злоумышленники часто могут обойти наивные проверки, выполняя:

  • Загрузку PHP файла, замаскированного под безобидное расширение (например, file.php.jpg) и полагаясь на серверы, которые выполняют .php содержимое.
  • Загрузку файла с действительными заголовками изображения, но с встроенными полезными нагрузками или трюками, которые вызывают удаленное выполнение в процессе обработки.
  • Использование слабых конфигураций сервера, где директория загрузок позволяет выполнение PHP.

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


Технический обзор (на высоком уровне, неэксплуатативный)

Плагин открывает путь загрузки или конечную точку AJAX/REST администратора, которая доступна для аутентифицированных пользователей с правами Конtributora. Один или несколько из этих средств безопасности отсутствуют или недостаточны:

  • Недостаточные проверки прав: конечная точка доверяет роли Конtributora для выполнения действия, которое должно быть более ограничительным (например, только для Администратора или Редактора).
  • Слабая или отсутствующая проверка файлов: плагин не надежно отклоняет файлы типов PHP, скриптов или других исполняемых файлов.
  • Отсутствие проверки содержимого: серверная валидация не проверяет содержимое файлов или MIME-тип эффективно.
  • Файлы хранятся в каталогах, доступных через веб (например, wp-content/uploads или папки, контролируемые плагином), с разрешением на выполнение.

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

Мы не будем предоставлять шаги эксплуатации здесь, но траектория риска проста: загрузка файла → написание веб-оболочки → выполнение кода через HTTP → постоянный доступ и эскалация привилегий.


Реальное воздействие: что может сделать злоумышленник

Если успешно эксплуатировано, злоумышленник может:

  • Загрузить PHP веб-оболочку или заднюю дверь и выполнить произвольный PHP код.
  • Создать административных пользователей, эскалировать привилегии или манипулировать содержимым базы данных.
  • Экстрагировать данные, включая записи пользователей, данные платежей или конфигурационные файлы.
  • Развернуть постоянное вредоносное ПО для SEO-спама, инъекций рекламы или криптодобычи.
  • Использовать скомпрометированный хост для перехода к другим системам (например, через собранные учетные данные или интерфейсы хостинг-провайдеров).
  • Вызвать порчу сайта или разместить ссылки, которые приведут к штрафам со стороны поисковых систем и внесению в черные списки.

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


Насколько вероятна эксплуатация?

Вероятность эксплуатации зависит от настроек сайта:

  • Высокая вероятность, если включена публичная регистрация и новые учетные записи по умолчанию имеют статус Конtributora или выше.
  • Высокая вероятность, если на сайте уже есть существующие пользователи Конtributora (гостевые блогеры, контентные команды).
  • Меньшая вероятность, если регистрация отключена, учетные записи участников редки, и соблюдаются строгие меры по 2FA/гигиене паролей.

Однако скомпрометированная учетная запись или злоумышленник с доступом через социальную инженерию могут превратить сценарий с низкой вероятностью в атаку с высокой вероятностью. Рассматривайте уязвимость как срочную.


Немедленные действия — пошаговый приоритетный контрольный список

Это шаги, которые вы должны предпринять сейчас, если вы управляете сайтом WordPress с установленным Auto Thumbnailer (<=1.0). Выполняйте их в порядке, указанном ниже; верхние действия содержат меры по снижению наибольшего риска.

  1. Определите уязвимость
       – Проверьте, установлен ли плагин и какая версия. В WP Admin: Плагины → найдите “Auto Thumbnailer” и запишите версию.
       – Если версия <= 1.0 — предполагайте, что уязвима, пока не будет доказано обратное.
  2. Немедленно отключите плагин (если возможно)
       – Если можете, деактивируйте плагин из WP Admin.
       – Если вы не можете получить доступ к администратору, переименуйте папку плагина через SFTP/SSH: wp-content/plugins/auto-thumbnailer → wp-content/plugins/auto-thumbnailer-disabled.
  3. Заблокируйте уязвимую конечную точку загрузки на уровне WAF
       – Добавьте временное правило WAF для блокировки запросов к конечной точке загрузки плагина (POST/PUT к известным путям плагина или AJAX-действиям). См. раздел WAF ниже для предложенных правил.
       – Если вы используете WP-Firewall, включите виртуальный патч, блокирующий подозрительные POST-запросы к конечным точкам плагина.
  4. Немедленно проверьте учетные записи участников
       – Проверьте всех пользователей с ролью Участник (и Редактор/Администратор).
       – Удалите или понизьте любые учетные записи, которые не нужны.
       – Принудительно сбросьте пароли для сотрудников и участников (особенно если вы не можете исключить компрометацию).
       – Примените MFA для пользователей с привилегированными ролями.
  5. Запретите загрузки участниками (временно)
       – Добавьте этот код в functions.php вашей темы (или через небольшой mu-плагин), чтобы временно заблокировать загрузки для участников:

    // Block media upload for contributors
    add_filter('user_has_cap', function($allcaps, $caps, $args) {
        $user = wp_get_current_user();
        if (in_array('contributor', (array) $user->roles)) {
            if ( isset($caps[0]) && $caps[0] === 'upload_files') {
                $allcaps['upload_files'] = false;
            }
        }
        return $allcaps;
    }, 10, 3);
    

       – Примечание: удалите это изменение после того, как плагин будет полностью исправлен и вы подтвердите безопасность.

  6. Запретите выполнение PHP в директории загрузок (немедленно и настоятельно рекомендуется)
       – Поместите файл .htaccess в wp-content/uploads с:

    <FilesMatch "\.(php|php5|phtml|phps)$">
      Order Deny,Allow
      Deny from all
    </FilesMatch>
    

       – Для Nginx используйте:

    location ~* /wp-content/uploads/.*\.(php|php5|phtml)$ {
    

       – Эти правила предотвращают выполнение загруженных PHP файлов, даже если они присутствуют.

  7. Ищите подозрительные файлы и признаки компрометации
       – Ищите неожиданные .php файлы в загрузках:

    find wp-content/uploads -type f -name "*.php" -o -name "*.phtml" -o -name "*.phar"
    

       – Ищите подозрительные недавно измененные файлы:

    find . -type f -mtime -30 -printf "%T+ %p
    

       – Проверьте журналы доступа на наличие активности POST к конечным точкам плагина или необычных запросов от неизвестных IP.

  8. Полное сканирование на наличие вредоносного ПО и проверки целостности
       – Проведите глубокое сканирование на наличие вредоносного ПО, охватывающее загрузки, файлы тем, плагины и mu-плагины.
       – Сравните текущие файлы ядра/плагина/темы с чистыми копиями из upstream (проверка контрольной суммы).
       – Если вы найдете вредоносные файлы, изолируйте их, и если возможно, восстановите из чистой резервной копии.
  9. Поменяйте учетные данные и ключи
       – Принудительно сбросьте пароли для учетных записей администратора/редактора/участника.
       – Поменяйте любые учетные данные или API ключи, которые могут храниться на сайте или связанных сервисах.
       – Если сайт использует FTP/SSH/SFTP, также поменяйте эти ключи/пароли.
  10. Уведомить заинтересованные стороны и мониторить
       – Уведомите свою команду, контентных авторов, провайдера хостинга (если вы подозреваете влияние на уровне хостинга).
       – Следите за журналами на предмет повторных попыток или новых индикаторов.
  11. Устранить и повторно включить
       – Когда автор плагина выпустит исправленную версию, убедитесь, что вы проверили исправление перед повторным включением.
       – Удаляйте временные блокировки возможностей только после тестирования.

WAF и виртуальное патчирование: что внедрить сейчас

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

Идеи правил WAF с высоким приоритетом:

  1. Блокировать прямые загрузки исполняемых расширений
    • Блокировать запросы, которые пытаются загрузить файлы с расширениями .php, .phtml, .phar, .asp, .aspx в именах файлов или в многокомпонентных данных формы.
  2. Блокировать известные конечные точки загрузки плагина для авто-миниатюры
    • Блокировать POST/PUT или ajax вызовы к конечным точкам загрузки плагина по параметру пути или действия. Пример логики:
      – Если запрос к /wp-admin/admin-ajax.php с параметром действия, используемым авто-миниатюрой → заблокировать или оспорить запрос.
  3. Принудительно проверять Content-Type/MIME
    • Отклонять загрузки multipart/form-data, где Content-Type не соответствует безопасному изображению MIME (image/png, image/jpeg, image/gif, image/webp).
    • Будьте осторожны: некоторые законные загрузки могут использовать другие MIME типы; сначала протестируйте на этапе подготовки.
  4. Блокировать имена файлов с двойными расширениями и подозрительными символами
    • Запрещать имена файлов, содержащие .php. или .phtml. или заканчивающиеся на .php независимо от добавленных других расширений (например, file.php.jpg).
  5. Мониторить и ограничивать действия с аутентификацией
    • Ограничьте количество POST-запросов к конечным точкам загрузки на аккаунт и по IP.
    • Отмечайте аккаунты, которые загружают много файлов за короткий промежуток времени.

Пример псевдозакона (похожий на ModSecurity, высокого уровня — адаптируйте для вашей платформы):

# Запретить загрузки, если имя файла содержит .php (двойные расширения) или расширение файла — php SecRule REQUEST_METHOD "POST" "phase:2,chain,deny,status:403,msg:'Блокировать возможную загрузку PHP файла'" SecRule REQUEST_HEADERS:Content-Type "multipart/form-data" "chain" SecRule FILES_NAMES|ARGS_NAMES "@rx \.php(\.|$)|\.(php|phtml|phar)$" "t:none"

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

Если у вас включено виртуальное патчирование WP‑Firewall, примените временное правило для перехвата и оспаривания любых запросов на загрузку, инициированных участниками, к плагину. Это обеспечивает немедленную защиту, пока развертывается постоянный патч плагина.


Укрепление директории загрузок (рекомендуемая лучшая практика)

Даже с исправлениями плагина и WAF, сделайте загрузки менее исполняемыми по дизайну:

  • Запретите выполнение PHP в загрузках через .htaccess (Apache) или конфигурацию Nginx (примеры выше).
  • Поместите файл index.html в директории загрузок, чтобы предотвратить перечисление директорий.
  • Установите права доступа к файлам так, чтобы загрузки были записываемыми веб-сервером, но не исполняемыми:
    – Директории: 755
    – Файлы: 644
  • Рассмотрите возможность запуска задания cron или мониторинга для регулярного удаления или карантина файлов с подозрительным расширением или нерегулярным владельцем.
  • Используйте сервис хранения, который отделяет загрузки от выполнения PHP (например, объектное хранилище вне сервера) для высокорисковых сред.

Обнаружение компрометации: индикаторы компрометации (IoCs)

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

  • Неожиданные PHP файлы в wp-content/uploads или папках плагинов.
  • Новые администраторы или измененные роли пользователей без ясных бизнес-причин.
  • Неожиданные исходящие сетевые соединения с сервера, особенно к необычным IP или доменам.
  • Необычная активность процессов на сервере (если у вас есть доступ к хосту).
  • Внезапное появление запланированных задач (cron jobs), которые вы не создавали.
  • Изменение внешнего вида, SEO-спам-страницы или вставленные ссылки в содержимое сайта.
  • Необычные всплески использования ЦП (возможный криптомайнинг) или дискового пространства.

Примеры поисковых запросов (SSH):

  • Найдите PHP файлы в загрузках:
    find wp-content/uploads -type f -iname "*.php"
    
  • Найти недавно измененные файлы в корне веб-сайта:
    find . -type f -mtime -7 -printf "%T+ %p
    
  • Grep для общих сигнатур функций веб-оболочки (используйте с осторожностью — могут быть ложные срабатывания):
    grep -R --exclude-dir=wp-content/plugins/auto-thumbnailer -n "eval(\|base64_decode(\|shell_exec(" .
    

Примечание: настройте шаблон grep и будьте осторожны с ложными срабатываниями в безвредном сжатом коде.


Практическое реагирование на инциденты: что делать, если вы нашли доказательства

  1. Изолировать
       – Временно отключите сайт или поместите его в режим обслуживания, если требуется полная изоляция.
       – Блокируйте IP-адреса атакующих на уровне брандмауэра, если наблюдается повторная активность.
  2. Сохранять
       – Сохраните журналы (журналы доступа, журналы ошибок, журналы WP) для анализа и, возможно, для юридических/судебных нужд.
       – Создайте судебную копию сайта, если у вас есть ресурсы.
  3. Искоренить
       – Удалите веб-оболочки и задние двери.
       – Замените скомпрометированные файлы ядра/плагинов/тем на известные чистые копии.
       – Удалите подозрительных пользователей и измените учетные данные.
       – Убедитесь, что нет оставшихся запланированных задач (проверьте записи cron в wp_options).
  4. Восстанавливаться
       – Восстановите сайт из чистой резервной копии, сделанной до компрометации, если шаги по устранению неясны или слишком рискованны.
       – Укрепите сайт (правила WAF, запрет выполнения PHP, обновление плагинов).
  5. После инцидента
       – Проведите анализ коренных причин, чтобы понять, как злоумышленник проник.
       – Реализуйте дополнительные превентивные меры (2FA, минимальные привилегии, периодическое сканирование).
       – Рассмотрите возможность проведения тестирования на проникновение или профессионального реагирования на инциденты для сложных нарушений.

Долгосрочная профилактика: политика и операционная безопасность

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

  • Принцип наименьших привилегий
    – Предоставляйте только минимально необходимую роль. Если пользователю нужно только отправить черновик, предоставьте минимальные возможности.
    – Удалите неактивные учетные записи пользователей.
  • Сильная аутентификация
    – Обеспечьте уникальные пароли и многофакторную аутентификацию для редакторов и администраторов.
    – Используйте SSO или корпоративные поставщики идентификации, где это возможно.
  • Жизненный цикл плагинов и инвентаризация
    – Ведите учет установленного плагина и их версий.
    – Удалите плагины, которые не используются или заброшены.
    – Подписывайтесь на каналы уязвимостей, которым вы доверяете, или интегрируйте сканирование уязвимостей в ваш CI/CD.
  • Мониторинг целостности файлов
    – Мониторьте критические директории на предмет изменений и уведомляйте о неожиданных модификациях.
  • Регулярные аудиты и резервные копии
    – Регулярно тестируйте резервные копии и проверяйте восстановление.
    – Запускайте запланированные проверки безопасности и просматривайте результаты.
  • Защита на уровне хоста
    – Держите PHP и серверные пакеты обновленными; используйте учетные записи системы с минимальными привилегиями.
    – Ограничьте возможность PHP записывать или выполнять код вне предназначенных директорий.

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

Ниже приведены правила в стиле WAF и фрагменты жесткой настройки сервера, которые вы можете адаптировать. Они являются защитными и предназначены для снижения риска эксплуатации.

  1. Блокировать двойное расширение имени файла (.php.jpg) в загрузках (псевдоправило):
    Если REQUEST_METHOD == POST и REQUEST_URI содержит "admin-ajax.php" или путь уязвимого плагина
    
  2. Отклонить загрузки с типом содержимого PHP:
    Если заголовок Content-Type для части файла равен "application/x-php" или расширение имени файла соответствует php
    
  3. Ограничить скорость загрузок от участников:
    Если user_role == contributor и запросы к конечной точке загрузки > X в минуту
    
  4. Запретить выполнение в директории загрузок — Apache (.htaccess):
    # Запретить выполнение PHP
    
  5. Запретить выполнение в загрузках — Nginx:
    location ~* ^/wp-content/uploads/.*\.(php|php5|phtml)$ {
    

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


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

  • Проверка версии:
    – WP Admin → Плагины: проверьте версию Auto Thumbnailer.
    – Или через WP CLI:

    wp плагин список --формат=csv | grep авто-миниатюра
    
  • Проверьте загрузки на наличие PHP:
    find wp-content/uploads -type f \( -iname "*.php" -o -iname "*.phtml" -o -iname "*.phar" \)
    
  • Ищите подозрительные запросы (журнал доступа Apache/Nginx):
    grep -i "admin-ajax.php" /var/log/nginx/access.log | grep -i "POST" | grep -i "авто-миниатюра"
    
  • Определите недавно добавленных пользователей:
    wp пользователь список --role=contributor --format=csv
    

    – Проверьте даты создания подозрительных новых аккаунтов.

  • Проверьте целостность сайта:
    wp core verify-checksums
    

Эти команды предполагают наличие доступа к WP-CLI и оболочке. Если у вас нет доступа к хостингу, согласуйте действия с вашим провайдером хостинга.


Если вы управляете несколькими сайтами: проведите сортировку и установите приоритеты

Для агентств, хостов и предприятий, управляющих множеством сайтов:

  • Используйте приоритизацию на основе риска:
    – Сайты с публичной регистрацией или множеством пользователей уровня контрибьютора имеют более высокий риск.
    – Сайты, размещающие чувствительные данные или интеграции (платежные сервисы), должны иметь приоритет.
  • Автоматизируйте обнаружение:
    – Запланируйте сканирование и обновление политики WAF для всех управляемых сайтов.
    – Используйте централизованное ведение журналов и SIEM для корреляции подозрительной активности на сайтах.
  • Пакетное смягчение:
    – Временно примените глобальное правило WAF, которое блокирует уязвимую конечную точку на всех сайтах до завершения патчирования.

О ответственной раскрытии и обновлениях

Эта уязвимость была ответственно сообщена (исследователь: kr0d) и опубликована с CVE-2025-12154. Разработчики плагинов и операторы сайтов должны следовать лучшим практикам безопасного раскрытия: согласовать патчирование и четко сообщать владельцам сайтов. Пока патч от поставщика не выпущен, рассматривайте плагин как ненадежный и применяйте вышеуказанные меры смягчения.


Защитите свой сайт — начните с бесплатного управляемого плана брандмауэра от WP‑Firewall

Обеспечьте безопасность вашего WordPress сейчас с помощью управляемого WAF и базовых защит

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

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

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

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


Окончательные рекомендации и резюме

  1. Если Auto Thumbnailer (<= 1.0) установлен на любом из ваших сайтов — считайте его уязвимым. Деактивируйте или заблокируйте плагин, пока не станет доступен исправленный релиз.
  2. Запретите выполнение PHP в загрузках сейчас (htaccess/nginx) и добавьте правила WAF для блокировки подозрительных загрузок или конечных точек загрузки плагина.
  3. Проверьте и защитите учетные записи участников — ограничьте загрузки и требуйте MFA, где это возможно.
  4. Проведите полное сканирование сайта на наличие веб-оболочек/задних дверей и удалите подозрительные файлы или восстановите из известной хорошей резервной копии.
  5. Включите управляемый уровень WAF/виртуального патчирования (например, бесплатный план WP‑Firewall) для немедленной защиты во время патчирования и устранения неполадок.

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


Если вы хотите получить пошаговый контрольный список или помощь в создании правил WAF, адаптированных к вашей хостинг-среде (Apache, Nginx или управляемые платформы), ответьте:

  • Есть ли у вас доступ к хостингу (SSH) и доступен ли WP‑CLI,
  • Используете ли вы наш управляемый WAF или нужны правила для стороннего брандмауэра,
  • Количество сайтов, требующих триажа.

Мы подготовим индивидуальные инструкции по устранению неполадок и фрагменты правил, которые вы сможете быстро и безопасно применить.


wordpress security update banner

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

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

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