Имя плагина	Тема WordPress Miller
Тип уязвимости	Включение локального файла
Номер CVE	CVE-2026-28053
Срочность	Высокий
Дата публикации CVE	2026-03-01
Исходный URL-адрес	CVE-2026-28053

Срочно: Уязвимость локального включения файлов (LFI) в теме Miller WordPress (≤ 1.3.3) — что владельцам сайтов нужно сделать сейчас

Краткое содержание: Критическая уязвимость локального включения файлов (LFI) (CVE-2026-28053) была раскрыта для версий темы Miller WordPress до и включая 1.3.3. Проблема позволяет неаутентифицированным злоумышленникам включать локальные файлы с уязвимого сайта и отображать их содержимое, что может привести к раскрытию учетных данных, полному компрометации базы данных или удаленному выполнению кода в зависимости от окружения. Базовый балл CVSS 3.1: 8.1 (Высокий). Если вы используете тему Miller (или управляете сайтами, которые ее используют), отнеситесь к этому как к первоочередной задаче.

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

---

Оглавление

• Что такое локальное включение файлов (LFI)?
• Что мы знаем о CVE-2026-28053 в теме Miller
• Почему эта уязвимость важна для сайтов WordPress
• Индикаторы компрометации (IoCs), на которые следует обратить внимание
• Немедленные шаги по смягчению (быстро, безопасно)
• Рекомендуемые меры по усилению безопасности и изменения конфигурации
• Обнаружение и реагирование на компрометацию
• Примеры правил WAF / сервера, которые вы можете развернуть (шаблоны блокировки и рекомендации)
• Как WP-Firewall может помочь (бесплатный план и быстрое смягчение)
• Долгосрочные рекомендации и контрольный список после инцидента
• Приложение: Полезные команды, образцы журналов и контрольный список

---

Что такое локальное включение файлов (LFI)?

Локальное включение файлов (LFI) — это класс уязвимости, при котором веб-приложение включает файлы из локальной файловой системы сервера на основе пользовательского ввода. В типичном сценарии LFI злоумышленник манипулирует параметром в URL или форме, чтобы приложение прочитало и вернуло содержимое таких файлов, как:

• wp-config.php (содержит учетные данные базы данных)
• .htaccess
• любой PHP файл (потенциально раскрывающий исходный код)
• системные файлы, такие как /etc/passwd

Хотя LFI сам по себе не обязательно позволяет удаленное выполнение кода (RCE), он часто является ступенькой. Например, злоумышленник может:

• Прочитать wp-config.php => получить учетные данные БД => перейти к захвату БД или перейти к другим действиям.
• Прочитать журналы, которые содержат внедренный PHP код, или загрузить журналы для достижения RCE.
• Используйте другие неправильные настройки (например, записываемые директории загрузки), чтобы разместить вредоносные файлы, а затем включить их.

Уязвимости LFI являются частью широких рисков “инъекции”, перечисленных в OWASP, и в WordPress часто приводят к полному компрометации сайта, если их не устранить быстро.

---

Что мы знаем о CVE-2026-28053 (тема Miller ≤ 1.3.3)

• Тип уязвимости: Локальное включение файлов (LFI)
• Затронутые версии: Версии темы Miller ≤ 1.3.3
• CVE: CVE-2026-28053
• Аутентификация: Не требуется (неаутентифицировано)
• Базовый балл CVSS: 8.1 (Высокий)
• Классификация OWASP: Инъекция (A3)
• Сообщается: исследователем безопасности (подробности публичного раскрытия различаются)
• Официальный патч: На момент написания официального патча темы от автора темы нет (подтвердите на странице поставщика темы для обновлений). Пока официальный патч не будет выпущен, сайты остаются под угрозой и должны полагаться на меры по смягчению.

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

---

Почему это опасно для владельцев сайтов на WordPress

Существует три основных последствия LFI в теме WordPress:

