PHP2Shellから、パッチを適用できないOT機器を守る

※本記事は、2026年11月5日に公開された英語版の記事「You Can't Patch PHP You Didn't Install: What PHP2Shell Means for OT」を翻訳したものです。

2026年10月20日、PHP本体に見つかった2件の重大な脆弱性のCVE番号がネット上に流出しました。PHPプロジェクトはリリースを1日前倒しし、10月21日に、現在「PHP2Shell」と呼ばれているCVE-2026-109618とCVE-2026-109619の修正版を公開しました(1)。どちらの脆弱性もCVSS 4.0で9.2と評価されており、攻撃者は認証情報なしでリモートから悪用できます(1)(2)。脆弱性は特定のアプリケーションではなくPHPのコアのリクエスト処理にあり、影響を受けるコードは2012年リリースのPHP 5.4までさかのぼります(1)。

ITチームなら、次にやることは明確です。PHPを更新し、すべてのワーカープロセスを再起動することです。しかしOTでは、その指示を実行できる人がいないことがよくあります。PHPをインストールしたのは、たいてい資産の所有者ではありません。PHPはファイアウォール、セルラー(モバイル回線)ルーター、ゲートウェイ、コントローラーのWeb管理インターフェースに組み込まれて出荷されており、更新できるのは機器のベンダーだけです。

修正版はすでにあります。しかしほとんどのOT機器では、資産の所有者がそれを適用することはできません。

状況は現在も変化しています。以下は、2026年10月26日時点の情報に基づいています。

確認されていることと、されていないこと

報告されていること：

脆弱性の内容：CVE-2026-109618は、リクエストの処理中にPHPのメモリが不足した場合にメモリ破壊を引き起こします。CVE-2026-109619は解放済みメモリの使用(use-after-free)の脆弱性です。あるリクエストが残した状態が解放済みのメモリを指し、同じワーカープロセス上の後続のリクエストがそのメモリを使用できてしまいます(2)。
修正版：PHP 8.5.12、8.4.27、8.3.36、8.2.35で両方の脆弱性が修正されています。7.4〜8.1系にはソースコードの限定的なバックポートだけが提供され、5.4〜7.3系はサポート終了のため、PHPプロジェクトからの修正はありません(1)(2)。
影響範囲：Webリクエストを処理するすべてのPHP環境が対象です。最もリスクが高いのはApacheとmod_phpの組み合わせです。実証されたエクスプロイトは、アプリケーションのコードが実行される前に成功するためです(2)。
悪用状況：Amazon Threat Intelligenceは、公表の4日前にあたる10月17日に自社のハニーポットへの悪用の試みを記録しており、その後も広範な悪用の試みを報告しています(1)。watchTowrは、両方の脆弱性が実際の攻撃で悪用されていると報告しています(3)。Rapid7は公開されている複数のPoC(概念実証コード)を検証し、いずれも特定のOS、PHPのバージョン、Webサーバーの組み合わせでしか動作しないことを確認しました(2)。
CISA KEVへの追加：CISAは10月26日、両方のCVEを「悪用が確認された脆弱性カタログ(KEV)」に追加し、早急なパッチ適用を呼びかけています(4)(5)。

公表されていないこと：

当社が確認した限り、これらの脆弱性によってOT機器が侵害されたことを確認した報告はありません。
多くのOTベンダーが、自社製品への影響をまだ調査しています。オランダ国家サイバーセキュリティセンター(NCSC-NL)のトラッカーには、10月22日時点で約430社の635製品が掲載されていました(6)(7)。

脆弱性は確認されています。悪用の試みも確認されています。どのOT製品が影響を受けるかはベンダーがまだ調べている段階で、OTの防御担当者は、全容が分からないまま今週中に行動しなければなりません。

OTのどこにPHPがあるのか

PHPは、Webページを作るためのスクリプト言語です。OTでPHPが産業プロセスそのものを動かすことはまれです。PHPが動かしているのはWeb管理インターフェース、つまり産業プロセスを動かす機器を設定・監視するために、エンジニアや委託業者がログインするブラウザー上の画面です。PHPは機器ベンダーがファームウェアに組み込んでいるため、資産の所有者がインストールすることも、目にすることもありません。資産台帳にはルーターやコントローラーは載っていても、ファームウェア内部のPHPランタイムは載っていないため、この露出は見落とされやすいのです。

