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

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

WordPress Backup Guard Plugin Vulnerability

Имя плагина Плагин WordPress Backup Guard
Тип уязвимости Прохождение пути
Номер CVE CVE-2026-4853
Срочность Низкий
Дата публикации CVE 2026-04-19
Исходный URL-адрес CVE-2026-4853

JetBackup (Backup) Уязвимость обхода пути (CVE-2026-4853) — Что владельцам сайтов на WordPress нужно сделать сейчас

Недавно раскрытая уязвимость, затрагивающая версии до 3.1.19.8 широко используемого плагина резервного копирования WordPress (JetBackup / Backup Guard), позволяет аутентифицированному администратору предоставить специально подготовленное имя файла и удалять произвольные директории в файловой системе через обход пути в имяФайла параметре. Проблеме присвоен CVE-2026-4853, и она была исправлена в версии 3.1.20.3.

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

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


Исполнительное резюме (список быстрых действий)

  • Затронутые версии плагина: <= 3.1.19.8
  • Исправлено в: 3.1.20.3 — обновите немедленно до 3.1.20.3 или более поздней версии.
  • CVE: CVE-2026-4853
  • Класс уязвимости: Обход пути, приводящий к произвольному удалению директорий (Нарушение контроля доступа)
  • Необходимые привилегии: Администратор (должен быть аутентифицирован)
  • Базовый балл CVSS (публичный совет): 4.9 — низкий, но разрушительный при сочетании с другими проблемами
  • Немедленные шаги:
    1. Обновите плагин до 3.1.20.3 (или исправленной версии, предоставленной поставщиком).
    2. Если вы не можете обновить немедленно, примените виртуальное патчирование через ваш WAF (примеры ниже).
    3. Проверьте учетные записи администраторов, измените учетные данные и включите 2FA.
    4. Проверьте резервные копии, хранящиеся вне сайта, и убедитесь, что они целы.
    5. Мониторьте журналы на предмет подозрительных имяФайла параметры и неожиданные удаления.

Техническая проблема простым языком

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

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

  • Плагин предоставляет действие администратора, где аутентифицированный администратор может удалить резервные файлы, отправив имяФайла параметр.
  • Плагин недостаточно ограничивал или канонизировал этот параметр. Путем предоставления последовательностей обхода пути (например, ../../../wp-config.php или закодированных вариантов) злоумышленник с правами администратора может заставить процедуры удаления работать за пределами ожидаемой директории резервного копирования.
  • В результате могут быть удалены произвольные директории или файлы, которые могут включать директории других плагинов, загрузки, резервные хранилища или файлы ядра WordPress.

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


Почему это важно (не только CVSS)

Публичное уведомление присваивает относительно низкий балл CVSS (4.9) из-за требуемых высоких привилегий. Тем не менее, с операционной точки зрения уязвимость опасна по нескольким причинам:

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

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


Как может выглядеть эксплойт (концептуально)

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

  • POST /wp-admin/admin-post.php?action=jetbackup_delete
  • Тело: fileName=../../../wp-content/uploads/old-backups/important-dir

Или через AJAX конечную точку администратора с имяФайла содержащим закодированный обход:

  • POST /wp-admin/admin-ajax.php?action=delete_backup
  • Body: fileName=wp-contentuploadsold-backupsimportant-dir

Если плагин объединяет эту строку в вызов unlink/rmdir без проверки канонического пути или обеспечения его нахождения в пределах предполагаемой директории резервного копирования, удаление будет успешным.


Пример уязвимости (псевдокод)

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

<?php

Почему это опасно: $file может включать ../ и экранирование $dir. Без канонизации и проверки, realpath() или basename() проверки не используются, что позволяет удаление вне $dir.


Шаблон безопасной обработки ввода (усиление на стороне сервера)

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

<?php

