OpenSSLとApache Tomcatに脆弱性が相次ぎ公表、JVNが注意喚起。Webの"土台"は誰が更新するのか

まず初めに

インターネットの土台は、名前も知られていないソフトの積み重ねでできている。OpenSSLとApache Tomcat。この2つの名前を今日初めて見た人も、今日すでに何十回もお世話になっている。鍵マークのついた通信も、会員サイトのログイン画面も、その裏で静かに動いている。静かすぎて、更新されているかどうかを気にする人がほとんどいない。脆弱性そのものより、「誰も見ていない配管を、誰が直すのか」という問いのほうが、この手のニュースの本題だ。※個人の感想です

何が起きているのか

JVNは、国内外で報告された脆弱性の情報を日本語でまとめ、注意を呼びかける公的な仕組みです。運営はJPCERT/CCとIPAが担っています。

このJVNが、9月3日に2件の脆弱性情報を公表しました。1件はOpenSSLに関するもので、「OCSPレスポンスの検証」という処理に関わる、クライアント側のメモリの扱いの不具合です(CVE-2026-54876)。OCSPは、通信相手の電子証明書が失効していないかを確認する仕組みで、その応答を検証する処理に問題があると、細工された応答によって不具合を起こされる恐れがあります。深刻度は「高」に区分されています。もう1件はApache Tomcatに同梱されているサンプルのチャットプログラムに関するDoS(サービスを停止させる攻撃)の脆弱性で、7月下旬に発見されたものです。