Palo Alto Networksは、HTTPSのWeb UIとXML APIを含むPAN-OSおよびPanoramaの管理Webインターフェースが影響を受けることを確認し、ホットフィックスを順次リリースしています(8)。Siemensも、ファイアウォールを仮想化環境で稼働させる産業用プラットフォーム「RUGGEDCOM APE1808」上のPAN-OSで、同じ脆弱性を確認しています。10月23日のアドバイザリーの時点で、Siemensはパッチを提供しておらず、顧客にサポート窓口への問い合わせを案内していました(9)。PAN-OSのようなファイアウォールは、工場のネットワークを企業ネットワークから分離する位置に置かれることが多いため、その管理インターフェースはOTの境界に位置しています。

公表から数日のうちに、産業機器ベンダー各社がアドバイザリーを公開し始めました。

産業用ルーター：Beldenは、NetModuleルーターのソフトウェアの全バージョンが影響を受けると報告しています。修正版はまだなく、BeldenはWebインターフェースの無効化を推奨しています(10)。
プロセス制御：B&Rは、APROLのR 4.4-65までのバージョンが影響を受けると報告しており、2026年10月26日と同29日にパッチを提供する予定としています(11)。
製造・ビル：Schneider Electricは、EcoStruxure Security Expert、ProLeiT LINEoptimize、EcoStruxure Control Engineeringを影響を受ける製品に挙げています。Security Expertはバージョン1.48.4.0で修正されています(12)。
調査中：Rockwell Automationは、現時点で影響が確認された自社製品はないとしており、Hitachi Energyは調査を続けています(10)。

ベンダーが何も発表していないからといって、その製品に問題がないとは限りません。

自社で管理しているサーバー上のPHPもあります。OTのDMZに置かれたZabbixやCactiなどのネットワーク監視ツールはPHPのアプリケーションで、これらは自社で直接パッチを適用できます。今週の対応リストの最優先にしてください。

難しいのは、それ以外の機器です。セキュリティの責任者であれば、機器そのものは管理していなくても、そのリスクには責任を負っているはずです。遠隔地の下水ポンプ場に設置されたセルラールーターを例に考えてみましょう。設置したのも、ログインして操作するのも委託業者で、ファームウェアのバージョンも自社ではなく委託業者の記録にしかありません。今週になって、その内部のPHPがパスワードなしで悪用されうること、そして修正は自社のチームが一度もやり取りしたことのないベンダーからしか提供されないことが分かったのです。遠隔管理される機器は、通常このように購入・設置・保守されるため、これは自社のチームが招いた問題ではありません。それでも、機器に対する説明責任は自社にあります。

通常の対応が通用しない理由

ファームウェアの修正は、PHPプロジェクトによる修正より遅れて提供されます。ベンダーのアプライアンスではPHPの設定を変更できないため、PHPプロジェクトが示している暫定回避策(管理者による設定変更と、すべてのPHPワーカープロセスの再起動が必要)は使えません(2)。ファームウェアに組み込まれているPHPが5.4〜7.3系であれば、PHPプロジェクトによる修正は存在せず、修正できるかどうかはベンダーが独自にバックポートするかどうかにかかっています。

ファームウェアが提供されても、適用は計画停止(メンテナンス時間枠)まで待たなければなりません。

OTサイバーセキュリティの意思決定者の60%が、停止できないシステムのセキュリティ更新を、生産停止を伴う定期のメンテナンス時間枠で行っていると回答しています(13)。

Gartnerは、サイバーフィジカル環境でエンジニアリング部門が承認するメンテナンス時間枠は、数か月から数年先まで予定が組まれていることが多いと指摘しています(14)。攻撃者の時間軸はその逆です。Dragosによると、脆弱性の公表からエクスプロイトが公開されるまでの期間の中央値は24日でした(15)。PHP2Shellでは、最初の悪用の試みが記録されたのは公表の4日前です(1)。

OTサイバーセキュリティの意思決定者の58%は、停止できないシステムのセキュリティ更新について、リスクを受容したうえで綿密に監視することで対応していると回答しています(13)。監視は出発点として正しい選択です。しかし、認証情報が不要で、アプリケーションのロジックが実行される前にコードを実行できる脆弱性では、アラートが届くのは、攻撃者のコードが機器上ですでに実行された後です(2)。

