PHP2Shell攻撃でPHPサイトは安全？今すぐ修正を確認

PHP2Shellは、2026年10月21日に公開されたPHPの重大な脆弱性に使われている名称です。PHPでサイトを運営しているなら、まず確認すべきことは、訪問者のリクエストを処理する実行環境にセキュリティ修正が入っているかどうかです。プラグインの更新やファイアウォールの正常表示だけでは、その答えは分かりません。

PHP2Shellはサイトの土台となるPHP実行環境に影響し、認証なしのリモートコード実行を可能にするおそれがあります。PHPは8.2.35、8.3.36、8.4.27、8.5.12で修正を公開しているため、実際にWebリクエストを処理する環境で修正版、または文書化されたベンダーのバックポートを確認してください。防御機能は維持しつつ、WAFや一時的な設定変更をパッチの代わりと考えないでください。

確認時点: 2026年10月21日17:15 UTC。 この記事は修正公開後の情報に基づいており、公開予定を伝えた初期の告知とは状況が異なります。ベンダーのパッケージや対応指針は短時間で変わる可能性があるため、作業前にリンク先の勧告を再確認してください。

PHP2Shellで実際に確認されていること

PHPのセキュリティチームは、ログインなしでリモート実行につながる可能性がある二つの欠陥を公表しています。公式勧告 は、Webリクエストを処理するPHP環境が危険にさらされると説明し、特にApacheのmod_phpを最もリスクの高い構成として挙げています。悪用の成立条件は、実行環境、ビルド、リクエスト処理の構成によって変わります。

どちらの勧告もCVSS v4.0のスコアは9.2です。SNS投稿で紹介された回避策だけに頼らず、CVE-2026-109618 とCVE-2026-109619 の一次報告を確認してください。

迅速に対応すべき理由はありますが、すべてのPHPサイトがすでに侵害された証拠ではありません。重大な脆弱性、攻撃の試行、確認済みの侵入は、それぞれ別の判断です。自社システムがどの状態にあるのかを対応の中で明らかにしてください。

PHP2Shellを修正するPHPのバージョンは？

本日公開された、サポート対象ブランチ向けのセキュリティリリースは次のとおりです。この表は上流版を確認するための出発点です。ディストリビューションのパッケージでは、別のパッケージリビジョンに修正が取り込まれている場合があります。

これらのリリースはPHPのリリース告知 で確認できます。バックポート版を使う場合は、ディストリビューションやホスティング事業者からセキュリティ告知と、導入済みパッケージの正確なリビジョンを入手してください。バージョン文字列だけでは、修正済みのベンダーパッケージを未修正と判断したり、古い同梱実行環境を見落としたりすることがあります。

PHP 8.1以前は、通常の上流更新を受けられません。PHPは7.4、8.0、8.1向けにも最小限のソースバックポートを提供していますが、継続的なサポートが復活したわけではありません。責任の所在が明確なベンダーサポート付き修正、またはアップグレード計画を確保してください。現在のブランチサポートはPHPのサポート表 で確認できます。

コンテナ、組み込みのPHP環境、アプライアンスは個別に確認してください。NCSC-NLの運用指針 も、ホストのPHPを更新しても、これらの実行環境が更新されるとは限らないと明確に注意しています。

WordPressやLaravelなどのPHPサイトも対象？

確認の起点は、アプリケーションを実行するインタープリターです。WordPressサイト、Laravelアプリケーション、独自のPHPポータルは、コードがまったく違っていても、同じ古い実行環境を使っている可能性があります。最新のテーマ、プラグイン、フレームワークを導入しても、PHP実行環境のセキュリティ修正は導入されません。

マネージドホスティングでは、各サイトに使われているPHPバージョンまたは修正済みパッケージ、全ノードへの反映状況、必要なワーカー再起動の完了を確認してください。アプリケーション更新の通知を証明と受け取らず、ホスティング基盤から根拠を求めてください。

自社管理のシステムでは、副次的なサイト、管理画面、古い仮想ホスト、プレビュー環境も台帳に含めます。本番アプリケーションを更新しても、同じ基盤の古いサイトが公開されたまま残ることがあります。外部に公開された環境ごとに担当者と修復方針を記録してください。

使われていないアップロードフォームがあるから安全だとは判断しないでください。PHPの勧告は実行環境のリクエスト処理経路を扱っています。訪問者から見える機能だけでは、露出状況を十分に評価できません。

