PHPの脆弱性でWordPressはどうなる？php2shellの影響と今すぐやることを解説【2026年10月21日時点】

2026年10月21日23時更新：PHP開発チームから修正版が正式に公開されました。今回の2件はいずれも、認証なしでリモートコード実行（RCE）につながる重大な脆弱性です。PHP公式は、PHPをWebサーバーとして利用しているすべてのユーザーに対して、修正版への即時アップデートを呼びかけています。

※10/22 に WordPress以外に影響を受ける可能性があるサービスの情報を追加しました。またConohaサーバーの発表 についても追加しました。

2026年10月20日、PHP開発チームが予告していた重大なセキュリティ修正が、日本時間10月21日23時に正式公開されました。

対象となるのはCVE-2026-109618とCVE-2026-109619の2件で、どちらもPHP本体に存在する脆弱性です。WordPress自体の脆弱性ではありませんが、WordPressはPHP上で動作するため、多くのWordPressサイトも影響を受ける可能性があります。

この記事では、PHP公式から公開された最新情報をもとに、何が起きているのか、WordPressサイトはどうなるのか、自分は何をすればよいのかを整理します。

先に結論 (10/21深夜に更新)

• PHP公式が PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 を公開しました。該当するPHPを利用している場合は、できるだけ早く更新してください
• CVE-2026-109618・CVE-2026-109619の2件で、いずれも 認証なしのリモートコード実行（RCE）につながる重大な脆弱性 です
• WordPress本体やプラグインの脆弱性ではなく PHP本体の問題 です。WordPressを最新版にするだけでは対策になりません
• PHP-FPM、Apacheのmod_php、php-cgi、FrankenPHP、LiteSpeedなど、Webリクエストを処理するPHP環境が対象です
• レンタルサーバー利用者は、サーバー会社が修正版を適用済みか公式のお知らせを確認してください
• VPS・クラウド・専用サーバーなどを自分で管理している場合は、修正版へ速やかに更新してください
• PHP公式によると完全な緩和策はなく、修正版への更新が唯一の完全な対策です
• PHPを使用していない静的HTML、Hugo、Astroなどのサイトは、PHPを別途動かしていない限り今回の脆弱性の直接の対象ではありません

何が起きているのか（時系列）

日時（日本時間）	出来事
10月21日 0時20分ごろ	掲示板に「PHPのリモートコード実行の脆弱性2件が近く公開される」という投稿が出る（後に削除。Sansec調べ）
10月21日 未明〜	セキュリティ企業watchTowrが「漏えいした情報は実在する」と発表。直後にPHP開発チームが、公式サイトで緊急セキュリティリリースを事前告知（協定世界時では10月20日付）
10月21日 13時〜	さくらのレンタルサーバで緊急メンテナンスが始まる（PHPの脆弱性との関係は報道が分かれるため、公式告知を確認）
10月21日 14時ごろ	GMO Flatt Securityが「設定変更だけでは攻撃を防げない見込み」と追記。攻撃コードを名乗るものが出回り始めたとも報告
10月21日 16時	エックスサーバーが公式サイトと管理画面を予防的に一時停止（利用者のサーバーは稼働を継続と案内）
10月21日 23時	PHP公式が修正版を公開。CVE-2026-109618 / CVE-2026-109619の詳細と影響範囲を正式発表
公開後	PHP公式は、影響を受ける環境に対して修正版への速やかなアップデートを推奨

PHP開発チームは「脆弱性の詳細が公開された場合や、実際の悪用が確認された場合は、予定より早く公開する場合がある」と述べています。

PHPの脆弱性「php2shell」とは？

今回見つかったのは、PHPの重大な脆弱性2件です。研究者の間では 「php2shell」 という通称で呼ばれています。リモートからサーバー上でプログラムを実行される「リモートコード実行（RCE）」にあたると報じられています。

現時点で分かっていること・分かっていないこと

公式が確定させている情報と、セキュリティ企業などによる未確認の情報を分けて整理します。

項目	現在判明している内容
脆弱性	CVE-2026-109618 / CVE-2026-109619 の2件
深刻度	いずれも Critical。CVSS v4.0で9.2
脆弱性の種類	認証なしのリモートコード実行（RCE）
修正版	PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35
影響する環境	PHP-FPM、Apacheのmod_php、php-cgi、FrankenPHP、LiteSpeedなど、PHPでWebリクエストを処理する環境
CVE-2026-109618	メモリ不足（OOM）が発生した際の内部データ処理に問題があり、メモリ破壊からRCEにつながる可能性がある
CVE-2026-109619	PHPワーカー内に古い内部状態が残り、後続のリクエストで利用されることでRCEにつながる可能性がある
対策	修正版PHPへのアップデート。PHP公式は完全な緩和策はないとしている

