PHPの脆弱性php2shell(CVE-2026-109618/109619)について、利用者がやるべきことは使っているサービスで変わります。大きく分けると、事業者が直すもの、利用者が再デプロイすれば直るもの、利用者が自分で更新するものの3種類です。

サービスの種類PHPを直すのは誰か利用者がやること
国内レンタルサーバー事業者告知で対応状況を確認する。古いPHPを選んでいれば切り替えを検討する
PaaS(App Engine・Heroku など)事業者がランタイムを更新自動更新でなければ再デプロイする
Linuxサーバー(VPS・EC2 など)利用者OSのパッケージを修正版に更新し、ワーカーを再起動する
Docker・コンテナ利用者イメージを作り直して再デプロイする

本記事では、主なサービスの公式発表をもとに、2026年10月22日午前時点の対応状況を整理します。状況は時間単位で変わっているため、最新の情報は各社の告知を確認してください。脆弱性の概要はphp2shellとは?影響範囲と今すぐやるべき対応で整理しています。

国内レンタルサーバー

レンタルサーバーでは、PHP本体の修正は事業者が行います。ただし、対応の進み方と、利用者に求めていることは事業者ごとに違います。

サーバーを修正して告知する事業者と、告知や管理画面から自分の利用環境を確認する利用者
Fig. 01 — 契約中のプランとPHPのバージョンが対応済みか、事業者の告知で確認する。
事業者公式発表の内容
エックスサーバー10月22日6:45時点で、PHP 8.2〜8.5は対象のすべてのサーバーへの修正パッチの適用が完了。旧バージョンは検証が済んだものから順次適用中(お知らせ)
さくらのレンタルサーバコントロールパネルで選べるすべてのPHPバージョンについて対応を完了。利用者が実施する緊急の対応はない(告知)
ロリポップ!セキュリティ強化のため緊急メンテナンス中(メンテナンス情報)
CPIサービスサイトと管理画面を停止して対応。現時点で脆弱性を悪用した攻撃は確認されていない(お知らせ)
KAGOYAレンタルサーバープランは修正版への更新を調整中。マネージド専用・共用・WordPress専用サーバープランは方針を調整中で、暫定策として公開停止やアクセス制限の検討を案内(お知らせ)

(調査時点: 2026年10月22日午前)

レンタルサーバーで利用者が確認すべきなのは、自分のサイトが使っているPHPのバージョンが対応済みかどうかです。古いバージョンを選んだまま使っている場合、修正が後回しになったり、そもそも提供されなかったりします。コントロールパネルで、サポート中のバージョン(8.2以降)に切り替えられるかを確認してください。切り替えるとWordPressのプラグインなどが動かなくなる場合があるため、事前にバックアップを取ります。

社内の担当や制作会社との分担を決める際は、php2shellへの職種別の対応を参照してください。経営者が判断することや、サイト担当が委託先に確認することを整理しています。

クラウド・PaaS

クラウドやPaaSでは、事業者がPHPのランタイムを更新しても、利用者が再デプロイしないと反映されないものがあります。

サービス公式発表の内容利用者がやること
Google Cloud App Engine スタンダード環境サポート中のランタイムは自動で修正。PHP 8.1以前は8.2以降への移行を案内8.1以前なら移行する
Google Cloud Runベースイメージの自動更新が無効、または自前のイメージを使う場合は、修正版のPHPで作り直して再デプロイ自動更新の設定を確認し、必要なら再デプロイする
Google Cloud App Engine フレキシブル環境・GKE依存関係を修正版に更新して再デプロイ再デプロイする
AWS Elastic Beanstalk10月21日に両CVEに対応したPHPプラットフォーム(v4.13.12)を公開プラットフォームを更新する
AWS Lightsail修正したブループリントを提供。稼働中のインスタンスは自動では更新されないインスタンス内のPHPを自分で更新する
Heroku8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 を提供。Heroku-22のPHP 8.1.34は公式のバックポート修正を入れて再ビルドアプリをデプロイし直して新しいPHPを使う

出典: Google Cloud、AWS セキュリティ情報 2026-143-AWS、Heroku(調査時点: 2026年10月22日)

CloudflareはWAFで今回の攻撃を検知・遮断するルールを提供しており、正式な公開前から利用者を狙う攻撃の通信を観測したと公表しています(Cloudflareのブログ)。WAFは被害を減らす手段にはなりますが、更新の代わりにはなりません。

Linuxサーバー(OSのPHPパッケージ)

VPSやEC2などで、OSのパッケージとしてPHPを入れている場合は、利用者が更新します。OSのパッケージは修正だけを取り込むため、バージョン番号がPHP公式の修正版と一致しません。次の版以降になっていれば修正済みです。

