BLOG / セキュリティ
【続報】PHP重大脆弱性の公表から約40時間。攻撃試行はすでに始まっていた｜AWS・XServer・お名前.comの最新対応状況
- 公開日時
- 更新日時
2026年10月21日に公表されたPHPのCVSS9.2重大脆弱性。公表から約40時間が経過し、AWSでは正式発表前から攻撃試行が観測されていたことが明らかになりました。AWS、XServer、お名前.comなどの最新対応状況と、企業サイトが今確認すべきポイントを解説します。
2026年10月23日
株式会社PieceInnovation
2026年10月21日に、PHP本体に存在する2件の重大な脆弱性「CVE-2026-109618」「CVE-2026-109619」が公表されてから、約40時間が経過しました。
いずれもCVSS v4.0で9.2 / Criticalと評価されており、認証されていない外部の攻撃者によって、条件次第ではサーバー上で任意のコードを実行される可能性があります。
発表直後は、
- どのPHPバージョンが対象なのか
- WordPressを使っていたら危険なのか
- PHPを更新すれば大丈夫なのか
- レンタルサーバーの場合は自分で対応が必要なのか
といった点が中心でした。
しかし、公表から約40時間が経過した現在、状況は次の段階へ進んでいます。
AWSは、PHP公式による正式公表より前の2026年10月17日時点で、今回の脆弱性を狙ったとみられる攻撃試行を観測していたことを公表しています。
さらに正式公表後は、インターネット上で広範囲なスキャンや攻撃試行が観測されています。
つまり現在は、
「重大な脆弱性が発表されたので、念のため対応する」段階ではなく、「すでに攻撃活動が始まっていることを前提に確認する」段階
へ移ったと考える必要があります。
今回は2026年10月23日時点で確認できるPHP公式、AWS、XServer、お名前.com、Google Cloud、Cloudflareなどの情報をもとに、発表から約40時間で何が起きたのか、企業サイトでは何を確認すべきなのかを整理します。
結論：発表から約40時間で何が変わったのか
PHP公式が案内している根本的な対応方法自体は変わっていません。
今回の脆弱性を修正したPHP、
- PHP 8.5.12
- PHP 8.4.27
- PHP 8.3.36
- PHP 8.2.35
への更新が基本となります。
PHP公式は、設定変更などによる対策についても案内していますが、それらはあくまで一部の攻撃経路を軽減するためのものです。
根本的な対応は、修正版PHPへの更新です。
一方、この約40時間で大きく変わったのは、実際の攻撃活動に関する情報が出てきたことです。
AWSや複数のセキュリティ企業から、スキャンや攻撃試行がすでに確認されていることが公表されています。
そのため今後は、
「PHPを更新したか」
だけではなく、
「更新される前に攻撃を受けていなかったか」
についても確認していく必要があります。
発表前から攻撃試行が観測されていた
今回、特に注目すべき情報を公表したのがAWSです。
Amazon Threat Intelligenceによると、AWSの脅威観測環境では、2026年10月17日の時点で今回のPHP脆弱性を狙ったとみられる攻撃試行が確認されています。
正式公表は10月21日です。
つまり、PHP公式から一般に詳細が公開される約4日前から攻撃試行が観測されていたことになります。
さらにAWSは、正式公表後にも攻撃コードが広く利用されている状況を報告しています。
ここで重要なのは、
「脆弱性が公開されたから、これから攻撃者が調べ始める」
とは限らないということです。
今回のような重大な脆弱性では、正式な情報公開前から何らかの方法で攻撃が試みられている可能性があります。
「攻撃試行」と「侵入成功」は別
ただし、注意したい点があります。
攻撃試行が観測されたからといって、
すべての対象サーバーへの侵入が成功したという意味ではありません。
攻撃が成立するかどうかは、
- PHPのバージョン
- PHPの実行方式
- Webサーバーの構成
- PHPの設定
- アプリケーション側の処理
- WAF
- リバースプロキシ
- リクエスト制限
などによって異なります。
そのため、
「攻撃が観測されている」＝「自社サイトが侵入された」
ではありません。
一方で、
「自社は有名な会社ではないから狙われない」
とも考えない方がよいでしょう。
今回のような攻撃では、特定企業を狙うのではなく、インターネット上に公開されているPHPサーバーを自動的に探すスキャンが行われる可能性があります。
PHP公式の現在の対応状況
2026年10月23日時点で、PHP公式が今回の脆弱性への修正版として案内しているバージョンは以下です。
| PHP系列 | 修正版 |
|---|---|
| PHP 8.5 | PHP 8.5.12 |
| PHP 8.4 | PHP 8.4.27 |
| PHP 8.3 | PHP 8.3.36 |
| PHP 8.2 | PHP 8.2.35 |
PHP公式では、今回の問題についてすべての利用者に速やかな更新を推奨しています。
PHP 8.1以前を利用している場合はさらに注意
PHP 8.1以前については、PHPプロジェクトによる通常のセキュリティサポートが終了しています。
今回については深刻度を考慮し、一部古いPHP向けにも限定的なソース修正が提供されています。
しかし、これは古いPHPの通常サポートが復活したという意味ではありません。
そのため、
- PHP 7.4
- PHP 8.0
- PHP 8.1
などを現在も使用している企業では、今回だけの修正で終わらせるのではなく、サポート対象PHPへの移行計画そのものを検討することをおすすめします。
AWSを利用している場合はどうする？
AWSについて最初に整理しておきたいのは、
「AWSそのものに今回の脆弱性がある」という話ではない
ということです。
問題になるのは、AWS上で利用者自身がPHP環境を構築している場合です。
例えば、
- Amazon EC2
- Amazon Lightsail
- Elastic Beanstalk
- Dockerコンテナ
- ECS
- 独自AMI
- 独自構築したPHPサーバー
などです。
AWSを利用しているからといって、自動的にPHPがすべて更新されるわけではありません。
EC2の場合
Amazon EC2上で、
- Apache
- Nginx
- PHP-FPM
- mod_php
などを自社で構築している場合、基本的には利用者側でOS・PHPパッケージを管理しています。
そのため、
php -v
などで実際に稼働しているPHPバージョンを確認し、使用しているLinuxディストリビューションの公式パッケージ更新状況も確認する必要があります。
ただし、LinuxではPHPのバージョン番号を維持したまま、セキュリティ修正だけをバックポートしているケースがあります。
そのため、
表示されるPHPバージョンだけではなく、CVE-2026-109618・CVE-2026-109619への対応有無を確認してください。
Elastic Beanstalk
Elastic Beanstalkを利用している場合は、PHPのPlatform Versionを確認してください。
AWS側から修正版PHPを含む新しいプラットフォームが提供されている場合でも、環境設定によっては利用者側で更新作業が必要です。
特に確認したいのが、
- 現在のPlatform Version
- Managed Platform Updatesの設定
- 実際に稼働しているPHPバージョン
です。
Lightsail利用者も要確認
Amazon LightsailでWordPressなどを運用しているケースも注意が必要です。
Lightsailでは、使用しているBlueprintやイメージによってPHP環境が異なります。
そのため、
「LightsailだからAWSが全部更新してくれる」
とは考えず、実際のインスタンス内で使用しているPHP環境を確認してください。
AWS WAFがあれば安心？
AWSでは、AWS WAFを利用した緩和策も案内されています。
例えば、
- 不自然に大きなPOSTリクエストの制限
- 特定のリクエストパターンの遮断
- PHPのアップロード処理を悪用する通信の検知
などです。
ただし、
WAFは今回の脆弱性そのものを修正するものではありません。
WAFはあくまで、
PHPを修正版へ更新するまでのリスクを減らす補助的な対策
と考える必要があります。
XServerの対応状況
今回、国内でも早い段階から大規模な対応を実施したサービスの一つがXServerです。
XServerでは10月21日から、一部の管理画面やサービスへのアクセスを一時的に停止し、予防的なセキュリティ対応を実施しました。
その後、PHPの各バージョンに対する修正パッチの適用が順次進められています。
利用者のWebサイトそのものについては、通常通り公開を継続しながら対応が実施されました。
XServer側は、今回の措置について実際の不正アクセス発生に伴うものではなく、予防措置と説明しています。
XServerを利用している場合は、公式の障害・メンテナンス情報を確認してください。
PHPの数字だけ見て「未対応」と判断しない
今回、レンタルサーバーを利用している企業で特に注意したいのがここです。
例えばPHP公式では、
PHP 8.3.36
が修正版として提供されています。
しかし、レンタルサーバー会社によっては、
PHP 8.3.35などの元のバージョン番号を変更せず、必要なセキュリティ修正だけを適用する
場合があります。
この方法を「バックポート」と呼びます。
そのため、
WordPressのサイトヘルスを見る
↓
PHP 8.3.35と表示されている
↓
「危険だ！」
とすぐに判断するのは適切ではありません。
確認すべきなのは、
- PHPの表示バージョン
- 利用しているサーバー会社
- サーバー会社による今回のCVEへの対応状況
の3点です。
お名前.com利用者も公式情報を確認
お名前.comでも、今回のPHP脆弱性への対応に伴うメンテナンス情報が公開されています。
お名前.comのレンタルサーバーを利用している場合も、
PHPバージョンの表示だけで判断するのではなく、公式のお知らせやコントロールパネル上の案内を確認してください。
特に企業サイトでは、
「サーバー会社が対応してくれていると思っていた」
という状態で終わらせるのではなく、管理会社や制作会社にも確認することをおすすめします。
Google Cloudも利用環境によって対応が異なる
Google Cloudについても考え方はAWSと似ています。
Google Cloudそのものに今回のPHP脆弱性があるのではなく、
Google Cloud上で利用者が稼働させているPHP環境が対象になる可能性があります。
例えば、
- Cloud Runの独自コンテナ
- Compute Engine
- 独自PHPランタイム
- App Engineの一部環境
などです。
マネージドサービスでGoogle側が更新する部分と、利用者側でコンテナやPHPを更新しなければならない部分を分けて確認する必要があります。
CloudflareなどのWAF事業者も対応
CloudflareなどのWAF・CDN事業者も、今回の脆弱性に対する防御ルールを展開しています。
これによって、一定の攻撃リクエストをPHPサーバーへ到達する前に遮断できる可能性があります。
しかし、ここでも考え方は同じです。
WAFで防御しているからPHPを更新しなくていいわけではありません。
PHP本体の修正版への更新が基本です。
一番重要なのは「パッチ適用前」を確認すること
ここからが今回の3本目の記事で特に伝えたいポイントです。
サーバー会社が、
「PHPの修正が完了しました」
と発表したとしても、
それ以前に攻撃を受けていなかったことまで保証されるわけではありません。
AWSでは10月17日から攻撃試行が観測されています。
そのため企業サイトでは、可能であれば10月17日頃まで遡ってアクセスログを確認することをおすすめします。
特に、
- 不自然な大量POST
- 通常発生しないURLへのアクセス
- 異常なファイルアップロード
- 不審なPHPファイルの追加
- 身に覚えのない管理者ユーザー
- 不自然な外部通信
- Webサーバーからの予期しないプロセス実行
- 突然変更されたファイル
- 身に覚えのないcron
- 不審なログイン
などがないか確認します。
WordPressの場合はここも確認
WordPressの場合は、PHPの更新状況と合わせて次の項目も確認しておくとよいでしょう。
1. 管理者ユーザー
WordPress管理画面から、
ユーザー → ユーザー一覧
を確認します。
知らない管理者アカウントが追加されていないか確認してください。
2. プラグイン
インストールした覚えのないプラグインがないか確認します。
また、無効化したまま長期間放置している不要なプラグインについては、削除も検討してください。
3. テーマ
利用していない古いテーマが大量に残っていないか確認します。
4. ファイル変更
可能であれば、
- wp-content
- plugins
- themes
- uploads
などに不自然なPHPファイルが追加されていないか確認します。
5. アクセスログ
レンタルサーバー会社からアクセスログを取得できる場合は、不自然なアクセスがないか確認してください。
「WordPressを更新したから大丈夫」ではない
今回の問題はWordPress本体ではなくPHP本体です。
そのため、
- WordPressを最新版にする
- プラグインを更新する
- テーマを更新する
- パスワードを変更する
だけでは今回の根本的な対策にはなりません。
まず、
PHP環境が今回の脆弱性に対応しているか
を確認してください。
そのうえでWordPress側のセキュリティ対策も実施します。
サーバー別：今確認したいこと
| 利用環境 | 現在確認したいこと |
|---|---|
| XServerなどの共用レンタルサーバー | サーバー会社の今回の脆弱性への対応状況 |
| お名前.comなどの共用サーバー | 公式メンテナンス情報とパッチ適用状況 |
| AWS EC2 | OS・PHPパッケージ・PHP-FPM・Apache等の更新 |
| Elastic Beanstalk | Platform Versionと自動更新設定 |
| Amazon Lightsail | 実際に使用しているPHP・イメージ |
| Docker | 修正版PHPイメージで再ビルド・再デプロイ |
| VPS | 利用者自身によるOS・PHP更新 |
| PHP 8.1以前 | サポート対象PHPへの移行検討 |
| WordPress | PHP対応＋WordPress環境の確認 |
特に危険なのは「誰が管理しているか分からないサイト」
今回のPHP脆弱性を通して、企業がもう一つ確認しておきたいことがあります。
それが、
「自社のホームページを現在誰が管理しているのか」
です。
実際、企業サイトでは、
- 制作会社との契約が終了している
- サーバーを契約した社員が退職している
- サーバーのログイン情報が分からない
- ドメインの管理者が分からない
- PHPを誰が更新するのか決まっていない
- バックアップがどこにあるか分からない
- 保守契約そのものがない
というケースがあります。
重大な脆弱性が発表されたときに、
誰が確認し、誰が判断し、誰が更新するのか
が決まっていなければ、対応が遅れてしまいます。
ホームページは「作って終わり」ではない
今回のような問題を見ると、ホームページは制作して公開すれば終わりではないことが分かります。
Webサイトの裏側では、
- PHP
- WordPress
- Laravel
- Webサーバー
- OS
- データベース
- ライブラリ
- SSL
- WAF
など、多数のソフトウェアが動いています。
これらには継続的に脆弱性が発見されます。
そのため企業サイトには、
制作後の保守・監視・アップデート体制
が必要です。
PieceInnovationが考える今回の最大のポイント
今回のPHP脆弱性への対応は、
「PHPを更新したので終了」
ではありません。
今後企業が確認したいのは、
1. 現在のPHPは修正済みか
2. 修正前に攻撃を受けていないか
3. 古いPHPを使い続けていないか
4. ログやバックアップは取得されているか
5. 次の重大脆弱性が出たときにすぐ対応できるか
です。
セキュリティ対策で重要なのは、
問題が起きてから対応するだけでなく、重大な情報が出た瞬間に影響範囲を確認できる体制を作ること
です。
Webサイト・サーバーのセキュリティ確認をご希望の企業様へ
株式会社PieceInnovationでは、愛知県岡崎市を拠点に、
- Webサイト制作
- Webシステム開発
- WordPress保守
- PHP・サーバー環境確認
- AWS環境の構築・運用
- Webサイトのセキュリティ対策
- アクセスログ確認
- 不正アクセス対策
- バックアップ体制構築
などをご支援しています。
例えば、
「自社サイトが今回対応済みなのか分からない」
「XServerを使っているが、何を確認すればいいのか分からない」
「お名前.comを使っているがPHPの状態が分からない」
「AWSを利用しているが、自社で対応する必要があるのか分からない」
「PHPが古く、バージョンを上げるとサイトが壊れそう」
「今回を機にWebサイトの保守体制を見直したい」
といった企業様もお気軽にご相談ください。
現在のWebサイト・サーバー構成を確認し、必要な対応を整理いたします。
関連記事
今回のPHP重大脆弱性については、これまでの経緯や確認方法もあわせてご覧ください。
第1回｜PHPに重大な脆弱性。CVSS9.2の危険性と企業サイトへの影響
2026年10月21日に公表された2件の重大なPHP脆弱性について、危険性や影響範囲、企業が取るべき初動対応を解説しています。
第2回｜WordPressのPHPバージョンを確認する方法
WordPressを利用している企業向けに、PHPバージョンの確認方法、修正版の見方、レンタルサーバー利用時に確認すべきポイントを解説しています。
今回の記事とあわせて、PHP脆弱性への対応状況をご確認ください。
参考情報
- PHP公式：2026年ニュースアーカイブ・セキュリティ勧告
- AWS Security Blog
- AWS Security Bulletins
- XServer：障害・メンテナンス情報
- お名前.com：ヘルプ・お知らせ
- Google Cloud Blog
- Cloudflare Blog
- WordPress公式：Hardening WordPress
※本記事は2026年10月23日時点で確認できる公開情報をもとに作成しています。PHPおよび各サーバー・クラウド事業者の対応状況は随時更新される可能性があります。実際の対応時には、必ず各サービス提供元の最新情報をご確認ください。
