PHP脆弱性で金融サービス停止…経営が問われる“再開判断”と6つの備え(4/4)

PHP対応の次はBrotli、何を守る？

　ところが、PHPの対応が一巡する間もなく、さらに新たな脅威が台頭している。Webサイトの裏側で使われるデータ圧縮技術「Brotli（ブロトリ）」に、深刻な脆弱性（CVE-2026-111497）が見つかったのだ。Brotliは米グーグルが開発した圧縮方式で、Webサイトに使われる文字やプログラムなどのデータを小さくして送る用途に広く使われている。

　荷物を圧縮袋に入れてコンパクトにし、届いた先で元に戻すようなものと考えればよい。今回、欠陥が見つかったのは、このうち圧縮されたデータを元に戻す「展開」の処理である。グーグルは10月21日に修正版を公開し、JPCERT/CCも26日に注意喚起を行った。

　仕組みはこうだ。攻撃者が細工した圧縮データを読み込ませると、展開の過程でプログラムが使うメモリの一部が壊れる。その結果、アプリケーションが突然終了する、内部の情報が漏れる、場合によっては不正なプログラムを実行される、といった被害が起こり得る。しかも、細工された圧縮データを展開する処理が動けば、攻撃が成立し得る。

　注意すべきは、本件が先の「PHP2Shell」（CVE-2026-109618・CVE-2026-109619）とは別の問題であり、かつ影響範囲が広いことだ。BrotliはNode.jsやBun、Python向けのパッケージなど、多くのソフトウェアの内部に部品として組み込まれている。

　対象はBrotliの1.0.3以上1.0.10未満、1.1.0以上1.1.1未満、1.2.0以上1.2.1未満で、修正版は1.0.10、1.1.1、1.2.1である。組み込み先の製品ごとに修正版が順次公開されている。

　もっとも、影響を受けるのは、外部から受け取った圧縮データを展開する処理がある場合に限られ、すべてのWeb閲覧が一律に危険という意味ではない。利用する製品や構成、修正状況に応じて影響を判断する必要がある。その分、自社のどこで展開処理が動いているかが見えにくいという厄介さがある。

　筆者が重く受け止めているのは、PHPという個別の言語にとどまらず、Web通信の基盤を成す「部品」にまで、このような緊急度の高い脆弱性が相次いで見つかった点である。インターネットバンキングやアプリのバックエンド、外部APIとの連携、委託先が運営するサイトなど、金融機関のサービスは多層のサービス、基盤、部品の上で成り立っている。

　経営層が把握しているのは最上位のシステムの名称だけで、どの部品がどこに実装されているかについては、現場レベルでさえ把握しきれていない可能性がある。

　では、こうした脅威にいかに備えるべきであろうか。対処の基本方針として、以下の5点を挙げておきたい。

Brotli対応、押さえるべき5つの確認点

（1）外部データの展開処理を洗い出す
　自社および委託先のシステムのうち、外部から受け取った圧縮データ（受信リクエスト、外部APIやサイトからの応答、圧縮ファイルなど）を展開している箇所を特定する。Node.js、Bun、Python向けのパッケージなどの組み込み先ごとに確認する必要があり、PHPの棚卸しで整備したIT資産台帳やSBOMを活用すべきである。インターネットに公開しているサーバやAPIから優先的に着手する。

（2）更新の反映まで確認する
　Brotli本体は修正版（1.2.1、1.1.1、1.0.10）へ、組み込み製品は各開発元が公開する修正版へ更新する。更新後は必要なプロセスの再起動や、更新済みのイメージによるコンテナの再作成など、実際の実行環境への反映まで確認する。Linuxの配布パッケージは上流の版番号と対応しないため、各ディストリビューションの案内で判断する。

（3）更新できない場合の暫定措置
　グーグルは本脆弱性に対する緩和策を提供していないため、組み込み製品の開発元の案内に従い、信頼できないデータの展開を一時的に止める、あるいは該当する機能や経路を止める判断が必要になる。配信側（CDN等）で圧縮を止めても、受け取った側の展開は止まらない点にも留意したい。ここでも、先のPHP対応で求められた「止める判断」と「再開の判断」の枠組みがそのまま当てはまる。

（4）更新前の侵害有無も調査する
　JPCERT/CCは、修正版の適用に加え、侵害の有無の調査も呼びかけている。修正前の版で外部データを展開していたシステムについては、異常終了の履歴や通信ログに不審な痕跡がないかを確認し、必要に応じて認証情報の見直しも検討する。更新して終わりではなく、更新前に悪用されていなかったかを確かめるまでが一連の対応である。

（5）委託先管理と情報共有を進める
　共同センターや外部ベンダー、クラウド事業者に対し、Brotliを組み込んだ製品の利用有無と対応状況の報告を求め、実態を把握する。あわせて、金融ISACや当局を通じた情報共有を活用し、単独では確認に限界のある中小の金融機関も、業界全体で知見を補い合うこと、すなわち共助を意識した対応を指向することが望ましい。

政府の呼びかけを待たず、判断できるか

　今回の特異な事案では、PHPに続きBrotliでも、深刻な脆弱性が特定の製品ではなく、Webの基盤を成す部品から連鎖的に表出する格好となった点に注目する必要がある。個別の脆弱性ごとに右往左往するのではなく、「自社はどの部品にどれだけ依存しているのか」を平時から把握し、停止・更新・再開を一連の手順として回せる体制を整えておくことが、新たな脅威に対する最も現実的な備えとなる。

　金融庁はかねて監督指針において「最悪なケースを想定」した対応態勢を平時から整備することを要請してきた。また、2024年10月に金融庁が公表したサイバーセキュリティガイドラインでは、経営層がサイバーセキュリティにおける一層のグリップを利かせることで、善管注意義務を意識した主体的な行動をとることを求めてもいる。

　総じて、経営層に求められるのは、「止める判断」を現場任せにせず、自らが責任を引き受ける姿勢を平時から明確にしておくことである。

　具体的には、（1）どのような条件下で、誰の権限によりシステムを停止できるのかを事前に定め、CISO（最高情報セキュリティ責任者）などへの権限委譲を含めて明文化しておくこと、（2）停止から再開に至る一連の判断を、演習を通じて経営陣自身が模擬的に経験しておくこと、（3）今回のような政府からの呼びかけを待たずとも、自社として迅速に判断を下せる体制を構築すること、の3点だ。

　先の金融庁のサイバーセキュリティガイドラインでも、経営陣の関与とリーダーシップが求められている。今回の事案は、サイバーセキュリティを「システム部門の課題」ではなく「経営課題」として位置づけられているか否かが試された局面であったと言えるだろう。

　脆弱性の公表から悪用までの時間が短縮されていく以上、次の「その時」に、政府が呼びかけてくれるとは限らない。止める判断と再開する判断を平時のうちに経営の手元に引き寄せておくことが、最大の備えとなるはずだ。