PHP 7.4・8.1以前は修正版なし｜PHP2Shell脆弱性の対処

2026年10月21日に公開されたPHPの重大な脆弱性、通称「PHP2Shell」。修正版はPHP 8.2〜8.5向けにしか出ていません。この記事では、何年も前に作ったホームページを PHP 7.4 や 8.0・8.1 のまま動かしている会社が、何をどの順で進めればよいかを整理します。情報は2026年10月22日時点のものです。

結論：PHP 8.1以前に修正版は出ない。選べる道は3つ

PHP 8.1以前（7.4・8.0・8.1、それより古い版も含む）には、PHPの開発元から修正版が出ません。PHP公式のお知らせは、8.1以前は「PHPプロジェクトの更新対象外」と明記しています。修正済みの版は PHP 8.5.12・8.4.27・8.3.36・8.2.35 の4つだけです（PHP公式のセキュリティアドバイザリ）。

ただし、共用のレンタルサーバーは事情が違います。開発元が出した最小限のパッチを事業者が組み込み、古い版にも修正を当てている場合があるためです（さくら・XREA・コアサーバー・ConoHa WINGは古い版にも修正を当て、版の変更は不要と公表。hetemlも7.4に修正済み）。共用サーバーなら、まず事業者のお知らせで、自分が使っている版に修正が当たっているかを確かめてください。各社の状況はレンタルサーバー各社の対応まとめで整理しています。当たっていなければ、応急処置を頼むか、バックアップを取って試したうえで8.3以上へ切り替えます。当たっていても8.1以前は開発元のサポートが終わっているので、次の脆弱性に備えて、下の道のどれかへ進む計画は立ててください。

この脆弱性は、ログインなしで外からサーバー上のプログラムを動かされるおそれがあるものです。PHP2Shellの全体像はPHP2Shellとは何か・まずやることのまとめで解説しています。古いPHPのサイトが選べる道は、次の3つです。

1. PHPを8.3以上へ上げる（いちばん確実。8.2は2026年12月31日でサポートが終わるので、上げるなら8.3以上が無難）
2. 古い版のまま、OS配布元などが用意した修正済みのPHPを入れる（自社でサーバーを管理している場合の選択肢。共用サーバーで事業者が古い版に修正を当てた場合も、これにあたります）
3. サイトを作り直す・別の仕組みへ移す（古いWordPressや独自プログラムで、版を上げると壊れる場合）

どれもすぐには終わらない場合は、まず今夜できる応急処置で攻撃の入口を狭めます。ただし、PHP公式も「完全な対策は更新だけ」としています。応急処置は時間を稼ぐためのもので、これで安全になるわけではありません。

まず自分のサイトのPHPバージョンを確かめる

最初に、自分のサイトが何番のPHPで動いているかを確かめます。版によってやることが変わるためです。

レンタルサーバーの管理画面で見る

レンタルサーバーを使っているなら、契約者向けの管理画面に「PHPバージョン設定」のような項目があり、ドメインごとの版を確認・変更できます。ログイン情報が分からない場合は、請求書やサーバー会社からのメールで契約者名と会員IDを確認し、サーバー会社に問い合わせるのが近道です。サーバー会社ごとの対応状況はレンタルサーバー各社のPHP脆弱性への対応にまとめています。

WordPressなら管理画面でも分かる

WordPressのサイトなら、管理画面の「ツール」→「サイトヘルス」→「情報」タブにある「サーバー」の欄に、PHPのバージョンが表示されます。管理画面に入れるなら、これがいちばん手軽です。

phpinfo のファイルは公開したままにしない

PHPのバージョンを調べる方法として、phpinfo() を書いたファイルをサーバーに置く手順がよく紹介されています。確認には使えますが、このページにはサーバーの設定やファイルの場所などが細かく表示されます。攻撃する側にとっても手がかりになるので、置いたら確認後すぐに削除してください。ファイル名を推測しやすいもの（info.php など）にしないことも大切です。

制作会社に聞くときの文面例

制作会社に管理を任せている場合は、次のように聞くと話が早く進みます。

