Commons CodecのBlake3で派生鍵が同一に、要コード修正
Apache Commons CodecのBlake3で、同じインスタンスから鍵を続けて派生するJavaコードは、別々のはずの鍵が同じ値になります。1.23.0は文書の修正だけなので、更新に加えて自社コードを点検し、必要なら鍵を再発行してください。
急ぎ度: 早めに
CVSS v3は9.1でApache自身の評価もimportantですが、EPSSは0.229%（14パーセンタイル）で、対応の中心はライブラリの更新ではなく自社コードの点検と鍵の見直しです。
関係があるか
JavaアプリでApache Commons CodecのBlake3クラスを使い、同じインスタンスでdoFinalizeを複数回呼んで鍵などを取り出している組織が対象です。Blake3を使っていなければ、この脆弱性に該当するコードはありません。
| 製品 | 影響を受ける版 | 修正版 |
|---|---|---|
| Apache Commons Codec | 1.16.0以上1.23.0未満 | 1.23.0（Javadocの修正のみ） |
確かめ方
- 1依存関係にcommons-codecが入っているかと、その版を確認します。直接の依存だけでなく、他のライブラリ経由の依存も見ます。Mavenなら
mvn dependency:tree -Dincludes=commons-codecで調べられます。 - 2自社のソースと社内ライブラリで
Blake3を検索し、Commons CodecのBlake3クラスを使っている箇所を洗い出します。 - 3見つかった箇所で、同じBlake3インスタンスにdoFinalizeを2回以上呼んでいないかを見ます。呼び出しの間に入力を追加していなければ、毎回同じ出力になります。
- 4クラスのJavadocにある鍵派生の例をそのまま写したコードがないかも確認します。
何が起きたか
暗号用のハッシュ関数Blake3を扱うApache Commons Codecで、Javadocの鍵派生の例どおりに書くと、別々のはずの2つの鍵が同じ値になります。
原因は、説明と実際の動作の食い違いです。Blake3クラスのJavadocは、doFinalizeを続けて呼ぶと、それまでに取り出したバイトに応じて出力が変わると説明していました。実際のdoFinalizeはハッシュの状態を変えません。入力を追加せずに呼べば、何度でも同じバイト列が返ります。
1.16.0から付属する鍵派生の例は、doFinalizeを2回続けて呼んで2つの鍵を作っています。この例に従ったコードでは鍵が一致し、用途ごとに鍵を分ける意味がなくなります。同じインスタンスで複数回呼び、そのたびに新しい出力を期待するコードも同じ状況です。弱点の分類はCWE-684とCWE-1068です。
修正版の1.23.0はJavadocを正しい内容に直した版で、doFinalizeの動作は変わっていません。
攻撃の流れ
-
1
例どおりに実装
開発者がJavadocの鍵派生の例に沿って、鍵を2つ派生するコードを書きます。
-
2
同じ出力が返る
同じインスタンスでdoFinalizeを2回呼ぶと、状態が変わらないため同じバイト列が返ります。
-
3
同一の鍵ができる
別用途のはずの2つの鍵が、同じ値で作られます。
-
4
鍵の分離が崩れる
用途ごとに鍵を分ける設計の前提が崩れ、一方の鍵が漏れるともう一方も同じ値で知られます。
どう悪用されるか
該当するのは、アプリがBlake3のインスタンスに対してdoFinalizeを続けて複数回呼び、毎回異なる出力が得られると想定している場合です。ライブラリを入れているだけでは該当しません。CVSSのベクトルはネットワーク経由で、認証も利用者の操作も不要という評価ですが、実態は呼び出す側のコードの誤りから生じる問題です。
該当したときは、本来は分かれているはずの鍵が同一の値になります。たとえば暗号化用と認証用の鍵を派生していた場合、一方の鍵が外に出ると、もう一方も同じ値で知られることになります。CVSSの機密性と完全性の影響が高いのは、この点が理由とみられます。
今すぐやること
-
1
該当コードを洗い出す
自社のソースと社内ライブラリで、Blake3の利用箇所と、同じインスタンスへのdoFinalizeの複数回呼び出しを探します。Javadocの例を写した箇所も対象です。
grep -rn "Blake3" src/ -
2
鍵の取り出し方を直す
必要な鍵の合計の長さを1回のdoFinalizeで要求し、得られた出力を分割して各鍵に使います。更新後のJavadocにも同じ方法が示されています。
-
3
すでに使った鍵を見直す
同じ値の鍵が複数の用途で本番に使われていた場合は、鍵の再発行と、その鍵で保護したデータの扱いを検討します。
-
4
修正版に更新する
Javadocを正しい内容にするため、Commons Codecを修正版に更新します。更新だけではコードの問題は直らないので、ここまでの手順を先に済ませます。
すぐ更新できないとき
コードの修正はライブラリを更新しなくてもできます。1.16.0以上1.23.0未満のままでも、必要な長さを1回で取り出して分割する書き方に変えれば、同じ鍵になる状況を避けられます。
背景
Apache Commons Codecは、Base64などのエンコードやハッシュを扱うJavaのライブラリです。他のライブラリやフレームワークの依存として入っていることが多く、自社で直接使っていなくても、依存関係をたどると見つかることがあります。BlakeはBLAKE3というハッシュ関数をJavaで扱うクラスで、鍵を派生させる用途にも使えます。
今回は実装の不具合ではなく、説明と動作の食い違いから生じました。説明どおりに書いたコードが、意図と違う結果になる形です。ライブラリを更新しても動作が変わらないので、依存関係の脆弱性スキャナーで版の一致だけを見ても、実際に影響を受けるかは分かりません。自社コードの中身を見る必要があります。
よくある質問
Q.Blake3をハッシュ値の計算だけに使っている場合も対象ですか。
Q.依存関係スキャナーがcriticalで検出しました。版を上げれば警告は閉じてよいですか。
まだ分かっていないこと
- この脆弱性の影響を受ける具体的なアプリや製品名、実際の被害の報告は、公表されていません。
この記事は、取得元の公開情報をもとに、人が監修しながらAIを活用して執筆しています。執筆と監修は佐々木 航が担い、公開したあとも人が内容を確認しています。誤りに気づいたときは直し、記事の末尾に訂正の行を残します。対応を決める前に、下の原文と参照先も確認してください。
影響パッケージ
| パッケージ | 影響を受ける版 → 修正版 | |
|---|---|---|
| Apache Software FoundationApache Commons Codec |
1.16.0 以上 1.23.0 未満→ 1.23.0 |
1.23.0 |
ディストリビューション別の修正状況
各ディストリビューションが公開している、この CVE の記録です。修正版は配布版ごとに違うので、リンク先で確かめてください。
- Ubuntu UBUNTU-CVE-2026-119078 libcommons-codec-java この記録に修正版の記載なし
原文の説明 取得元が公開している説明をそのまま載せています (多くは英語)。
Apache Commons Codec's Blake3 class documented the output of its doFinalize methods as depending on any previously finalized bytes, so that consecutive calls would return different output. In fact, doFinalize does not change the hash state: calling it again without supplying more input returns the same bytes. The key-derivation example in the class Javadoc, shipped since 1.16.0, derives two keys with two consecutive doFinalize calls. Code that follows it gets identical keys, so the separation between the derived keys is lost. The same applies to any application that calls doFinalize more than once on one instance and expects new output each time.
This issue affects Apache Commons Codec from 1.16.0 before 1.23.0.
Version 1.23.0 corrects the documentation, but the behavior of doFinalize is unchanged. Upgrading alone does not fix affected code. Users should check their applications for repeated doFinalize calls on the same Blake3 instance and derive multiple keys by requesting the combined length in one call and splitting the output, as the updated Javadoc shows.
出典: CVE.org (CVE Program・cvelistV5) NVD GitHub Advisory
参照URL
- web security@apache.org
- web nvd.nist.gov
- web github.com
- web openwall.com