結論から述べます。Java向けの暗号ライブラリ「Bouncy Castle」が2026年7月28日にリリースした1.85で、22件の脆弱性が修正されました。うち2件はCVSS 4.0で9.3（クリティカル）、いずれもTLS通信の証明書検証が事実上働かなくなるという、暗号ライブラリとしては致命的な内容です。JPCERT/CCも2026年8月13日のWeekly Reportで注意を促しています。
そして厄介なのは、「うちはBouncy Castleなんて導入していない」と思っている組織ほど確認が必要だという点です。このライブラリは単体で導入するものというより、Java製の業務アプリケーションや認証基盤、アプライアンス製品の中に同梱されて動いているタイプのものだからです。
この記事でわかること
- Bouncy Castleとは何で、どこに紛れ込んでいるのか
- 1.85で修正された22件のうち、優先度が高い4件の中身
- 自社に該当するかを判定する具体的な手順（ファイル名で探す）
- ベンダー製品に同梱されていた場合の現実的な進め方
Bouncy Castleとは何か──「使っていない」と即断しないでください
Bouncy Castleとは、JavaやC#で暗号処理を行うためのオープンソースの暗号ライブラリです。オーストラリアのLegion of the Bouncy Castle Inc.が開発しており、現在はKeyfactorが商用サポートを提供しています。公式サイトによれば25年の歴史があり、月間ダウンロード数は約620万件に達します。
何に使われるのか。Java標準の暗号機能（JCA/JCE）だけでは足りない処理を補うために使われます。具体的には、S/MIMEによるメールの署名・暗号化、CMS（電子署名の標準形式）の生成と検証、OpenPGP、PKCS#12形式の鍵ストア操作、証明書の発行・検証、そしてTLS通信そのものの実装（JSSEプロバイダ）です。FIPS認証を取得したBC-FJA版もあり、政府調達や金融系で「FIPS準拠が要件」となる構成では実質的な標準選択肢になっています。
そして最も重要な点。どこに組み込まれているのか。Bouncy Castleは、次のような形で「知らないうちに」動いていることがあります。
- シングルサインオン／ID管理基盤：オープンソースの認証基盤Keycloak（およびRed Hat build of Keycloak）は、FIPS 140-2モードで動作させる場合に
bc-fips/bctls-fips/bcutil-fipsのjarをprovidersディレクトリへ配置することが公式ドキュメントで必須とされています。 - Java製のパッケージ製品・アプライアンス：製品のインストーラがjarとして同梱するため、資産管理台帳にも「インストール済みソフトウェア一覧」にもBouncy Castleという行は現れません。
- 自社開発のJavaアプリケーション：MavenやGradleの依存関係として入っています。開発チームが直接指定していなくても、別のライブラリが引き込んでいる（推移的依存）ケースが多々あります。
なお、Androidにも com.android.org.bouncycastle としてリパッケージされたものが含まれていますが、これはAOSP独自の派生であり、上流のバージョン体系（1.85など）とは対応しません。今回の修正がそのまま当てはまるとは限らないため、Android端末側については別途OSアップデートの提供状況で判断してください。
何が起きたのか──22件のうち、まず見るべき4件
1.85は2026年7月28日にリリースされ、22件のCVEをまとめて修正しています。件数の多さに目を奪われがちですが、種類として明確に危険度が高いのは「検証をすり抜ける」タイプです。単なるメモリ枯渇（DoS）系と、認証・署名の検証が破られる系とでは、実務上の重みがまったく違います。
| CVE | CVSS 4.0 | CWE | 内容 |
|---|---|---|---|
| CVE-2026-58062 | 9.3 クリティカル | CWE-295 | ステープルされたOCSP応答を、検証対象の証明書と結び付けずに受け入れる |
| CVE-2026-59638 | 9.3 クリティカル | CWE-297 | JSSEのホスト名検証で、CN（コモンネーム）へのフォールバックが既定で有効になっていた |
| CVE-2026-12860 | 8.7 高 | CWE-347 | RSA PKCS#1署名検証で、ハッシュ末尾2バイトを検証していない経路がある |
| CVE-2026-59639 | 8.7 高 | CWE-347 | CMSの verifySignatures が、署名者ゼロのSignedDataに対して true を返す |
CVE-2026-58062：失効した証明書が「有効」として通る
OCSPは証明書が失効していないかを確認する仕組みで、OCSPステープリングはその応答をサーバ側がTLSハンドシェイク中に添えて渡す方式です。本来クライアントは「この応答は、いま提示されている証明書についてのものか」を照合しなければなりません。ところが1.85未満ではその紐付けを確認していませんでした。
結果として、攻撃者は「別の（有効な）証明書についての正当なOCSP応答」を添えることで、失効済みの証明書を有効であるかのように通せることになります。証明書の失効という、インシデント対応の最後の砦が効かないという話です。CVSSベクタは AV:N/AC:L/PR:N/UI:N/VC:H/VI:H で、公表日は2026年8月2日。影響範囲は1.66以上1.85未満、LTS版は2.73.0以上2.73.12未満です。
なお同時期に、OpenSSLでもOCSP応答処理の脆弱性（CVE-2026-54876）が公表されています。こちらはメモリリークによるサービス拒否で性質が異なりますが、あわせて確認しておくとよいでしょう（OpenSSLのOCSP脆弱性、影響は3.6と4.0のみ）。
CVE-2026-59638：ホスト名検証が20年前の作法に戻っていた
TLSでは、接続先のホスト名が証明書のSAN（Subject Alternative Name）に含まれるかを検証します。証明書のCN（コモンネーム）でホスト名を判定するのは古い作法で、現在は非推奨です。Bouncy Castleでもこのフォールバックは「明示的に有効化した場合のみ動く（opt-in）」とドキュメントに書かれていました。
ところが実装は既定で有効になっていた、というのが本件です。ドキュメントと実装が食い違っていたわけで、利用者は「切ってあるはず」と信じたまま、緩い検証で通信していたことになります。中間者攻撃（MITM）で不正な証明書を掴まされるリスクが上がります。設定を見直したところで気づけない類の欠陥であり、更新以外に手はありません。
署名検証系の2件も見逃せない
CVE-2026-59639は、署名者が1人も含まれていないCMS SignedDataに対して、検証メソッドが true を返すというものです。「署名を検証した」つもりのコードが、実際には何も検証していないことになります。電子契約・請求書の署名検証、ソフトウェア配布物の検証などにCMSを使っている場合は影響が出ます。
CVE-2026-12860は、RSA PKCS#1署名の検証において、ハッシュ値の末尾2バイトを比較していない経路があるというものです。検証の厳密性が落ちる問題で、CWEはいずれもCWE-347（暗号署名の不適切な検証）です。
このほか、Name Constraintsの回避（CVE-2026-8763）、CCMモードでタグ検証前に平文を書き出す問題（CVE-2026-58061）、OpenPGPのAEAD復号でチャンク境界のタグ検証が飛ぶ問題（CVE-2026-12817）、S/MIMEで署名者が主張した時刻をそのまま信頼する問題（CVE-2026-59641）などが含まれます。全22件の一覧は公式のリリース情報で確認できます。
自社は影響を受けるのか──ファイル名で探すのが最短
資産管理ツールでは見つからないため、jarファイル名で直接探すのが確実です。Bouncy Castleのjarは命名規則が決まっているので、これが一番早く当たります。
bcprov-jdk18on-*.jar（暗号プロバイダ本体）bcpkix-jdk18on-*.jar（証明書・CMS・OCSP関連）bctls-jdk18on-*.jar（TLS／JSSEプロバイダ）bcutil-jdk18on-*.jar（ASN.1ユーティリティ）bc-fips-*.jar/bctls-fips-*.jar（FIPS版）bcprov-lts8on-*.jar（LTS版）bcprov-jdk15on-*.jar（1.71より前の旧命名。既にサポート終了なので発見したら別途対処が必要）
探し方の例です。
# Windows（PowerShell）
Get-ChildItem -Path C:\ -Recurse -Include bcprov-*.jar,bcpkix-*.jar,bctls-*.jar,bcutil-*.jar,bc-fips-*.jar -ErrorAction SilentlyContinue | Select-Object FullName
# Linux
find / -name 'bc*.jar' 2>/dev/null注意点として、war/earファイルの中に埋め込まれている場合はファイル検索で出てきません。アプリケーションサーバに配備しているwar/earは、unzip -l や jar tf で中身の WEB-INF/lib を確認してください。SBOMを整備している組織であれば、そちらで org.bouncycastle を検索するほうが速く、漏れも少なくなります。
修正版は、通常版が1.85、LTS版が2.73.12です。FIPS版（BC-FJA）はCVEごとに修正バージョンが異なる（モジュール系列ごとに番号が分かれている）ため、公式アドバイザリで自社の系列に該当する番号を個別に確認してください。ここを一律に扱うと取りこぼします。
現場目線の課題──見つけても、自分では直せない
正直なところ、この種の脆弱性でいちばん重いのは「見つけた後」です。
自社開発のアプリなら、開発チームに依存関係の更新を依頼すれば済みます。しかしベンダー製品に同梱されていた場合、jarを勝手に差し替えるとサポート対象外になる可能性が高い。実際には「該当を確認しました。ベンダーの対応版をお待ちします」で止まるケースが少なくありません。それでも棚卸しには意味があります。どの製品が該当し、どのベンダーに問い合わせ中で、いつ回答が来たのか——この記録があるかないかで、監査や経営層への説明の質がまったく変わるからです。
もう一つ、この件は脆弱性管理の「粒度」の問題でもあります。多くの組織の脆弱性管理は製品単位で回っており、製品の中にある個々のライブラリまでは追えていません。libssh2やOpenSSLのようなライブラリ系の脆弱性が出るたびに、同じ苦労を繰り返すことになります（libssh2に深刻な整数オーバーフロー脆弱性2件、PoC公開）。SBOMの整備は掛け声だけになりがちですが、こういう日に効いてきます。まず「Java製品だけでも依存ライブラリの一覧を持つ」ところから始めるだけでも、次回の初動が変わります。
情シスはどうすべきか
今回の対応そのものは「該当を洗い出して更新する」に尽きます。そのうえで、こうしたOSSコンポーネント起因の脆弱性に日常的に備えるための指針として、公的機関の資料を参照してください。自前で長いチェックリストを作るより確実です。
- IPA「中小企業の情報セキュリティ対策ガイドライン」：資産の把握と脆弱性対応の体制づくりの基礎。規模を問わず使えます。
- JPCERT/CC Weekly Report（2026年8月13日号）：本件を含む週次の脆弱性情報。定期購読しておくと、この種の見落としが減ります。
- IPA「セキュリティインシデント対応 机上演習教材」：「該当製品が判明したがベンダー対応待ち」という状況をどう管理するかは、演習で一度通しておくと動きが変わります。
あわせて、開発チームや製品導入部門と「使っているライブラリを聞ける関係」を作っておくことも、地道ですが効果的です。技術的な対策と同じくらい、この横のつながりが初動を左右します。
まとめ
- Bouncy Castle 1.85で22件の脆弱性が修正された。うち2件はCVSS 9.3のクリティカルで、OCSP応答の紐付け欠如（CVE-2026-58062）とホスト名検証のCNフォールバック既定有効（CVE-2026-59638）という、TLSの証明書検証が事実上効かなくなる内容。
- 「導入した覚えがない」は根拠にならない。Java製の認証基盤・パッケージ製品・自社開発アプリにjarとして同梱されているため、資産管理台帳には現れない。
bcprov-*.jar等のファイル名検索、またはSBOMで確認する。 - 修正版は通常版1.85／LTS版2.73.12。FIPS版はCVEごとに番号が異なる。ベンダー製品に同梱されている場合は自己判断で差し替えず、該当状況を記録したうえでベンダーの対応版を待つ。
