Kenerに認証回避の脆弱性、4.1.10で修正
ステータスページ用のKenerで、署名鍵を設定していない環境では、ログインしていない第三者が管理者になりすませる脆弱性が見つかりました。3.0.0以上4.1.10未満を使っている組織が対象です。4.1.10への更新と、署名鍵の設定状況の確認を進めてください。
急ぎ度: 早めに
CVSS v3は8.1、v4は9.2で、認証なしに管理者権限を奪われるおそれがあり、修正版の4.1.10も出ているため、署名鍵が未設定の環境から順に早めに更新するのが妥当です。
関係があるか
Kener 3.0.0以上4.1.10未満を自社で運用している組織が対象です。環境変数KENER_SECRET_KEYが空か未設定のインスタンスが、とくに危険な状態にあります。
| 製品 | 影響を受ける版 | 直った版 |
|---|---|---|
| Kener（rajnandan1/kener） | 3.0.0以上、4.1.10未満 | 4.1.10 |
確かめ方
- 1稼働中のKenerの版を確認します。リリースの版が3.0.0以上4.1.10未満なら更新の対象です。
- 2Kenerを動かしているプロセスの環境変数KENER_SECRET_KEYに値が入っているかを確認します。値そのものを画面やチャットに出さないよう、空かどうかだけを調べてください。
- 3管理画面（/manage）がインターネットや広い社内ネットワークから到達できるかを、リバースプロキシやファイアウォールの設定で確認します。
何が起きたか
Kenerに、ログインしていない第三者が管理者になりすませる認証回避の脆弱性が見つかりました。
Kenerはログイン状態を署名付きトークンで管理しています。署名に使う秘密鍵は環境変数KENER_SECRET_KEYで指定しますが、これが空または未設定だと、ソースコードに書き込まれた固定の予備鍵に切り替わります。Kenerはオープンソースなので、この予備鍵は誰でも読めます。鍵が公開されているのと同じ状態になり、本物と見分けのつかないトークンを外部で作れてしまいます。
分類はCWE-321（ハードコードされた暗号鍵の使用）です。ログイン用のセッショントークンに加えて、パスワード再設定用のトークンも同じ仕組みで偽造できるとされています。公表日は2026年10月26日です。
攻撃の流れ
-
1
予備鍵に切り替わる
KENER_SECRET_KEYが空または未設定のKenerは、ソースコード上の固定鍵で署名を検証します。
-
2
管理者を特定
攻撃者が、管理者のメールアドレスを何らかの方法で把握します。
-
3
偽トークン作成
公開されている固定鍵を使い、管理者として通用するトークンを手元で作ります。
-
4
管理APIに到達
偽のトークンが受理され、管理用のAPIが管理者権限で使われます。
どう悪用されるか
悪用に認証は要りません。ネットワーク経由で、Kenerにアクセスできる位置にいれば試せます。利用者の操作を待つ必要もありません。
ただし条件が二つあります。KENER_SECRET_KEYが空か未設定であることと、攻撃者が管理者のメールアドレスを知っていることです。CVSS v3で攻撃条件の複雑さが高とされているのは、この前提があるためです。管理者のメールアドレスは問い合わせ先や通知先として外部に見えていることも多く、二つ目の条件は低い壁だと考えたほうが安全です。
成功すると、管理用のAPIを管理者と同じ権限で操作されます。公開しているステータス表示や監視・通知の設定が書き換えられ、登録された情報が読み出されるおそれがあります。パスワード再設定用のトークンを偽造された場合は、管理者アカウントそのものを乗っ取られます。
今すぐやること
-
1
Kenerを4.1.10に更新する
3.0.0以上4.1.10未満のインスタンスは、修正版に更新します。署名鍵が未設定の環境と、管理画面を外部から開けられる環境から先に進めてください。
-
2
署名鍵が設定済みか確認する
Kenerを動かしているプロセスの環境で、KENER_SECRET_KEYが空かどうかだけを確認します。値を表示するコマンドは使いません。Dockerで動かしている場合の例です。<コンテナ名>は自分の環境の名前に置き換えてください。
docker exec <コンテナ名> sh -c 'test -n "$KENER_SECRET_KEY" && echo set || echo unset' -
3
不正アクセスの痕跡を調べる
鍵が未設定だった期間があれば、リバースプロキシやアクセスログで/manage/apiへの想定外のアクセスを確認します。管理者アカウント、通知先、公開設定に身に覚えのない変更がないかも見てください。
-
4
必要なら認証情報を入れ替える
未設定の状態で外部に公開していた場合は、管理者のパスワードを変更します。痕跡の有無が判断できないときも、念のため変更しておくと安心です。署名鍵を変えると既存のログインが無効になる可能性があるため、変更は利用者の少ない時間帯に行ってください。
すぐ更新できないとき
すぐに更新できない場合は、KENER_SECRET_KEYに十分に長いランダムな値を設定してKenerを再起動します。予備鍵が使われる条件を外すための措置です。あわせて、リバースプロキシやファイアウォールで/manageへのアクセスを社内ネットワークや特定のIPアドレスに限ると、到達できる相手を絞れます。どちらも一時しのぎなので、更新は別途進めてください。
背景
Kenerはオープンソースのステータスページツールです。サービスの稼働状況や障害を、顧客や社内の利用者に向けて公開するために使います。管理画面では、表示内容、監視の設定、通知先などを操作します。障害のさなかに見られる場所であるため、管理権限を奪われると、公開情報を偽られたり、障害の連絡経路を乱されたりするおそれがあります。
署名付きトークンは、署名鍵が秘密であることを前提に成り立つ仕組みです。鍵がソースコードに書かれていて、そのソースが公開されていれば、署名の検証は意味を失います。今回の脆弱性は、設定を忘れた場合の安全装置であるはずの予備鍵が、この状態を招いた例です。Kenerのリポジトリ上では、該当する処理が4.1.9のコードとして確認できます。
よくある質問
Q.CVSSのv3とv4で数値が違うのはなぜですか。
まだ分かっていないこと
- 実際の攻撃で悪用されたかどうかは公表されていません。悪用の有無は、脆弱性を公表したVulnCheckの告知とKenerのリリースノートで確認してください。
- 4.1.10でKENER_SECRET_KEYが空のときの動作が、起動の拒否なのか別の処理なのかは、確認できていません。更新後の設定の扱いは、リリースノートと修正のコミットで確認してください。
- 標準の導入手順で署名鍵が未設定のまま稼働しやすいかどうかは、分かっていません。
この記事は、取得元の公開情報をもとに生成 AI で作成しています。誤りを含むことがあります。対応を決める前に、下の原文と参照先を確認してください。
影響パッケージ
| 種類 | パッケージ | 影響を受ける版 | 直った版 |
|---|---|---|---|
| rajnandan1 | kener |
3.0.0 以上 4.1.10 未満 |
4.1.10 |
原文の説明 取得元が公開している説明をそのまま載せています (多くは英語)。
Kener 3.0.0 before 4.1.10 contains an authentication bypass vulnerability that allows unauthenticated attackers to forge session tokens by using the hardcoded DUMMY_SECRET fallback key. When KENER_SECRET_KEY is empty or unset, attackers knowing an administrator email can sign a kener-user cookie to access /manage/api with full administrative privileges or forge password-reset tokens.
出典: CVE.org (CVE Program・cvelistV5) NVD GitHub Advisory
参照URL
- advisory github.com
- advisory vulncheck.com
- advisory nvd.nist.gov
- advisory github.com
- package github.com
- patch github.com
- report github.com
- web github.com
- web github.com