どうしたらいい？ PHPコアにおける重大な遠隔コード実行脆弱性「php2shell」
PHPの重大な脆弱性が発見されたと話題ですね。Wordpressのサイトを沢山運営しているのでもちろん全部PHP使われていますね。PHPはレンタルサーバ側が提供しているので、推奨に応じてバージョンアップしてきたのですが、それでは足りないのでしょうか。確認していきます。
利用しているサーバでは、ユーザは管理画面が閉ざされており、レンタルサーバ会社が対応中のようです。しばらく待ってるくらいしかないのかなあ。いまのところ、Web自体は動いていますが。
PHP8.1以前はもうサポートが終わっているので、今回はパッチがでません。8.1以前を使っている場合は、サーバ側の対応が終わっても脆弱性が残るので、アップデートせねばなりません。
PHPアップデートをすると、Wordpressのテンプレートやプラグインとかが古いと画面が崩れがちなので、その対応も大変になりそうですね。
現時点での対応
PHP8.1以下の人はサーバ管理画面が開き次第バージョンアップする。
ただバージョンアップするとサイトが崩れたりするので、テンプレとかプラグインを見直す。
脆弱性の発覚経緯とインシデントの全貌
世界中のWebサーバーで基幹的な役割を果たしているスクリプト言語「PHP」において、極めて重大なセキュリティ上の欠陥が公表され、国内外の主要なセキュリティ機関が緊急の警戒態勢に入っています。
The PHP Groupは2026年10月20日（協定世界時）、2件の深刻な脆弱性を修正するためのセキュリティリリースを予告しました。公開予定日時は協定世界時2026年10月21日14時（日本時間同日23時）と定められ、事前準備を促す異例の通知が行われました。共通脆弱性評価システム（CVSS v4.0）のベーススコアは、双方ともに10点満点中「9.2」の最高危険度区分（Critical）と算定されています。
事態をさらに緊迫させている要因は、情報公開前の守秘義務（エンバーゴ）下に置かれていた技術情報が外部へ漏洩した点にあります。欧州サイバーセキュリティ機関（CERT-EU）をはじめ、オーストラリアサイバーセキュリティセンター（ASD/ACSC）、日本の情報処理推進機構（IPA）が即座に注意喚起を発出し、パッチ公開前の段階で自組織のPHP資産を洗い出すよう要請しました。セキュリティ研究コミュニティの間では、この一連の脆弱性チェーンは「php2shell」と呼称されています。
| 項目 | 詳細内容 |
| 対象識別子（CVE） | CVE-2026-109618、CVE-2026-109619 |
| 脆弱性通称 | php2shell |
| 深刻度評価 | CVSS v4.0 スコア 9.2（Critical） |
| 想定される攻撃形態 | 認証不要の遠隔コード実行（Unauthenticated RCE） |
| 公式修正リリース日時 | 協定世界時（UTC）2026年10月21日 14:00（日本時間 23:00） |
| 主要警告発信機関 | CERT-EU、ASD/ACSC、IPA（情報処理推進機構） |
公式パッチの配布を待たずして概念実証（PoC）コードや検証動画がネット上に拡散し始めており、悪意ある第三者による無差別探索行動が活発化しています。
影響を受けるバージョンと実行環境の網羅的分析
本インシデントにおける最大の懸念事項は、影響対象が特定のフレームワークや一部の拡張機能に限定されず、PHPのコアランタイムそのものに内在している点にあります。
CERT-EUの勧告およびセキュリティ企業各社の独自検証によると、脆弱性の根幹はPHP 5系以降の広範なバージョンに内在していると報告されています。PHPはオープンソースコミュニティによるライフサイクル管理に基づいており、すでにサポートが終了した古いバージョン（EOL: End-of-Life）に対しては、開発元からセキュリティパッチが公式に提供されることはありません。
| PHP系列 | サポート状態 | 公式セキュリティパッチ提供 | 運用環境における直接的リスク |
| PHP 8.5系 | アクティブサポート | 修正版リリース予定（8.5.12等） | パッチ適用により即時解消可能 |
| PHP 8.4系 | アクティブサポート | 修正版リリース予定（8.4.27等） | パッチ適用により即時解消可能 |
| PHP 8.3系 | セキュリティサポート | 修正版リリース予定（8.3.36等） | パッチ適用により即時解消可能 |
| PHP 8.2系 | セキュリティサポート（2026年末EOL） | 修正版リリース予定（8.2.35等） | パッチ適用により即時解消可能 |
| PHP 8.1系以前（8.0 / 7.x / 5.x） | サポート終了（EOL） | 公式提供なし | 公式修正が存在せず、恒久的脆弱性に晒される |
Web技術統計機関W3Techsの計測では、サーバーサイド言語が判明しているWebサイトの約69.3%がPHPを採用しています。その内訳は、PHP 8系が約65.2%を占める一方で、サポートが完全に終了しているPHP 7系が約27.0%、PHP 5系が約7.7%残存しています。公式修正が受け取れないEOL環境がWeb空間の約3分の1を占めている実態は、攻撃者にとって格好の足場が放置されている構図を意味します。
実行アーキテクチャの観点からも、Apacheのモジュール構成（mod_php）や近年の標準構成であるPHP-FPM（FastCGI Process Manager）の双方で攻撃の再現が確認されています。加えて、WordPress、Laravel、Symfony、Drupal、Magentoなど、PHPをエンジンとして稼働する主要なCMSやフレームワーク全般が脆弱性の発現領域に含まれます。
脆弱性の深層メカニズムと多段階の脅威シナリオ
セキュリティの予備知識を持たない組織構成員であっても、本脆弱性がなぜこれほどまでに危機視されているのか、その本質を理解することが不可避です。
メモリ破壊から遠隔コード実行に至る機構
本脆弱性は、ファイルアップロードの進捗状況を追跡するPHPの標準機能「Session Upload Progress（ext/session）」周辺におけるメモリ破壊の不具合が起点となっています。この機能は特別なアドオンではなく、PHPの標準配布物において初期状態で有効化されています。
攻撃者は、特別に細工したマルチパート形式のHTTPリクエストを送信することで、サーバー側メモリ内のデータ構造を不正に混乱させます。通常のセキュリティ機構（アドレス空間配置のランダム化：ASLR）を回避するために必要な関数アドレス等の断片情報をメモリから読み取らせ、最終的にOS内部のコマンド実行ルーチンへと処理を誘導します。
この攻撃の決定的な脅威は、標的サイトの管理画面アカウントやパスワードなどの認証情報を一切必要としない「認証不要（Unauthenticated）」である点です。インターネットから閲覧可能なWebサイトに対して細工された通信を送り込むだけで、サーバーのOS権限を直接掌握する「リバースシェル」の接続が確立されます。
侵害後に想定される複合的リスク
サーバー上で任意のプログラムを実行できる権限を攻撃者が手に入れた場合、Webサービスの改ざんや停止にとどまらず、組織全体を巻き込む甚大な被害が発生します。
第一に懸念されるのは、バックドア（Webshell）の永続化と機密データの持ち出しです。攻撃者はサーバー内に不正なスクリプトを埋め込み、外部から自由に遠隔操作を継続できる状態を作り上げます。これにより、Webサイトのデータベースに蓄積された顧客の個人情報、クレジットカード決済データ、認証トークンなどの漏洩が発生します。
第二に、ランサムウェアの侵入とインフラの暗号化破壊が挙げられます。過去、2024年6月に発覚したPHPの重大脆弱性（CVE-2024-4577）においては、公表から48時間以内にTellYouThePassランサムウェアによる大規模な無差別攻撃が観測され、多数のサーバーが被害を受けました。今回の「php2shell」も同等以上の攻撃容易性と破壊力を有しており、侵害されたシステムは身代金要求の対象となります。
第三に、他組織を攻撃するための「中継踏み台化（Operational Relay Box: ORB化）」のリスクです。国家背景を持つ高度持続的脅威（APT）グループなどは、奪取した民間サーバーを踏み台にして別の重要インフラや企業へのサイバー攻撃を行います。この場合、自社インフラが犯罪の道具として悪用され、意図せぬ加害者に仕立て上げられる危険を孕んでいます。
稼働環境におけるPHPバージョンの診断手法
防護措置を講じる前提として、自社が関与するWebサイトやシステムがどのバージョンのPHPに依存しているかを迅速に特定する必要があります。
WordPressを採用している一般的なWebサイトでは、サーバーの専門知識を要さず、管理画面の機能から即座にバージョンを確認できます。管理画面にログイン後、サイドメニューの「ツール」から「サイトヘルス」へ進み、「情報」タブ内にある「サーバー」の展開アコーディオンを開くことで、現在アクティブなPHPの正確なビルド番号が画面上に表示されます。
エックスサーバー、さくらインターネット、ロリポップなどの共用レンタルサーバーを利用しているケースでは、サービス各社が提供する顧客管理コントロールパネル（サーバーパネル等）にログインすることで確認可能です。「PHP設定」あるいは「言語バージョン管理」の画面を開くと、独自ドメインごとにどのPHPバージョンが割り当てられているかが一元表示されます。
クラウド（AWSやGoogle Cloud等）の仮想インスタンス、自社物理サーバー、またはDockerコンテナを直接管理している技術者は、コンソール端末から直接バージョンを照会します。コマンドライン上で php -v を入力することで、実行バイナリの正確なリリース版数を取得できます。ただし、Webサーバープロセス（ApacheやPHP-FPM）が読み込んでいる環境とCLIの環境が乖離しているケースもあるため、Webサーバー側のバーチャルホスト設定やプール設定ファイルに記述されたPHPランタイムのパスも併せて精査することが推奨されます。
防御策の比較評価と暫定回避策の技術的限界
パッチ適用が理想的である一方、運用現場ではシステムの検証期間や業務影響の制約から、暫定的な回避策に頼らざるを得ない局面が存在します。しかし本脆弱性においては、中途半端な設定変更が致命的な油断を生む危険性があります。
緩和策の有効性と副作用の比較
セキュリティ企業各社の動的解析により、初期に提唱された簡易的な設定変更では攻撃を十分に防げない実態が明らかになっています。
| 防御アプローチ | 実装手法 | 防御有効性の技術的評価 | 運用上のデメリット・副次的影響 |
| 公式パッチの適用 | 最新修正版（8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 等）へのバイナリアップデート | 完全（根本解決） メモリ破壊のバグそのものが解消される。 | アプリケーションの互換性検証、サービスの瞬間的な再起動が必要。 |
| PHP設定の変更 | php.ini で session.upload_progress.enabled = 0 を指定 | 極めて不十分（回避可能） 初期検証では期待されたが、追跡調査で本設定のみでは攻撃を遮断できないことが判明。 | アップロード進捗表示機能が失われるのみで、攻撃耐性は確立されない。 |
| Webサーバー層での遮断 | NginxやApacheのルールで multipart/form-data 形式のHTTPリクエストを拒否（403/503） | 高い（暫定防御として有効） PHPエンジンがデータを受け取る前にWebサーバーが破棄するため発火しない。 | 画像・ファイルのアップロード、問い合わせフォーム、管理画面の投稿機能などが広範に動作停止する。 |
| WAFルールの緊急適用 | Cloudflare等のエッジWAFで異常リクエスト遮断シグネチャを有効化 | 中〜高（既知の手法に対して） 公知のエクスプロイトパターンをエッジで防護可能。 | 攻撃者が細工文字やエンコードを変更して迂回した場合に突破されるリスクが残る。 |
| サービスの計画的縮退・一時停止 | PHPプロセスを停止し、静的メンテナンス画面へ切り替え、または読み取り専用化（GET/HEADのみ許容） | 完全（稼働停止中のみ） PHPコードが実行されないため、外部からの侵入リスクを物理的にゼロ化。 | 会員ログイン、商品購入、決済などの動的サービス提供が全面的に停止する。 |
国内のホスティング事業者やプラットフォーム運営者（エックスサーバー、さくらインターネット、BASEなど）が、パッチ公開前後に管理画面や一部Web UIを計画的に一時停止させたのは、設定ファイル修正などの部分的な緩和策では安全が担保できないという判断に基づいた合理的な予防措置です。
インフラ形態に応じた実務的対応プロトコル
Webサイトを管理する主体が直ちに行動に移すべき対応手順は、インフラの運用契約形態によって二分されます。
共用レンタルサーバー利用組織の対応行動
エックスサーバーやさくらインターネットなどの共用レンタルサーバーサービスを利用している一般企業やWebサイト所有者の場合、インフラ基盤としてのPHPランタイムの更新はサーバー事業者が責任を持って実行します。そのため、利用者がサーバー内部に侵入してスクリプトやバイナリを手動で書き換える必要はありません。
利用者がまず行うべき行動は、契約しているホスティング事業者の公式サポートや障害・メンテナンス情報の確認です。各社が実施する緊急メンテナンスのスケジュールを把握し、管理画面へのアクセス制限等が発生している場合も、通常業務への影響を過度に恐れず作業の完了を待ちます。また、知識のない状態で設定ファイル（.htaccess など）を改変すると、Webサイトの表示崩れやシステムダウンを誘発するリスクがあるため、独断での変更は控えるべきです。
注意すべき点として、レンタルサーバーの管理パネルで自ら指定しているPHPバージョンが「PHP 7.4」などの古い状態に固定されている場合、サーバー事業者側の全体パッチ適用の恩恵を受けられない恐れがあります。Web制作会社や社内担当者と連携し、Webサイトの動作確認を行いながら、現行のサポート対象バージョン（PHP 8.2以上）への移行計画を速やかに進める必要があります。
VPS・クラウド・専用サーバー管理組織の対応行動
AWS、Google Cloud、自社オンプレミス環境などで仮想マシンやコンテナを自前で運用しているシステム部門は、パッチの調達から適用までの全工程を自力で完遂しなければなりません。
第一に、組織内の全公開アセットに対するPHP稼働インベントリの緊急棚卸しを完了させます。ステージング環境においてアプリケーションの単体テストやEnd-to-End（E2E）テストを実行し、最新パッチ適用に伴う既存コードの後方互換性エラーが発生しないかを即座に検証します。検証が完了次第、本番環境へのパッチ適用作業を最優先スケジュールで実行します。
第二に、パッチの適用に時間を要する場合や、EOL版のPHPを改修できないレガシーシステムを抱えている場合は、ネットワークレベルでの外部アクセス遮断やIPアドレス制限を即時導入します。社内ツールや管理用バックエンドなど、インターネット全域に公開する必要のないシステムは、社内VPNやゼロトラストネットワークアクセス（ZTNA）経由のみに隔離し、外部からの攻撃ベクトルを物理的に遮断します。
第三に、最小権限の原則に基づく被害局限化とフォレンジックの準備です。万が一Webサーバーが侵害された場合に備え、Web実行プロセス（www-data や apache 等）のOS権限を削ぎ落とし、クラウド上のIAMロールやサービスアカウントが持つ特権を極小化することで、社内ネットワークや他リソースへの横展開（ラテラルムーブメント）を封じ込めます。同時に、アクセスログやエラーログを改ざん不可能な外部ストレージへ安全に退避・保全し、不審なWebshellの設置や異常なPOSTトラフィックの有無を継続的に監視する体制を確立します。
結論と今後のセキュリティ運用指針
本件の緊急脆弱性「php2shell」（CVE-2026-109618 / CVE-2026-109619）は、事前のアクセス権限を持たない遠隔の攻撃者がWebサーバーを完全に乗っ取ることを可能にする、最高度の警戒を要するセキュリティ事案です。PHP 5系以降という膨大なバージョン範囲に及ぶ構造的欠陥であり、Webエコシステム全体に甚大な波及効果をもたらしています。
技術的な検証が示している通り、設定ファイルの微修正や部分的な回避策で本質的な安全を得ることは極めて困難であり、唯一の実効的な防衛策は「公式が提供する修正済みPHPランタイムへの即時更新」に尽きます。
過去の深刻な脆弱性における攻撃事例が証明しているように、公表から半日〜数日以内には自動化された攻撃ボットによる広範な無差別走査が開始されます。「自社のサイト規模が小さいから標的にならない」という認識は、ボットによる自動探索の前では完全に無効です。
システム責任者は、自社のシステム構成および依存するPHPバージョンを即時精査し、共用サーバーにおける公式アナウンスの監視、自社管理サーバーにおける最新バイナリの緊急適用を迅速に完遂することが強く求められます。
そんなところで
