# 【10/23最新】PHP脆弱性、WordPressの対応方法｜会社のサイトで確かめる7つのこと（php2shell）

> PHPの重大な脆弱性 php2shell は、WordPressやプラグインを更新しても直りません。会社のWordPressサイトで確かめる7つのこと（PHPのバージョンの見方、修正済みかの判断、サーバー会社別の状況、制作会社への確認文、PHPを上げる手順、乗っ取りの確認）を、10月23日時点の情報でまとめました。

- URL: https://enhanced.co.jp/articles/php-vulnerability-wordpress-checklist/
- 公開日: 2026-10-23
- カテゴリー: [AIニュース](https://enhanced.co.jp/topics/ai-news/)
- タグ: PHP, WordPress, php2shell, セキュリティ, 脆弱性
- 発行: エンハンスド株式会社 (https://enhanced.co.jp/)

---

# 【10/23最新】PHP脆弱性、WordPressの対応方法｜会社のサイトで確かめる7つのこと（php2shell）

2026年10月21日、PHPの開発元が、**ログインなしで外からサーバーを乗っ取られるおそれのある脆弱性2件**（通称 php2shell、CVE-2026-109618・CVE-2026-109619）を修正した版を公開しました。WordPress は PHP で動いているので、**会社のサイトを WordPress で作っているなら、ほぼ確実に関係があります**。

ただし、やるべきことは「WordPress を最新にする」ではありません。WordPress.org は、**WordPress 本体の更新は不要で、サイトを動かしている PHP を更新するよう**呼びかけています（[WordPress.org](https://ja.wordpress.org/2026/10/21/critical-php-security-release/)）。

この記事は、WordPress で会社のサイトを持つ担当者の方に向けて、**何を・どこで・誰に確かめればよいか**を7つにまとめたものです。エンジニアでなくても確かめられることから順に並べ、技術者に任せる部分は「頼み方」まで書きました。脆弱性の仕組みやサーバーでの緩和策は、[php2shell の解説記事](https://enhanced.co.jp/articles/php2shell-cve-2026-109618-109619/)をご覧ください。

![WordPressのサイトで確かめる7つのこと。1 PHPのバージョン。2 修正済みかどうか。3 どこで動いているか。4 誰が管理しているか。5 PHPを上げる準備。6 乗っ取られていないか。7 忘れているサイト](https://enhanced.co.jp/cdn-cgi/image/width=1200,quality=80,anim=false,format=auto/https://api.kakasete.com/Enhanced/medias/505/20261023114006_wp-01-summary.webp)

> **結論：確かめるのは WordPress ではなく、その下で動いている PHP です。** 管理画面に出る PHP の番号だけでは「修正済み」と判断できないので、サーバー会社の告知か、サイトを管理している会社の回答で確かめてください。PHP 8.1 以前で動いているなら、8.3 以上への切り替えが必要です。

WordPressのPHP対応をお手伝いします

「うちのWordPressは大丈夫？」を、代わりに確かめます

PHPのバージョンと修正の状況の確認、8.3以上への切り替えと動作の確認、10月17日以降の侵害の調査まで、エンハンスドが対応します。制作会社と連絡が取れないサイトや、管理者が分からないサイトもご相談ください。

[WordPressのPHP対応を相談する](https://enhanced.co.jp/?inquiry=security#contact)

## 【10月23日時点】WordPressのサイトに関わる最新の状況

- **国内では少なくとも246の組織がサイトやサービスを止めた**：piyolog の集計では、10月21日〜22日にサービスやサイトを止めた組織は246にのぼります（10月23日昼までに各組織の告知で確かめられた範囲。[piyolog](https://piyolog.hatenadiary.jp/entry/2026/10/21/174516)）
- **国内の主なレンタルサーバーは修正をほぼ当て終えた**：エックスサーバー・ロリポップ・さくらのレンタルサーバなどが、サポートの切れた古い PHP も含めて修正を当てたと告知しています（[サーバー会社別の状況](#hosting)）。ただし、VPS やクラウドで動かしているサイトは、自社か管理会社が更新しない限り直りません
- **WordPress のサイトへの攻撃は続いている**：WordPress 向けのセキュリティ企業 Wordfence は、自社のファイアウォールで 7.4万件以上の攻撃や探りを止めたと発表しました（10月22日）。10月22日時点で侵害が確定した例はまだ無いとしつつ、WordPress のログに残らない形で起きている可能性もあるとしています（[Wordfence](https://www.wordfence.com/blog/2026/10/attacks-on-php2shell-continue-but-no-known-compromises-as-a-result-yet/)）
- **狙われているのは wp-config.php の中身**：同社によると、攻撃者はサーバーを調べたあと、データベースのパスワードなどが入った `wp-config.php` や環境変数を盗み、アップロード用のフォルダなどに Web シェル（遠隔操作用のファイル）を置こうとしています
- **侵害の確認は10月17日以降が対象**：AWS は、公表の4日前の10月17日に悪用の試みを観測しています（[AWS](https://aws.amazon.com/jp/blogs/news/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/)）。JPCERT/CC も10月22日に注意喚起を出し、ログで確かめる観点を示しました（[JPCERT/CC](https://www.jpcert.or.jp/at/2026/at260033.html)）

## まず押さえておきたい3つのこと

![直すのはWordPressではなく、その下のPHP。WordPress本体・テーマ・プラグインは今回の原因ではない。PHPが今回の穴で、修正版へ更新する。PHPを入れているサーバーは、共有のレンタルサーバーならサーバー会社が、VPS・クラウド・自社のサーバーなら自社か管理会社が直す](https://enhanced.co.jp/cdn-cgi/image/width=1200,quality=80,anim=false,format=auto/https://api.kakasete.com/Enhanced/medias/505/20261023114008_wp-02-layers.webp)

### 1. WordPress本体やプラグインを更新しても直らない

今回の脆弱性は、WordPress ではなく**PHP そのもの**にあります。WordPress.org は、WordPress 本体の更新は不要で予定もないとしたうえで、ホスティング会社に確かめ、必要なら PHP を早急に更新するよう求めています（[WordPress.org](https://ja.wordpress.org/2026/10/21/critical-php-security-release/)）。

なお、2026年7月に話題になった **wp2shell** は、名前は似ていますが別の問題です。こちらは WordPress 本体の脆弱性で、本体を 6.8.6・6.9.5・7.0.2 以降に更新すれば直ります。**php2shell は PHP の更新、wp2shell は WordPress 本体の更新**と覚えておきましょう。ついでに、本体が最新（10月23日時点で 7.1.3）になっているかも確かめておくと安心です。

### 2. セキュリティプラグインやWAFだけでは防ぎきれない

Wordfence などのセキュリティプラグインは、WordPress の中で動いて攻撃を選り分けます。Wordfence 自身も、自社のファイアウォールが守るのは WordPress のアプリの層で、**今回は WordPress が動き出す前に始まる攻撃もある**ため、PHP の更新とサーバーの再起動が欠かせないとしています（[Wordfence](https://www.wordfence.com/blog/2026/10/critical-php-update-wordpress-vulnerabilities-testing/)）。PHP 公式も、Apache の mod_php ではアプリのコードが動く前に攻撃が成り立つとしています（[PHP公式](https://www.php.net/archive/2026.php)）。

国内でよく使われる SiteGuard WP Plugin は、主にログインや管理画面を守るプラグインで、今回のような PHP への攻撃を防ぐためのものではありません。

Cloudflare などの WAF（Webアプリケーションファイアウォール）は、更新までの時間を稼ぐのに役立ちます。ただし、Patchstack や Sucuri は、**サーバーに WAF を通らずに直接届く道が残っていると回り込まれる**と注意しています（[Patchstack](https://patchstack.com/articles/php-major-vulnerability-alert-10-2026/)、[Sucuri](https://blog.sucuri.net/2026/10/critical-php-security-update-two-rce-flaws-cve-2026-109618-cve-2026-109619.html)）。どれも PHP の更新の代わりにはなりません。

### 3. サイトヘルスに警告が出なくても、安全とは限らない

WordPress の「サイトヘルス」は、PHP が古すぎると警告を出します。ところが、この判定は **8.3 や 8.4 といった系列しか見ておらず、末尾の番号は見ていません**。私たちが10月23日に WordPress.org の判定の仕組み（API）で確かめたところ、修正されていない 8.3.1 も、修正版の 8.3.36 も、同じ「問題なし」の判定でした（[判定の API](https://api.wordpress.org/core/serve-happy/1.0/?php_version=8.3.1)）。

逆に、番号が古くても修正済みのこともあります。サーバー会社によっては、**番号を変えずに修正だけを当てている**からです（後述）。つまり、**サイトヘルスの表示だけでは、修正済みかどうかは分かりません**。

## WordPressのサイトで確かめる7つのこと

### ① PHPのバージョンを見る

WordPress の管理画面に管理者でログインし、次の順に開きます（[WordPress.org](https://ja.wordpress.org/2026/10/21/critical-php-security-release/)）。

1. 左のメニューの「ツール」→「サイトヘルス」
2. 上の「情報」タブ
3. 「サーバー」の欄を開く
4. 「PHP バージョン」の数字を控える

同じ欄の「**PHP SAPI**」も控えておくと、技術者に状況を伝えやすくなります。`apache2handler` と出ていれば Apache の mod_php で、PHP 公式が**最もリスクが高い**としている環境です。`fpm-fcgi` なら PHP-FPM、`litespeed` なら LiteSpeed です。

レンタルサーバーなら、サーバーの管理画面の「PHP のバージョンの設定」のような画面でも、サイトごとの版を確かめられます。なお、確かめるために `phpinfo()` を書いたファイルを公開の場所に置くのはやめましょう。サーバーの設定が外から丸見えになります。

### ② 修正済みかどうかを確かめる

![サイトヘルスに出たPHPの番号の読み方。8.5.12、8.4.27、8.3.36以上はPHP公式の修正版で修正済み、侵害がないかの確認へ。8.2.35以上は修正済みだが8.2は2026年12月31日にサポート終了なので年内に8.3以上へ。8.2から8.5で上の番号より小さいなら、まだ古いかサーバー会社が番号を変えずに修正したかなので、告知か管理会社に確かめる。8.1以前はPHP公式の修正は出ないので8.3以上へ移り、修正が無ければ止めることも検討](https://enhanced.co.jp/cdn-cgi/image/width=1200,quality=80,anim=false,format=auto/https://api.kakasete.com/Enhanced/medias/505/20261023114010_wp-03-version.webp)

控えた番号を、上の表に当てはめてください。PHP 公式の修正版は **8.5.12 / 8.4.27 / 8.3.36 / 8.2.35** です（[PHP公式](https://www.php.net/archive/2026.php)）。これ以上なら修正済みです。

これより小さい番号でも、**サーバー会社が番号を変えずに修正を当てている**ことがあります。たとえばエックスサーバーは PHP 5.6〜8.1 の修正をバージョン番号を変えずに当て、ConoHa WING はすべての版で番号を変えずに修正したと告知しています。この場合は、[サーバー会社の告知](#hosting)で、自分のサーバーと PHP の版が修正済みかを確かめます。

技術者に確かめてもらう場合は、PHP の**ビルドの日付（Build Date）が10月21日以降か**を見てもらうのが確実です。番号が変わらない修正でも、ビルドの日付は新しくなるためです。

**PHP 8.1 以前**（7.4・8.0・8.1 など）で動いている場合は、PHP 公式の修正は出ません。IPA も、調査に関わった Wiz 社の情報として、PHP 5.4 以降の版は少なくとも1つの脆弱性の影響を受けるとしています（[IPA](https://www.ipa.go.jp/security/security-alert/2026/alert20261022.html)）。サーバー会社が独自に修正を当てていても、その版はもうサポートが終わっています。**8.3 以上へ切り替える**前提で準備しましょう（⑤）。

### ③ どこで動いているかを確かめる

![サイトがどこで動いているかで、直す人が変わる。共有のレンタルサーバーはサーバー会社が直すので、告知で修正済みかを確かめ、古いPHPを選んだままなら8.3以上へ。マネージドのWordPressは運営会社が直す。VPS・クラウド・専用サーバーは自社か管理会社が直すので、誰がいつ更新し、Webサーバーを再起動したかを確かめる。制作会社に任せているなら契約しだいで、保守の契約に含まれるかと連絡が取れるかを確かめる](https://enhanced.co.jp/cdn-cgi/image/width=1200,quality=80,anim=false,format=auto/https://api.kakasete.com/Enhanced/medias/505/20261023114012_wp-04-who.webp)

PHP を直すのが誰かは、サイトがどこで動いているかで決まります。サーバーの契約書や請求書を見て、サーバー会社の名前とプランの名前を確かめましょう。

- **共有のレンタルサーバー**（エックスサーバー、ConoHa WING、さくらのレンタルサーバ、ロリポップ! など）：PHP の修正はサーバー会社が当てます。自社で確かめるのは、告知の内容と、**管理画面で古い PHP を選んだままになっていないか**です
- **VPS・クラウド・専用サーバー**（プラン名に「VPS」「クラウド」「専用」と入っているもの、AWS の Lightsail や EC2 など）：**PHP の更新は利用者の仕事**です。サーバー会社は直してくれません。更新したあとに Web サーバー（Apache や PHP-FPM）を再起動しないと、古い PHP が動き続ける点にも注意が必要です
- **社内のサーバー**：情報システムの部門か、構築した会社に確かめます

### ④ 誰が管理しているかを確かめる

サイトを制作会社や保守会社に任せている場合は、すぐに状況を問い合わせましょう。聞くことが漏れないよう、次の文面をそのまま使ってください。

件名：PHPの脆弱性（php2shell）への対応状況の確認のお願い  
  
いつもお世話になっております。  
10月21日に公表されたPHPの脆弱性（php2shell、CVE-2026-109618・CVE-2026-109619）について、弊社のWebサイト（URL：　　　　）の対応状況を教えてください。  
  
1. サイトを動かしているPHPのバージョンと、修正が当たっているか（修正版 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 以降か、サーバー会社の修正が当たった版か）  
2. 修正が済んでいない場合、いつ対応いただけるか  
3. 更新のあと、Webサーバー（Apache・PHP-FPM など）を再起動したか（VPS・クラウドの場合）  
4. 10月17日以降のログに、不審なアクセスや侵入の痕跡がないか確かめていただけるか  
5. PHP 8.1 以前で動いている場合、8.3 以上へ切り替える予定と、切り替えたときに動かなくなるおそれのある部分  
6. 最新のバックアップがあるか  
7. 上の対応が保守の契約の範囲か、別に費用がかかるか  
  
お手数ですが、〇月〇日までにご回答いただけますと幸いです。

**制作会社と連絡が取れない、もう会社が無い**という場合は、次の順に確かめます。

1. **サーバーの契約者**：請求書やクレジットカードの明細で、サーバー代を誰が払っているかを確かめます。自社の名義なら、サーバー会社のサポートに直接問い合わせられます
2. **WordPress の管理者のアカウント**：自社で管理者としてログインできるかを確かめます。できれば、①〜②の確認は自社でできます
3. **サーバーの管理画面に入れるか**：入れれば、PHP のバージョンの切り替えも自社でできます

どれも分からない場合や、制作会社の名義でサーバーを契約している場合は、権利関係の整理も含めて専門の会社に相談するのが近道です。[エンハンスドでも、管理者が分からなくなったサイトの調査と引き継ぎを承っています](https://enhanced.co.jp/?inquiry=security#contact)。

### ⑤ PHPを上げる前に準備し、上げたあとに確かめる

![サイトを壊さずにPHPを上げる5つの段階。1 ファイルとデータベースのバックアップを取る。2 WordPress本体・テーマ・プラグインを先に更新する。3 サーバーの管理画面でPHPを8.3以上に切り替える。4 トップと下の階層、問い合わせフォームの送信、管理画面、画像のアップロードを確かめる。5 壊れたら元のPHPに戻して原因を調べる](https://enhanced.co.jp/cdn-cgi/image/width=1200,quality=80,anim=false,format=auto/https://api.kakasete.com/Enhanced/medias/505/20261023114013_wp-05-upgrade.webp)

PHP 8.1 以前で動いているサイトや、8.2 のサイトは、この機会に **8.3 以上**へ切り替えましょう。WordPress も PHP 8.3 以上を推奨しています（[WordPress.org](https://wordpress.org/about/requirements/)）。PHP 8.2 は**2026年12月31日でサポートが終わります**。

注意したいのは、**古いテーマやプラグインが、新しい PHP で動かなくなる**ことがある点です。プラグインの説明にある「必要な PHP のバージョン」は下限しか示しておらず、新しい PHP で動くかどうかは分かりません。互換性を調べるプラグインとして知られる PHP Compatibility Checker も、すでに保守が終わっています（[WordPress.org](https://wordpress.org/plugins/php-compatibility-checker/)）。確実なのは、**テスト環境で実際に切り替えて動かしてみる**ことです。

切り替えたあとは、少なくとも次を確かめます。

- トップページと、下の階層のページが崩れずに表示されるか（スマホでも）
- 問い合わせフォームを実際に送れて、自動返信のメールが届くか
- 管理画面にログインでき、記事の保存と画像のアップロードができるか
- 会員の機能や決済があれば、それも動くか

画面に「**このサイトで重大なエラーが発生しました**」と出たら、原因はたいていテーマかプラグインです。WordPress は、管理者のメールアドレスに「リカバリーモード」でログインするためのリンクを送ります。そこから原因のプラグインを止めて直せます（[WordPress.org](https://wordpress.org/documentation/article/recovery-mode/)）。メールが届かないこともあるので、すぐに直せない場合は、サーバーの管理画面で PHP を元の版に戻します。**戻すのは、その版にもサーバー会社の修正が当たっている場合に限り、原因を直すまでの一時的な措置**にしてください。

### ⑥ 乗っ取られていないかを確かめる

![乗っ取られていないかを10月17日以降で2段に分けて確かめる。担当者が管理画面で自分でできる確認は、見覚えのない管理者、入れた覚えのないプラグイン、Search Consoleのセキュリティの問題、site:検索で見覚えのないページ、サーバー会社からの連絡。技術者に頼む確認は、アクセスログの長すぎるセッションIDや不審なファイル送信、エラーログのメモリ不足やワーカーの異常終了、uploadsなどに置かれたPHPファイル、本体のファイルの改ざん、見覚えのない予定の処理や外への通信。疑わしいときはサイトを止め、パスワードと認証用キーとAPIキーを変え、専門家に調査を頼む](https://enhanced.co.jp/cdn-cgi/image/width=1200,quality=80,anim=false,format=auto/https://api.kakasete.com/Enhanced/medias/505/20261023114015_wp-06-compromise.webp)

PHP を修正しても、**修正の前に入り込まれていたら、その被害は消えません**。10月17日以降について、2段に分けて確かめましょう。

**担当者が管理画面でできる確認**は次のとおりです。

- 「ユーザー」の一覧で、権限が「管理者」の人に見覚えのない人がいないか
- 「プラグイン」の一覧に、入れた覚えのないものがないか
- Google Search Console の「セキュリティの問題」に何か出ていないか
- Google で `site:自社のドメイン` と検索し、見覚えのないページ（外国語の広告など）が出ないか
- サーバー会社から、不正アクセスやファイルの改ざんの連絡が来ていないか

**サーバーに入れる技術者に頼む確認**は次のとおりです。JPCERT/CC は、ログで次の3点を確かめるよう示しています（[JPCERT/CC](https://www.jpcert.or.jp/at/2026/at260033.html)）。

- 応答の `PHPSESSID` の Cookie に、異常に長い値や形のおかしい値が入っていないか
- 不審な `multipart/form-data` のリクエストと、その前後のメモリ上限のエラーや HTTP 500 のエラーがないか
- PHP のワーカーが予期せず落ちたり、頻繁に再起動したりしていないか

WordPress に特有の確認としては、Wordfence が公表した痕跡（`wp2s.php`・`php2shell.php`・`axiom_*.php` という名前のファイル、`P2S_OK` などの文字列）を探すことや、本体のファイルが書き換えられていないかの照合があります。WP-CLI が使えるなら、次のコマンドが役立ちます（[WP-CLI](https://developer.wordpress.org/cli/commands/core/verify-checksums/)）。

```
wp core verify-checksums                     # 本体のファイルの改ざん・余分なファイル
wp plugin verify-checksums --all             # 公式ディレクトリのプラグインの改ざん
wp user list --role=administrator            # 管理者の一覧（登録日つき）
wp plugin list --status=must-use             # 自動で読み込まれるプラグイン（mu-plugins）
wp cron event list                           # 予定された処理
find wp-content/uploads -type f -iname '*.php'   # アップロード用のフォルダに PHP がないか
```

ただし、JPCERT/CC も、**痕跡が見つからなくても攻撃を受けていないとは言い切れない**としています。疑わしい点が見つかったら、次の対応をとります。

- サイトを止め、調査が終わるまで公開しない
- WordPress の全員のパスワード、サーバーと FTP・SFTP のパスワード、データベースのパスワードを変える
- `wp-config.php` の認証用キー（ソルト）を作り直し、全員をログアウトさせる（[WordPress.org](https://wordpress.org/documentation/article/faq-my-site-was-hacked/)）
- サイトにつないでいる外部サービスの API キーも変える（メモリの中身が漏れたおそれがあるため。[Patchstack](https://patchstack.com/articles/php-major-vulnerability-alert-10-2026/)）
- 問い合わせフォームなどの個人情報が漏れたおそれがある場合は、個人情報保護委員会への報告が必要になることがあります。専門家に調査を頼みましょう

### ⑦ 忘れているサイトがないかを確かめる

見落としやすいのが、**メインのサイト以外の WordPress** です。

- キャンペーンサイト、採用サイト、ブランドサイト、イベントのサイト
- テスト環境（ステージング）や、リニューアル前の旧サイト
- 何年も前に作って、今はほとんど更新していないサイト

使っていないサイトは、**この機会に閉じる**のがいちばん安全です。残す必要があるなら、PHP を使わない静的なページに置き換える方法もあります。Sucuri も、WAF を通らない古いホスト名やステージングを閉じるよう勧めています。

WordPressのPHP対応

「確かめ方は分かったが、手が回らない」ならご相談ください

エンハンスドが、サイトヘルスやサーバーの状況の確認、制作会社やサーバー会社への問い合わせの代行、PHP 8.3 以上への切り替えと動作の確認、侵害の痕跡の調査まで対応します。複数のサイトをまとめて確かめることもできます。

[WordPressの確認を頼む](https://enhanced.co.jp/?inquiry=security#contact)

## サーバー会社別の状況と確認のしかた（10月23日時点）

国内の主なサーバー会社の告知を、10月23日の夕方時点でまとめました。会社の名前のリンクから、各社の告知を開けます。状況は変わるので、最新の情報は必ず告知で確かめてください。

表の「**番号は変わらない**」に注目してください。**番号を変えずに修正を当てた会社が多く**、たとえば ConoHa WING は、修正済みでもサイトヘルスに修正版の番号（例：8.5.12）ではなく、これまでの番号（例：8.5.11）が出ることがあると告知しています。

### 共有のレンタルサーバー

各社とも、10月22日までに修正の作業を進めました（KAGOYA の一部のプランを除く）。

| サーバー会社 | 修正の状況 | 利用者がやること |
| --- | --- | --- |
| [エックスサーバー](https://www.xserver.ne.jp/news_detail.php?view_id=19734)（XServerビジネス・シン・レンタルサーバー・スターサーバーも同じ） | 5.6〜8.5 を修正済み。**5.6〜8.1 は番号が変わらない**。5.5 以下は作業中 | 急いで切り替える必要はないとしている。8.1 以前なら、計画的に 8.3 以上へ |
| [ConoHa WING](https://www.conoha.jp/wing/news/?btn_id=wing-news--news_wing-news&ap=2015054909) | すべての版（5.6〜8.5）を修正済み。**番号は変わらない**（例：8.5.11 のまま） | 不要としている |
| [さくらのレンタルサーバ](https://help.sakura.ad.jp/notification/n-2700/) | 選べるすべての版を修正済み（サポートの切れた版も含む） | 緊急の操作はない。サポート中の版への切り替えを勧めている |
| [ロリポップ!](https://lolipop.jp/info/news/8239/)・[ヘテムル](https://heteml.jp/info/detail/id/2954) | 修正済み。すべての版で「セッションのアップロード進捗」の機能を止めた。一部のサーバーで約10時間サイトの表示を止めた | サイトが動いているかの確認。8.2 以上への切り替えを勧めている |
| [mixhost](https://mixhost.jp/news/1974) | 5.2〜8.5 を修正済み。**番号は変わらない** | 不要。8.2 未満なら 8.2 以上を勧めている |
| [カラフルボックス](https://secure.colorfulbox.jp/announcements/231/) | 7.4〜8.5 を修正済み | 不要としている |
| [XREA・CORESERVER・バリューサーバー](https://www.value-domain.com/information/detail/?no=20261022-1) | すべての版を修正済み。**番号は変わらない場合がある** | 動作の確認と、8.2 以上への切り替えの検討 |
| [ABLENET](https://shared.ablenet.jp/index.php?rp=/announcements/18/%E9%87%8D%E8%A6%81PHP%E3%81%AE%E8%84%86%E5%BC%B1%E6%80%A7php2shellCVE-2026-109618CVE-2026-109619%E3%81%B8%E3%81%AE%E5%AF%BE%E5%BF%9C%E7%8A%B6%E6%B3%81%E3%81%AE%E3%81%8A%E7%9F%A5%E3%82%89%E3%81%9B%E7%B6%9A%E5%A0%B1.html) | 5.6〜8.5 を修正済み。**番号は変わらない** | 不要。5 系・7 系なら 8.4 以上を勧めている |
| [お名前.com レンタルサーバー](https://www.onamae.com/news/article/11591) | 番号を変えずに順次修正中（完了の告知は確かめられなかった） | 告知を確かめる。PHP 5 系・7 系は版の変更が要る場合がある |
| [CPI](https://www.cpi.ad.jp/news/support-info/261022/) | **修正版が出ている版だけ修正済み**（8.2.35・8.3.36・8.4.27 へ更新） | **修正の無い古い版なら、php.ini での緩和策か、修正済みの版への切り替えが必要** |
| [KAGOYA](https://www.kagoya.jp/news/2026102237094/) | レンタルサーバーのプランは修正済み。**マネージド専用・共用と WordPress 専用のプランは対応を調整中**（10月23日時点） | 後者のプランは告知を確かめる。公開の停止やアクセス制限が案内されている |

### 自分でPHPを更新する必要があるもの

次のような、**サーバーを自分で管理する形のサービス**では、サーバー会社は PHP を直してくれません。

- **[KUSANAGI](https://kusanagi.tokyo/releases/27651/)**：PHP 8.2〜8.5 の修正済みのパッケージが公開されています。自分で更新して、PHP を再起動します。8.1 以前の修正は出ないので、移行が必要です（[KUSANAGI](https://kusanagi.tokyo/releases/27681/)）
- **[AWS Lightsail の WordPress](https://aws.amazon.com/security/security-bulletins/2026-143-aws/)**：AWS は、**動いているインスタンスの中身は更新できない**としています。更新済みのイメージから新しいインスタンスを作り、サイトを移すよう案内しています
- **各社の VPS・クラウド・専用サーバー**（ConoHa VPS、さくらの VPS、AWS の EC2 など）：OS のパッケージを更新し、Apache や PHP-FPM を再起動します。手順は[php2shell の解説記事](https://enhanced.co.jp/articles/php2shell-cve-2026-109618-109619/)にまとめています

## よくある質問

### サイトヘルスで「8.4.27」と出ました。もう何もしなくていいですか？

PHP の修正は済んでいます。ただし、修正の前に入り込まれていないかは別の話です。10月17日以降について、⑥の確認をしてください。

### サーバー会社が「対応済み」と発表しています。自社では何もしなくていいですか？

共有のレンタルサーバーなら、PHP の修正はサーバー会社の仕事なので、多くの場合は済んでいます。それでも、**管理画面でサポートの切れた古い PHP を選んだままになっていないか**と、**侵害がないか**は自社で確かめる必要があります。VPS やクラウドで動かしているなら、サーバー会社は PHP を直さないので、自社か管理会社が更新します。

### 小さな会社のサイトや、ほとんど見られていないサイトでも狙われますか？

狙われます。攻撃は、インターネット上のサーバーを機械で片っ端から探る形で行われています。公表から2日足らずで、Wordfence のファイアウォールだけでも7.4万件以上の攻撃や探りを止めています。サイトの規模や知名度は関係ありません。

### WordPressのメンテナンスモードにすれば安全ですか？

安全とは言えません。メンテナンスモードのプラグインは、WordPress が動き出してから表示を切り替える仕組みなので、その手前で起きる PHP への攻撃は防げません。止めるなら、サーバーの管理画面でサイトの公開を止めるなど、サーバーの側で止めます。

### Cloudflareを使っています。大丈夫ですか？

Cloudflare は、無料のプランも含めて WAF で防御を当てたと発表しています。ただし、サーバーに Cloudflare を通らずに直接届く道が残っていると、回り込まれます（[Patchstack](https://patchstack.com/articles/php-major-vulnerability-alert-10-2026/)）。WAF は時間稼ぎで、PHP の更新は別に必要です。

### PHPを上げたら「重大なエラー」が出ました。どうすればいいですか？

管理者のメールに届くリカバリーモードのリンクから入り、原因のプラグインやテーマを止めます。すぐに直せなければ、サーバーの管理画面で PHP を元の版に戻し（その版にも修正が当たっている場合に限ります）、テスト環境で原因を調べてから、もう一度切り替えます。

### サーバーで php -v と打った番号と、サイトヘルスの番号が違います

よくあることです。`php -v` はコマンドラインの PHP の版で、Web サイトを動かしている PHP とは別のことがあります。サイトに効いているのは、サイトヘルスに出る版（Web の側の PHP）です。

### 7月の wp2shell と何が違いますか？

wp2shell は **WordPress 本体**の脆弱性で、本体を 6.8.6・6.9.5・7.0.2 以降に更新すれば直ります。今回の php2shell は **PHP** の脆弱性で、WordPress をいくら更新しても直らず、PHP の更新が必要です。

### PHP 7.4 のまま使い続けるとどうなりますか？

PHP 7.4 には PHP 公式の修正が出ません。サーバー会社が独自に修正を当てていても、今後また見つかる脆弱性が直る保証はありません。WordPress の統計では、いまも WordPress のサイトの約35%が PHP 8.1 以前で動いています（[WordPress.org](https://api.wordpress.org/stats/php/1.0/)）。古いまま放っておくほど、切り替えの手間も大きくなります。

## 年内にやっておきたいこと

今回をしのいでも、次の締め切りがすぐに来ます。**PHP 8.2 は2026年12月31日でサポートが終わります**。年内に、次の3つを済ませておきましょう。

1. **すべてのサイトを PHP 8.3 以上にする**（8.1 以前と 8.2 のサイト）
2. **サイトの一覧を作る**：どのサイトが、どのサーバーで、どの PHP と WordPress で動いていて、誰が管理しているか
3. **更新の担当と頻度を決める**：WordPress 本体・プラグイン・PHP を、誰が、いつ更新するか。保守の契約に何が含まれるか

## まとめ

- php2shell は **PHP** の脆弱性。WordPress 本体やプラグインを更新しても直らない
- サイトヘルスの番号だけでは修正済みか分からない。**サーバー会社の告知か、管理会社の回答**で確かめる
- 共有のレンタルサーバーはサーバー会社が修正を当てた。**VPS・クラウドは自社か管理会社が更新**する
- PHP 8.1 以前・8.2 のサイトは、**年内に 8.3 以上へ**。切り替えの前にバックアップ、あとに動作の確認
- 修正のあとも、**10月17日以降に入り込まれていないか**を確かめる

WordPress のサイトは、作ったあと誰も PHP を気にしないまま何年も動き続けていることが少なくありません。今回をきっかけに、自社のサイトを誰が守っているのかを確かめておきましょう。

WordPressの保守・PHPの切り替え

古いPHPのWordPressも、止めずに切り替える道筋をご提案します

古いテーマやプラグインの多いサイトは、PHP を上げると動かなくなることがあります。エンハンスドは、影響の調査、テスト環境での切り替えと改修、侵害の調査、その後の保守までを一貫して承ります。

[WordPressのPHP対応を相談する](https://enhanced.co.jp/?inquiry=security#contact)

## 参考資料

- [PHP の重大なセキュリティリリース - WordPress.org 日本語](https://ja.wordpress.org/2026/10/21/critical-php-security-release/)（原文：[Critical PHP Security Release](https://wordpress.org/news/2026/10/critical-php-security-release/)）
- [PHP公式ニュース（セキュリティアドバイザリ・各修正版のリリース告知）](https://www.php.net/archive/2026.php)
- [PHPにおける複数の脆弱性（CVE-2026-109618、CVE-2026-109619）に関する注意喚起 - JPCERT/CC](https://www.jpcert.or.jp/at/2026/at260033.html)
- [PHPの脆弱性対策について（CVE-2026-109618、CVE-2026-109619：PHP2shell）- IPA](https://www.ipa.go.jp/security/security-alert/2026/alert20261022.html)
- [PHP2Shell の公表前の悪用を MadPot で特定 - AWS](https://aws.amazon.com/jp/blogs/news/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/)
- [Why It’s Urgent to Update PHP on Your WordPress Site - Wordfence](https://www.wordfence.com/blog/2026/10/critical-php-update-wordpress-vulnerabilities-testing/)
- [Attacks on PHP2Shell Continue, But No Known Compromises as a Result Yet - Wordfence](https://www.wordfence.com/blog/2026/10/attacks-on-php2shell-continue-but-no-known-compromises-as-a-result-yet/)
- [PHPの重大な脆弱性についての告知 - Patchstack](https://patchstack.com/articles/php-major-vulnerability-alert-10-2026/)
- [PHPの2件のRCEの脆弱性についての解説 - Sucuri](https://blog.sucuri.net/2026/10/critical-php-security-update-two-rce-flaws-cve-2026-109618-cve-2026-109619.html)
- [WordPress の動作環境 - WordPress.org](https://wordpress.org/about/requirements/)
- [Recovery Mode - WordPress.org](https://wordpress.org/documentation/article/recovery-mode/)
- [FAQ My site was hacked - WordPress.org](https://wordpress.org/documentation/article/faq-my-site-was-hacked/)
- [wp core verify-checksums - WP-CLI](https://developer.wordpress.org/cli/commands/core/verify-checksums/)
- 各サーバー会社の告知（[サーバー会社別の状況](#hosting)の表のリンク先）

---

出典: 「【10/23最新】PHP脆弱性、WordPressの対応方法｜会社のサイトで確かめる7つのこと（php2shell）」エンハンスド株式会社 https://enhanced.co.jp/articles/php-vulnerability-wordpress-checklist/