PHP2Shell：時間との競争 — PHPの脆弱性はWebサイト、機器、そしてあなたのデータに何をもたらすのか

PHPの重大な欠陥が2件、予定より早く破られた情報公開のエンバーゴ、そして正式公開前から始まっていた攻撃の試み。PHP2Shellが影響するのは、従来型のWebサイトだけではありません。脆弱なランタイムは、ファイアウォール、ホスティング管理パネル、その他の機器にも組み込まれている可能性があります。何が起きたのか、誰が対応すべきか、個人ユーザーが実際に何をすべきかを、分かりやすく解説します。

10月20日、当初は何の変哲もない2つの番号がインターネット上に現れました。CVE-2026-109618とCVE-2026-109619です。その背後にあったのは、まだ完全には公開されていないPHPの2件の脆弱性でした。PHPは、無数のWebサーバーでフォームを処理し、データベースに問い合わせ、ページを生成する技術です。

本来、情報公開は秩序立って進むはずでした。まず更新プログラムと事前に用意した防御ルールを公開し、その後に技術的な詳細を示すという順序です。しかし識別子が予定より早く公になり、誤った最高スコア10.0が広まり、その日の夜には実際に動作する攻撃を示す動画まで誤って公開されました。PHPはリリースを1日前倒ししました。

しかし、静かなスタートには遅すぎました。Amazonは後に、パッチ公開の4日前に当たる10月17日付の悪用試行を発見しました。公開後、各事業者は急速に拡大する攻撃の波を記録し、ロイターはCloudflareの情報として、数時間で数百万件の試行があったと報じました。これは数百万件の侵害が成功したという意味ではありませんが、重大な脆弱性が現在どれほど迅速に自動検証されるかを示しています。

脆弱性そのものがスマートフォン内に存在するわけではありません。それでも、事業者に保存されたデータ、改ざんされたWebサイト、より説得力のあるフィッシング、または予防的に停止されたサービスを通じて影響を受ける可能性があります。端末が無害でも、別の事業者のサーバー上にあるデータが危険にさらされていることはあります。

まず押さえておくべきこと

PHP2Shellは、PHPコアに存在する2件のメモリ安全性の欠陥を指す名称です。条件がそろうと、攻撃者はログインせずにサーバー上でコードを実行できます。さらに一方の脆弱性では、セッショントークン、パスワード、APIキー、データベース認証情報を含むメモリ内容が漏えいする可能性があります。両CVEのCVSS 4.0評価は9.2です。

アップストリームの各ブランチは、PHP 8.5.12、8.4.27、8.3.36、8.2.35以降で修正されています。古いブランチには、ディストリビューション、ホスティング事業者、LTSベンダーがバックポートを提供する場合があります。CMSやプラグインだけを更新しても不十分です。実際にWebリクエストを処理するPHPランタイムが重要です。

個人ユーザーがスマートフォンに何かをインストールする必要はありません。運用担当者は、PHPを使用するWebサイト、コンテナ、管理インターフェース、機器を洗い出してパッチを適用し、過去に攻撃を受けていないか調査する必要があります。

1. 古いメモリ問題が世界規模の競争へ発展した経緯

2024年：攻撃の実証には至らなかった警告サイン

経緯は2024年に始まりました。外部によるPHPのセキュリティ監査で、後にout-of-memory問題となる兆候が初めて確認されました。しかし、Webリクエストからコード実行へ至る確実な経路はなく、修正案には互換性や安定性を損なうおそれがありました。小規模なセキュリティチームは迅速な合意に至りませんでした。PHP Foundationは後に、この遅延を構造的な失敗だったと公に認めています。意思決定の経路が重く、リソースも不足していたためです。

2026年夏：AI支援研究が理論を現実へ変える

2026年7月と8月、Calif、OpenAI、Wizは、従来の手法と高性能なAIモデルを用いてPHPコアを調査しました。8月11日には、リモートコード実行へ至る具体的な経路が報告されました。Wizも独立して別の亜種を発見し、実際のPHPアプリケーションに対する攻撃チェーンを実証しました。結果の再現、誤検知の排除、パッチの確認には、引き続き人間の作業が必要でした。それでもAIは探索時間を短縮し、脆弱性公開後に防御側へ残される時間も短くしました。

10月17日：確認されている最初期の試行