お世話になっております。PHPの脆弱性（PHP2Shell、CVE-2026-109618・109619）の件でご連絡しました。弊社サイトについて、次の3点を教えてください。

1. いま動いているPHPのバージョン

2. 修正版（8.2.35・8.3.36・8.4.27・8.5.12）への更新、または8.3以上への切り替えの予定と時期

3. 切り替えるとWordPressやプラグイン、独自のプログラムが動かなくなるおそれがあるか

サーバーの管理画面に入れる情報（契約者名・ログインID）が弊社に無い場合は、あわせて教えてください。

制作会社と連絡がつかない場合でも、サーバーの契約者が自社であれば、サーバー会社に直接相談できます。契約者が制作会社の名義になっていると手続きが難しくなるので、名義もこの機会に確かめておきましょう。

PHPのバージョン別：修正の有無とサポート状況

2026年10月22日時点の状況を、版ごとにまとめました。「公式サポート」は、PHPの開発元がセキュリティの修正を出す期間です（php.net のサポート中バージョン一覧・サポート終了バージョン一覧）。

7.4・8.0・8.1向けの「最小限のパッチ」は、PHPをソースコードから自分で組み立てている人向けのものです。レンタルサーバーの利用者がそのまま使えるものではありません。ただし、サーバー会社がこのパッチを組み込み、古い版に修正を当てている場合があります（冒頭の結論を参照）。また、セキュリティ企業のWizによれば、PHP 5.4以降のほぼすべての版が少なくとも1件の影響を受けます。「古いから関係ない」ということはありません。

「8.2に上げて終わり」ではない

PHP 8.2は、2026年12月31日で公式サポートが終わります。その後に新しい脆弱性が見つかっても、修正は出ません。いま8.2へ上げても、2か月あまりで同じ問題に戻ります。上げるなら8.3以上（8.3は2027年末、8.4は2028年末までサポート）を選んでください。WordPressも公式の動作環境で「PHP 8.3以上」を推奨しています（WordPress の動作環境）。

PHPのバージョンアップができない理由と対処

「PHPを上げればいいのは分かるけれど、上げられない」という相談は、実務でもよく受けます。理由はおおむね次の3つです。

古いWordPress・テーマ・プラグイン

WordPress本体を何年も更新していないと、新しいPHPで動かないことがあります。本体より厄介なのはテーマとプラグインです。PHP 8では古い書き方の一部が使えなくなったため、更新が止まったプラグインや、制作会社が作り込んだテーマが原因で、画面が真っ白になったりエラーが出たりします。WordPress本体 → プラグイン → テーマの順に最新へ更新してから、PHPを上げるのが基本です。更新が止まったプラグインは、代わりのプラグインを探すか、外せるかを確かめます。

独自に作り込んだPHPプログラム

問い合わせフォームや予約、会員ページなどをPHPで一から作っている場合、新しいPHPに合わせた書き直しが必要になることがあります。直す量はプログラム次第なので、中身を見られる技術者に見積もってもらうことになります。作った会社と連絡がつかないときは、別の会社に調査から依頼できます。

EC-CUBEなどのパッケージ

EC-CUBEのようなネットショップの仕組みは、パッケージ自体の版ごとに動くPHPの版が決まっています。PHPだけ上げることはできないので、パッケージの公式サイトで動作環境を確かめ、パッケージごと上げる計画を立てます。お金や個人情報を扱うサイトは、自力で進めずに専門家へ相談するのが安全です。

安全に切り替える手順

いきなり本番のサイトで版を切り替えると、表示が崩れたまま気づかないことがあります。次の順で進めてください。

1. バックアップを取る：サイトのファイルと、データベース（記事やお問い合わせが入っている箱）の両方。サーバー会社の自動バックアップがあっても、手元にも1つ残します
2. テスト環境（ステージング）を用意する：本番の複製を別のURLで動かせる機能を持つレンタルサーバーもあります。無ければ、サブドメインに複製を作ります
3. テスト環境で8.3以上へ切り替える
4. 動きを確かめる：トップページ、主要なページ、問い合わせフォームの送信とメールの受信、管理画面へのログイン、ネットショップならカートと決済の手前まで
5. 本番を切り替えて、同じ確認をする：問題が出たら元の版に戻せるよう、戻し方を先に確かめておきます

