脆弱性・CVE速報深刻度: 高

RPKI 認証局ソフト Krill に 3 件の脆弱性 CVE-2026-109140・109141・109142(CVSS v3.1 8.4): 0.16.1 で修正

目次(7)

CVE-2026-109140

CVE-2026-109141

CVE-2026-109142

NVD は 2026-11-02 に、RPKI(インターネットの経路情報の正当性を証明する仕組み)の認証局ソフト「Krill」の脆弱性 3 件、CVE-2026-109140・CVE-2026-109141・CVE-2026-109142 を登録しました。いずれも「ログインできる利用者」が前提で、権限を越えて管理者相当の操作や、他の認証局(CA)になりすました操作ができる問題です。0.16.0 までが対象で、修正版は 0.16.1 です。

3 件の概要

CVE内容CWECVSS v3.1
CVE-2026-109140ログインセッションのトークンを暗号化する際の nonce(使い捨ての値)が、Krill の再起動のたびに 0 から数え直されるカウンタで作られる。再起動後に同じ(鍵, nonce)の組が再び使われ、ログインできる利用者が "admin" のトークンを偽造できるとベンダーは説明しているCWE-3238.4
CVE-2026-109141特定の CA だけに制限された役割(cas = [...])が、CA に紐づかないリクエストでは権限一式を持ってしまう。一括取り込みの API(POST /api/v1/bulk/cas/import)で、既存の任意の CA の下に子 CA を追加し、その CA の資源を渡し、リクエストで指定した ROA(経路の正当性を示す署名付きの情報)を作れるCWE-6398.4
CVE-2026-109142CA の親が同じ Krill サーバー上にある場合、署名付き CMS メッセージを作って検証する代わりに、RFC 6492 の資源配布のやり取りをサーバー内で直接行い、呼び出し側が親の連絡先に入れた子の識別名(child_handle)をそのまま信用する。その識別名が要求元の CA のものか確かめない。CA の運用者が、同じサーバー上のどの CA の子としても振る舞えるCWE-6398.4

共通の前提と影響範囲

  • 攻撃者の位置: 3 件とも、ネットワーク越しで、低い権限(PR:L)、つまり Krill にログインできる利用者が前提です。攻撃の複雑さは High、スコープは Changed と評価されています(CNA の NLnet Labs が付与、種別 Secondary)。認証なしで届く問題ではありません。
  • 対象: Krill 0.16.0 まで。複数の CA を 1 つの Krill サーバーで運用している構成では、CA ごとの分離が破られる点が影響します。
  • 想定される影響: ROA は、どの組織がどの IP アドレス範囲を経路に載せてよいかを示す情報です。誤った ROA が作られると、経路検証の結果が狂い、通信の迂回や遮断の判断に影響するおそれがあります。ただし、Krill が作った ROA が実際に広まる範囲や影響の大きさは、運用の構成によって異なり、確認できていません。
  • 攻撃の具体的な手順は、本記事では扱いません。

修正

3 件とも、ベンダー勧告の解決策は「Krill 0.16.1 以降へ更新」です。

数値と出典(2026-11-03 時点)

項目内容
CVSS v3.13 件とも 8.4(AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:L)。NLnet Labs(CNA)が付与(種別 Secondary)。v4.0 の値は登録なし
NVD の状態3 件とも Deferred(NVD 自身の分析は未実施)
NVD 公開日2026-11-02(16:17 UTC)
CISA の SSVC 評価悪用 none、自動化 no、技術的影響 total
EPSS3 件とも未算定(FIRST の API に該当データなし)
KEV3 件とも掲載なし(CISA のカタログを確認)
出典NVD、ベンダー勧告(NLnet Labs の CVE-2026-109140・109141・109142 の各テキスト)、FIRST(EPSS)、CISA(KEV)

severity を high とした提案の理由

3 件とも Krill へのログインが前提で、認証なしでは届きません。CVSS v3.1 は 8.4 で、過去の判断の基準(認証不要かつ CVSS 9 以上は critical、それ以外は high)に従い、high を提案します。ただし RPKI の認証局という性質上、権限を越えた操作が経路検証の情報に及ぶ点は重く見る必要があります。

対応として考えられること

  1. Krill を運用している場合は、版を確認し、0.16.0 以前なら 0.16.1 以降へ更新します。
  2. 更新までは、Krill にログインできる利用者とその役割(特に CA を限定した役割)を見直し、信頼できない利用者のアカウントを無効にします。
  3. 複数の CA を同じサーバーで運用している場合は、更新後に、意図しない子 CA や ROA が作られていないか、設定と発行済みの ROA を確認します。
  4. 管理 API を公開していないか、アクセス元を絞れているかを確認します。

未確認の点

  • 実際の攻撃での悪用は確認していません(CISA の SSVC 評価では悪用 none)。
  • Krill の利用組織の数や、実際に偽の ROA が発行された例は確認できていません。
  • 各問題の技術的な詳細(再現条件)は、ベンダー勧告の要約を超えて確認していません。
  • NVD の分析は未実施です。

この記事について

出典

この記事を共有