Amazon Threat Intelligenceは後に、MadPotのテレメトリから10月17日付の悪用試行を確認しました。ハニーポットへの着弾は、実システムの侵害成功を証明するものではありませんが、フォレンジックで遡るべき期間を前倒しします。攻撃者がこれほど早い段階で十分な情報を得た方法は不明であり、信頼できる帰属判断もありません。

10月20日と21日：エンバーゴが破られ、パッチが公開される

10月20日、CVE識別子が、誤ったCVSS評価10.0および誤って公開された攻撃動画とともに広まり始めました。PHPはリリースを10月21日14:00 UTCへ前倒ししました。ホスティング事業者、ディストリビューション、セキュリティベンダーは並行してパッケージとフィルターを準備しました。Cloudflareはリリース前から防御ルールを有効化し、リクエストとレスポンス双方のシグナルを組み合わせました。それでもWAFは追加の防壁にすぎず、脆弱なPHPコード自体を修正するものではありません。

修正版は10月21日に公開され、その直後から公開された悪用ツールと大規模スキャンが続きました。行政機関、病院、大学、企業は予防措置としてサービスを停止し、ベルリンおよびブランデンブルク州の警察サービスも一時的に停止しました。これは侵害の証拠ではありません。むしろ、機能する緊急対応の表れである可能性があります。侵害されたまま稼働を続けるより、制御された形で停止する方が安全です。PHP2Shellは、インターネットに公開されたシステムが重大なRCE脆弱性に対し、日単位ではなく時間単位で対応しなければならないことも示しました。

2件の重大なPHP脆弱性、実際の悪用試行、そして極めて広い潜在的な攻撃対象が確認されています。一方で、実際に侵害されたシステムの数や、失われたデータの量は分かっていません。

2. 技術的に何が起きているのか — 平易に解説

PHPはWebサイトの「機関室」で動きます。WordPress、オンラインショップ、ポータルのコードを実行し、入力を処理し、データベースと通信します。欠陥はCMSより下の層に存在します。そのため、アプリケーションが完全に最新でも、脆弱なPHPランタイム上で動作している可能性があります。

CVE-2026-109618：不完全なデータのままクリーンアップ

PHPが不適切なタイミングでmemory_limitに到達すると、内部データ構造が部分的にしか初期化されていない状態で処理が停止することがあります。後処理の際、PHPがそうした領域を有効なデータとして扱う場合があります。攻撃者はこの状態を意図的に引き起こし、メモリ配置を操作してコード実行につなげようとします。

Apacheとmod_phpの組み合わせでは、認証不要の攻撃が実証されており、アプリケーション本体のコードが実行される前に成立する可能性があります。その場合、ログイン、二要素認証、WordPressのセキュリティプラグインでは防げません。他のPHP実行方式も影響を受ける可能性がありますが、前提条件と再現性はSAPI、アプリケーション、設定によって異なります。

CVE-2026-109619：古い参照が次のリクエストまで残る

2件目の脆弱性では、重大なエラーの後も、すでに解放されたメモリへの参照が残ります。同じPHPワーカーが後続のリクエストを処理すると、その古い状態を再利用します。これは解放後使用（use-after-free）または古いグローバル状態に相当します。

結果として、コード実行、クラッシュ、メモリ内容の漏えいが起こる可能性があります。特にメモリ漏えいは厄介です。攻撃者は、目に見えるWebシェルを残さなくても、セッショントークン、データベースパスワード、APIキー、証明書を取得できる可能性があります。そのため、パッチ適用後に変更ファイルだけを探しても十分ではありません。

リモートコード実行は、まずPHPまたはWebサーバーのアカウント権限でコードが動くことを意味し、自動的にroot権限が得られるわけではありません。ただし、そのアカウントが設定ファイルを読み、データベースへ接続し、内部サービスへアクセスできる場合があります。侵害がどこまで広がるかは、ファイル権限、ネットワーク分離、最小権限の徹底に左右されます。

3. インターネットの約70%が影響を受けるのか

W3Techsによると、2026年10月23日時点で、サーバー側プログラミング言語を特定できるWebサイトの69.3％がPHPを使用しています。これらのPHPサイトのうち、65.3％がPHP 8、26.9％がPHP 7、7.7％がPHP 5を使用しています。