元の古い版に戻すと、PHP2Shellの危険も元に戻ります。戻すのは原因を調べるあいだだけにして、その間は次の応急処置を組み合わせてください。

上げられないときの応急処置（今夜できること）

PHP公式は、すぐに更新できない場合の暫定策を示しています。どれも「特定の攻撃経路を減らす」だけで、サイトを安全にするものではありません。また、多くはサーバーの設定ファイル（php.ini など）を直接変える必要があります。共用のレンタルサーバーでは変えられない項目もあるので、サーバー会社か制作会社に頼むことになります。

効果があるとされる設定

• session.upload_progress.enabled=0：php.ini か、PHPの動作単位（FPMプール）の設定で変え、PHPの処理を全部再起動します。プログラム内の ini_set() や、.user.ini での指定では効きません
• post_max_size を小さくする：ファイルのアップロードが要らないサイトは8M、必要なら32M。upload_max_filesize はそれより小さく
• memory_limit=-1：アプリ側から上書きできない形（FPMプールの php_admin_value など）で設定し、有限の上限に戻す設定が残っていないかも確かめます。それでも、より下の層でメモリの確保に失敗すると脆弱な処理にまだ届くため、完全には塞げません。また、1つのアクセスがサーバーのメモリを使い切るおそれがあるので、コンテナや cgroup のメモリ上限で、問題のワーカーだけが止まるようにします。RLIMIT_AS／RLIMIT_DATA（ulimit -v など）は逆に引き金になるので使いません
• WAF（不正なアクセスを遮る仕組み）を入れる：Cloudflare は無料プランを含む全プランに対策ルールを出しています。ほかにも多くのWAFが対応済みですが、どれも補助的な対策です
• 静的なメンテナンス画面に切り替える：PHPを通さないHTMLだけの画面に切り替えます。WordPressなどのアプリが持つ「メンテナンスモード」は効きません。アプリより先に、PHPが届いたデータを読み込んでしまうためです

効かないこと・逆効果なこと

応急処置で稼いだ時間は、バージョンアップか作り直しの段取りに使ってください。更新が済んだら、念のため更新後に確認したい攻撃の痕跡とパスワードの入れ替えも進めます。セキュリティ企業のSansecは、この脆弱性でサーバーのメモリにあるパスワードなどが外へ漏れうると報告しているためです。

作り直しを検討する目安

古いPHPから上げるのにかかる手間が大きい場合、作り直したほうが早く、安くつくこともあります。判断の目安を表にしました。

作り直すときは、次に何年も放置しても困りにくい仕組みを選ぶのが大切です。更新のしやすさと保守の手間の違いはWordPressとNext.jsの比較記事で詳しく比べています。Mihataでも、古いサイトを今の環境へ移すホームページのリニューアルをお手伝いしています。

記事の途中で恐縮ですが、私たちはホームページの制作と作り直しも行っております。「PHPを上げられないので、この機会に作り直したい」というご相談も承っておりますので、よろしければあわせてご覧いただけたら嬉しいです。

今日・今週・年内にやること

2026年10月22日時点では、Cloudflare などが実際の攻撃を観測しており、攻撃手順を示すコードも公開されています。慌てる必要はありませんが、後回しにはしないでください。

• 今日：自分のサイトのPHPの版を確かめる。8.1以前で共用サーバーなら、まず事業者のお知らせで、使っている版に修正が当たっているかを確かめる（レンタルサーバー各社の対応まとめ）。当たっていない場合や自社で管理するサーバーなら、制作会社かサーバー会社に連絡し、応急処置（WAF・設定変更・静的なメンテナンス画面）を頼む
• 今週：バックアップを取り、テスト環境で8.3以上への切り替えを試す。動かない部分を洗い出す
• 年内：本番を8.3以上へ。8.2に上げた場合も、12月31日のサポート終了までに8.3以上へ

PHPに限らず、古いサイトを安全に使い続けるための基本は中小企業のホームページのセキュリティ対策の基本にまとめています。