Bouncy Castleに脆弱性32件 CVE-2026-59638ほか、1.85へ更新を

Javaの定番暗号ライブラリ「Bouncy Castle」に、32件の脆弱性がまとめて公表されました。2026年8月3日、開発元が自ら採番したCVE番号が一斉に公開されています。危険度が最も高い「緊急」に分類されたものが4件、「重要」が22件です。

修正は 1.85（2026年7月12日公開）に入っています。1.84以前はすべて対象と考えて差し支えありません。長期サポート版は 2.73.12、FIPS版は成分ごとに別のバージョンです（後述します）。

そして、この件の本題はここからです。32件のうち29件は、AIを使った解析で見つかったものでした。CVEの記録に「Alex Gaynor in collaboration with Claude and Anthropic Research」という報告者名が並んでいます。単一のライブラリで29件という規模は、これまで公表されてきたAI起点の脆弱性発見のなかでも最大級です。

ところが——この32件は、いまお使いの脆弱性チェックツールにほぼ何も表示されません。GitHubのセキュリティ勧告データベースへの登録は32件中0件。DependabotもGitHub Advanced Securityも沈黙したままです。以下、順に整理します。

どのバージョンなら安全なのか

Bouncy Castleは3つの系統で配布されており、系統ごとに修正版の番号が違います。ここを取り違えると「上げたつもりで直っていない」が起きます。

通常版なら話は簡単で、org.bouncycastle:bcprov-jdk18on をはじめとする8つの成分をすべて 1.85 に揃えれば終わりです。mvn dependency:tree や gradle dependencies で、他のライブラリが内部で引き込んでいる版まで洗い出してください。

数字で言うと、移行はまったく進んでいません。公開されている依存関係データでは、修正版1.85を参照しているコンポーネントは1,256件にとどまるのに対し、脆弱な1.84は7,433件、1.78.1は8,749件が今も参照しています。

FIPS版を使っている場合は、話がややこしくなります

金融機関や官公庁向けのシステムでは、米国政府の暗号モジュール認証を取得したFIPS版が使われます。こちらは「1.85にすればいい」では済みません。成分ごとに修正版の番号がバラバラで、しかも1.0系・2.0系・2.1系の3系統がそれぞれ別番号です。

この表は、32件のCVE記録に書かれた影響範囲をすべて突き合わせて組み立てたものです。加えて、実際にMaven Centralに各バージョンが存在するかも1つずつ確認しました。

1点、名前で引っかかりやすい落とし穴があります。FIPS版のプロバイダは bcprov-fips ではなく bc-fips です。通常版が bcprov-jdk18on なので、そのつもりで探すと見つかりません。

さらに厄介な点があります。開発元のFIPS版ダウンロードページには、プロバイダの修正版が置かれていません。掲載されているのは 2.1.2 / 2.0.1 / 1.0.2.6 で、修正版である 2.1.3 / 2.0.2 / 1.0.2.7 が並んでいないのです（Maven Centralには存在します）。公式サイトの手順どおりに取得すると、修正版に辿り着けません。

なお、FIPS認証を取得しているのは 2.1.0 と 2.0.0 に対してであり、修正版 2.1.3 は認証済みバージョンではありません。認証取得を要件にしている環境では、セキュリティ修正と認証要件のどちらを優先するかという判断が発生します。ここは各組織の事情によるので、当サイトから「こうすべき」とは書きません。

緊急に分類された4件

32件のうち、危険度9.3（10点満点）の「緊急」が4件あります。いずれも「守っているつもりの検証が、実は素通りしていた」という性格のものです。

CVE-2026-59638: 証明書のホスト名検証が、既定で緩い設定になっていた

4件のなかで最も影響が広いものです。TLS通信で相手のサーバーが本物かを確かめる際、証明書に書かれたホスト名を照合します。この照合方式には古い方式（コモンネームを見る）と現行方式があり、古い方式は偽装に弱いため、使いたい人だけが明示的に有効化する仕組みになっているはずでした。ところが実装では既定で有効になっていました。ドキュメントの記載と実際の挙動が食い違っていた形です。

CVE-2026-58062: 証明書の失効確認が、別の証明書のものでも通っていた

証明書が失効していないかを確認する仕組み（OCSP）で、受け取った失効確認の応答が、いま検証している証明書のものかを紐づけていませんでした。別の有効な証明書に対する「問題なし」の応答を持ってくれば、失効済みの証明書でも通ってしまいます。

CVE-2026-8763: 末尾のドット1つで、証明書の発行制限を回避できた

