Критическая уязвимость в Docker-образе Kimai: дефолтный APP_SECRET позволяет захватить учётную запись

Kimai

Разработчики системы учёта рабочего времени Kimai выпустили обновление 2.58.0, закрывающее критическую уязвимость в официальном Docker-образе. Проблема, зарегистрированная как CVE-2026-52824, была обнаружена исследователем AzureADTrent и опубликована мейнтейнером Кевином Папстом 11 июня. Уязвимость затрагивает версии до 2.57.0 включительно и оценивается как критическая.

Уязвимость CVE-2026-52824

Причина кроется в небезопасном значении переменной окружения APP_SECRET, установленном по умолчанию. В файле Dockerfile секрет определён как "change_this_to_something_unique", и точка входа контейнера не проверяет и не заменяет это значение. Таким образом, любой экземпляр Kimai, запущенный в Docker без явного указания APP_SECRET, использует общеизвестный криптографический ключ.

Symfony, фреймворк, на котором построен Kimai, применяет этот секрет в качестве "kernel.secret" для подписи нескольких чувствительных компонентов безопасности. В частности, речь идёт о KIMAI_REMEMBER (cookie запоминания сессии), ссылках для входа LoginLink, URL сброса пароля и CSRF-токенах. Все эти данные защищены HMAC-подписью, вычисляемой на основе секрета. Если злоумышленник знает секрет, он может подделать любую из этих подписей.

Усугубляет ситуацию то, что идентификаторы пользователей в Kimai являются последовательными целыми числами. Первая учётная запись администратора почти всегда получает ID=1. Эти ID могут быть видны в URL (например, при просмотре профиля) и в ответах API. Атакующему необходимо знать имя пользователя, угадать его ID и убедиться, что на аккаунте не включена двухфакторная аутентификация. В таком случае возможен полный захват учётной записи, включая суперадминистратора.

Проблема классифицирована как CWE-1188 ("Инициализация ресурса с небезопасным значением по умолчанию"). Она иллюстрирует распространённый недостаток в безопасности контейнеров: поставку предсказуемых секретов в образах, предназначенных для продакшена, без принудительной смены при старте. Уязвимость не ограничивается Docker-образом: в конфигурационном файле для установки на сервере (.env.dist) также содержится то же значение по умолчанию, поэтому bare-metal инсталляции, не изменившие секрет, также подвержены риску.

В официальном бюллетене безопасности мейнтейнеры пояснили, что исправление в версии 2.58.0 включает несколько изменений. Точка входа контейнера теперь автоматически генерирует случайный APP_SECRET с помощью "bin2hex(random_bytes(32))", если переменная не задана через окружение. Сгенерированный секрет сохраняется в файл "/opt/kimai/var/data/.appsecret", и на его основе создаётся файл ".env.local". Само значение "change_this_to_something_unique" удалено из Dockerfile. Кроме того, увеличена энтропия в LoginLink (связанное предупреждение GHSA-m492-gv72-xvxj) - это дополнительно защищает от атак, даже если на старых установках остался дефолтный секрет. Однако разработчики подчёркивают, что это не заменяет установку патча.

Организациям, использующим Kimai в Docker, рекомендуется немедленно обновить образ до версии 2.58.0 или выше. Даже после обновления стоит явно задать сильный, уникальный APP_SECRET в переменных окружения и перезапустить контейнер. Администраторам также следует отозвать все активные сессии - это можно сделать через базу данных или через принудительный сброс паролей. Желательно проверить учётные записи администраторов на предмет подозрительной активности и включить двухфакторную аутентификацию для всех привилегированных пользователей. Если доступ к Kimai не требуется из интернета, рекомендуется ограничить публичный доступ с помощью сетевых экранов или VPN.

После исправления разработчики внедрили автоматическую генерацию секрета при старте контейнера, что снижает риск для новых развёртываний. Однако для уже работающих экземпляров важно провести ротацию секрета и проверить логи на предмет возможной компрометации. Уязвимость CVE-2026-52824 стала очередным напоминанием о том, что значения по умолчанию в контейнерных образах должны быть безопасными, а процедура инициализации - проверять и заменять потенциально опасные параметры.

Ссылки

Комментарии: 0