訪問者に応答する実行環境へのパッチ適用と検証

実際に稼働しているものを把握する

Webサーバーとの連携方式、実行環境のパッケージまたはコンテナイメージ、設定の取得元、サービス担当者を特定します。その台帳を顧客が使うホスト名と結び付けてください。違うホストを確認すると、見た目は説得力があっても対象外のバージョン報告になってしまいます。

次の読み取り専用コマンドは、コマンドライン版の導入状況と設定を示します。

1php -v
2php --ini

これだけでは、PHP-FPM、Apache、その他のWeb連携方式で何が動いているかは証明できません。認証されたホスティング管理情報、または管理下の確認手順で、リクエストを処理する実行環境を特定してください。設定や環境の詳細を公開する診断ページを、一般公開したままにしないでください。

コンテナ構成では、レジストリ内の置き換え用イメージだけでなく、実際にトラフィックを受けるイメージとアプリケーションインスタンスを確認します。ロードバランサー配下の全インスタンスと、別に動くワーカーサービスも変更記録に含めてください。

サポートされた修正を適用し、アプリケーションを試験する

保守されているパッケージ提供元やイメージ供給元が文書化した更新手順を使います。導入リビジョンと、両方のCVEを対象とするベンダー告知を記録してください。パッケージを取得すれば稼働中のプロセスも変わると思い込まず、構成に合わせてサービス再起動やインスタンス置き換えを計画します。

業務を中断し得る変更の前に、関連ログを保全してください。検証済みのバックアップと復旧計画を確保し、更新後に代表的なアプリケーション操作を試験します。アプリケーションで使用しているなら、ログイン、セッション、購入手続き、アップロード、バックグラウンド処理などが候補になります。

最後に、リクエストを処理する実行環境を再確認して変更を完了します。更新したインスタンス、トラフィックを切り替えた時点、アプリケーション試験を承認した担当者の証拠を残してください。デプロイジョブの成功表示は有用ですが、検証全体を示すものではありません。

Cloudflare WAFはPHP2Shellを防げる？

CloudflareはPHP2Shell向けWAF保護の展開 と攻撃トラフィックの観測を報告しており、Freeおよび有料WAFの顧客が対象とされています。発表では、リクエストとレスポンスの情報を使った保護が説明されています。同時に、その保護があってもPHPにパッチを適用するよう明確に勧めています。

個々のサイトでは、対象トラフィックが保護対象サービスを実際に通っているか、適用すべきルールが有効かを確認します。例外、バイパスルール、別経路で到達可能なオリジンも見直してください。これは構成の確認であり、Cloudflareの発表がアプリケーションへのあらゆる経路の保護を保証する、という意味ではありません。

WAFのイベントデータを調査資料として保持してください。リクエストの遮断記録は、そのリクエストがルールに一致したことを示せます。しかし、別経路でオリジンに到達しなかったことや、過去に侵入がなかったことまでは証明できません。

実行環境の更新を完了する間も、WAFを追加の防御層として使ってください。ダッシュボードに攻撃遮断の記録があるという理由だけで、PHPの修正を先延ばしにしないことが大切です。

一時的な緩和策はPHP2Shellの完全な修正ではない

すぐにパッチを適用できない場合は、システム担当のエンジニアや事業者と、最新のPHP勧告に従ってください。古い状態に関する勧告 は、session.upload_progress.enabledの無効化をリクエスト解析前に行う必要と、ワーカー再起動が必要な理由を説明しています。この目的でini_set()やFPMの.user.iniに依存しないよう、特に注意しています。

この変更で阻止できるのは、確認済みのセッション関連経路であり、すべての派生経路ではありません。PHP 8.5にはfatal_error_backtracesに関する別の指針もあります。フォーラムから短い設定例をコピーしても、両方の脆弱性への対応が完了した証拠にはなりません。

メモリ不足に関する勧告 は、リクエスト制限やメモリ制限処理の変更など、異なる対策を説明しています。リソースや可用性への影響もあります。本番サーバーのメモリ境界を安易に取り除かず、実際の構成に合わせて指示全体を検討してください。

パッチ前に露出を許容できる程度まで下げられないなら、対象アプリケーションの一般公開を制限することを相談してください。一時措置、その限界、責任者、恒久修正の計画を文書化します。回避策には解除条件や見直し条件を定め、記録のない恒久設定として残さないでください。

