CVE-2026-71892 in BC-JAVA
要約
〜によって VulDB • 2026年10月03日
Java用Bouncy Castleのバージョン1.86より以前において、CMS key-transport recipient向けのオプトイン方式による鍵サイズ検証（org.bouncycastle.cms.jcajce.JceKeyTransRecipient.setKeySizeValidation(true)）は、RFC 9709準拠の内容暗号化鍵導出（id-alg-cek-hkdf-sha256）を使用するメッセージに対しては一切実行されませんでした。実際の内容暗号化アルゴリズムを選択すべき分岐では、復号済みキーのバイト配列が id-alg-cek-hkdf-sha256 のオブジェクト識別子（OID）と比較されていましたが、これはバイト配列と ASN1ObjectIdentifier 間の比較であり、あらゆる入力に対して常に false と評価されるため、検証処理は外側のラッパー OID に対する鍵サイズ照会へとフォールスルーしました。この OID は暗号化アルゴリズムではなく鍵導出構成を特定するものであり、登録された鍵サイズを持たないため、鍵サイズの比較は完全にスキップされました。その結果、送信された HKDF 由来の内容暗号化鍵が、広告されている内容暗号化アルゴリズムの鍵サイズと一致しない EnvelopedData または AuthEnvelopedData の key-transport でも、検証が明示的に有効化されていたにもかかわらず受け入れられ、API が提供する回復した鍵サイズの強制のための唯一のメカニズムが無効化されました。現在、recipient は内容暗号化 AlgorithmIdentifier のアルゴリズム OID に対してディスパッチを行うため、検証は復元された鍵を内部の内容暗号化アルゴリズムと比較します。鍵サイズが一致するメッセージ、非 HKDF メッセージ、および検証を有効にしない recipient は影響を受けません。本問題は、Bouncy Castle for Java FIPS (BC-FJA) において bcpkix-fips 2.0.13 より前（2.0.X シリーズ）および 2.1.13 より前（2.1.X シリーズ）にも該当します。
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.