この数字が示すのは普及率であり、パッチ適用状況や攻撃成功件数ではありません。多くのシステムは数時間以内に更新され、ディストリビューションは古いバージョン番号のまま修正をバックポートし、機器によっては脆弱な経路が外部公開されていない場合もあります。したがって、公平な結論は次のとおりです。サーバー側言語を特定できるWebサイトのおよそ10件中7件がPHPを使用しており、防御状況を確認する必要がありました。現在も脆弱または侵害済みのシステム数を、信頼できる形で算出することはできません。

4. PHP2Shellが個人ユーザーに意味すること

PHPが端末を直接感染させるわけではない

PHP2Shellはサーバー上で動作します。スマートフォンを初期化したり、専用アプリを入れたりする必要はありません。端末へのリスクが生じるのは、改ざんされたWebサイトに誘導され、悪意あるファイルをダウンロードした場合です。OS、ブラウザー、アプリを最新に保ち、信頼できる提供元だけを利用してください。端末向けと称する「PHP2Shellアップデート」は、ほぼ確実におとりです。

それでもデータは影響を受ける可能性がある

オンラインショップで注文すると、氏名、住所、注文履歴が長期間保存される場合があります。サーバーが侵害されれば、数か月そのサイトを訪れていなくてもデータが影響を受ける可能性があります。メモリ内容の漏えいにより、サーバー上のファイルとして存在しないトークンやアクセスキーが見えることもあります。

よく知っているWebサイトでも改ざんされる可能性があります。ドメインと鍵アイコンは同じままでも、埋め込まれたスクリプトがログイン情報や決済情報を盗むことがあります。HTTPSが保護するのはサーバーまでの通信経路であり、サーバー自体の完全性ではありません。見慣れない決済画面、リダイレクト、ダウンロードが表示されたら中止し、既知の公式経路から事業者へ連絡してください。

技術的な攻撃の後には詐欺が続くことが多い

盗まれた情報があると、フィッシングはさらに本物らしくなります。実名と正しい注文番号が記載されたメッセージでも偽物の可能性があります。重要なサービスは、公式アプリ、ブックマーク、または自分で入力したアドレスから開いてください。アカウント乗っ取りの兆候には、心当たりのないログイン通知やパスワード再設定通知、未知のセッション、変更された復旧情報、自分が開始していないプッシュ承認、TAN、二要素認証の要求などがあります。「念のため」に承認せず、アカウントを直接確認して不明な端末を削除してください。

オンラインバンキングでは、強力な顧客認証により、通常はパスワードやPINだけでは手続きできません。それでもフィッシングにより、第三者のログインや支払いに対する正規の承認を自分で実行させられる可能性があります。受取人、IBAN、金額を確認し、不明な取引があれば公式アプリまたは既知の電話番号から銀行へ連絡してください。

今すぐ取るべき実践的な対応

サービスがメンテナンスまたは予防的な停止だけを告知している場合、無差別にパスワードを変更したり、カードを停止したりする必要はありません。公式の代替経路を利用し、事業者の更新情報を確認してください。

事業者がログイン認証情報の漏えい可能性を告知した場合、そのサービスのパスワードと、同じパスワードを再利用していたすべての場所のパスワードを変更してください。アクティブなセッションを終了し、二要素認証またはパスキーを有効にし、特にメールアカウントを優先して保護してください。

疑わしいサイトに情報を入力した、またはセキュリティアプリを装うものをインストールした場合は、別の端末からアカウントを保護し、決済情報が関係するなら銀行へ連絡し、影響を受けた端末を点検してください。

セキュリティアプリもVPNも、他社のオンラインショップにあるPHPランタイムを修復することはできません。セキュリティソフトは、悪意あるダウンロード、偽アプリ、既知の悪性サイトを使う第2波の攻撃には役立ちますが、他社サーバー上のデータが安全だという保証にはなりません。

5. PHPはファイアウォール、NASなどの機器でも動作する

PHPはWebサイトだけに使われているわけではありません。ファイアウォール、ルーター、NAS、ホスティング管理パネル、VoIP機器、カメラレコーダー、産業用アプライアンスの管理インターフェースや付加サービスにも組み込まれています。ただし、到達可能なWebリクエストを脆弱なPHPバージョンで処理している場合に限り、製品が影響を受けます。外部への露出状況とメーカー製パッチの有無も重要です。