何が危険なのか

リモートコード実行とは、攻撃者がサーバー上で好きなプログラムを動かせてしまう状態です。悪用された場合、次のような被害が想定されます。

• サイトの改ざんや、不正なページの設置
• データベース内の情報（会員情報や問い合わせ内容など）の盗難
• 不正侵入用のプログラム（Webシェル）の設置
• 他のサイトへの攻撃の踏み台にされる

セキュリティ研究者は、インターネットに接続された約130万台のホストが影響を受ける可能性があると推定しています。

7月の「WP2Shell」とは別の話

名前が似ているので混同しやすいのですが、2026年7月にWordPress本体で見つかった「WP2Shell」（CVE-2026-63030・CVE-2026-60137）は 別の脆弱性 です。こちらはWordPress 6.8.6・6.9.5・7.0.2で修正済みです。

	WP2Shell（7月）	php2shell（今回）
問題がある場所	WordPress本体	PHP本体
対策	WordPressの更新	PHPの更新
状況	修正済み	修正版は10月21日23時（日本時間）公開予定

こちらはちょっと前に話題になりましたが、違うプログラムです。

WordPressはどうなる？

WordPressサイトは影響を受ける可能性が高い

WordPressはPHPで動いています。PHP本体に脆弱性があれば、WordPressに限らず、PHPで動くほぼすべてのサイトが影響を受ける可能性があります。

PHP公式によると、PHP-FPM、Apacheのmod_php、php-cgi、FrankenPHP、LiteSpeedなど、PHPでWebリクエストを処理する環境が影響を受けます。

特にApacheのmod_phpについては、アプリケーション側のコードが実行される前の段階で脆弱性を悪用できることが確認されています。そのため、WordPress本体やプラグイン側で対策するのではなく、サーバー上のPHPそのものを修正版へ更新する必要があります。

WordPressやプラグインを更新しても防げない

ここが最も大事なポイントです。

• WordPress本体の更新 → PHPは更新されません
• プラグインやテーマの更新 → PHPは更新されません
• WordPressの自動更新 → 更新されるのはWordPress本体やプラグインなどで、サーバーのPHPは対象外です

今回必要なのは、サーバー上のPHP本体を修正版に更新すること です。WordPressの管理画面からは行えません。

サイトが止まったり、壊れたりする？

PHPの修正版は、同じ系列内のパッチ更新（たとえば8.3.35から8.3.36）になると見込まれています。こうした更新は機能の変更を含まないのが普通なので、互換性の問題は起きにくいと考えられます。ただし、これは修正版の公開後に公式発表で確認してください。また、更新の作業中にサイトが数分から1時間ほど止まることはあります。

ITmedia NEWSは、保育園向けSaaS「コドモン」、ゲーム「Shadowverse: Worlds Beyond」、ネットショップ作成サービスの「BASE」、「さくらのレンタルサーバ」などが緊急メンテナンスに入った、または予告したと報じています。いずれもPHPの脆弱性の影響とみられるという報道です。ただし、さくらのレンタルサーバについては、別のLinuxカーネルの脆弱性への対応とする報道もあります。いずれにしても、修正版の公開前に備えるための措置とみられるので、慌てる必要はありません。

PHPバージョンを変更しても基本的にWordPressは動きますが、古いテーマやプラグインをお使いの場合は動かなくなる可能性があります。

ConoHa WINGはPHPバージョンの切り替え不要と案内

WordPressを利用している方の中には、「今回の脆弱性対策として、自分でPHP 8.3から8.4などへ切り替えた方がいいの？」と心配している方もいると思います。

ConoHa WINGは、今回のPHP脆弱性について、現在利用しているPHPバージョンを維持したまま、ConoHa側でセキュリティパッチを順次適用すると発表しています。

そのため、ConoHa WINGでは今回の脆弱性対策を目的として、利用者自身がPHPバージョンを変更する必要はありません。

むしろ、PHPのメジャー・マイナーバージョンを自分で変更すると、古いWordPressテーマやプラグインとの互換性によってサイトに不具合が発生する可能性もあります。今回の脆弱性だけを理由に、慌ててPHP 8.3から8.4などへ切り替える必要はありません。

これはConoHa WINGに限った考え方ではなく、共用レンタルサーバーではサーバー会社側がPHPへセキュリティパッチを適用するケースがあります。 利用しているレンタルサーバーから今回の脆弱性について案内が出ている場合は、まずその内容を確認してください。

