CVE-2026-92916 in Grav
Сводка
по VulDB • 17.09.2026
Grav — это CMS с использованием flat-file (файловой базы данных). В версиях Grav 1.7.0–1.7.53.2 и 2.0.0–2.0.21, когда отладчик включен (system.debugger.enabled: true, что не является настройкой по умолчанию), конечная точка профилировщика Clockwork доступна без аутентификации: метод InitializeProcessor::handleDebuggerRequest() перехватывает любой путь, содержащий /__clockwork/, на этапе инициализации (bootstrap) и передает его в Debugger::debuggerRequest(), который не выполняет проверку пользователя, ограничение по IP или проверку аутентикатора Clockwork, а также поддерживает анонимную пагинацию по всей сохраненной истории. При значении censored: false, которое установлено по умолчанию, каждая сохраненная запись содержит сырые куки запроса (включая сессионный cookie Grav, значение которого является идентификатором PHP-сессии, что позволяет атакующему возобновить чужую сессию, включая сессию авторизованного администратора), полностью разобранный тело запроса (поскольку форма входа Grav отправляет данные в формате data[username]/data[password], пароли сохраняются в открытом виде, так как фильтр паролей Clockwork проверяет только ключи верхнего уровня) и всю системную конфигурацию сайта и плагинов, включая сохраненные оператором секреты, такие как учетные данные SMTP, API-ключи сторонних сервисов и лицензионные ключи. Заголовки Authorization и X-API-Token сохраняются даже при censored: true. В Grav 2.0 установка provider: debugbar не устраняет проблему, поскольку Grav принудительно использует провайдер Clockwork для запросов с предпочтением формата JSON. Проблема исправлена в версиях 1.7.53.4 и 2.0.22, которые ограничивают доступ к /__clockwork/ локальными серверными запросами или запросами, содержащими новый секрет system.debugger.token, а также удаляют куки и заголовки учетных данных из сохраняемых записей. Временные решения включают установку debugger.enabled: false или блокировку пути /__clockwork/ на уровне веб-сервера или CDN.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.