pfSense：Netgateは、PHPベースのGUIとキャプティブポータルが影響を受けると確認しました。標準GUIは通常LAN内からしか到達できませんが、キャプティブポータルは意図的に信頼されていないクライアントへ公開されます。同じ欠陥でも、露出状況によってリスクは異なります。

Palo Alto Networks：一部のPAN-OSおよびPanoramaバージョンが影響を受けます。メーカーによると、問題はXML APIを含む管理Webインターフェースにあり、データプレーンやGlobalProtect全体が一律に影響を受けるわけではありません。修正を適用するまでは、管理アクセスを信頼できるネットワーク、または管理されたジャンプホストからのみに限定してください。

Plesk：顧客のWebサイトはそれぞれ独自のPHPハンドラーを使用し、Pleskインターフェースは別のエンジンを使用します。片方の層だけを更新すると、もう片方を見落とす可能性があります。そのためPleskは両コンポーネント向けの更新を公開しました。

CiscoとSophosの事例は、製品、クラウドサービス、顧客環境への導入を別々に評価すべき理由を示しています。Ciscoは一部の製品ファミリーへの影響を確認し、別の製品は影響なしと判断し、さらに追加製品の調査を続けました。Sophosは自社製品に影響はないと説明しましたが、別途ホストしていた旧式のMyUTMポータルが脆弱なPHPを使用していたため、一時的に停止しました。

オランダのNCSCは、継続的に更新されるステータス一覧を公開しています。これは有用なインベントリですが、最新のメーカーアドバイザリに代わるものではありません。PHPへの依存だけでは悪用可能性を証明できず、掲載がないことも安全宣言にはなりません。

家庭または組織内の機器で確認すべきこと

メーカー、モデル、ファームウェア、追加パッケージを記録してください。公式サポートサイトで両CVEと「PHP2Shell」を検索し、更新は必ず所定のファームウェアまたはパッケージ機能から適用してください。組み込みPHPを自己判断で置き換えてはいけません。アプライアンスには、メーカー独自の変更や署名済みコンポーネントが含まれることが多いためです。

WAN側からのリモート管理、不要なポート転送、UPnPの開放を無効にし、クラウド経由のリモートアクセスも確認してください。外部アクセスが必要な場合は、可能な限りVPNを使用し、接続後にのみローカル管理画面を開いてください。

ゲスト、IoT、管理ネットワークを分離し、侵害された機器からローカルの管理サービスへ到達できないようにしてください。ファイアウォール、NAS、カメラレコーダーがセキュリティ更新を受けられなくなった場合、交換が唯一の持続可能な対策となることがあります。

6. 運用担当者が今すぐ行うべきこと

ステップ1：責任範囲と資産を明確にする

マネージドホスティングでは、通常は事業者が更新を行います。VPS、専用サーバー、コンテナ、アプライアンスでは、自社または委託先が責任を負います。両CVE、パッケージまたはファームウェアのバージョン、すべてのPHPプロセスの再起動について、検証可能な回答を求めてください。同時に、ドメイン、サブドメイン、ステージング環境、旧プロジェクト、Webメール、コンテナ、PHP内蔵機器を一覧化します。

ステップ2：正しいパッチレベルを確認する

PHP 8.5.12 · PHP 8.4.27 · PHP 8.3.36 · PHP 8.2.35。PHP 7.4、8.0、8.1にはソースコードのバックポートが提供されています。判断基準は、ディストリビューターまたはLTS事業者のアドバイザリです。

ディストリビューションは、古いパッケージバージョンへ修正をバックポートする場合があります。たとえばUbuntu 24.04 LTSは8.3.6-0ubuntu0.24.04.13を修正版として示しており、cPanelもバックポートを提供しました。そのため、上流版の単純なバージョン番号だけでなく、パッケージの完全なバージョンをディストリビューターまたはプラットフォーム事業者のアドバイザリと照合してください。

ステップ3：実際にリクエストを処理しているランタイムを確認する

php -vで表示されるのは通常、コマンドライン版だけです。WebサーバーはPHP-FPM、mod_php、またはコンテナ経由で別のインストールを使用している可能性があります。FPMプール、Webサーバーモジュール、仮想ホスト、イメージを確認してください。

