- AWS、Google Cloud、Microsoft（Azure App Service）、Herokuは、いずれも公式ページでphp2shell（CVE-2026-109618 / CVE-2026-109619）への対応を出しています。どの社も「クラウド自体は影響を受けないが、利用者が動かしているPHPは影響を受けうる」という立場です。
- 自動で直るのは、クラウド会社が用意したPHPの実行環境（ランタイム）をそのまま使っている場合だけです。App Engine standard、自動更新を有効にしたCloud Run、App Service on Linuxの標準のPHPなどが当たります。
- 自分で作ったコンテナ、EC2やCompute Engineなどの仮想サーバー、PHP 8.1以前は、利用者が更新しないと直りません。Lightsailは、AWSが動いているインスタンスを更新できないため、新しいインスタンスを作って移すよう案内しています。
- 【10/22 9:50 訂正】「AWSが広い範囲での悪用を報告した」という話は、当初はAWSのセキュリティ情報（告知）に書かれていませんでした。その後、AmazonがAWS Security Blogで「PHP2Shellは現在、広く悪用されている」と発表しています。
この記事の見方
PHP本体の重大な脆弱性2件（通称php2shell）を直した修正版、PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35が10月21日に公開されました［php.net］。8.1以前は、PHPプロジェクトからの修正版が出ません。脆弱性の中身はphp2shellの解説記事にまとめています。
この記事は、AWSやGoogle Cloud、AzureなどのクラウドでPHPのサイトやシステムを動かしている会社に向けて、各社の公式の告知をまとめたものです。各ページは2026年10月22日 8時ごろ（日本時間）に開いて確かめました。時刻は出典の表記に日本時間を添えています。PDTは米国太平洋夏時間で、日本時間はPDTに16時間を足した時刻です。
国内のレンタルサーバー各社の状況はレンタルサーバー各社の対応状況に、海外の動きは海外の動向にまとめています。
クラウド各社の対応（一覧）
| サービス | 状況 | 利用者がやること | 出典（日時） |
|---|---|---|---|
| AWS Elastic Beanstalk | 2件のCVEに対応したPHPプラットフォーム v4.13.12 を10月21日に公開。PHP公式の修正を含む次のリリースは10月22日の予定 | マネージド型のプラットフォーム更新を有効にしていれば、次のメンテナンス時間に自動で更新。無効なら、環境のプラットフォームのバージョンを自分で更新 | AWS セキュリティ告知 2026-143-AWS（10/21 14:30 PDT＝10/22 6:30） |
| Amazon Lightsail | 更新したブループリント（インスタンスのひな形）を10月21日に出す見込み。動いているインスタンスはAWSが更新できない | 更新後のブループリントで新しいインスタンスを作り、アプリを移す | 同上 |
| Amazon Linux（EC2など） | Amazon Linux 2023のphp8.2〜8.5は22日に修正済み（ALAS2023-2026-3301〜3304）、php8.1とAmazon Linux 2 Coreのphpは「No Fix Planned（修正の予定なし）」 | パッケージが出しだい適用する。8.1以前は対応版へ移る | 同上／Amazon Linux Security Center（8:14ごろ確認） |
| Amazon WorkMail | AWSが設定で到達条件を絞った。PHP 8.3.36への更新は10月22日の予定 | 不要 | AWS セキュリティ告知 |
| Google App Engine standard | サポート中のランタイム（PHP 8.2以降）は自動で更新 | 8.2以降なら不要。8.1以前は8.2以降に上げて再デプロイ | Google Cloud セキュリティ告知 GCP-2026-070（10/21）、Google Cloud ブログ（10/21 15:30 PDT＝10/22 7:30 更新） |
| Google App Engine flexible | 自動では更新されない | PHP 8.2以降で再デプロイ。カスタムランタイムはPHPを更新して再デプロイ | 同上 |
| Cloud Run／Cloud Run functions | ベースイメージの自動更新を有効にしたもの（PHP 8.2以降）は自動で更新 | 自動更新が無効なもの、自分で作ったコンテナは、修正版のPHPで作り直して再デプロイ | 同上 |
| Google Kubernetes Engine（GKE） | 自動更新の対象外 | コンテナイメージを修正版のPHPに更新し、Podを再デプロイ | 同上 |
| Azure App Service on Linux（標準のPHP） | LatestとStandardの両チャネルで、修正版（8.2.35 / 8.3.36 / 8.4.27 / 8.5.12）の配布を完了。Extendedチャネルは最後に届く | Extendedなら、LatestかStandardに切り替える。php --version で確認。サポート終了のPHPは対応版へ上げる | Azure App Service Team Blog（10/21） |
| WordPress on App Service | Debian版のイメージは修正版のPHPに更新済み。古いAlpine版のイメージは更新されない | Alpine版なら、Debian版へ移る | 同上 |
| Heroku | 修正版の4つのPHPを提供開始。Heroku-22スタックのPHP 8.1.34は、PHPプロジェクトが用意した修正を取り込んで作り直した（正式なリリースではない） | アプリを再デプロイする。8.1はサポート中の版へ上げることを強く推奨 | Heroku Changelog（10/21） |
| Docker Hubの公式phpイメージ | 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 のタグが公開済み。8.1のタグは2026年1月から更新なし | Dockerfileの元イメージを修正版に替えて作り直す | Docker Hub（タグの更新は10/21 18:59〜22:09 UTC＝10/22 3:59〜7:09） |
Azureの告知は「App Service on Linux」についてのものです。WindowsのApp Serviceについての案内は、確認したページにはありませんでした。
AWS
AWSはセキュリティ告知「2026-143-AWS」を、10月21日 14:30（PDT、日本時間22日 6:30）付けで出しています。区分は「Important（対応が必要）」です。AWSのサービス自体は影響を受けず、下に挙げたサービスで影響のあるPHPを使っている利用者が影響を受けうる、としています。
影響の範囲について、AWSは、影響が及ぶのは狙われたPHPのワーカー（リクエストを処理するプロセス）と、そのアプリの権限の範囲までとし、ほかの利用者に広がった例は今のところ確認していないと書いています［AWS］。
Elastic Beanstalk
Elastic Beanstalkは、アプリを置くだけでサーバーの用意をAWSに任せられるサービスです。AWSは10月21日に、2件のCVEに対応したPHPプラットフォーム v4.13.12 を出しました。PHP公式の修正を含む次のリリースは、22日の予定としています。
「マネージド型のプラットフォーム更新」を有効にしていれば、次のメンテナンス時間に自動で更新されます。無効にしている場合は、利用者が環境のプラットフォームのバージョンを更新します［AWS］。メンテナンス時間までの間を短くしたい場合も、手動で更新できます。
Lightsail
Lightsailは、WordPressなどが入った状態のサーバーを手軽に借りられるサービスです。AWSは更新したブループリント（インスタンスを作るときのひな形）を10月21日に出す見込みとしています。ただし、動いているLightsailのインスタンスは、AWSがその場で更新できません。PHPを動かしている利用者は、更新後のブループリントで新しいインスタンスを作り、アプリを移すよう案内されています［AWS］。
Amazon Linux（EC2など）
EC2のような仮想サーバーでAmazon LinuxのPHPを使っている場合は、AWSが出す更新パッケージを利用者が適用します。AWSは更新パッケージを22日に出す予定としています［AWS］。
Amazon Linux Security Centerの各CVEのページ（10月22日 8時14分ごろ確認）では、状態は次のとおりでした。
- Amazon Linux 2023 の php8.2 / php8.3 / php8.4 / php8.5：Fixed（22日、ALAS2023-2026-3301〜3304）
- Amazon Linux 2 の Extras（php8.2）：Fixed（22日、ALAS2PHP8.2-2026-015）
- Amazon Linux 2027 Preview の php8.5：Pending Fix（修正待ち）
- Amazon Linux 2023 の php8.1、Amazon Linux 2 Core の php：No Fix Planned（修正の予定なし）
修正の予定がないパッケージを使っている場合は、修正版が出る版へ移る必要があります。LinuxでのPHPの更新手順はVPS・自社サーバーのPHPを更新する手順にまとめています。
AWS WAFでの暫定策
AWSは、すぐに更新できない場合の「補う対策」として、AWS WAFの設定を示しています［AWS］。
- CVE-2026-109618：AWS WAFのコアルールセット（CRS）にある
SizeRestrictions_BODYルールを使う。8KB（8,192バイト）を超えるリクエストの本文を止めるルールです。 - CVE-2026-109619：告知に載っているカスタムルールをWebACLに追加する。PHPのアップロード進捗の機能を使うPOSTリクエストを止める内容です。
AWSはPHP向けのマネージドルールグループも近く更新するとしています。あわせて、完全な対策は修正版への更新だけで、設定変更はどれも完全な緩和策ではないと明記しています。
「AWSが悪用を報告した」という話について
【10/22 9:50 訂正・追記】この記事の公開時点では、AWSのセキュリティ情報（告知）に悪用の状況は書かれていませんでした。その後、AmazonのCISOがAWS Security Blogで、公表の4日前（10月17日）に攻撃の試みを観測し、現在は広く悪用されていると発表しました［AWS Security Blog（10/22 7:36）］。調査は少なくとも10月17日までさかのぼるよう勧めています。悪用の状況について確認できた情報は海外の動向の記事にまとめています。
Google Cloud
Google Cloudは、セキュリティ告知「GCP-2026-070」を10月21日付けで出しました。深刻度は「Critical」です。あわせて、Google CloudのCISO（情報セキュリティの責任者）らの名前でブログを公開し、10月21日 15:30（PDT、日本時間22日 7:30）にCloud Armorの案内を追記しています。Google Cloud自体は影響を受けないが、Google Cloud上でPHPを動かしている利用者は影響を受けうる、という立場です［Google Cloud］。
環境ごとの案内
- App Engine standard：サポート中のランタイムは自動で更新されます。PHP 8.2以降なら対応は不要です。8.1以前なら8.2以降に上げて再デプロイします。
- App Engine flexible：自動では更新されません。PHP 8.2以降で、できるだけ早く再デプロイします。カスタムランタイムの場合はPHPを修正版にしてから再デプロイします。
- Cloud Run／Cloud Run functions：ベースイメージの自動更新を有効にしているもの（PHP 8.2以降）は自動で更新されます。有効にしていないものは、作り直して再デプロイします。
- GKE：コンテナイメージを修正版のPHPに更新し、Podを再デプロイします。
- Google Cloud Marketplace：CMSやLAMP構成など、PHPを含むソリューションを使っている場合は、提供元の更新を当てるか、PHPを直接更新します。
Googleは、サポート対象外のランタイムには修正を当てないと書いています。PHP 5.5、7.2、7.3、7.4、8.1のアプリは影響を受けたままで、8.2以降に上げる必要があります。また、自分で作ったコンテナイメージは利用者の責任と明記しています［Google Cloud］。
見つける・防ぐための機能
Artifact Analysis（コンテナイメージの脆弱性を調べる機能）を使っている利用者には、新しいイメージと既存のイメージの両方について、この脆弱性の通知が届くとしています。Cloud Armor（Google CloudのWAF）では、マネージドルールを有効にしていれば自動で保護が加わります。まだ使っていない場合は、少なくとも「File Upload」と「RFI」のカテゴリを有効にすること、大きすぎるリクエスト本文を止めるルールを作ることを勧めています。ルールは最初にプレビュー（記録だけ）で動かし、問題がないか確かめてから止める設定に切り替えるよう案内しています［Google Cloud］。
SNSには「Google Cloudから、影響のあるプロジェクトIDを書いたメールが届いた」という投稿もあります。公式の告知とブログで触れている通知は、Artifact Analysisの利用者向けのものだけで、このメールについての記載は見つかりませんでした。
Microsoft Azure
SNSでは「Azure App Serviceは自動でパッチが当たった」という投稿がありました。Azure App Serviceのチームのブログ（10月21日付け）を確かめると、App Service on Linuxの標準のPHPイメージについては、その内容を裏づける記載があります［Azure App Service Team Blog］。
- 修正版のPHP（8.2.35 / 8.3.36 / 8.4.27 / 8.5.12）を入れた標準のイメージは、LatestとStandardの両方のチャネルで配布を終えたと追記されています。
- App Serviceでは、更新を受け取る順番を「プラットフォームのリリースチャネル」で選びます。Latestが最初、Standard（既定）が次で、Extendedは最後に届きます。Extendedを使っている場合は、StandardかLatestに切り替えるよう勧めています。
- カスタムコンテナや、自分で用意したPHPは、App Serviceが更新しません。利用者がイメージを作り直します。
- サポートが終わったPHPには修正が届きません。チャネルを変えても、サポート終了の版がサポート中の版に変わるわけではない、とも書いています。
- WebSSH（ブラウザからサーバーに入る機能）で
php --versionを実行し、バージョンを確かめるよう案内しています。
Microsoft Marketplaceの「WordPress on App Service」で作ったサイトも修正版のPHPに更新済みです。ただし、古いAlpine版のイメージは更新されないため、Debian版のイメージへ移るよう案内しています［Azure App Service Team Blog］。
このブログはLinuxのApp Serviceについてのものです。WindowsのApp Serviceや、Azureの仮想マシンについての案内は確認できませんでした。仮想マシンでPHPを動かしている場合は、OSのPHPを利用者が更新します。
Heroku・Docker Hub・Cloudflare
Heroku
Herokuは10月21日付けの更新履歴で、修正版の4つのPHPを使えるようにしたと告知しました。アプリを再デプロイすると修正版が入ります。Heroku-22スタックのPHP 8.1.34は、PHPプロジェクトが用意した修正を取り込んで作り直したとしています。Heroku自身が「最低限の緩和策で、サポートされたリリースではない」と書き、サポート中の版へ上げることを強く勧めています［Heroku］。
Docker Hubの公式phpイメージ
Docker Hubの公式phpイメージには、8.5.12 / 8.4.27 / 8.3.36 / 8.2.35のタグが出ています［Docker Hub］。php:8.3 のような版の番号だけのタグを使っていても、すでに作ったイメージは古いままです。イメージを作り直してから入れ替えます。8.1のタグは2026年1月から更新されていません。
Cloudflare
Cloudflareは、無料・有料のWAFで防御のルールを既定で有効にし、攻撃の通信を観測したと発表しています［Cloudflare］。中身と注意点はWAFでの防ぎ方の記事にまとめています。
利用者側でやること（IaaSとPaaSの違い）
クラウドで自分がやることは、PHPを誰が用意しているかで決まります。
| 使い方 | 例 | PHPを更新するのは | やること |
|---|---|---|---|
| PaaS（クラウド会社のPHPをそのまま使う） | App Engine standard、Cloud Run（自動更新あり）、App Service on Linuxの標準のPHP、Elastic Beanstalk、Heroku | クラウド会社。ただし再デプロイやプラットフォーム更新が必要なものがある | 自動更新の設定とチャネルを確かめる。必要なら再デプロイ。実際に動いているPHPのバージョンを確かめる |
| コンテナ（自分でイメージを作る） | Cloud Run（自前イメージ）、GKE、App Serviceのカスタムコンテナ、ECSなど | 利用者 | 元イメージを修正版にして作り直し、入れ替える |
| IaaS（仮想サーバー） | EC2、Compute Engine、Azureの仮想マシン、Lightsail | 利用者 | OSのPHPパッケージを更新し、PHP-FPMやWebサーバーを再起動する。Lightsailは新しいインスタンスへ移る |
どの使い方でも、PHP 8.1以前は自動更新の対象外です。各社とも8.2以降へ上げるよう案内しています。WordPressのPHPを上げるときの注意はWordPressのPHPバージョンアップの記事を参考にしてください。
Cloud Runの自動更新、Elastic Beanstalkのマネージド型更新、App Serviceのリリースチャネルは、どれも利用者が選ぶ設定です。前任者が設定したまま中身を知らない場合は、管理画面で設定を確かめ、動いているPHPのバージョンを直接確かめてください。
WAFは時間稼ぎ
AWS WAF、Cloud Armor、CloudflareのWAFは、どれも攻撃とみられる通信を入り口で止める仕組みです。AWSは「完全な対策は修正版への更新だけ」と書き、Googleも修正版への更新を「根本から取り除くために欠かせない」としています［AWS、Google Cloud］。WAFは、修正版を当てるまでの時間稼ぎとして使ってください。
WAFを通らずにサーバーへ直接届く経路があると、ルールは働きません。WAFの限界はWAFでの防ぎ方の記事で詳しく説明しています。
よくある質問
クラウドは大手が運営しているので、何もしなくていいですか？
使い方によります。クラウド会社が用意したPHPをそのまま使い、自動更新を有効にしている場合は、クラウド会社が更新します。仮想サーバーや自分で作ったコンテナでは、利用者が更新しないと直りません。各社とも、クラウド自体は影響を受けず、利用者が動かしているPHPが影響を受けうるとしています。
Lightsailで動いているWordPressはどうすればいいですか？
AWSは、更新後のブループリントで新しいインスタンスを作り、アプリを移すよう案内しています。動いているインスタンスはAWSがその場で更新できないためです。移す作業の前にバックアップを取り、新しいインスタンスのPHPのバージョンを確かめてください。
Elastic Beanstalkは自動で更新されますか？
マネージド型のプラットフォーム更新を有効にしていれば、次のメンテナンス時間に自動で更新されます。有効にしていない場合は、利用者がプラットフォームのバージョンを更新します。
Azure App ServiceのPHPはもう直っていますか？
App Service on Linuxの標準のPHPは、LatestとStandardのチャネルで修正版の配布が終わったと告知されています。Extendedチャネル、カスタムコンテナ、サポートが終わったPHPは別です。WebSSHで php --version を実行して確かめるのが確実です。
PHP 8.1のままでも、クラウド会社が直してくれますか？
Google CloudとAzureは、サポートが終わった版には修正を当てないとしています。Amazon Linux 2023のphp8.1も「修正の予定なし」です。HerokuはPHP 8.1.34を作り直していますが、Heroku自身が最低限の緩和策と位置づけています。8.2以降へ上げる準備を進めてください。
Webセキュリティ診断センターでは、クラウドで動いているPHPのバージョンや自動更新の設定の確認、コンテナの作り直し、PHP 8.1以前からのバージョンアップをお受けしています。無料相談はこちら
参考にした情報
- php.net（PHP公式のセキュリティアドバイザリ）
- AWS Security Bulletin 2026-143-AWS「PHP web runtimes (CVE-2026-109618 and CVE-2026-109619)」（英語）
- Amazon Linux Security Center CVE-2026-109618 / CVE-2026-109619（英語）
- Google Cloud セキュリティ告知 GCP-2026-070（英語）
- Google Cloud Blog「Responding to core PHP vulnerabilities CVE-2026-109618 and CVE-2026-109619」（英語）
- Azure App Service Team Blog「Critical PHP Security Release: What It Means for Azure App Service on Linux」（英語）
- Heroku Changelog「PHP updates - October 2026 (CVE-2026-109618 and CVE-2026-109619)」（英語）
- Docker Hub 公式phpイメージ
- Cloudflare Blog「Cloudflare deploys protections against php2shell vulnerability」（英語）