露出確認後は何を監視するべき？

基準となる状態を把握し、重要な時間帯の記録を保全することから始めます。一つの不審なリクエストだけで診断を完結させず、WebリクエストをPHP、Webサーバー、ホストのイベントと突き合わせてください。ログがない部分は、調査の制約として明確に記録します。

これらは調査の着眼点であり、PHP2Shell固有の侵害指標や侵入の証拠ではありません。正常な運用でも似た現象は起こります。一方で、警告がないからといって、未修正システムが安全だったとは証明できません。

侵入を疑わせる証拠があれば保全し、パッチ適用と並行してインシデント対応を手配してください。インタープリターの更新は、永続化の仕組みを除去したり、盗まれた認証情報を無効にしたり、アクセスされたデータを特定したりするものではありません。それぞれを対応計画の別の課題として扱ってください。

よくある質問

PHP2Shell攻撃とは何ですか？ PHP2Shellは、CVE-2026-109618とCVE-2026-109619として追跡されるPHPの脆弱性を指します。実行環境のメモリ処理に関わり、認証なしのリモートコード実行につながる可能性があります。単なるWordPressプラグインの欠陥ではありません。

PHP2Shellパッチでは、どのバージョンを確認すべきですか？ 2026年10月21日に公開されたサポート対象ブランチの修正版は、PHP 8.2.35、8.3.36、8.4.27、8.5.12です。ディストリビューションのバックポートでは、ベンダー勧告を取得し、実際にWebリクエストを処理する環境の修正済みパッケージリビジョンを確認してください。

WordPressを更新すればPHP2Shellは修正されますか？ WordPressの更新だけでは、その土台のPHPインタープリターは更新されません。アプリケーションの保守も続けつつ、ホスティング事業者やサーバー担当エンジニアと、PHP実行環境のセキュリティ修正を別に確認してください。

Cloudflare配下のサイトは自動的に安全になりますか？ CloudflareはWAF保護を報告していますが、トラフィックの経路、適用ルール、オリジンの露出は確認が必要です。保護を有効に保ち、PHPにパッチを適用してください。ファイアウォールのダッシュボードだけでは、実行環境の修正や過去の侵入がなかったことは証明できません。

セッションのアップロード進捗機能を無効にすれば十分ですか？ いいえ。PHPは、その措置が確認済みのセッション関連経路を遮断するものであり、すべての派生経路に対応するわけではないと説明しています。適切な設定層で適用し、ワーカーを再起動する必要があります。修正済み実行環境または検証済みのベンダーバックポートへの更新は引き続き必要です。

公開された攻撃コードを本番サイトで試してよいですか？ 初期確認では、バージョン、パッケージ、設定の証拠を優先してください。検証に攻撃テストが必要なら、明示的な許可の下で、隔離、監視、復旧計画を備えた管理環境で実施します。未検証の攻撃スクリプトを本番に対して実行しないでください。

パッチ導入で、サーバーが侵害されていなかったと証明できますか？ いいえ。パッチは実行環境の欠陥に対処するもので、インシデント評価では過去の活動、永続化、認証情報、データアクセスの可能性を調べます。両方の作業を連携させ、入手できた証拠の限界を記録してください。

PHPサイトの調査、監視、パッチ適用をご相談ください

当社は、サイトを動かすPHP実行環境の特定、露出評価、利用可能なログと防御機能の確認、必要なパッチやサポート対象版への更新計画を支援します。継続的な観測が必要な場合は、特定したリスクに合わせて監視範囲、警告への対応責任、エスカレーション手順を合意できます。

当社のアプリケーションセキュリティサービス は評価と調査を支援し、サーバーセキュリティサービス はホスティングと設定の境界を扱います。ホスティング事業者と連携し、ベンダー修正の検証、変更の調整、更新後のアプリケーション試験の記録を支援できます。

必要なのは、確認した事項、修正した事項、未確定の事項、今後の担当者が分かる明確な記録です。バージョン文字列や一度のスキャンだけで、安全性を保証することはありません。作業範囲と対応可能な時期は、着手前に合意します。

PHP2Shellの露出確認、セキュリティ監視、パッチ適用支援についてお問い合わせください 。ホスティング構成、対象ドメイン、把握しているPHPバージョン、変更を承認できる担当者をお知らせください。最初のお問い合わせにパスワードやアクセストークンを含めないでください。