今回問題になったPHPの脆弱性「CVE-2026-109618」および「CVE-2026-109619」は、CVSS（共通脆弱性評価システム）v4.0で9.2という高いスコアを記録した。攻撃者が認証を経ずに任意のコードを実行できる恐れがあり、すでにマルウェア「Mirai」によるスキャン活動も報告された。影響を受ける可能性のあるシステム構成は、世界で2260万件に上るとみられる。

　PHPの開発元は2026年10月21日（協定世界時）に修正版を公開した。しかし、本番環境へのパッチ適用には、開発・運用部門との調整やテスト、業務影響の評価が必要で、即座の実行はたいていの場合困難だ。そこでトレンドマイクロは、被害を防ぐための3段階の手順を推奨する。

　第1段階は「影響範囲の特定」だ。サイバーリスク管理ツールを使って、コンテナやアプライアンス製品を含む全てのPHP実行システムを洗い出す。同時に、アップストリーム（開発元）のサポートが終了している古いバージョンの有無や、不審なWebシェルの起動、想定外のファイルアクセスといった侵害の兆候を調査する。

　第2段階は「仮想パッチの即時適用」だ。本番環境のプログラムを直接変更せずに、ネットワーク保護ツールやエンドポイント保護ツールを用いて対象のシステムを防御する。これと並行して、悪用試行を検出する体制を敷く。これらの導入がない場合は、管理インタフェースをVPN（仮想プライベートネットワーク）の内側に配置する、WAF（Webアプリケーションファイアウォール）のルールを有効化するなどの代替策で公開アクセスを制限する必要がある。

　第3段階は「優先順位を付けた恒久的な修正」だ。インターネットに公開されているシステムから優先的にパッチを適用し、リスクの高い順に処理を進める。すでにアップデートの提供が終了している古いバージョンを使用している場合は、システムを隔離するか、安全なシステム構成への移行計画を策定することが求められる。

Webブラウザ側の対処だけでは不十分――eMudhra認証鍵問題の技術的死角

　PHPの脆弱性と同日に公表されたのが、電子認証局であるeMudhraに関する問題だ。同局が発行した8つの鍵が、復元可能なほど強度が低いことが判明した。

　この問題に対して「Google Chrome」や「Firefox」などの主要なWebブラウザのベンダーは、侵害された中間CA（認証局）証明書を速やかにブロックし、eMudhraも2026年10月18日（協定世界時）にこれらを失効させる措置をとった。

　しかし、トレンドマイクロは「Webブラウザ以外の場所」に課題が残っていると指摘する。「Linux」サーバ、コンテナ、プログラミング言語のランタイム（実行時の処理システム）、組み込みデバイスなどでは、証明書の失効リストが自動で確認されないケースがある。今回問題になった中間CA証明書には、別の認証局（Sectigo）によるクロス署名版も存在するため、eMudhraのルート証明書を削除するだけでは信頼経路が残存する危険性がある。

　企業が取るべき対策としては、デスクトップ以外のトラストストア（信頼する証明書のリスト）の更新、「Go」などのプログラミング言語で開発されたアプリケーションやコンテナイメージの再ビルド、TLSインスペクション（暗号化通信の検査）用ゲートウェイにおける該当証明書のブロックがある。eMudhraが発行した強度不足の鍵のうち2つはコード署名証明書を発行できる権限を持っていたため、これらの証明書チェーンにつながるバイナリファイルが存在しないかどうか、社内のシステム構成を精査する必要がある。

経営層の「4つの問い」に答える報告

　技術的な防衛措置と並行して、IT・セキュリティ担当者にとって経営層への説明は重要な責務だ。経営陣が外部の報道で事態を知る前に、担当者自らが状況を報告することが、組織全体の信頼維持につながる。トレンドマイクロは、経営層から問われる可能性がある4つの質問と、その回答方針を提示している。

1．自社は影響を受ける可能性があるのか？

　被害が発生した場合のビジネスへの損失度合いを基準に、システムを「高、中、低」のリスク別に分類して報告する。「顧客データや決済情報を扱うインターネット公開システムを高リスクと位置付け、48時間以内にパッチを適用する」といった具体的な期限と対応方針をセットで提示する。

2．すでに侵害されていないか？

　調査の進展と判断の確度を明確にする。「高リスクシステムの90％は調査を完了させ、現時点では侵害の兆候を確認していない」といった具体的な数値を交えて報告する。未確認の部分に関しては、なぜ確認が完了していないのか、いつまでに完了するのか、それまでの間の保護措置を説明する。

3．修正はいつ完了するのか？

　自社の人員や権限で完結できる処理と、外部ベンダーのパッチ提供などに依存している処理を明確に区別する。自社でコントロールできる部分の完了期日を提示するとともに、サプライチェーン全体に対するリスク管理方針を説明する。

4．修正できないシステムはどうするのか？

　パッチ適用や改修が不可能なシステムの割合と、それに対する代替策を示す。「高リスクシステムの5％には直接的な修正手段がないため、仮想パッチの適用とネットワークの隔離を実施した。四半期末までに代替システムへの移行方針を決定する」といった形で、経営層に対して必要な意思決定を要請する。

　インシデント発生時に重要なのは、影響範囲を正確に把握し、リスクを解消するまでの初動の速さだ。一時的な保護措置で時間を稼ぎつつ、確実なパッチ適用と検証を進めるというプロセスを、技術部門と経営層が一元化された認識の下で推進することが不可欠だ。