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

Срочно: Уязвимость локального включения файлов в теме Welldone (<= 2.4) — что владельцы сайтов на WordPress должны сделать прямо сейчас

Обнаружена уязвимость локального включения файлов (LFI) высокой степени серьезности, затрагивающая тему WordPress Welldone (версии <= 2.4). Отслеживается как CVE-2026-28118 и имеет базовый балл CVSS 8.1, эта уязвимость позволяет неаутентифицированным злоумышленникам включать локальные файлы на уязвимом сайте и раскрывать их содержимое злоумышленнику. Поскольку информация, хранящаяся в локальных файлах (учетные данные базы данных, ключи API, детали конфигурации), может привести к полному компромиссу, требуется немедленное устранение для любого сайта, использующего затронутую тему.

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

Резюме раскрытия

• Затронутое программное обеспечение: тема WordPress Welldone
• Уязвимые версии: <= 2.4
• Тип уязвимости: Локальное включение файлов (LFI)
• CVE: CVE-2026-28118
• CVSS: 8.1 (Высокий)
• Требуемые привилегии: нет (без аутентификации)
• Влияние: Произвольное чтение локальных файлов; возможное раскрытие учетных данных и конфиденциальных файлов; может привести к полному захвату в зависимости от конфигурации сервера
• Сообщено: Тран Нгуен Бао Ханем (сообщено 19 августа 2025 года; публичное раскрытие 26 февраля 2026 года)

Почему LFI так опасен для сайтов WordPress

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

Для сайтов на WordPress последствия особенно серьезны:

• wp-config.php часто включает учетные данные базы данных и соли; чтение этого может дать злоумышленнику полный доступ к базе данных.
• Другие файлы могут содержать ключи API, учетные данные SMTP или конфиденциальные данные.
• Если обертки PHP (например, php://filter) или места загрузки доступны, злоумышленник может перейти от чтения файлов к выполнению кода (например, найдя и извлекая записываемую загрузку, которая позже будет использована для хранения задней двери).
• Поскольку уязвимость доступна без аутентификации, массовое автоматизированное сканирование и попытки эксплуатации вероятны — и мы ожидаем, что оппортунистические злоумышленники быстро нацелятся на открытые установки.

Как злоумышленники обычно эксплуатируют LFI (на высоком уровне)

Злоумышленник обнаруживает параметр, который используется в вызове включения файла (например, что-то вроде include( $template_path . $_GET['page'] . '.php' ); ). Если этот параметр не проверен, злоумышленник может отправлять запросы, которые ссылаются на другие локальные файлы через обход каталога (../../../../wp-config.php) или через обертки потоков PHP (php://filter, data://). Даже когда прямая инклюзия заблокирована, многие цепочки LFI могут быть превращены в удаленное выполнение кода (RCE), сначала открыв файлы, журналы или включив другие доступные ресурсы.

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

Признаки атаки и компрометации — на что обращать внимание

Следите за своими журналами (журналы доступа веб-сервера, журналы ошибок PHP, журналы WordPress) на наличие этих признаков:

1. Запросы, содержащие шаблоны обхода каталога в строках запроса:
   • Не закодированные или закодированные "../" последовательности (например, .., %2e%2e%2f)
   • Повторяющиеся попытки обхода, такие как ../../../../
2. Запросы, ссылающиеся на чувствительные имена файлов:
   • wp-config.php, wp-config.php.bak, .env, /etc/passwd, .htpasswd, и т. д.
3. Запросы, использующие общие имена параметров LFI:
   • Параметры запроса с именем файл, страница, шаблон, инк, путь, модуль, или другие
   • Внезапные всплески запросов к конечным точкам темы с различными полезными нагрузками обхода
4. Использование шаблонов обертки потоков PHP:
   • php://filter, ожидайте://, data:// появляющиеся в параметрах запроса
5. Аномальные записи в журналах или новые файлы PHP/JS в wp-контент/загрузки, wp-content/themes/ /, или других записываемых директориях:
   • Подозрительно названные файлы
   • Недавно измененные шаблоны или файлы плагинов, которые вы не изменяли
6. Внезапные необычные запросы к базе данных, неожиданное создание учетных записей администраторов или изменения в основных файлах темы/плагина.

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

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

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

1. Временно отключите уязвимую тему:
   • Переключитесь на стандартную тему (например, чистую, поддерживаемую стандартную тему). Это самый быстрый способ уменьшить поверхность атаки, если вы можете позволить себе кратковременное визуальное изменение.
   • Если это невозможно, переведите сайт в режим обслуживания, пока вы применяете другие меры.
2. Удалите или поместите уязвимую тему в карантин из файловой системы:
   • Если у вас есть доступ к серверу (SFTP/SSH), переименуйте или удалите директорию уязвимой темы из wp-content/themes/. Это предотвращает выполнение кода темы.
   • Важный: Сохраните копию (вне сервера) для анализа, если вы проводите расследование.
3. Блокируйте подозрительные запросы на веб-сервере или межсетевом экране веб-приложения:
   • Блокируйте запросы с последовательностями обхода директорий и попытками доступа к основным файлам:
   • Пример (nginx, упрощенный): отклонять запросы с закодированными .. последовательностями или php://:

   if ($request_uri ~* "(||\.\./|\.\.\\)") {
   

   • Примечание: Используйте осторожное тестирование перед применением правил на уровне сервера, чтобы избежать поломки легитимных URL; тестируйте на тестовом сайте, когда это возможно.
   • Пример (Apache .htaccess) — запретить прямой доступ к wp-config и заблокировать строки запроса с подозрительными шаблонами:

   <Files "wp-config.php">
     Order allow,deny
     Deny from all
   </Files>
   
   # Block attempts to access common sensitive files
   <IfModule mod_rewrite.c>
     RewriteEngine On
     # Block requests containing ../ or php:// or data:// (basic)
     RewriteCond %{QUERY_STRING} (\.\.|php://|data://) [NC,OR]
     RewriteCond %{REQUEST_URI} (\.\.|php://|data://) [NC]
     RewriteRule ^.* - [F,L]
   </IfModule>
   

4. Укрепите права доступа к файлам и их владельцам (быстрые проверки):
   • Гарантировать wp-config.php не является общедоступным для чтения. Рекомендуемые права:
     • wp-config.php → 400 или 440 в зависимости от настройки сервера
     • Каталоги → 755
     • Файлы → 644 (за исключением конфиденциальных файлов конфигурации, которые должны быть более строгими)
   • Убедитесь, что файлы принадлежат правильному пользователю (пользователь веб-сервера не должен владеть файлами, если ваш хост поддерживает более безопасное разделение).
5. Отключите опасные обертки и функции PHP, где это возможно:
   • В php.ini, убедитесь allow_url_fopen = Выключено и allow_url_include = Выключено. Это снижает риск удаленного включения файлов или злоупотребления обертками потоков.
   • Рассмотрите возможность отключения рискованных функций (только если ваше приложение не нуждается в них): исполнительный, shell_exec, система, проходной, proc_open, popen. Пример:

   disable_functions = exec,shell_exec,system,passthru,proc_open,popen
   

6. Блокируйте параметры, предоставленные пользователем, используемые для загрузки файлов:
   • Если вы определите конкретные конечные точки темы, которые принимают файл или шаблон параметры, добавьте быстрые серверные правила блокировки для запросов, включающих эти имена параметров, пока тема не будет исправлена.
7. Активируйте WAF/виртуальный патч
   • Если вы используете управляемый веб-приложение брандмауэр (WAF) или плагин безопасности, который может развертывать виртуальные патчи, включите или добавьте правила, которые:
     • Обнаруживают последовательности обхода каталогов
     • Обнаружить php:// и data:// обертки
     • Блокировать запросы, пытающиеся получить доступ wp-config.php или другие конфиденциальные файлы
   • Виртуальное патчирование предотвращает эксплуатацию, даже если основной код остается уязвимым, давая вам время до появления официального патча.

Среднесрочное (дни) устранение и проверка

1. Замените или обновите тему
   • Проверьте наличие официального патча или новой версии темы, которая устраняет CVE-2026-28118. Если станет доступен официальный патч, тщательно протестируйте его на тестовом сервере, а затем обновите рабочий.
   • Если официального патча нет, рассмотрите возможность замены темы на поддерживаемую альтернативу или на дочернюю тему, созданную на основе поддерживаемой базовой темы.
2. Проверьте вашу файловую систему на наличие веб-оболочек и подозрительных файлов
   • Сканируйте wp-контент/загрузки, каталоги тем и каталоги плагинов на наличие:
     • Файлов с исполняемым PHP, где этого не должно быть
     • Файлов с недавно измененными временными метками, которые вы не узнаете
     • Известных индикаторов из ваших систем обнаружения вторжений
3. Ротация учетных данных и секретов
   • Измените все пароли администратора WordPress, пароли базы данных, ключи API и любые другие учетные данные, которые могут храниться на сервере или быть раскрыты.
   • Если вы восстанавливаете из резервной копии, измените учетные данные после этого.
4. Просмотрите журналы сервера и приложения
   • Посмотрите журналы за период до и после даты раскрытия на предмет подозрительной активности, указывающей на успешную эксплуатацию (например, коды ответов, которые включают вывод конфиденциальных файлов, или повторные попытки эксплуатации).
   • Экспортируйте соответствующие журналы в безопасное место для любых необходимых судебных работ.
5. Полное сканирование сайта на наличие вредоносного ПО и проверка целостности
   • Выполните полное сканирование на наличие вредоносного ПО; многие сканеры обнаружат веб-оболочки, задние двери и измененные файлы ядра.
   • Используйте инструменты целостности файлов для сравнения вашей кодовой базы с известными хорошими источниками.
6. Восстановите из чистых резервных копий, если компрометация подтверждена
   • Если вы обнаружите доказательства компрометации, которые не можете полностью устранить, восстановите из резервной копии, сделанной до появления первых признаков компрометации. Убедитесь, что вы выполните другие шаги по восстановлению (жесткие разрешения, ротация учетных данных) после восстановления.

Долгосрочная профилактика и укрепление (недели / на постоянной основе)

1. Принцип наименьших привилегий
   • Убедитесь, что пользователи файлов и баз данных имеют только необходимые им разрешения.
   • Избегайте запуска процессов веб-сервера от имени того же пользователя, который может изменять файлы.
2. Изолируйте окружения
   • Держите тестовые и производственные окружения изолированными.
   • Используйте разные учетные данные для разных окружений.
3. Непрерывный мониторинг и оповещение
   • Централизуйте журналы (доступа, ошибок, PHP) и добавьте оповещения для:
     • Попыток обхода директорий
     • Запросов, ссылающихся на wp-config.php и другие чувствительные файлы
     • Необычных всплесков в ответах 4xx/5xx
4. Регулярное сканирование на уязвимости
   • Выполняйте автоматизированные сканирования и регулярные запланированные ручные проверки кода тем и плагинов.
   • Подписывайтесь на потоки информации о уязвимостях и настраивайте свои процедуры управления патчами, чтобы они были отзывчивыми.
5. Регулярные резервные копии и протестированные восстановление
   • Поддерживайте резервные копии вне сайта, с версионностью, и регулярно тестируйте процедуры восстановления.
6. Укрепление самого WordPress
   • Держите ядро WordPress, плагины и темы обновленными.
   • Удалите неиспользуемые плагины и темы.
   • Отключите или защитите редакторы тем и плагинов.
   • Реализуйте заголовки безопасности и HTTPS повсюду.

Предложенные правила обнаружения и предотвращения WAF (концептуально)

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

• Блокировать запросы с попытками обхода директорий (базовый):
  • Регулярное выражение: (\.\./|\.\.\\||)
• Блокировать обертки php://, data://, expect://:
  • Регулярное выражение: (php://|data://|expect://|zip://|phar://)
• Блокировать попытки ссылаться на конфиденциальные файлы в строках запроса:
  • Регулярное выражение: (wp-config\.php|/etc/passwd|/proc/self/environ|\.env|\.htpasswd)
• Блокировать длинные последовательности закодированных символов, указывающих на обфускацию:
  • Регулярное выражение: (%[0-9A-Fa-f]{2}){6,}

Пример псевдо-правила (независимо от WAF):

• Если строка запроса совпадает с любым из:
  • (\.\./|\.\.\\||) ИЛИ
  • (php://|data://|expect://) ИЛИ
  • (wp-config\.php|/etc/passwd|\.env)

  → тогда заблокировать запрос (HTTP 403) и записать детали для проверки.

Примечания по ложным срабатываниям: Многие CMS и легитимные библиотеки могут включать токены, которые напоминают рискованные шаблоны. Тщательно тестируйте любой шаблон, ограничивайте правила вероятными конечными точками (файлы тем, конечные точки включения) и постепенно ужесточайте охват.

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

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

1. Выведите сайт из сети (режим обслуживания) или изолируйте хост.
2. Сделайте полный снимок сайта и журналов для судебного анализа.
3. Измените все пароли (администраторы, база данных, FTP/SFTP, панель управления).
4. Поменяйте все ключи и токены, которые могли быть сохранены на сервере.
5. Сканируйте и удаляйте вредоносные файлы и веб-оболочки. Если вы не уверены в ручной очистке, восстановите из чистой резервной копии.
6. Проверьте целостность базы данных и удалите несанкционированных администраторов или инъекции контента.
7. Проведите полный аудит, чтобы определить, как злоумышленник получил доступ и какие боковые перемещения он мог выполнить.
8. При необходимости восстановите окружение из известных хороших источников; не полагайтесь на “просто очистку”, если задние двери сложные.

Как WP‑Firewall помогает (что делает управляемый WAF для вас)

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

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

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

Краткая техническая заметка для разработчиков и системных администраторов

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

• Никогда не используйте пользовательский ввод напрямую для создания имен файлов без белого списка разрешенных значений.
• Используйте безопасные сопоставления (например, сопоставляйте короткие, известные ключи с разрешенными именами файлов), а не принимайте полный ввод пути.
• Нормализуйте и проверяйте любой путь перед передачей в include/require.
• Если выбор шаблона определяется пользовательским контентом, ограничьте выборы доверенным набором, который существует в вашей кодовой базе.

Пример более безопасного подхода (псевдокод):

<?php;

Этот шаблон сопоставляет ввод пользователя с контролируемым списком и предотвращает произвольное включение файлов.

Новый ресурс для владельцев сайтов: начните с немедленной, бесплатной защиты

Защитите свой сайт сейчас с нашим базовым бесплатным планом — управляемый брандмауэр, WAF, сканирование на наличие вредоносного ПО и защита от рисков OWASP Top 10. Он предназначен для немедленной защиты сайтов, пока вы планируете необходимые обновления или замены тем.

Защитите свой сайт прямо сейчас — начните с WP‑Firewall Basic (бесплатно)

• Что вы получаете мгновенно:
  • Управляемый брандмауэр и WAF с возможностью виртуального патча
  • Неограниченная пропускная способность для трафика безопасности
  • Сканирование на наличие вредоносного ПО для поиска подозрительных файлов и изменений
  • Защита от угроз OWASP Top 10 (включая шаблоны LFI)
• Почему это полезно:
  • Вы получаете немедленное блокирование известных шаблонов эксплуатации для недавно раскрытых уязвимостей
  • Виртуальное патчирование сокращает окно атаки, пока вы тестируете официальные обновления или мигрируете
• Начать: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

(Мы также предлагаем платные уровни, если вам нужна автоматическая удаление вредоносного ПО, управление блокировкой IP, ежемесячные отчеты или управляемые услуги безопасности.)

Практические примеры — быстрые правила, которые вы можете вставить и протестировать (резюме)

• Защитите wp-config.php (разместите в .htaccess):

<files wp-config.php>
  order allow,deny
  deny from all
</files>

• Правило Nginx для блокировки попытки с оберткой php:

if ($query_string ~* "php://|data://||(\.\./)") {

• Укрепление PHP ini:

allow_url_fopen = Off

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

Окончательные рекомендации — что делать в следующие 24–72 часа

1. Инвентаризация: определите любые сайты, работающие на теме Welldone ≤ 2.4.
2. Примените как минимум одно немедленное смягчение:
   • Отключите/переименуйте папку темы или
   • Заблокируйте шаблоны эксплуатации на уровне сервера/WAF и
   • Ограничьте доступ к wp-config.php.
3. Включите непрерывное сканирование и мониторинг.
4. Если можете, подпишитесь на план управляемой защиты (доступен бесплатный уровень), чтобы получить виртуальные патчи, примененные немедленно, пока вы планируете постоянное решение.
5. Общайтесь с заинтересованными сторонами, если вы хостите сайты клиентов — прозрачность и быстрое смягчение важны.

Если вам нужна техническая помощь

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

Заключение

Эта уязвимость Welldone LFI (CVE-2026-28118) является серьезной, неаутентифицированной уязвимостью, которая может раскрыть локальные файлы и привести к раскрытию учетных данных и полной компрометации. Самый быстрый путь к безопасности — удалить или изолировать уязвимую тему и развернуть правила виртуального патчирования на периметре, пока вы планируете контролируемое обновление или замену. Укрепление сервера (отключение рискованных оберток, исправление разрешений, ограничение доступа к файлам) и мониторинг журналов на наличие вышеуказанных индикаторов значительно снизят уровень уязвимости.

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

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

Ссылки и примечания

• Уязвимость отслеживается как CVE-2026-28118 (включение локальных файлов в теме Welldone, сообщено 19 августа 2025 года; опубликовано 26 февраля 2026 года).
• Этот совет предназначен для помощи защитникам. Мы не публикуем код эксплуатации здесь. Если вы администратор, который подозревает нарушение, и вам нужна прямая помощь, обратитесь к вашим специалистам по безопасности или свяжитесь с надежным поставщиком безопасности WordPress.