クラウドで提供される防御も、ここでは役に立ちません。PHP2Shell向けに公開されたクラウド型WAF(Webアプリケーションファイアウォール)のルールが対象とするのは、クラウドプロバイダーを経由する通信だけで、プロバイダー自身も一時しのぎの対策と位置付けています(1)。工場ネットワーク上の管理インターフェースへの通信は、クラウドサービスを経由しません。下水ポンプ場のルーターも同じです。

有効なのは、ネットワーク経路上に置き、機器が処理する前に、何を管理インターフェースに届けるかを判断する対策です。Gartnerは、この対策の一つの形を仮想パッチと説明しています。機器のソフトウェアを変更せずにネットワークレベルで悪用の試みをブロックし、恒久的なパッチを安全に適用できるまでの一時的な代替策とするものです(14)。また、代替策でリスクを緩和するまでの平均時間と、恒久的なパッチで修復するまでの平均時間を分けて追跡し、前者を数時間から数日に抑えることを推奨しています(14)。

ネットワーク経路上での防御とは

攻撃者のペースに合わせてパッチを適用できない機器の脆弱性に対して、TXOneは常にネットワーク経路上での防御で対応しています。PHP2Shellも同じです。TXOne Edgeは機器の前段に設置され、通信が管理インターフェースに届く前に処理します。EdgeIPSのハードウェアアプライアンスに障害が発生しても、バイパス機能によって通信は継続されるため、アプライアンスが新たな障害点になることはありません。このインラインの配置によって2つの防御が可能になります。まず、すべての管理インターフェースに有効な防御から説明します。

すべての管理インターフェースへのアクセス制限：機器への唯一のネットワーク経路としてインラインで導入したTXOne Edgeは、機器の管理インターフェースへのアクセスを、あらかじめ指定した管理者と委託業者の送信元に限定し、インターネットからのセッションを拒否し、それ以外のサービスをすべて遮断します。TXOne Edgeは送信元、宛先、サービスだけで判断するため、管理通信が暗号化されているかどうかに関係なく機能します。多くの組み込み機器のように初期設定でHTTPとHTTPSの両方を提供している場合、攻撃者は暗号化されたポートを選ぶだけでよいため、どの場合でも経路を確実にふさげるのはアクセス制限です。管理インターフェースを企業ネットワークや工場ネットワークから分離することも同じ対策の一部です。侵害された機器がアクセスできる範囲を限定し、その後の予期しない外向きの通信を遮断できます。

Palo Alto Networksも、PAN-OSについてアクセス制限を推奨しています。管理インターフェースへのアクセスを信頼できる社内のIPアドレスや単一の踏み台サーバーに限定すると、PAN-OSにおけるこれらの脆弱性のCVSSスコアは8.7から7.1に下がります(8)。

暗号化されていないHTTPの管理通信に対する仮想パッチ：PHP2Shellについては、偽のPoCや不正確な分析が広く出回っています(2)(16)。TXOne Threat Researchは公開されているPoCを分析して共通するエクスプロイトチェーンを特定し、実際のエクスプロイトでそれを確認しました。深刻度「Critical」のEdgeIPSルール1239159は、両方のCVEについてこのチェーンに対応しており、初期設定で該当するリクエストを拒否してログに記録します(16)(17)。このルールのタイトルには、対象とするエクスプロイトの経路にちなんでCVE-2026-109618だけが記載されていますが、参照リストには両方のCVEが含まれています。最新のEPSS、KEV、CVSS-BTの情報は、TXOne Encyclopediaの該当ページで確認できます(17)。

このルールは、HTTP POSTリクエストの本文を検査します。EdgeIPSはTLSを復号しないため、PAN-OSのWeb UIを含むHTTPS専用のインターフェースは、このルールの対象外です(8)。PHPプロジェクトは、公開されているPoCが使う経路以外にも確認済みの悪用経路を挙げているため、このルールはアクセス制限に代わるものではなく、その上に重ねる防御です(2)。Edgeをご利用のお客様には、2026年10月22日と同23日に各モデル向けにリリースしたIPSパターンでこのルールを提供しています。EdgeOneをご利用のお客様は、ルール1239159を含むIPSパターンを各機器に配信してください(16)。

TXOneは、当社製品がこれらの脆弱性を悪用するあらゆる攻撃を防げるとは主張しておらず、特定ベンダーの機器についての主張もしていません。防御できる範囲は、導入形態と設定によって異なります。どのソリューションを評価する場合も、自社の機器と管理経路が対象になっているかを必ず確認してください。

