PHP脆弱性の対策まとめ｜今すぐやる順番

自分が契約している、または管理を任されているサーバーだけを確認してください。当サイトは独立した個人運営のサイトで、PHP Group・php.netとは無関係です。サイトやサーバーへアクセスして検査することはありません。

先に結論

対策の本筋は、サーバー側のPHPを修正版に更新することです。PHP公式は、更新だけが完全な解決策で、ほかの対策は特定の攻撃経路へのリスクを減らすにとどまるとしています（php.net 公式告知、2026年10月22日確認）。日本のJPCERT/CCも、緩和策は特定の攻撃経路への対処にとどまり、アップデートのみが対策だとしています（JPCERT/CC 注意喚起、2026年10月22日確認）。
今回の脆弱性は、CVE-2026-109618 と CVE-2026-109619 の2件（通称 php2shell）です。PHP公式の修正版は PHP 8.2.35・8.3.36・8.4.27・8.5.12 です。7.4・8.0・8.1 には、番号の付いた修正版のリリースはなく、ソースのブランチ（最小限の移植）だけが公開されています。7.3 以前については、php.net は移植版にも触れていません。
順番は「PHPの出どころを調べる → バージョンを確認する → 更新する（または会社の対応を待つ）→ 再起動する → 確認し直す」です。WAF（不正な通信を止める仕組み）やアクセス制限は、更新までのつなぎであって、修正の代わりにはなりません。

サイトを見るだけの人（閲覧者）向けの行動指針は、このページの対象外です。このページは、サイトやサーバーを運営している人向けです。

今日やることの順番

1. PHPがどこから来ているかを調べる

自分のサイトのPHPを誰が更新するのかで、やることが変わります。まず次の表で自分の環境を見分けてください。

あなたの環境	PHPを更新するのは	次に読むページ
レンタルサーバー（共用サーバー）	基本的にサーバー会社。ただし管理画面で選んだPHPの系統によっては自分で切り替えることもある	レンタルサーバーの対応まとめ
WordPress（上記のレンタルサーバー上が多い）	PHP本体はサーバー側。WordPress本体やプラグインの更新では直らない	WordPress編
制作会社・保守会社に任せているサイト	契約先の会社	「PHPのバージョンと、php2shell対応の状況」を問い合わせる
VPS・クラウド・自前サーバー	自分（OSのパッケージ更新）	UbuntuとDebian編、修正版バージョン一覧
Dockerなどのコンテナ	自分（イメージのビルドし直し）	下の「Dockerの場合」

「ホームページはあるがPHPが何か分からない」という場合は、php2shell の解説の冒頭から読むのが近道です。

2. バージョンを確認し、チェッカーで照合する

PHPのバージョンは、レンタルサーバーなら管理画面、WordPressならサイトヘルス、サーバーにログインできるなら php -v で分かります。調べ方はPHPバージョンの確認方法にまとめています。見つけた番号はチェッカーに入力すると、本サイトのデータ（公式発表から作成）と、ブラウザの中だけで照らし合わせます。

ここで1点だけ注意があります。番号が古く見えても、修正済みの場合があります。 会社によっては、修正を適用してもバージョン番号を変えないためです。mixhostは、修正後もサイトヘルスやphpinfoの番号は変わらないと案内しています（mixhostのお知らせ、2026年10月22日確認）。UbuntuやDebianなどの配布パッケージも、本家の番号ではなく、配布元が出したパッケージ番号で比べます。レンタルサーバーでは、番号だけで判断せず、契約している会社の発表で確認してください。

3. 更新する、または会社の対応を待つ

レンタルサーバーの場合

多くの会社が10月22日に、会社側での適用を発表しています。まず契約先の発表を読み、自分のPHPの系統とプランが対象に入っているかを確認してください。最新の状況はホスティング状況ページにまとめています。たとえばさくらインターネットは、コントロールパネルから選べるすべてのPHPバージョンで対応を完了したとし、利用者が緊急で行う対応はないと案内しています（さくらインターネットのお知らせ、2026年10月22日確認）。

管理画面で古いPHPの系統（7.4・8.0・8.1、またはそれ以前の7.3以下）を選んでいる場合は、とくに会社の発表を読んでください。たとえばエックスサーバーは、PHP 5.6〜8.5は適用が完了したが、5.5以下は修正パッチの作成・検証を続けているとしています（エックスサーバー公式X、2026年10月22日確認）。

【目安】本サイトの案内であり、会社の指示ではありません。サポートが終わった系統を使い続けないよう、バックアップを取ってから、サポート期間中の最新版への切り替えも検討してください。会社が切り替え不要と案内している場合は、その案内を優先します。