Важные заметки:

  • basename() само по себе недостаточно в каждой ситуации. В сочетании с realpath() и сравнением с разрешенной базовой директорией это становится надежным.
  • Избегайте выполнения операций с файловой системой напрямую на пользовательском вводе без таких проверок.

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

  1. Обновите плагин до исправленной версии (3.1.20.3 или позже) — сделайте это в первую очередь и убедитесь, что обновление прошло успешно.
  2. Если вы не можете выполнить обновление немедленно:
    • Отключите плагин, пока не сможете безопасно обновить (если ваш процесс резервного копирования может терпеть временную паузу).
    • Или примените правила виртуального патча на вашем WAF (примеры ниже).
  3. Отозвать или изменить учетные данные для аккаунтов, которые не должны иметь доступ администратора; провести аудит недавней активности администратора.
  4. Включить/требовать двухфакторную аутентификацию для всех учетных записей администратора.
  5. Проверить целостность критических директорий (wp-content, плагины, загрузки) и ваших резервных копий, хранящихся вне сайта.
  6. Ужесточить разрешения файловой системы (где это возможно), чтобы ограничить, какой системный пользователь может удалять веб-процесс.
  7. Мониторить журналы доступа на предмет подозрительной активности. имяФайла параметры и массовые шаблоны удаления.
  8. Если вы обнаружите активность удаления, изолируйте сайт, сохраните журналы и восстановите из известной хорошей резервной копии.

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

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

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

Пример Nginx (в конфигурации вашего сайта):

# block fileName parameter with traversal sequences (case-insensitive, includes encoded forms)
if ($arg_fileName ~* "(?:\.\./|\.\.\\||)") {
 return 403;
}

Apache (mod_rewrite в .htaccess):

# Block requests where fileName argument contains path traversal patterns (encoded or plain)
RewriteEngine On
RewriteCond %{QUERY_STRING} fileName=.*(\.\./|\.\.\\||) [NC,OR]
RewriteCond %{REQUEST_BODY} fileName=.*(\.\./|\.\.\\||) [NC]
RewriteRule .* - [F]

Пример ModSecurity:

SecRule ARGS:fileName "@rx (?:\.\./|\.\.\\||)" \
 "id:1001001,phase:2,deny,log,msg:'Blocked path traversal attempt in fileName param (CVE-2026-4853)'

Общая подпись WAF (концепция):

  • Блокировать, если любой запрос включает аргумент с именем имяФайла (или аналогичное ожидаемое имя параметра), содержащий ../ или закодированные эквиваленты, такие как %2e%2e%2f или 2e2e2f (двойное кодирование).

Примечания:

  • Измените имя параметра, чтобы оно соответствовало тому, как плагин его отправляет (регистры могут различаться: имяФайла, имя файла, и т.д.).
  • Черный список не должен нарушать законные процессы, использующие многодиректориальные имена; тщательно протестируйте.
  • Держите правило активным, пока не обновите плагин.

Обнаружение и реагирование на инциденты: что искать сейчас

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

  • HTTP-запросы к конечным точкам администрирования плагина, содержащие имяФайла параметр:
    • Примеры: admin-ajax.php, admin-post.php, или специфические страницы администрирования плагина.
  • Запросы, в которых имяФайла содержит ../, .., %2e%2e%2f, или другие закодированные последовательности обхода.
  • Внезапные удаления директорий под wp-контент, загрузки, или папками плагина.
  • Пропавшие или пустые резервные директории, которые ранее были.
  • Временные метки модификации файловой системы, совпадающие с подозрительной активностью на уровне администратора.
  • Повышенная активность от конкретных учетных записей администратора (внезапные всплески в POST-запросах).

Команды поиска (пример; выполните на журналах или экспортах журналов):

# grep access logs for the fileName parameter (simple)
zgrep -i "fileName=" /var/log/nginx/access.log*
# look for encoded traversal attempts
zgrep -i "" /var/log/nginx/access.log*
# search for admin-ajax requests with potential traversal patterns
zgrep -i "admin-ajax.php" /var/log/apache2/access.log* | zgrep -i -E "fileName=.*(\.\./|)"

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

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

Контрольный список восстановления после подтвержденного или подозреваемого удаления

  1. Сохраните доказательства: скопируйте журналы, дампы баз данных и снимок текущей файловой системы.
  2. Поменяйте учетные данные администратора и любые другие учетные данные привилегированных аккаунтов.
  3. Отмените любые неиспользуемые ключи API, токены OAuth или SSH-ключи, которые могли быть использованы.
  4. Переустановите плагин из источника поставщика после того, как патч станет доступен (при необходимости сначала удалите директорию плагина).
  5. Восстановите файлы из проверенной, известной хорошей резервной копии (предпочтительно вне сайта или неизменяемой резервной копии).
  6. Повторно просканируйте восстановленный сайт на наличие веб-оболочек, неизвестных администраторов или вредоносного ПО.
  7. Реализуйте долгосрочные меры по укреплению безопасности, указанные ниже.