1. Раскрытие учетных данных — wp-config.php часто содержит учетные данные базы данных в открытом виде, соли и секретные ключи. Раскрытие этих данных может обеспечить полный доступ к базе данных и административный захват.
2. Удаленное выполнение кода или контроль над сайтом — сочетание LFI с записываемыми директориями или отравление журналов, которые позже будут включены, может привести к RCE. RCE позволяет злоумышленнику устанавливать задние двери, порочить сайт или размещать вредоносное ПО.
3. Эскалация привилегий и перемещение — с учетными данными базы данных или выполнением командной оболочки злоумышленники могут создавать администраторов, экстрагировать пользовательские данные, использовать хостинг сайта для атак на другие сети или монетизировать доступ.

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

---

Индикаторы компрометации (на что обратить внимание прямо сейчас)

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

• Журналы доступа HTTP с запросами, содержащими последовательности обхода директорий (../ или ..\\) или попытки доступа к файлам темы с параметрами, такими как ?file=, ?template=, ?inc=, и т. д.
• Подозрительные GET-запросы, ссылающиеся на /wp-content/themes/miller/ или подобные с закодированной навигацией: %2e%2e%2f или 2e2e2f.
• Запросы, содержащие строки, такие как /etc/passwd, wp-config.php, или php://filter/ в аргументах.
• Неожиданное создание или изменение файлов в wp-content/uploads, wp-content/themes или других директориях с правами на запись для всех.
• Новые учетные записи администраторов, созданные в странное время.
• Неожиданные исходящие соединения с сервера или задания cron, которые запускают неизвестные PHP-скрипты.
• Оповещения от вашего сканера безопасности о изменениях файлов, измененных временных метках или измененных контрольных суммах в файлах тем.

Если вы видите какие-либо такие журналы или артефакты, переходите к реагированию на инциденты (см. ниже).

---

Немедленные меры по смягчению последствий — что делать в следующие 60–120 минут

1. Если сайт использует тему Miller (активную или присутствующую), немедленно отключите ее, если это возможно
   • Временно переключитесь на известную хорошую стандартную тему (Twenty Twenty-Three или эквивалент).
   • Если вы не можете безопасно переключиться на сайте с большим объемом трафика, примените меры смягчения на основе WAF (см. следующие пункты).
2. Блокируйте векторы эксплуатации на веб-уровне
   • Примените правила WAF для блокировки запросов, содержащих последовательности навигации по файлам и попытки включения локальных файлов.
   • Если у вас есть межсетевой экран веб-приложений на уровне хоста или плагин на основе межсетевого экрана, добавьте подписи для смягчения, которые соответствуют шаблонам LFI (см. образцы правил в этой статье).
   • Отказывайте в запросах к конкретным конечным точкам включения тем, если они не требуются публично.
3. Ограничить прямой доступ к чувствительным файлам
   • Убедитесь, что wp-config.php не доступен для чтения публично и что права доступа к файлам ограничены (например, 400/440 для файлов, которым не нужен доступ на запись).
   • Добавьте правила .htaccess/nginx, чтобы запретить прямой доступ к *.php в подпапках темы, которые не должны выполняться публично.
4. Укрепите настройки PHP
   • Убедитесь, что allow_url_include отключен (по умолчанию он должен быть выключен).
   • Реализуйте ограничения open_basedir, чтобы ограничить доступ PHP к назначенным директориям.
   • Отключите опасные функции (если это возможно): exec, shell_exec, system, passthru, proc_open, popen.
5. Повернуть учетные данные
   • Если ваши журналы указывают на успешное чтение wp-config.php или других конфиденциальных файлов, немедленно измените учетные данные базы данных и ключи API, хранящиеся в файлах.
   • Сбросьте соли WordPress и пароли пользователей — принудительно сбросьте пароли для всех администраторов.