なお、PHP 7.xや8.0、8.1など古いPHPを使用している場合は別の問題です。今回の緊急対応とは切り分けて、WordPressやテーマ、プラグインとの互換性を確認したうえで、サポート中のPHPへの移行を検討することをおすすめします。

自分の環境別：誰が何をすればいい？

あなたの環境	PHPを更新するのは	あなたがやること
共用のレンタルサーバー	基本はサーバー会社	お知らせの確認、バックアップ、PHPバージョンが古くないか確認
マネージドWordPressホスティング	基本はサーバー会社	お知らせの確認、バックアップ
VPS・クラウド・専用サーバー	自分	23時の公開直後にPHPを更新し、PHP-FPMやWebサーバーを再起動
Dockerで運用	自分	修正版のイメージで再ビルドして入れ替え
cPanelやPlesk、業務ソフトなどにPHPが同梱	ソフトの提供元	提供元のセキュリティ情報を確認（IPAやNCSCも確認を呼びかけ）
インターネットに公開していない開発環境	自分	優先度は低いが、公開前に更新しておく

契約中のサーバー会社が分からない場合は、ドメインのAレコード（IPアドレス）やネームサーバーの情報から、どの会社のサーバーを使っているか見当をつけられることがあります。

今夜までにやること（修正版の公開前チェックリスト）

1. 自分のサイトのPHPバージョンを確認する

WordPressなら、管理画面の「ツール」→「サイトヘルス」→「情報」→「サーバー」でPHPのバージョンを確認できます。サーバー会社のコントロールパネルにも、PHPバージョンの設定項目があることが多いです。

自分でサーバーを管理している場合は、php -v で確認できます。ただし、コマンドラインで動くPHPと、Webサイトを動かしているPHP（PHP-FPMやApacheのモジュール）のバージョンが別のことがあります。Webサイト側のバージョンも必ず確認してください。

良くわからない場合、ドメシラでドメインをスキャンすれば、WordPressのバージョンやPHPのバージョンを確認できます。

2. バックアップを取る

PHPの更新前に、サイトのファイルとデータベースの両方をバックアップしておきます。サーバー会社の自動バックアップがある場合でも、手元に1つ持っておくと安心です。

3. サーバー会社のお知らせを確認する

契約中のレンタルサーバーの「お知らせ」や「障害・メンテナンス情報」を確認します。10月21日18時ごろの報道では、エックスサーバーは公式サイトや管理画面を予防的に停止している一方、利用者のサイト表示とメール送受信は継続していると案内されていました。さくらのレンタルサーバは21日13時ごろから22日朝にかけて緊急メンテナンスを実施しています。ただし、さくらについては理由をPHPの脆弱性とみる報道と、別のLinuxカーネルの脆弱性への対応とする報道があるため、公式の告知で確認してください。

4. 自分でサーバーを管理している場合の準備

• PHPの更新手順と、更新後にサイトが正常に動くかを確認する手順（テストなど）を確認する
• 23時に更新できるよう、作業の時間を空けておく
• 更新後に、PHP-FPMまたはWebサーバーを再起動する手順を確認しておく（再起動しないと新しいPHPが読み込まれません）
• サーバー内に不要なデータを置いていないか、サーバーに与えている権限が広すぎないかを見直す
• アクセスログやエラーログが保存されているか確認する

5. 古いPHP（8.1以前）を使っている場合

PHP公式から通常の修正版が公開されたのは、現在サポートされているPHP 8.2・8.3・8.4・8.5です。

PHP 8.1以前はすでに公式サポートが終了しているため、基本的にはサポート中のPHPへ移行してください。

PHP公式は今回の脆弱性の深刻度を考慮し、PHP 7.4・8.0・8.1向けにも最小限の修正をバックポートしたソースを公開しています。ただし、一般的な利用環境ではOSやホスティング事業者などが提供するセキュリティ修正を確認するか、サポート中のPHPへ移行することをおすすめします。

なお、PHP 8.2のセキュリティサポートも2026年末までです。これからPHPを更新するのであれば、利用しているWordPressテーマやプラグインなどの互換性を確認したうえで、PHP 8.3以降への移行も検討するとよいでしょう。

6. 設定変更は「気休め程度」と考える

GMO Flatt Securityは当初、PHPの設定 session.upload_progress.enabled=0 が緩和策になりうると述べていました。しかし、その後「攻撃自体は回避できない見込みで、緩和にとどまる」と見解を改めています。watchTowrも、確認された回避策は現時点でないとしています。