これに先立ち、8月25日には、Apache Tomcat本体の複数の脆弱性(識別番号「JVNVU#96149019」)も公表されています。こちらには、認証の回避、アクセス制御の回避、DoSなど、10件前後の弱点が含まれており、クライアント証明書による認証やOCSP検証を回避されるリスクも指摘されています。

いずれも、Apache SoftwareファウンデーションやOpenSSLプロジェクトが修正版を公開しており、JVNはそれらの適用を呼びかけています。なお、報道や日付の表記はソースによって多少ずれがあり、Apache Tomcat本体の脆弱性の件数も「10件前後」とされるなど幅があります。重要なのは個々の番号よりも、「自分の環境が影響を受けるバージョンか」を提供元の情報で確認し、該当すれば更新する、という基本動作です。

OpenSSLの脆弱性については、影響を受けるのが「サーバー側」ではなく、証明書の失効確認(OCSP)を行う「クライアント側」の処理である点も押さえておく必要があります。つまり、他のサーバーへ接続しに行くプログラムやライブラリが、悪意のある応答を返す相手と通信した場合に問題が生じうる、という構図です。自社サーバーだけを見て「外部公開していないから関係ない」と判断すると、見落とす可能性があります。

なぜ重要なのか

第一に、影響範囲の広さです。OpenSSLは、ウェブサイトの暗号化通信(鍵マークのついたHTTPS)を支える定番のライブラリで、サーバーやネットワーク機器、IoT機器など、数え切れないほどの製品に組み込まれています。Apache Tomcatは、Javaで作られた業務システムやウェブアプリケーションを動かす土台として、企業システムで広く使われています。どちらも「特定の誰かの製品」ではなく、あらゆるところに埋め込まれている部品です。

第二に、更新の届きにくさです。こうした基盤ソフトは、利用者が直接インストールしているとは限らず、他社の製品の中に組み込まれた形で使われていることが多くあります。その場合、修正は「製品メーカーが新しい部品を取り込んで、更新版を配る」のを待つしかなく、時間がかかったり、古い製品では対応されなかったりします。

第三に、深刻度の幅です。今回の一連の脆弱性には、影響の限定的なもの(サンプルプログラムのDoSなど)と、認証回避のように影響の大きいものが混在しています。「まとめて公表された」からといって一律に緊急とは限らず、自分の環境で何が該当するかを見極める必要があります。

私たちへの影響

一般の利用者が、OpenSSLやApache Tomcatを直接操作する場面はほとんどありません。スマートフォンやパソコンのOS・アプリの更新を通常どおり適用していれば、利用者側でできることの大半はカバーされます。

対応が必要なのは、サーバーやウェブアプリケーション、ネットワーク機器を運用している企業・組織の管理者です。まず、自分たちのシステムでOpenSSLやApache Tomcatを(組み込みも含めて)どこで使っているかを把握し、提供元やソフトウェアベンダーが公開した更新情報を確認します。そのうえで、影響を受けるバージョンを使っている場合は、更新版へ差し替えます。すぐに更新できない場合は、外部からの到達経路を絞る、該当する機能(サンプルプログラムなど)を無効化する、といった緩和策を検討します。

家庭で使うルーターやネットワークカメラ、NASなどにもOpenSSLは組み込まれています。これらは、メーカーが配布するファームウェア更新を適用することが対策になります。自動更新を有効にしておく、定期的に更新の有無を確認する、といった習慣が有効です。

初心者が知っておくべきこと

「OpenSSL」は、通信を暗号化し、通信相手が本物かどうかを確認するための処理をまとめた、無償で公開されているソフトウェア部品(ライブラリ)です。ウェブの暗号化通信の多くが、これに支えられています。

「Apache Tomcat」は、Javaという言語で作られたウェブアプリケーションを動かすための土台となるソフトです。企業の業務システムや会員制サイトの裏側で広く使われています。

「JVN」は、脆弱性の情報を日本語で集約し、対策を呼びかける公的な仕組みです。システムを運用する立場の人は、JVNやJPCERT/CCの発表を定期的に確認することが推奨されます。

よくある質問

Q. 自分のパソコンやスマホは大丈夫ですか。 A. OSやアプリの更新を通常どおり当てていれば、利用者側の対応としては十分な場合がほとんどです。今回の脆弱性は、主にサーバーやネットワーク機器を運用する側に関わるものです。

Q. 会社でサーバーを運用しています。何から始めればいいですか。 A. まず、自社のシステムでOpenSSLやApache Tomcatをどこで使っているか(他社製品への組み込みも含めて)を洗い出します。次に、JVNや提供元の情報で影響を受けるバージョンを確認し、更新版を適用します。

Q. 「まとめて10件」と聞くと不安ですが、全部が危険なのですか。 A. いいえ。影響が限定的なものと、認証回避のように影響が大きいものが混在しています。自分の環境で有効になっている機能や設定に照らして、優先度を判断する必要があります。

IT Postの見方

IT Postでは、この種のニュースは「一発の危機」ではなく「終わらない維持管理」の話として読むべきだと考えている。OpenSSLもApache Tomcatも、世界のインフラの土台でありながら、開発と保守を担うのは限られた人手だ。脆弱性は今後も定期的に見つかるし、そのたびに世界中の管理者が更新に追われる。

問題は、その更新がいちばん届いてほしい場所——安い機器、古い製品、担当者のいなくなったサーバー——にこそ、届きにくいことだ。攻撃者はそこを狙う。今回の一連の公表も、大半の組織は粛々と当てて終わりだが、一定数は当てられないまま残り、数カ月後に事故として名前が出る。毎回そうだ。

やることは地味で、変わらない。自分のシステムで何が動いているかを把握する。提供元とJVNの情報を追う。更新を当てる。派手さはないが、これを続けている組織と、続けていない組織の差は、事故が起きたときにはっきり出る。※個人の感想です

今後どうなりそうか

OpenSSLやApache Tomcatのような基盤ソフトの脆弱性は、今後も一定の頻度で公表され続けます。各製品メーカーは、これらを取り込んだ自社製品の更新版を順次配布するとみられ、利用者はその案内に沿って更新を適用することになります。IT Postでは、今回の脆弱性を悪用した攻撃が国内で観測された場合や、影響の大きい追加の脆弱性が公表された場合に、あらためて取り上げます。