中間認証局には「この範囲の証明書しか発行してはいけない」という制限をかけられます。その制限の照合で、user@bank.com. のように末尾にドットを1つ足すと、除外リストとの比較に引っかからなくなるという欠陥でした。制限をかけたつもりの認証局が、範囲外の証明書を発行できてしまいます。

CVE-2026-59650: 相手から送られた値を検証せずに計算に使っていた

鍵交換の処理で、通信相手から受け取った値が正しい範囲にあるかを確かめないまま、そのまま計算に投入していました。細工した値を送り込むことで、共有される鍵を攻撃者の望む形に誘導できる余地が生まれます。

残る28件も、性格は似ています。署名者が0人の署名データを「検証成功」と返していた（CVE-2026-59639）、署名の検証でハッシュの最後の2バイトを読み飛ばしていた（CVE-2026-12860）、暗号文の改ざん検知が終わる前に平文を呼び出し元のバッファへ書いていた（CVE-2026-58061）——といった具合です。派手な乗っ取りではなく、「検証したことになっているが、実際には検証していない」類が並びます。暗号ライブラリの欠陥としては、こちらのほうが厄介です。

誰が、何のために狙うのか

今回の32件で狙われるのは、あなたのサーバーそのものではありません。標的になるのは、そのサーバーが「相手は本物だ」「この署名は正しい」と判断する、その判断そのものです。

具体的に想定されるのは、通信経路に割り込める立場にいる相手です。公衆無線の提供者、経路上のネットワーク機器を握った侵入者、あるいは不正に発行された証明書を用意できる立場。そうした相手が行うのは、偽のサーバーや偽の署名を、正規のものとしてすり抜けさせることです。ホスト名の照合が緩ければ偽サイトが本物として通り、失効確認が紐づいていなければ失効済みの証明書が生き返ります。

被害の出方が独特なのは、成功しても何も壊れない点です。エラーは出ず、ログにも異常は残らず、通信は正常に完了します。利用者から見れば、いつもどおりログインできて、いつもどおり処理が終わる。その裏で、通信の中身が第三者に読まれているか、偽の相手とやり取りしているだけです。侵入の痕跡を探す通常の監視では、まず気づけません。

ただし現時点で悪用の報告はありません。米政府CISAが公開する実際に攻撃が確認された脆弱性のリスト（KEV）にも、32件はいずれも収載されていません。

29件を見つけたのは誰か

CVEの記録には、報告者としてこう書かれています。「Alex Gaynor in collaboration with Claude and Anthropic Research」。32件中29件がこの名義です。

Alex Gaynor氏は、GitHubのプロフィールによればAnthropicに所属するエンジニアです。Python Software FoundationとDjango Software Foundationの理事を務め、Pythonの主要な暗号ライブラリ pyca/cryptography のメンテナでもあります。暗号実装の世界では以前から名前の通った人物で、AIが単独で見つけたのではなく、その領域の専門家がAIを道具として使ったという構図です。

本人は2026年7月15日のブログで、「バグ修正では脆弱性の黙示録から抜け出せない」という趣旨の主張を書いています（冒頭で「私はAnthropicで働いている」と所属を開示しています）。新しい技術によって既存のソフトから大量の脆弱性が掘り出され、脆弱性の総量に関する前提が崩れる。個別の修正では追いつかないので、脆弱性の「種類」そのものを消す作りに投資すべきだ、という内容です。今回の32件は、まさにその主張の実例になっています。

Anthropicは、Claudeが見つけた脆弱性について開示方針を公開しています。90日の開示期限、悪用中の重大な脆弱性は7日目標、報告は人間がレビューしAI由来であることを明示する、事前調整なしの大量提出はしない——といった内容です。同社の2026年5月の中間報告では、1,000件超のオープンソースを調べて23,019件を検出、うち危険度の高いものが6,202件、開示済みが530件、修正済みが75件と公表されています。

なおこの投稿は今回の32件についてのものではありません。同社が7月28日に公表した、実装のバグではなく暗号アルゴリズムそのものの数学的な弱点を探す別の研究についての告知です。今回のBouncy Castleの32件について、Anthropicは公式には何も発表していません。同社のニュース・研究ページにも、開示状況をまとめたダッシュボードにも記載がなく、CVEの記録が事実上唯一の一次情報です。

開発元の告知も、Gaynor氏にもClaudeにもAnthropicにも一切言及していません。1.85のリリース告知にあるのは「advanced AI-based coding analysis tools（先進的なAIベースのコード解析ツール）を使う人々から受けた助けの結果」という一文だけで、固有名詞はどこにもありません。