PHPバージョンを確認・変更する画面は会社ごとに違います。主な会社の入口だけを、各社の公式ヘルプから抜き出しました。細かい手順と注意点は、各社のページを見てください。

会社	確認・変更する画面	出典（確認日）
さくらのレンタルサーバ	サーバーコントロールパネル →「スクリプト設定」→「言語バージョン設定」。ログインはドメイン／パスワードです	さくらのヘルプ（2026年10月22日）。詳しくはさくら編
ConoHa WING	コントロールパネル →「WING」→「サイト管理」→「サイト設定」→「応用設定」→「PHP設定」（ドメインごと）。ただしConoHaは、利用者ご自身でPHPバージョンを変更する必要はないとしており、切り替えは求められていません	ConoHaのヘルプ、ConoHaのお知らせ（いずれも2026年10月22日）。詳しくはConoHa WING編
エックスサーバー	サーバーパネル →「PHP Ver.切替」→ ドメインを選んで変更	エックスサーバーのマニュアル。10月22日は公式ページが予防的メンテナンス中で開けず再確認できなかったため、2026年9月30日の保存版によります。詳しくはエックスサーバー編
ロリポップ！	ユーザー専用ページ →「サーバーの管理・設定」→「PHP設定」（ドメインごと）。反映に時間がかかることや、元に戻せない場合があることは、ロリポップ！編に書いています	ロリポップ！のマニュアル。公式ページを直接開けなかったため、2026年7月31日の保存版によります。詳しくはロリポップ！編

どの会社でも、PHPのバージョンを変えるとアプリケーションが動かなくなることがあります。変更前にバックアップを取り、変更後はサイトの表示や投稿などの動作を確認してください。たとえばさくらのヘルプには、不具合があれば古いバージョンを選び直して元の環境に戻せると書かれています。

VPS・自前サーバーの場合

ふだん使っている更新手段で、PHPのパッケージを更新します。Ubuntu・Debian・RHEL系は、配布元が出した修正版のパッケージ番号と比べるのが確実です。具体的な番号と手順はUbuntuとDebian編と修正版バージョン一覧にあります。Ubuntuの公式通知（USN-8948-1、2026年10月22日確認）が示す更新手順は、「通常のシステムアップデートで必要な変更が行われる」というものです。

Dockerの場合

docker pull だけでは、すでに動いているコンテナは入れ替わりません。PHP公式イメージでタグに使われている番号は、本家のバージョン番号です。修正版のタグ（8.4.27 など）が公開されていることを確認して、Dockerfileのベースイメージの指定を変え、イメージをビルドし直し、コンテナを作り直します。docker compose で動かしているなら、作り直しに --force-recreate を付けます（Docker公式リファレンス、2026年10月22日確認）。コマンドの例と確認のしかたは、php2shellの解説にあります。タグごとの状況は、英語のみですがDockerイメージ編にまとめています。

WordPressの場合

今回の問題はWordPress本体ではなくPHPにあります。WordPress・テーマ・プラグインを最新にしても直りません。PHPのバージョンは、管理画面の「ツール」→「サイトヘルス」→「情報」タブ →「サーバー」で確認できます（WordPress.org 日本語版の案内、2026年10月22日確認）。PHPの更新は、サーバー側で行います。更新前にサイトのバックアップを取ってください。WordPress.orgの案内によると、バックアップに戻すときは、ホストのPHPのバージョンも元に戻す必要があります。更新後にうまく動かないときは、PHPのバージョンを戻すか、サーバー会社や詳しい人に相談してください。詳しい手順はWordPress編です。

PHP 7.4・8.0・8.1、または7.3以前を使っている場合

7.4・8.0・8.1には、PHPプロジェクトからの番号の付いたリリース版はなく、ソースのブランチ（ソースからビルドする人向けの、最小限の移植）だけが公開されています（php.net 公式告知、2026年10月22日確認）。番号だけで「修正済み」とは言えないため、判断の仕方は7.4・8.0・8.1の解説を見てください。7.3以前については、php.netは移植版にも触れていません。使っている場合は、提供元（OSやレンタルサーバーの会社）の発表を確認するか、サポートされている版へ移ってください。

4. 再起動する