6. Изолируйте затронутый хост, если компрометация подтверждена.
   • Временно отключите сайт или ограничьте его по IP, пока не будет восстановлено чистое состояние.
7. Разверните временный виртуальный патч.
   • Если вы используете WAF или можете развернуть правила на обратном прокси/балансировщике нагрузки, добавьте правило для блокировки запросов, пытающихся выполнить локальное включение файлов (примеры ниже).
   • Виртуальное патчирование снижает немедленный риск, ожидая официального патча от поставщика.

---

Рекомендуемые меры по усилению безопасности и изменения конфигурации (в долгосрочной перспективе).

• Держите темы, плагины и ядро WordPress в актуальном состоянии. Но помните: обновления иногда задерживаются и могут быть недоступны сразу; виртуальное патчирование на основе WAF является полезной временной мерой.
• Удалите неиспользуемые темы и плагины. Даже неактивный код темы иногда может быть обнаружен и использован.
• Ограничьте права доступа к файлам:
  • Каталоги: 755 (или 750, где это уместно)
  • Файлы: 644 для большинства файлов; 440 или 400 для wp-config.php, если это позволяет пользователь сервера.
• Используйте open_basedir, чтобы ограничить PHP только необходимыми директориями.
• Реализуйте мониторинг целостности файлов: следите за контрольными суммами файлов тем/плагинов и уведомляйте о любых изменениях.
• Отключите выполнение PHP в директориях загрузок:

  # Запретить выполнение PHP в загрузках
  

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

• Убедитесь, что ваша хостинг-среда использует минимальные привилегии для пользователя базы данных — учетная запись БД должна иметь только необходимые привилегии (например, избегайте GRANT привилегий).
• Поддерживайте безопасные резервные копии с версионированием, хранящиеся вне сервера. В случае компрометации вы должны иметь возможность восстановить известное чистое состояние.

---

Обнаружение попыток эксплуатации — практические запросы и проверки

1. Ищите в HTTP журналах шаблоны:

   grep -i -E "(\.\./|\\|\\\|php://filter|wp-config.php|/etc/passwd)" /var/log/apache2/access.log

2. Проверьте журналы ошибок на наличие ошибок или предупреждений о включенных файлах:

   grep -i "не удалось открыть поток" /var/log/apache2/error.log

3. Ищите файлы, которые были недавно изменены в директориях плагинов/тем:

   find /var/www/html/wp-content -type f -mtime -7

4. Ищите подозрительное создание учетных записей администраторов в базе данных:

   Запросите таблицу wp_users на наличие учетных записей с неожиданными датами создания.

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

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

---

Процедура реагирования на инциденты (если вы подозреваете компрометацию)

1. Содержать
   • Блокируйте все атаки на брандмауэре/WAF.
   • Переведите сайт в режим обслуживания или ограничьте доступ по IP во время расследования.
2. Сохраняйте доказательства
   • Сделайте судебную копию журналов и файловой системы перед внесением разрушительных изменений.
   • Сделайте снимок сервера, где это возможно.
3. Искоренить
   • Удаляйте задние двери и вредоносные файлы.
   • Переустановите ядро WordPress, тему и плагины из известных хороших источников.
   • Замените скомпрометированные учетные данные (БД, админ WP, FTP, SSH).
   • Поменяйте любые ключи API, найденные в конфигурационных файлах.
4. Восстановление и проверка
   • Восстановите из известной чистой резервной копии.
   • Проверьте целостность файлов и просканируйте на наличие вредоносного ПО.
   • Убедитесь, что все патчи и меры по усилению безопасности применены.
5. Общение
   • Уведомите заинтересованные стороны, клиентов или пользователей в соответствии с политикой или законом, особенно если личные данные могли быть раскрыты.
6. Анализ после инцидента
   • Задокументируйте коренную причину (например, эксплуатация уязвимой темы include).
   • Пересмотрите процессы мониторинга и патчирования, чтобы предотвратить повторение.

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