32件すべてがAI発見というわけではありません

この点は、はっきり書いておきます。AI起点は29件であって、32件ではありません。残る3件は別の報告者です。

また CVE-2026-13506 は、発見者が「Yt」名義の別人で、Gaynor氏は報告者として併記されています。「AIが32件見つけた」と書くと、実在する研究者の仕事を消してしまうことになります。

それでも、あなたのツールは何も言いません

ここが今回いちばん実務に効く話です。29件をAIが見つけたところで、その情報が届かなければ意味がありません。そして現状、ほとんど届いていません。

NVDへの取り込みは、公開当日のうちに追いつきました。本記事の初出時点では23件でしたが、同日13時台に残る9件（CVE-2026-12802・12803・12816・12817・12852・12860・13506・13586・14682）が登録され、32件すべてがNVDで引けるようになっています。一方でGitHub Advisoryは動いていません。GitHubのAPIに32件を1件ずつ問い合わせて、すべて空の結果でした。対照実験として過去のBouncy CastleのCVE番号を投げると正しく1件返るので、APIが壊れているわけではありません。単に登録されていないのです。

JVN iPediaに至っては、Bouncy Castleの収録が2023年で止まっています。2024年・2025年・2026年のエントリが1件も存在しません。国内の脆弱性情報をJVN経由で追っている組織には、今回の32件どころか、ここ2年分がまるごと届いていないことになります。

さらに細かい話をひとつ。32件のCVE記録が「開発元の詳細説明」として指しているリンクは、31件がリンク切れです。いずれもプロジェクトのWikiページを指していますが、該当ページが1件しか作られていません。しかもその唯一のページは、ファイル名に通常のハイフンではない別種の文字が使われており、CVE側のリンクからは辿り着けずトップページへ飛ばされます。開発元の開示方針は「修正リリースの数日以内にアドバイザリを公開する」と述べていますが、リリースから3週間が過ぎた時点で1件です。

依存関係の点検を手早く済ませたい場合は、パッケージ一覧を貼るだけで確認できるスキャナーのような仕組みもありますが、こちらはnpmとPythonが対象です。Javaは上記のコマンドで手動確認するしかありません。今回に限っては、自動化された仕組みのどれもが当てにならないという前提で動く必要があります。

国内でも、脆弱な版が現役で使われています

「Javaの暗号ライブラリ」と聞くと縁遠く感じるかもしれませんが、国内でも身近なところで使われています。しかも公開情報を追う限り、いずれも修正前のバージョンです。

ひとつめ。OSSTechの「LibJeID」は、NFC対応スマートフォンでマイナンバーカード・運転免許証・パスポート・在留カードのICチップを読み取るためのライブラリです。本人確認や窓口業務で使われます。同社のリリースノートには「2026年4月2日: Bouncy Castle LTS 2.73.10にアップデートしました」とあります。修正版は 2.73.12 です。

ふたつめ。NTTデータのJavaフレームワーク「Nablarch」は、電子署名つきメール送信のサンプルでBouncy Castleを使っています。公式ドキュメントに載っている設定は bcjmail-jdk18on の 1.78.1 です。この成分は今回、S/MIMEの署名時刻検証の欠陥（CVE-2026-59641）に直撃しています。もっとも同ドキュメントは「最新リリースの有無を必ず確認すること」と明記しており、注意喚起自体は行われています。

みっつめ。GMOペイメントゲートウェイは、技術ブログで、公共料金事業者向け決済サービスの加盟店ファイル連携におけるPGP暗号化にBouncy Castleを採用したと公表しています（JJUG CCC Fall 2025での発表）。PGP処理を担う bcpg には、今回5件の脆弱性が集中しています。ただし同社が使っているバージョンは記事に書かれておらず、影響の有無は未確認です。

いずれも「危ない」と断定するものではありません。公開情報として確認できるバージョンが修正前だ、という事実の指摘です。

AIによる脆弱性発見は、いまどのくらいの規模なのか

単一ライブラリで29件という数がどれくらいのものか、これまでの事例と並べてみます。

全体の傾向としては、もっと大きな数字が出ています。Epoch AIの分析によれば、2026年6月に公開された危険度の高いCVEは約1,500件で、それ以前の月間最高記録（約400〜430件）の3.5倍を超えています。集計対象はMicrosoft・Google・Apple・Oracle・Ciscoなど著名21組織の開示に絞られており、無名の届出は混ざっていません。