根本的な対策は、修正版のPHPへの更新だけ です。設定変更に頼らず、更新の準備を優先してください。

7. 更新できるまでの時間稼ぎ

英国のNCSC（国家サイバーセキュリティセンター）は、すぐに対応できない場合は、システムをオフラインにすることも検討するよう呼びかけています。個人のブログであれば、一時的な公開停止やメンテナンスモードの利用も選択肢です。

修正版公開後に今すぐやること

1. 修正版のPHPへ更新する

現在使用しているPHPのバージョンを確認し、次の修正版以降へアップデートしてください。

• PHP 8.5 → 8.5.12以降
• PHP 8.4 → 8.4.27以降
• PHP 8.3 → 8.3.36以降
• PHP 8.2 → 8.2.35以降

レンタルサーバーやマネージドホスティングを利用している場合は、サーバー会社側ですでにセキュリティ修正が適用されている可能性があります。公式のお知らせや管理画面で対応状況を確認してください。

VPS・クラウド・専用サーバーなどを自分で管理している場合は、利用しているOSのパッケージマネージャーなどを通じてPHPを更新し、必要に応じてPHP-FPMやWebサーバーを再起動してください。

2. 更新が反映されたか確認する

• PHP-FPMやWebサーバーを再起動したか
• 自分のサイトのPHPバージョンが修正版になっているか
• Linuxのパッケージで更新した場合は、バージョン番号が変わらず修正だけが取り込まれること（バックポート）があるため、apt changelog や rpm -q --changelog で、変更履歴にCVE-2026-109618が含まれているかを確認する

3. 攻撃を受けた痕跡がないか確認する

修正版を入れる前に攻撃を受けていた場合、更新しただけでは侵入は解消されません。次の点を確認します。

• PHPのプロセス（php-fpmやApacheなど）が、シェルやcurl、wgetなどを不審に起動していないか
• wp-content/uploads やキャッシュ用のフォルダに、見覚えのないPHPファイルがないか
• 見覚えのない管理者アカウントや、定期実行（cron）の設定がないか
• アクセスログやエラーログに不審な記録がないか

4. 侵入が疑われる場合

• サーバーをネットワークから切り離し、ログを保全する
• データベースのパスワード、WordPressの認証キー（wp-config.php）、各種APIキーなどを入れ替える
• 必要に応じて、クリーンな環境へ作り直す（バックアップが侵害前のものか確認）
• 自分で判断できない場合は、専門の事業者に相談する

サイトを見るだけの人・一般ユーザーは？

この脆弱性はサーバー側の問題です。サイトを見ただけで、あなたのパソコンやスマホが直接乗っ取られるという話ではありません。サイト運営者でなければ、特別な対応は必要ありません。

ただし、一般論として、改ざんされたサイトが閲覧者にマルウェアを配布したり、登録済みの情報が盗まれたりすることはあります。普段使っているサービスから通知が届いたときは、内容を確認してください。

そのうえで、次のような一般的な備えをしておくと安心です。

• パスワードを複数のサービスで使い回さない
• 利用中のサービスから不正アクセスの通知が届いたら、案内に従ってパスワードを変更する
• 不正アクセス後には、そのサイトの名前を使ったフィッシングメールが増えることがあるので注意する

WordPress以外に影響を受ける可能性があるサービス

今回の脆弱性はWordPress固有の問題ではなく、PHP本体に存在します。そのため、脆弱なPHPを使ってWebリクエストを処理している場合、WordPress以外にも多くのCMS、ECサイト、掲示板、Webアプリケーションなどが影響を受ける可能性があります。

代表的なものには次のようなものがあります。

CMS・Webサイト

• WordPress
• Drupal
• Joomla!
• MediaWiki
• TYPO3
• Concrete CMS（concrete5）
• Grav
• Craft CMS
• October CMS
• MODX
• ExpressionEngine
• ProcessWire

MediaWikiもPHPで動作するため対象になり得ます。MediaWikiはWikipediaをはじめとしたWikiサイトで利用されているCMSです。

ECサイト・ネットショップ

• Magento / Adobe Commerce
• PrestaShop
• OpenCart
• WooCommerce（WordPress）
• EC-CUBE
• Shopware
• Sylius

これらについても、サービス自体の脆弱性ではなく、動作しているサーバーのPHPが脆弱なバージョンであれば影響を受ける可能性があります。

掲示板・コミュニティ

• Flarum
• phpBB
• MyBB
• XenForo
• SMF（Simple Machines Forum）
• Vanilla Forumsのセルフホスト版

FlarumもPHPで作られており、現在のFlarumはPHP 8.3以降を動作要件としているため、PHPが修正版へ更新されているか確認する必要があります。

