Kimaiの公式Dockerイメージに重大な脆弱性が公表されました。この脆弱性を悪用すると、認証を経ていない攻撃者が認証トークンを偽造し、super_adminを含む任意のユーザーアカウントを乗っ取ることができます。
CVE-2026-52824として追跡されているこの欠陥は、Kimaiのコンテナ化デプロイメントに組み込まれたハードコードのデフォルトシークレットに起因します。
Kimaiの公式Dockerイメージは、Dockerfile内でデフォルトの環境変数としてAPP_SECRET=change_this_to_something_uniqueを設定しています。
重大な問題は、Dockerのエントリーポイントスクリプトがこのプレースホルダー値を検証も上書きもしないことです。つまり、Docker経由でKimaiをデプロイする運用者が手動で一意のAPP_SECRETを設定しない限り、そのインスタンスは公に知られたSymfonyのkernel.secretを使って稼働することになります。
Kimaiはユーザーアカウントに連番の整数IDを割り当てており、最初に作成されたsuper_adminアカウントはほぼ必ずid=1を持ちます。ユーザーIDはURLやAPIレスポンスに頻繁に露出するため、攻撃者は高権限アカウントを確実に狙う手段を持つことになります。
偽造可能なAPP_SECRETと組み合わせることで、攻撃者は既知のユーザー名と、そのユーザー名に対応する正しいアカウントID、そして対象アカウントで二要素認証が有効になっていないことという条件さえ揃えば、アカウントの乗っ取りに成功してしまいます。
この問題はCWE-1188「安全でないデフォルト値によるリソースの初期化」に分類されます。これは、本来管理者がカスタマイズすべき値が、本質的に安全でないデフォルト値のまま出荷されるという問題です。
注目すべき点として、この欠陥はDockerに限った話ではありませんでした。ベアメタル環境向けの.env.distテンプレートにも同一のプレースホルダーが含まれており、コードベースのどこにも起動時にこの既知の危険なシークレットのまま起動することを防ぐチェックが存在していませんでした。
Kimaiのメンテナーであるkevinpapst氏がこの問題に対処し、バージョン2.58.0で複数の多層的な緩和策を導入しました。entrypoint.shスクリプトは、bin2hex(random_bytes(32))を用いて暗号学的に安全なランダムのAPP_SECRETを自動生成し、/opt/kimai/var/data/.appsecretに永続化するようになりました。
この生成されたシークレット、あるいは環境変数から供給されたシークレットは、コンテナ起動時に/opt/kimai/.env.localに書き込まれ、安全でないデフォルト値はDockerfileから完全に取り除かれました。
ドキュメントも更新され、一意のシークレットを設定する必要性が強調されました。さらに、関連するアドバイザリGHSA-m492-gv72-xvxjの下でログインリンクに追加のエントロピーが付与され、古いハードコードのシークレットのまま稼働しているレガシーなインスタンスに対しても悪用経路が塞がれました。
Dockerで運用しているKimaiユーザーは、直ちにバージョン2.58.0以降にアップグレードする必要があります。すぐにパッチを適用できない管理者は、暫定対策として一意かつ高エントロピーなAPP_SECRETを手動で設定し、すべての管理者アカウントに二要素認証を強制すべきです。
より強力な予防的防御で重大インシデントと金銭的損失を防ぎましょう。15,000のSOCから得られるライブ脅威フィードを統合する
翻訳元: https://cyberpress.org/critical-kimai-docker-flaw/