当サイトでも以前、Claude CodeとCodexに実際の脆弱性を修正させる検証を行い、17回中1回しか直せなかったという結果を記録しています。見つけることと直すことは別の能力だ、というのがそのときの結論でした。今回の29件は、その「見つける」側が実運用の規模に達したことを示す事例です。VulnCheckが2026年4月に集計した時点では、Anthropic系のクレジットが付いたCVEは全ベンダー合計で40件でした。第三者が追跡している一覧でも、Bouncy Castle分はこれまで1件だけです。今回の32件はまだ反映されていません。

修正版は3週間前から出ていました

日付を並べると、この件の性格がよく見えます。

修正版の公開からCVE公開まで22日間あります。この間、番号が付いていないので何も検知されず、中身を知らないまま自動更新で1.85に上がった環境と、1.84のまま残った環境が併存していたことになります。

この「先に直して、あとから番号を付ける」という順序は、実はこのライブラリでは初めてではありません。次に述べる CVE-2024-14041 も、修正から2年以上が経ってから番号が付いた案件でした。

2026年7月公表: 秘密鍵が処理時間から漏れる CVE-2024-14041

ここからは、2026年7月28日に公表された別の脆弱性の話です。上記32件とは別件ですが、同じライブラリの話なので記録として残します。

CVE-2024-14041 は、処理にかかる時間のわずかな差を大量に測ることで、外に出してはいけない秘密鍵が復元できてしまうというものです。危険度はCVSS 4.0で8.2。

この欠陥は2024年4月公開の1.78ですでに直っています。影響するのは1.73から1.77で止まっている環境だけです。1.72以前は、舞台となるML-KEM（旧称Kyber）という新しい暗号方式の実装自体が入っていないため対象外です。

割り算にかかる時間から、鍵が割れる

この欠陥の種類はタイミング攻撃と呼ばれます。プログラムの出力そのものではなく、処理にかかった時間から、中で扱っている秘密の値を推測する手口です。

鍵になっているのは、CPUの割り算です。多くのCPUでは、割り算の所要時間が「割られる数」の中身によって微妙に変わります。ところがML-KEMの実装では、秘密の値を、誰でも知っている固定の数（3329）で割る処理が何か所かに入っていました。割る数は公開されていても、割られる数が秘密であれば、かかった時間はその秘密の情報を漏らします。これを大量の通信で観測して統計的に積み上げると、長期利用している秘密鍵そのものが復元できてしまいます。

この問題はKyberSlashという名前で知られています。Bouncy Castleで該当したのは3か所で、復号したメッセージを取り出す Poly.toMsg（KyberSlash1）と、暗号文を圧縮する Poly.compressPoly・PolyVec.compressPolyVec（KyberSlash2）です。暗号化のときに動く圧縮処理は対象外で、そこで扱う値は最終的に公開される暗号文になるため、時間から漏れても問題になりません。危ないのは復号側だけです。

修正は素直で、2023年12月16日と2024年1月5日の2つの変更で、秘密の値に対する割り算をすべて掛け算とビットのずらし操作の組み合わせに置き換えています。掛け算とシフトは、中身によって所要時間が変わりません。

この投稿は、暗号研究者のダニエル・J・バーンスタイン氏が2023年12月に問題を公表したときのものです。KyberSlashはもともと、形式検証されたKyber実装を作っていたCryspenのチームが最初に気づき、開発元のpq-crystalsへ報告して2023年12月1日に1か所目が修正されました。バーンスタイン氏はこれとは独立に発見し、同年12月30日には実際に鍵を復元する実演を公開しています。その後の研究をまとめた論文はCHES 2025の最優秀論文賞を受賞しており、「KyberSlash2なら数分、KyberSlash1でも数時間で鍵を復元できた」と報告されています。理屈の上の話ではなく、実際に動く攻撃です。

この攻撃を実際に使える相手は限られる

この手口を実際に使えるのは、無差別に脆弱なサーバーを探し回る相手ではありません。狙えるのは、同じ鍵を使い続けているサーバーに対して、何万回・何十万回と通信を投げ、その一回ごとの応答時間を精密に測り続けられる立場にいる相手です。同じクラウドの隣の仮想マシンにいる、同じネットワークの内側にいる、といった条件が要ります。

その相手がやるのは、測った時間の分布から、サーバーが持っている長期の秘密鍵を計算で組み立て直すことです。鍵さえ手に入れば、あとは正規の受信者として通信を復号できます。侵入した形跡は残りません。失われるのは、その鍵で守られていた通信の中身すべてで、過去に記録された通信までさかのぼって読まれる可能性もあります。ただし、ここまでの条件を揃えられる相手は限られており、ばら撒き型の攻撃で踏む類のものではありません。