PHPフレームワークで作られたWebアプリ

• Laravel
• Symfony
• CodeIgniter
• CakePHP
• Yii
• Slim
• Laminas
• FuelPHP
• Phalcon
• ThinkPHP

LaravelやSymfony自体に今回の脆弱性があるわけではありません。しかし、そのアプリケーションを処理しているPHPが脆弱であれば影響を受ける可能性があります。

ファイル・クラウド・業務ツール

• Nextcloud
• ownCloud
• Roundcube
• phpMyAdmin
• Matomo
• Mautic
• WHMCS
• FreshRSS
• Tiny Tiny RSS
• Piwigo

特にphpMyAdminやRoundcubeなどは管理画面やメールといった重要な情報を扱うため、インターネット上に公開している場合はPHPの更新状況を確認しておくことをおすすめします。

日本で利用されているPHP製品

日本国内では、次のようなPHP製品についても同様に確認が必要です。

• EC-CUBE
• baserCMS
• XOOPS / XOOPS Cube
• OpenPNE
• a-blog cms
• PHPで独自開発されたWebシステム

また、古い社内システムや制作会社が独自開発したWebサイトなど、CMS名が表面に出ていなくてもPHPが使われているケースがあります。

重要なのは「何のCMSを使っているか」よりPHPのバージョン

今回については、「WordPressだから危険」「Flarumだから危険」という意味ではありません。

そのサービスを動かしているPHPが脆弱なバージョンかどうかが重要です。

PHP 8.2・8.3・8.4・8.5を利用している場合は、それぞれ 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12以降へ更新します。

また、レンタルサーバーやマネージドサービスでは、利用者ではなくサービス提供会社がPHPを管理している場合があります。その場合は、自分でPHPを変更するのではなく、提供会社のセキュリティ情報や対応状況を確認してください。

よくある質問

PHPを使っていないサイトも対象ですか？

PHPが動いていなければ、今回の脆弱性の影響は基本的にありません。静的なHTMLだけのサイトや、PHP以外の言語で作られたサイトが該当します。ただし、同じサーバー上でPHPのアプリケーションが動いている場合は注意してください。

すでにハッキングされているか確認する方法は？

修正版を適用する前に攻撃を受けていた場合、PHPを更新しても設置されたWebシェルなどは消えません。アクセスログや不審なPHPファイル、管理者アカウント、cronなどを確認してください。

WAF（Webアプリケーションファイアウォール）で防げますか？

一部の攻撃手法を止める暫定策として役立つ可能性はありますが、根本的な対策ではありません。Cloudflareが暫定ルールを提供したとの報道もありますが、Cloudflare経由のアクセスにしか効きません。必ずPHPを更新してください。

パスワードはすぐ変えるべきですか？

PHPに脆弱性があるというだけで、すべてのサービスのパスワードを一斉に変える必要性は低いと考えられます。利用中のサービスが「侵害された」と発表した場合や、サービスから通知が来た場合は、案内に従って変更してください。パスワードの使い回しをしていないかの見直しは、この機会にしておくと安心です。

今回の脆弱性は、どのくらい危険ですか？

深刻度は最上位の「緊急」クラスです。また、情報が事前に漏れており、公開直後から攻撃が広がる可能性が指摘されています。一方で、修正版が出れば、更新するだけで対処できます。パニックになる必要はありませんが、更新は急いでください。

まとめ

• PHPの重大な脆弱性 CVE-2026-109618 / CVE-2026-109619 の詳細と修正版が正式に公開された
• いずれも認証なしでリモートコード実行（RCE）につながるCriticalの脆弱性
• 修正版は PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35
• WordPress本体の問題ではないため、WordPressやプラグインを更新するだけでは対策できない
• レンタルサーバー利用者はサーバー会社の対応状況を確認し、自分でPHPを管理している場合は速やかに修正版へ更新する
• PHP公式は完全な緩和策はないとしており、PHP本体のアップデートが根本的な対策
• 更新前に攻撃を受けていた可能性もあるため、必要に応じてアクセスログや不審なファイルなども確認する

更新履歴

• 2026年10月21日 20時：初版公開（PHPの修正版公開前の情報）
• 2026年10月21日 23時：PHP公式の修正版公開を受け、影響範囲・修正版・脆弱性の詳細・対策を更新

関連記事

• PHPの脆弱性でWixのサイトは大丈夫？影響の有無と確認すべきことを解説【2026年10月22日時点】
• PHPの脆弱性でShopifyは大丈夫？ストア運営者が確認すべきことを解説