php -v
php -r 'echo PHP_VERSION, " | ", PHP_SAPI, PHP_EOL;'
systemctl list-units --type=service 'php*-fpm.service'

更新後は古いワーカーを置き換える必要があります。mod_phpでは通常Webサーバーを再起動し、PHP-FPMではプールを再起動します。同じイメージのままコンテナを再起動しても解決しません。イメージを更新し、再デプロイする必要があります。

ステップ4：パッチを適用できないシステムでは、リクエストがPHPへ到達する前に止める

すぐにパッチを適用できない場合は、信頼できるネットワークまたはVPNにアクセスを限定するか、サービスを停止してください。攻撃がアプリケーションコードより先に成立する場合、WordPressのメンテナンスプラグインでは防げません。静的なメンテナンスページを使用するか、リバースプロキシ、ロードバランサー、Webサーバーで遮断してください。

WAFやCDNのルールは時間を稼げますが、パッチではありません。Cloudflareは攻撃パターンの変化を観測し、リクエストとレスポンスを組み合わせて評価する必要がありました。オリジンサーバーが別のIPアドレスや代替ホスト名から直接到達できないことも確認してください。

セッションのアップロード進捗機能を無効にする、メモリやアップロードの制限を厳しくするといったPHP設定は、一部の攻撃経路を減らすだけで、副作用が生じる可能性があります。

ステップ5：少なくとも10月17日まで遡って確認する

ローテーションされる前に、Webサーバー、PHP、プロキシ、WAF、システム、コンテナのログを保全してください。不審なフォームリクエスト、PHP_SESSION_UPLOAD_PROGRESS、メモリエラー、予期しないシェルプロセス、新しいファイル、アカウント、cronジョブ、外向き通信を調べます。攻撃が成功してもワーカーがクラッシュするとは限りません。逆に、単発のエラーだけで侵害を証明することもできません。重要なのは全体像です。

ステップ6：PHPが読めたシークレットをローテーションする

メモリ内容が漏えいする可能性があるため、インターネットに公開され、未修正だったシステムでは、PHPプロセスが読み取れたすべてのシークレットをローテーションしてください。対象には、データベースパスワード、API・クラウド・デプロイ用トークン、SMTPまたはOAuth認証情報、セッションキーなどが含まれます。まず脆弱性を修正または隔離し、その後、信頼できる環境から新しい認証情報を生成してください。

ステップ7：侵害の兆候がある場合は「掃除」だけで済ませない

侵害の兆候がある場合は、制御された方法でシステムを隔離し、ログと必要に応じて揮発性データを保全し、目に見えるファイルを削除するだけでなく、信頼できるアーティファクトから重要なホストを再構築してください。管理者アカウント、データベースアカウント、デプロイパイプライン、接続先システムも確認します。個人データが影響を受けた可能性がある場合は、プライバシーまたはデータ保護の担当者を早期に関与させてください。GDPR上、通知対象の侵害は原則として72時間以内に報告する必要があります。

7. より大きな教訓：発見が加速するなら、修正も追いつく必要がある

PHP2Shellは、AIが「理論上は可能」と「実際に悪用可能」の境界をどう動かしているかを示しています。モデルは、ソースコード、クラッシュトレース、パッチ差分を大規模に分析できます。その結果、公開から実用的な攻撃コードが登場するまでの時間も短くなります。

答えは、単にAIを増やすことではありません。メンテナーにはリソースと明確な意思決定プロセスが必要であり、運用担当者には完全なインベントリ、迅速なパッチ適用経路、隔離、訓練済みの復旧手順が必要です。Protectstarでは、コードレビューと人による検証を補完する形でAIを利用しています。AIは発見を加速しますが、責任の代わりにはなりません。

結論

PHP2Shellが直接影響するのはサーバーですが、個人にはデータリスク、詐欺の試み、サービス停止として波及する可能性があります。パニックではなく注意深く行動してください。公式の連絡経路を使い、予期しない承認要求には応じず、影響を受けた事業者からの通知に合わせて的確に対応してください。

運用担当者にとって重要なのは、実際に稼働しているPHPランタイム、忘れられたすべてのインスタンス、組み込みコンポーネント、古いプロセスの再起動、そして少なくとも10月17日まで遡る調査です。パッチがない場合は、稼働を続けるより隔離する方が責任ある対応です。Webサイトにアクセスできることは、安全である証明にはなりません。