新たなデータから、組織によるPHP2Shellのパッチ適用が、攻撃者による悪用のペースに追いついていないことが明らかになりました。サイバーセキュリティの専門家は、今回は更新作業が特に複雑なため、無理もないと指摘しています。
データは10月21日から少しずつ出始め、新たなPHPの脆弱性に対する世界の初動の様子を浮かび上がらせました。その内容は芳しいものではありませんでした。
有利な立場にある一部の専門家は、膨大な量の脅威活動を捉えています。Cloudflareの最高経営責任者（CEO）であるMatthew Prince氏は、水曜日に脆弱性が公開される前の10時間で、同社は数千件の悪用試行を観測したと述べました。「公開から45分後には数万件、2時間以内には数十万件に急増し、現在は数百万件に達している」と、同氏は10月21日深夜にXで投稿しました。
翌日、Check Point Researchは、悪用の試行がすでに世界の組織の10%に達したと主張しました。一方で、脆弱な組織のうち、新しいPHPリリースへの更新が目に見えて進んでいるのはごく一部にとどまっています。
Ox Securityの研究者は、Shodanで検出可能な環境をサンプルに調査しました。その結果、修正版の公開から24時間が経過した時点で、99%超のインスタンスが、パッチ適用済みの新バージョンを示していませんでした。Flareの研究者も追い打ちをかけるように、そうしたインスタンスの73%が、PHP Foundationによる更新提供がすでに終了したブランチを示していたと指摘しています。（Flareは、単純なインターネットスキャンでは重要な細部を見落とすため、この数値には留保が必要だとも述べています。）
一方、Cisco Talosは、オープンソースインテリジェンス（OSINT）に基づき、PHPシステム全体の約半数にパッチが提供されないと推定しています。
米東部時間の10月23日朝、Oxは、99%という数値が97.5%に下がったとDark Readingに伝えました。Flareも、公開記録のうち上流でサポートされているブランチを示すものは27%で、そのうち更新済みなのは約5%だとDark Readingに述べています。
PHP2Shellへの対処は、「更新」をクリックするだけで済むほど単純ではないと、現場の実務者は認めています。それでも、ほとんどの組織がすぐに実行できる自衛策はあります。たとえば、組織内の全システムでPHPの導入状況を丹念に洗い出す、侵害の兆候を調査する、すぐにパッチを適用できないシステムはアクセスを制限するかオフラインにする、といった対応です。
ステップ1：あらゆる場所のPHPを見つける
原則として、PHP2Shellへの対策は単純なはずです。問題の脆弱性であるCVE-2026-109618とCVE-2026-109619に対応した新バージョンが公開されており、更新すれば済みます。しかし実際には、PHPをどこで、どのように使っているかによって、対処の中身は組織ごとに大きく異なり、必要な労力も変わってきます。
サイバーセキュリティの専門家が口をそろえる最初のステップは、PHPが動作しているすべての資産を発見して棚卸しすることです。ただ、言うは易く行うは難しです。米サイバーセキュリティ・インフラストラクチャセキュリティ庁（CISA）は10月21日のセキュリティアラートで、PHPはウェブサイトを動かすだけのものではなく、「他のソフトウェアの構成要素になっていることが多く、普及状況を直接把握できない場合がある」と指摘しています。
Flareの研究者は、攻撃対象領域を調べる中でそれを実感したといいます。同社のシニアサイバー犯罪研究者であるAdrian Cheek氏は、「調査で印象的だったのは、一般的なウェブホスティングの外にあるPHPの多さです。ストレージ機器、物理的な入退室管理システム、カメラ、リモートアクセス用インターフェースでも確認しました。主要なウェブサイトだけを見ていたり、外部からの評価を80番と443番ポートに限っていたりすると、こうしたものは見落としてしまいます」と話します。
こうした露出がある組織について、同氏は次のように続けます。「ストレージ機器や物理的な入退室管理装置にログインして、PHPを自力でアップグレードすることは通常できません。メーカーによる更新ファームウェアの提供が必要です。メーカーがその製品のサポートをすでに終了していれば、パッチが存在しない可能性もあります」
「更新」をクリックするほど単純ではない
例外的なケースは脇に置き、ある組織が自社のPHP環境をすべて見つけ出し、一覧にできたと仮定しましょう。驚くことに、そこからさらに事態は複雑になります。
公開されているデータからは、世界で動いているPHPの大半が古いブランチで稼働していることがうかがえます。Cheek氏は次のように説明します。「PHP 5やPHP 7を前提に作られたアプリケーションを運用している場合、最新のPHPリリースへ移行するには、アプリケーションの一部を書き直し、依存関係を置き換え、不具合が出そうな箇所をすべてテストする必要があるかもしれません。特に運用上重要なアプリケーションであれば、組織が軽々しくその作業を避けるのにも、もっともな理由があります」
こうした場合、組織が対処に踏み切るとしても、修復は時間のかかる作業になります。幸い、そして紛らわしいことに、古いPHPのバージョンが必ずしも救いようがないわけではありません。
公開記録で最も多いバージョンの7.4.3は、Ubuntu 20.04に同梱されていたものです。Cheek氏は「Linuxディストリビューションでは、古いPHPのバージョン番号を維持したまま、セキュリティ修正をバックポートすることがよくあります。したがって、バージョン番号が古くても、ソフトウェアにパッチが適用されていないとは限りません」と指摘します。OS以外でも、アプリケーションが同梱するPHPに修正をバックポートする場合があります。
このように、古いPHPを使う組織は、実際には状況の大きく異なるグループに分かれます。アプリケーションや製品の移行・置き換えという大仕事に取り組まなければならない組織もあります。専門家は、その間は脆弱なシステムを完全にオフラインにすることを検討すべきだと述べています。また、Cheek氏は、PHPの設定にアクセスできる組織向けに、CVE-2026-109619を緩和するための実践的なヒントを1つ紹介しています。
同氏は「報告されている攻撃は、PHPのセッションアップロード進捗機能を経由して行われます。この機能はデフォルトで有効で、アプリケーション側でsession_startを呼び出す必要もありません。session.upload_progress.enabledを無効にしてPHPワーカーを再起動すれば、PHPのバージョンを上げなくても、確認済みのセッションアップロード進捗経由の攻撃経路を遮断できます」と説明します。ただし、もう1つのPHP2Shellの脆弱性であるCVE-2026-109618には効果がないため、あくまで一時的な措置にすぎないと断っています。
ベンダー経由でバックポートされた修正を適用できる恵まれた組織もあります。UbuntuのディベロッパーであるCanonicalは10月21日、14.04以降の全バージョンに向けたPHP2Shellの修正を公開しました。こうした組織でも、管理の手間は増えます。OSやアプリケーションの更新が、PHPのバージョンアップを伴うとは限らないためです。Ubuntuの更新を適用しても、今後のスキャンでは見かけ上、PHP 7.4.3が動いているように表示され続ける可能性があります。
Cheek氏は、さらにこう念を押します。「再起動は重要です。修正済みのPHPパッケージをインストールしても、稼働中のワーカープロセスにすでに読み込まれているインタープリターが置き換わるとは限りません」
PHP2Shellへの対応は組織ごとに異なる
技術的な詳細に加え、組織の規模もPHP2Shellへの対応を大きく左右します。
他の緊急のサイバーセキュリティ脆弱性と同様に、中小企業は、状況の把握や、対応を完了するためのリソースの面で不利なスタートを切る可能性があります。しかし、1,000を超える組織のPHP2Shell対応を48時間休みなく支援したOX SecurityのCEO、Neatsun Ziv氏は、小規模であることの利点をすぐに挙げます。
「小さな組織なら、何でも好きにできます。入ってパッチを当て、5時間待つだけです。何かが壊れても、誰も文句を言いません」と、同氏は語ります。
しかし、大規模な組織は事情が異なると同氏は言います。「大企業にはゴールデンイメージ、つまり更新の基準となるサーバーのベースラインがあります」とZiv氏は話します。「常に下流へ展開するモデルです。新しいゴールデンイメージをデプロイし、そのイメージに新しいソフトウェアを組み込み、それを本番環境に投入します。本番環境は誰も変更できません。これが現在の展開の標準です。サーバーに直接入ってパッチを当てる人はいません。長期的には保守不能になるからです」
さらに、大規模な組織での大型の更新には、さまざまなチームの多くの担当者が関与しなければなりません。大手組織は、止められない重要なシステムを不釣り合いなほど多く抱えています。組織内でもPHPの利用は広範で多様です。こうした点は言うまでもありません。Ziv氏は「当社が支援したほとんどの組織で、PHPが動作しているサーバーが数百台見つかりました」と指摘します。
Check Pointの最高セキュリティ・信頼責任者であるAlex Spokoiny氏は、自社の内部にとどまらず、サプライヤー各社のPHP2Shellへの対応状況も組織にとってのリスクになると付け加えます。
「最初のステップは、関連するサプライヤーに働きかけて、どう対応しているのかを把握することです。影響を受けているのか。どのような防御策を講じたのか。修復はいつ完了する見込みなのか。これらの質問に明確で妥当な回答が得られないのであれば、それ自体をリスク評価に織り込み、代替手段の検討も視野に入れるべきです」と、同氏は助言します。
組織同士が協力すれば、全員の利益にもなります。Spokoiny氏は「たとえば、技術的に可能であれば、自社のWebアプリケーションファイアウォール（WAF）の保護を第三者が運用するアプリケーションにまで拡張できるかもしれません。プロバイダーが恒久的な修正を進める間、リスクの低減につながります」と述べています。
翻訳元: https://www.darkreading.com/application-security/exposed-php2shell-cyber-experts-advice