耐量子暗号への移行で、これから増える種類の欠陥

ML-KEMは、将来の量子コンピュータでも破られないことを目指した耐量子暗号の代表格で、米国立標準技術研究所がFIPS 203として2024年に標準化したものです。Googleは2029年を暗号が破られ始める節目と見ていると公表しています。

KyberSlashが示したのは、暗号方式そのものが数学的に安全でも、実装の書き方ひとつで鍵は漏れるという、地味だが重い事実です。しかも漏れた原因は、高度な暗号解読ではなく「割り算を1つ使っていた」ことでした。今回の32件も性格は同じで、方式ではなく実装の側の話です。暗号ライブラリの欠陥は、node-forgeの署名偽造のように、気づきにくい形で信頼の土台を崩すのが常です。

いま確認すべきこと

第一に、依存関係の中のBouncy Castleを数えることです。直接書いていなくても、他のライブラリが内部で引き込んでいることがよくあります。mvn dependency:tree や gradle dependencies で、間接的に入っている版まで洗い出してください。認証基盤のKeycloakのような有名どころも、Bouncy Castleの脆弱性対応を課題として追跡しています。

第二に、系統に応じた修正版へ上げることです。通常版なら1.85、長期サポート版なら2.73.12。FIPS版は前掲の表で成分ごとに確認してください。ここが今回いちばん間違えやすい箇所です。

第三に、自動チェックの結果を信じないことです。Dependabotが黙っていても、それは安全という意味ではありません。今回に限っては、スキャナーの緑色は「まだデータが登録されていない」だけである可能性が高い。手でバージョン番号を見る以外に確認方法がありません。

第四に、1.73〜1.77が残っていたら、前掲のCVE-2024-14041も併せて該当します。もっとも1.85に上げれば両方まとめて解決します。Javaの定番部品に穴が見つかったときの騒ぎ方という点では、Fastjsonの乗っ取りの件とは事情が違います。あちらは無認証で即座に乗っ取られるもので、こちらは条件つきの検証すり抜けです。急ぎ方は分けて考えてください。

まとめ

Bouncy Castleに32件の脆弱性がまとめて公表されました。緊急4件・重要22件で、内容は「検証したことになっているが実際には検証していない」類が中心です。修正は通常版1.85、長期サポート版2.73.12、FIPS版は成分ごとに別番号。1.84以前はすべて対象と考えてください。悪用の報告はありません。

32件のうち29件は、Anthropicに所属するエンジニアがAIを使って見つけたものです。単一ライブラリでこの規模は前例がありません。ただし32件すべてがAI発見ではなく、3件は別の研究者による報告です。

そしてこの記事で最も伝えたいのは、華やかな発見の話ではなくその29件が世界中のスキャナに1件も届いていないことのほうです。GHSA 0件、Debian 0件、Ubuntu 0件、JVN 0件。開発元が示す詳細説明のリンクも31件が切れています。見つける速度に、届ける仕組みが追いついていません。AIが脆弱性を掘り出す量が増えるほど、この落差は広がります。今回はその落差が、はっきり数字で見える形で出てきました。

参照元

• ▸Bouncy Castle - 1.85 リリース告知（32件のCVE一覧）
• ▸Bouncy Castle - FIPS版ダウンロード
• ▸Bouncy Castle - 脆弱性開示ポリシー
• ▸NVD - CVE-2026-59638（ホスト名検証の既定設定）
• ▸NVD - CVE-2026-8763（証明書の発行制限回避）
• ▸Alex Gaynor「You can't bug fix your way out of the vulnpocalypse」
• ▸Anthropic - 協調的脆弱性開示ポリシー
• ▸Anthropic - Project Glasswing 中間報告（2026年5月）
• ▸VulnCheck - Anthropic系クレジットCVEの集計（2026年4月）
• ▸Epoch AI - 危険度の高いCVE公開数の推移
• ▸NVD - CVE-2024-14041（KyberSlash）
• ▸KyberSlash - 解説ページ（Daniel J. Bernstein ほか）
• ▸KyberSlash - 各実装の対応状況一覧
• ▸bc-java - KyberSlash1（Poly.toMsg）の修正コミット
• ▸bc-java - KyberSlash2（圧縮処理）の修正コミット
• ▸論文「KyberSlash: Exploiting secret-dependent division timings in Kyber implementations」（CHES 2025最優秀論文賞）