CVE-2026-100669 in GravИнформация

Сводка

по VulDB • 26.09.2026

В версиях Grav до 2.0.25 поставляются образцы конфигураций веб-серверов, в которых правила контроля доступа (deny rules) сопоставляются с учетом регистра. В файле webserver-configs/web.config (IIS) каждое правило запрета (user_sensitive_folders, user_accounts, user_data, user_error_redirect, user_pages, system, vendor, ignore_folders) устанавливает для элемента URL Rewrite <match> значение ignoreCase="false", что переопределяет стандартное поведение IIS по умолчанию (ignoreCase="true"); поскольку это правила сопоставления при перезаписи, а не элементы <requestFiltering>, отсутствует механизм резервного копирования с игнорированием регистра. На системах IIS, работающих поверх файловых систем NTFS с регистронезависимым поиском, незарегистрированный удаленный злоумышленник может изменять регистр имени папки или расширения файла (например, GET /user/CONFIG/system.YAML) таким образом, чтобы ни одно правило запрета не совпало, и статический обработчик файлов IIS разрешал путь к файлу и возвращал его содержимое, что приводит к раскрытию конфиденциальных данных, таких как секреты конфигурации или хеши паролей учетных записей. Будет ли фактически возвращен обходной файл, зависит от регистрации MIME-типов: .json обслуживается по умолчанию, тогда как файлы с расширениями .yaml/.yml на стандартном IIS возвращают HTTP 404.3, если не добавлено сопоставление MIME для YAML. Тот же класс уязвимости присутствует в поставляемом файле webserver-configs/lighttpd.conf, правила которого (user/(config|env), directory, script-extension, root-file и dotfile) не содержат модификатора (?i); однако риск ниже, поскольку lighttpd обычно работает на файловых системах с учетом регистра. Развертывания, обслуживаемые Apache (.htaccess), nginx, Caddy или встроенным сервером PHP, не затронуты. Проблема исправлена в версии 2.0.25; поскольку установщик .htaccess не изменяет файлы web.config и lighttpd.conf, операторам необходимо повторно скопировать исправленные образцы файлов после обновления.

If you want to get best quality of vulnerability data, you may have to visit VulDB.

Ответственный

VulnCheck

Резервировать

26.09.2026

Раскрытие

26.09.2026

Модерация

принято

Вход

VDB-410659

EPSS

0.00000

KEV

Нет

Деятельности

Очень низкий

Источники

Are you interested in using VulDB?

Download the whitepaper to learn more about our service!