---

Пример правил WAF / сервера для блокировки общих попыток LFI

Ниже приведены шаблоны, которые вы можете использовать в веб-приложении Firewall (WAF) или в качестве серверных правил для Apache mod_security или Nginx. Это не исчерпывающий список; настройте их под вашу среду, чтобы избежать ложных срабатываний. Если у вас много пользовательских маршрутов, сначала протестируйте в режиме без блокировки/логирования.

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

Общие шаблоны для обнаружения попыток обхода и включения

• Блокируйте запросы, содержащие:
  • ../ или ..\\ (не закодированные или закодированные)
  • %2e%2e%2f или 2e2e2f
  • php://filter
  • wp-config.php
  • /etc/passwd
  • ввод: файл=, включить=, инк=, шаблон=, страница=, путь= когда используется в контексте включения темы

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

SecRule REQUEST_URI|ARGS|ARGS_NAMES "@rx (\.\./|\\|\2e\2e|php://filter|wp-config\.php|/etc/passwd)" \"

Пример фрагмента конфигурации Nginx:

# блокировать подозрительные последовательности обхода

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

Если вы идентифицируете конкретный файл темы, который раскрывает параметр include (например inc.php?file=), ограничьте доступ к этой конечной точке:

• Запретить по умолчанию, разрешить по рефереру/IP или заблокировать весь внешний доступ, если это не необходимо.

Пример .htaccess для Apache:

<Files "inc.php">
  Require ip 192.0.2.0/24       # Only allow your IP range or internal systems
  Require all denied
</Files>

Используйте эти серверные защиты вместе с WAF для лучшего покрытия.

---

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

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

• Поддерживайте белый список разрешенных целей include (сопоставьте ключи, такие как заголовок1, подвал2 с фактическими путями к файлам).
• Проверяйте и нормализуйте имена файлов — никогда не принимайте ../.
• Избегайте динамических includes из пользовательского ввода. Если это необходимо, сопоставляйте только короткие токены с предопределенными путями.
• Используйте функции PHP для канонизации путей (realpath) и проверки, что файл находится в ожидаемой директории.

Псевдокод безопасного шаблона:

<?php

Никогда не принимайте полный путь к файловой системе и не позволяйте последовательностям обхода каталогов.

---

Как приоритизировать смягчение по всему вашему сайту

1. Создайте инвентаризацию сайтов и определите, какие используют тему Miller (активные или установленные).
2. Приоритизируйте активные сайты, доступные для публики или с высоким трафиком, для немедленных действий.
3. Применяйте правила WAF по всей сети, чтобы блокировать известные схемы эксплуатации, пока вы исправляете или удаляете тему.
4. Для некритичных сайтов рассмотрите возможность удаления темы или отключения выполнения PHP в ее каталогах до исправления.
5. После исправления или удаления продолжайте мониторинг в течение как минимум 30 дней, чтобы поймать задержанную активность после эксплуатации.

---

Как WP-Firewall помогает вам прямо сейчас

WP-Firewall специализируется на быстром виртуальном исправлении и постоянной защите во время выполнения для сайтов WordPress. Если вы управляете флотом сайтов или одним важным объектом, WP-Firewall предоставляет:

• Управляемые правила WAF, которые могут быть развернуты немедленно для блокировки схем LFI и известных сигнатур эксплуатации.
• Сканирование на наличие вредоносного ПО и мониторинг целостности файлов для обнаружения того, получил ли злоумышленник доступ к конфиденциальным файлам.
• Смягчение рисков OWASP Top 10 из коробки (включая попытки инъекций и включения файлов).
• Простой способ виртуально исправить уязвимые темы, пока официальное обновление не станет доступным от автора темы.

Защитите свой сайт сейчас — быстрая, бесплатная защита доступна