Долгосрочное укрепление безопасности (уменьшение радиуса поражения для будущих проблем)

  • Принцип наименьших привилегий:
    • Минимизируйте количество учетных записей администраторов. Используйте учетные записи редакторов/авторов, где это возможно.
    • Используйте отдельные служебные учетные записи для автоматизации и меняйте учетные данные.
  • Обеспечьте двухфакторную аутентификацию для всех администраторов.
  • Ограничьте доступ к wp-admin по IP для известных адресов администраторов или через VPN для вашей команды.
  • Держите все плагины, темы и ядро WordPress обновленными; применяйте патчи в рамках вашего SLA.
  • Используйте управляемый WAF, который может автоматически применять виртуальные патчи и блокировать подозрительные шаблоны.
  • Установите строгие разрешения на файлы: убедитесь, что пользователь веб-сервера не может ненужно изменять каталоги кода.
  • Централизовать стратегию резервного копирования:
    • Храните резервные копии вне сайта и неизменяемыми, где это возможно.
    • Регулярно тестируйте восстановление.
    • Храните несколько поколений резервных копий.
  • Реализуйте мониторинг целостности файлов для обнаружения неожиданных удалений или изменений.
  • Ведите журнал активности администраторов и оповещения о аномальном поведении.

Для агентств и хостинг-провайдеров — как немедленно защитить клиентские флотилии

  • Сканируйте хостинг-аккаунты на наличие плагинов и уязвимых версий. Используйте WP-CLI для перечисления:
    wp плагин список --path=/path/to/site --format=json
  • Приоритизируйте клиентов с высоким уровнем риска: мультисайты, электронная коммерция и сайты с высоким трафиком.
  • Примените виртуальное патчирование по всему флоту, используя WAF на границе (пример правил выше).
  • Временно приостановите или отключите плагин на клиентских сайтах, где это безопасно; координируйтесь с клиентами, если резервные копии критически важны.
  • Предложите или обеспечьте аудит учетных записей администраторов и ротацию учетных данных для клиентов.
  • Предоставьте управляемую помощь по восстановлению клиентам с затронутыми или скомпрометированными сайтами.
  • Реализуйте мониторинг по всему флоту для обнаружения попыток эксплуатации (распространенные шаблоны запросов) и блокировки IP-адресов атакующих.

Является ли эта уязвимость чрезвычайной ситуацией?

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

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

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


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

В: Нужна ли аутентификация для атакующего?
О: Да — уязвимость требует прав администратора. Однако атакующие часто получают доступ администратора через фишинг, повторное использование учетных данных или скомпрометированные учетные данные поставщика. Любой сайт с слабыми административными контролями или устаревшими учетными записями администратора находится под более высоким риском.

В: Будет ли достаточно восстановления резервной копии после эксплуатации?
О: Восстановление необходимо, если критические файлы были удалены. Но сначала вы должны убедиться, что атакующий больше не может получить доступ к администратору (смените учетные данные, удалите задние двери) перед восстановлением, иначе атакующий может снова удалить резервные копии.

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

В: Должен ли я полностью отключить плагин?
О: Если вы не можете немедленно установить патч и не полагаетесь на другие немедленные меры, временное отключение плагина до его обновления является безопасным вариантом. Но убедитесь, что у вас есть альтернативный план резервного копирования.


Пример контрольного списка администратора (по шагам)

  1. Определите затронутые сайты:
    • Проверьте версии плагинов на разных сайтах.
  2. Запланируйте или примените патч для обновления до 3.1.20.3 или новее.
  3. Если установка патча задерживается, примените правила WAF для блокировки обхода в имяФайла.
  4. Проверьте учетные записи администратора и включите 2FA.
  5. Проверьте целостность резервных копий и подготовьте план восстановления.
  6. Мониторьте журналы на предмет подозрительных имяФайла запросов и событий удаления.
  7. Проведите сканирование после патча на отсутствие файлов и восстановите при необходимости.

Защитите свой сайт за считанные минуты — начните с бесплатного плана WP‑Firewall

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

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


Заключительные заметки от команды безопасности WP‑Firewall

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

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

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

Будьте в безопасности и устанавливайте патчи своевременно.

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


wordpress security update banner

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

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

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