Linuxディストリビューションのセキュリティ情報と、サーバーで稼働中のPHPパッケージを照合する図
Fig. 02 — OSのPHPは、ディストリビューションが示す修正版と、稼働中のパッケージの版を照合する。
ディストリビューションパッケージ修正済みの版
Ubuntu 22.04php8.18.1.2-1ubuntu2.28
Ubuntu 24.04php8.38.3.6-0ubuntu0.24.04.13
Ubuntu 26.04php8.58.5.4-0ubuntu1.5
Debian 12(bookworm)php8.28.2.35-1~deb12u1
Debian 13(trixie)php8.48.4.27-1~deb13u1

出典: Ubuntu CVE-2026-109618、Debian Security Tracker(調査時点: 2026年10月22日)

Red Hat系は、Red Hatがセキュリティ情報(RHSB-2026-013)で対応状況を公開しており、RHEL 8・9・10の多くのPHPストリームで修正版が出ています。AlmaLinuxは10月21日に、8・9・10のすべてのPHPストリームの修正版をリポジトリに公開しました(AlmaLinuxのブログ)。

Amazon Linuxは、ALASのCVEページで一部のパッケージが「Pending Fix(修正待ち)」、Amazon Linux 2のcore phpとAmazon Linux 2023のphp8.1が「No Fix Planned(修正予定なし)」となっています(調査時点: 2026年10月22日)。修正予定のないパッケージを使っている場合は、サポート中のPHPへの移行が必要です。

パッケージを更新したら、PHP-FPMやApacheを再起動し、Webサーバー経由で動いているPHPが新しいパッケージになっていることを確認してください。

Docker・コンテナ

Docker Hubの公式phpイメージは、10月21日(UTC)に8.2〜8.5の各系列が修正版に更新されました(docker-library/official-images)。サポートが終了した8.1以前のイメージは更新されていません。

コンテナで注意すべきなのは、イメージが更新されても、稼働中のコンテナは古いままという点です。

更新したイメージの取得とビルド、再デプロイ、稼働確認の順に進めるコンテナ更新の流れ
Fig. 03 — イメージを作り直して再デプロイし、PHPの版と古いコンテナが残っていないかを確認する。
  1. Dockerfileのベースイメージの指定を確認する。php:8.3.30-apache のように細かいバージョンで固定している場合は、修正版に書き換える
  2. キャッシュを使わずにイメージを取得し直して作り直す
  3. 再デプロイし、古いイメージのコンテナが残っていないかを確認する
  4. CIや検証環境で使っているイメージも同じように更新する

WordPressやDrupalなど、PHPを含むアプリケーションの公式イメージも更新されていますが、中に入っているPHPのバージョンは、作り直した後にコンテナの中で確認してください。

再デプロイ後は、エラーログやアップロード・ログインなどの動作を確認します。具体的な確認手順と報告されている不具合はパッチの修正内容と更新後の確認ポイントにまとめています。

今回の更新を継続的な運用にするには、担当者と完了条件まで決めます。ライブラリ更新・IAM・退職者管理・SaaS整理の確認項目も参照してください。

WordPress・フレームワークを使っている場合

WordPressを動かす、PHP本体を確認する
WordPress
サイト・アプリ
WordPressなど
PHP
PHP本体
今回の更新対象
WordPress本体やプラグインの更新とは別に、サーバーで動くPHPの修正が必要です。
ロゴ:PHP © Colin Viebrock(CC BY-SA 4.0、形状・配色の変更なし)、WordPress®(WordPress Foundation)。

今回の問題はPHP本体にあり、WordPressやLaravelなどのアプリケーション側の更新では直りません。セキュリティ企業のCalifは、WordPress・Drupal・Laravel・Symfonyなど主要なCMSやフレームワークの最新版で、認証なしにコードを実行できることを確認したと公表しています(Calif)。使っているCMSやフレームワークに関係なく、その下で動くPHPを、上で整理したサービスごとの方法で更新してください。

今回を機にCMSの変更を考えている場合は、WordPressから乗り換えるべきかの判断材料も参照してください。PHPの修正と安全確保を先に進め、乗り換えは編集業務や保守体制、移行の費用と影響を比較して判断します。

当社でお手伝いできること

当社は受託開発のほか、技術顧問・SRE顧問として、インフラの構成管理やデプロイの自動化、障害対応の手順づくりを担当しています。「どのサービスでPHPが動いているか分からない」「レンタルサーバーで古いPHPから切り替えたいが、サイトが壊れないか不安」「コンテナの更新手順が整っていない」といった段階からご相談いただけます。

今回の対応や、OSやイメージの更新を定期的に回せる仕組みづくりについては、SRE顧問へのお問い合わせからご連絡ください。