Мы рекомендуем каждому владельцу сайта WordPress подписаться на базовый (бесплатный) план WP-Firewall, чтобы быстро получить основные защиты: управляемый брандмауэр, неограниченная пропускная способность, WAF, сканирование на наличие вредоносного ПО и смягчение рисков OWASP Top 10. Этот бесплатный уровень предоставляет вам немедленную блокировку для общих схем LFI и инъекций, чтобы вы могли снизить риск, пока выполняете полное восстановление. Подпишитесь на бесплатный план здесь: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

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

---

Улучшения долгосрочной безопасности

LFI в Miller напоминает, что безопасность WordPress требует слоев:

• Управление исправлениями: поддерживайте ядро, темы и плагины в актуальном состоянии.
• Защита приложений: используйте WAF и усиливайте PHP.
• Минимальные привилегии: ограничьте права доступа к БД и файлам.
• Мониторинг + ведение журналов: мониторинг целостности файлов, хранение журналов и оповещение.
• Резервное копирование + восстановление: регулярные резервные копии с версиями вне хоста и проверенное восстановление.
• Безопасная разработка: разработчики тем и плагинов должны применять лучшие практики безопасного кодирования (белые списки для включений, валидация ввода, кодирование вывода).

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

---

Практический контрольный список — пошагово для владельцев сайтов (скопируйте этот список)

1. Определите, установлена ли тема Miller (активна или неактивна).
2. Если Miller активен:
   • Переключитесь на безопасную тему, если это возможно, ИЛИ
   • Немедленно разверните правила WAF для блокировки шаблонов LFI, если вы не можете переключиться.
3. Добавьте серверные правила для блокировки обхода пути и php:// запросов стилей.
4. Установите разрешения на файлы: wp-config.php 400/440, файлы 644, каталоги 755.
5. Отключите выполнение PHP в загрузках и других каталогах, не относящихся к коду.
6. Убедитесь, что allow_url_include = Off; реализуйте ограничения open_basedir.
7. Сканируйте файлы на изменения и проведите углубленное сканирование на наличие вредоносного ПО.
8. Проверьте журналы на попытки LFI и подозрительную активность администратора.
9. Если есть подозрение на компрометацию: сохраните журналы, отключите сайт, измените учетные данные, восстановите из чистой резервной копии и проведите обзор после инцидента.
10. Подпишитесь на управляемый WAF/виртуальное патчирование, чтобы снизить риск, ожидая официального патча.

---

Приложение: Полезные команды и примеры поисков

• Найдите недавно измененные файлы внутри тем:

  find /var/www/html/wp-content/themes/miller -type f -mtime -7 -ls

• Поиск веб-журналов на наличие последовательностей обхода:

  grep -iE "(\.\./|\\|php://filter|wp-config\.php|/etc/passwd)" /var/log/nginx/access.log

• Список пользователей WordPress, добавленных за последние 7 дней (MySQL):

  ВЫБРАТЬ ID, user_login, user_email, user_registered ИЗ wp_users ГДЕ user_registered >= NOW() - ИНТЕРВАЛ 7 ДНЕЙ;

• Проверьте конфигурацию PHP на наличие опасных настроек:

  php -i | grep -E "allow_url_include|open_basedir|disable_functions"

---

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

Этот LFI в теме Miller является реальным примером того, как одна уязвимая инклюзия или шаблон доступа к файлам в коде темы могут подвергнуть опасности весь сайт. Основные выводы:

• Рассматривайте любую уязвимость неаутентифицированной инклюзии файлов как высокоприоритетную.
• Не полагайтесь только на “ожидание патча”. Используйте виртуальное патчирование (WAF) и серверные меры контроля, чтобы немедленно уменьшить поверхность атаки.
• Меняйте учетные данные и проводите тщательное расследование, если подозреваете утечку wp-config.php или других секретов.
• Используйте многослойную защиту: WAF, укрепление хоста, безопасное кодирование, мониторинг и резервное копирование.

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

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