ここは、公式の指示というより、本サイトのガイドで案内している手順です。php.netが再起動に触れているのは、後述の暫定策（設定の変更）のときだけです。更新しても、すでに動いているPHPのプロセスが新しい版に入れ替わるとは限らないため、VPSや自前サーバーでは、更新のあとにPHP-FPM（Apacheのmod_phpならApache）を再起動することをおすすめします。具体的なコマンドはUbuntuとDebian編にあります。レンタルサーバーでは、再起動の手順は本サイトでは案内していません。会社の発表に従ってください。Dockerでは、上のようにコンテナを作り直します。

5. 確認し直す

PHPのバージョン（またはパッケージの番号）を、もう一度チェッカーで照合します。レンタルサーバーで番号が変わらない会社の場合は、会社の完了発表を確認します。
サイトのトップページ、記事ページ、問い合わせフォーム、WordPressのログイン画面が、普通に表示されるかを見ます。
念のため、不審なファイルの作成や、心当たりのない外部への通信がないかも確認します。JPCERT/CCは、修正版へ更新するとともに、侵害を示す痕跡の確認と継続的な監視を求めています。痕跡が見つからなくても、攻撃を受けていないとは断定できないとしています。侵害が疑われるときは、関連するログを保全したうえで、影響範囲の調査や、該当システムの隔離を行ってください（JPCERT/CC 注意喚起、2026年10月22日確認。確認項目の詳細はそちらをご覧ください）。

WAFだけに頼らない：緩和策は修正ではありません

WAFやアクセス制限は「今すぐ更新できないとき」のつなぎとして使えますが、修正の代わりにはなりません。

PHP公式は、更新以外の対策は特定の攻撃経路へのリスクを減らすだけで、環境を直したことにはならないとしています。
WAFを提供しているCloudflareも、WAFで守られていても、PHPの修正を適用するよう求めています。WAFは追加の防御層として有効にしたままにしつつ、ベンダーの更新を適用することをすすめています（Cloudflareのブログ、2026年10月22日確認）。アップロードを制限したり、サイズを小さくしたりしても、PHPの修正の代わりにはならないとも述べています。
さらに、Patchstackは、Cloudflareはこの対応をつなぎにすぎないとしており、ルールが効くのは、サーバーがCloudflare経由の通信だけを受けている場合に限ると伝えています（Patchstackの記事、2026年10月22日確認）。

自分でサーバーを管理していて、すぐには更新できない場合、PHP公式は、設定の変更や、Webサーバー・コンテナ側の制限など、複数の暫定策を公式告知に一覧にしています。具体的な設定と手順は、攻撃の詳細に近いためここには書かず、公式告知をご覧ください（php.net 公式告知、2026年10月22日確認）。どれも特定の攻撃経路へのリスクを減らすだけで、更新の代わりにはなりません。

レンタルサーバーで会社の対応が間に合っていない場合は、会社の案内を優先してください。たとえばKAGOYAは、マネージド専用サーバー・共用サーバー・WordPress専用サーバーの各プランについて、恒久的な対応を調整中として、暫定的なリスク低減策に、サイトの公開停止（メンテナンス画面への切り替え）やアクセス制限を検討するよう案内しています。レンタルサーバープランについては、修正版へのアップデートを順次進めており、10月22日24時の完了を見込むとしています（完了したとは書かれていません。KAGOYAのお知らせ、2026年10月22日確認）。データ上の記録は次のとおりです。最終確認日は 2026-10-22 です。

事業者	状態	利用者の対応	情報源	確認
KAGOYA レンタルサーバー (カゴヤ・ジャパン)共有サーバー / 日本	順次対応中	KAGOYAは、CVE-2026-109618 / CVE-2026-109619を名指しした案内（10月22日の最新更新、ページ更新18:48）で、レンタルサーバープラン（PHP 7.4系、8.1系、8.2系、8.3系、8.4系、8.5系）については修正版へのアップデートを順次進めており、10月22日24時の完了を見込んでいるとしています。マネージド専用サーバー・共用サーバー・WordPress専用サーバーの各プランについては、恒久的な対応の方針を引き続き調整中とし、暫定的なリスク低減策として、Webサイトの公開停止（メンテナンス画面への切り替え）やアクセス制限などの検討を求めています。当サイトの案内: レンタルサーバープランについては、KAGOYAがすでにアップデートを進めているため、完了を待ち、同じお知らせのページで続報を確認してください。マネージド専用サーバー・共用サーバー・WordPress専用サーバーの各プランについては、Webサイトの公開停止やアクセス制限などの暫定策を挙げています（お知らせに.htaccessの記載例があります）。	情報源	2026-10-22 23:17 UTC

PHP脆弱性（php2shell）の対策まとめ：サイト運営者が今すぐやること