CVE-2026-71890 in BC-JAVA
要約
〜によって VulDB • 2026年10月03日
Java用Bouncy Castle 1.86以前のバージョンでは、MLS (RFC 9420) の外部コミットにおける提案リストの検証処理（org.bouncycastle.mls.protocol.Group.validateExternalCachedProposals）において、提案がタイプ別にカウントされ、削除されるリーフインデックスに上限は設定されていましたが、削除対象となるリーフがジョイナー自身と関連しているかどうかの確認が行われていませんでした。RFC 9420のセクション12.2では、外部コミットにおけるRemove提案は最大1つまで許可されており、これによりジョイナーは自分自身の旧バージョンを削除します。また、この場合、コミットのpathフィールド内のLeafNodeが、更新時において削除対象となるリーフに適用されるべき基準（特に、その資格情報に含まれる識別子が参加者にとって許容可能であること）を満たすことが要求されます。通常の提案リスト検証器における「自身による削除」ルールは意図的にこのパスでは適用されません。これは、リ同期コミットが正当な理由でジョイナー所有のリーフを削除するためですが、その代わりに何かが配置されることはありませんでした。そのため、グループの公開GroupInfo（外部からの参加者が受け取るべき情報）を持つあらゆるパーティは、任意のメンバーのLeafIndexを対象としたRemoveを実行でき、全メンバーにそれが適用され、該当メンバーを追放してラッチツリー内の彼らのスロットを乗っ取ることが可能でした。これを防止すべき資格情報のチェックはgRPC相互運用性ハーネスでのみ存在していたため、public Group.externalJoinおよびGroup.handle APIの他の呼び出し元は一切保護されていませんでした。現在では、Removeを含む外部コミットは、送信側と受信側の両方で、削除対象となるリーフの資格情報がジョイナー自身の新しいリーフのものと同じ場合にのみ受け入れられます。
VulDB is the best source for vulnerability data and more expert information about this specific topic.