今週やるべきこと

ベンダーの情報がそろうのを待たずに始められます。以下の確認項目は、TXOneの「Discover(可視化)、Assess(リスク評価)、Protect(防御)」のフレームワークに沿っています。

Discover(可視化)

Web管理インターフェースを持つOTとDMZの機器(ファイアウォール、セルラールーター、ゲートウェイ、HMIパネル、エッジコントローラー、ビル管理用コントローラー)をすべて洗い出します。それぞれの機種、ファームウェアのバージョン、管理責任者、遠隔管理の担当者を記録します。
各機種を、ベンダーのアドバイザリーとNCSC-NLのトラッカーで確認します(7)。「発表なし」は「影響なし」ではなく「不明」として記録します。

TXOneの製品では、Edgeがインラインで資産とその通信を識別し、どの機器がWeb管理インターフェースを公開していて、どの送信元からアクセスされているかを可視化します。インラインで機器を設置せずに可視化したい拠点には、SenninReconがエージェントレスのパッシブな資産検出を提供します。

Assess(リスク評価)

洗い出した管理インターフェースのうち、インターネットや企業ネットワークからアクセスできるものを確認します。攻撃者と同じように自社の外部IPアドレス範囲をスキャンし、委託業者には、設置したセルラーモデムなどの接続について確認します。
ネットワーク監視ツールやWebダッシュボードなど、自社で管理していてPHPが動いているサーバーについては、PHPのバージョンを修正版と照らし合わせます。Apacheのmod_phpで動いているものから始めてください。

EdgeOne v2.7でAsset Vulnerability Management(AVM)をご利用のお客様向けに、2026年10月23日にリリースしたCVDS脆弱性パターン1.46.3_261023_1以降で、CVE-2026-109618とCVE-2026-109619の検出定義を追加しました。影響を受ける可能性のある資産の特定に役立ち、TXOne Vulnerability Detection Service(VDS)の推奨に基づく対処方法も表示されます(16)。

Protect(防御)

自社で管理しているものにはパッチを適用します。PHPを更新し、すべてのワーカープロセスを再起動します。まだ更新できない場合は、PHPプロジェクトの暫定回避策を適用してから、すべてのワーカープロセスを再起動します(2)。
ファームウェアの提供を待っているベンダーの機器については、インターネットへの露出をなくし、管理アクセスを指定した送信元に限定したうえで、適切に設定したネットワークレベルの防御を前段に配置します。監視は不審な活動の検知やインシデント対応に役立ちますが、監視だけでは、脆弱な管理インターフェースに攻撃通信が届くのを止められません。どの方法にもコストがあります。ファームウェアの更新には調整や計画停止が必要になることがあり、待てばその間、機器は露出したままです。ネットワーク経路上の対策なら、機器に手を加えず、生産も止めずに今すぐ露出を減らし、恒久的な修正は次の計画停止に回せます。

すべての委託業者に3つの質問を：セキュリティ部門ではなく、工場や公益設備、施設の運営を担当している方こそ、この質問をするのに適した立場にあります。その答えは、PHP2Shellの対応にとどまらず役立つことが多いはずです。

当社の機器のうち、御社が使っているWeb管理インターフェースを持つものはどれですか?
どのように、どこからアクセスしていますか?
ベンダーのPHP2Shell対応ファームウェアをいつ適用する予定ですか?そのために、当社から何が必要ですか?

回答は、セキュリティの責任者と共有してください。文書化されていないアクセス経路が見つかれば、それはこれからふさぐことのできる経路です。

機器が侵害された疑いがある場合は、Amazonが最初の悪用の試みを記録した10月17日にさかのぼって調査してください(1)。そのうえで、ベンダーのインシデント対応のガイダンスに従い、機器で使われていた認証情報を変更し、新しいアカウントが作られていないかを確認してください。

PHPプロジェクトはすでに修正版を公開しています。しかしほとんどのOT機器は、ベンダーのリリース時期とメンテナンス時間枠に左右されて、修正されないまま稼働を続けることになります。その間、機器はずっと露出した状態です。ネットワーク経路上の対策なら、その露出を今すぐふさぐことができます。ファームウェアが届いたら、自社のスケジュールで、次のメンテナンス時間枠に適用すればよいのです。