PHP2Shell対策｜独自CMSのPHPバージョンアップ手順

2026年10月21日、PHP本体に重大な脆弱性「PHP2Shell」（CVE-2026-109618／CVE-2026-109619）が公表されました。ログイン不要でサーバー上のプログラムを外部から実行される恐れがあります。

WordPressなら管理画面からPHP対応を確かめられますが、自社や制作会社が作った独自CMSはそうはいきません。「PHPを上げたら画面が真っ白になった」というトラブルも起きやすく、後回しにされがちです。

この記事では、独自CMSを今のサーバーのまま、脆弱性修正が提供されているPHP8.2以上へ上げるための確認事項と手順を、実際の改修でよく直すコードとあわせて解説します。

PHP2Shellとは？独自CMSも対象になる理由

PHP2Shellは、PHP本体に見つかった2件のリモートコード実行（RCE）の脆弱性の通称です。深刻度はCVSS v4.0で9.2と、最上位に近い評価です。問題はアプリ側ではなくPHPそのものにあるため、WordPressでも独自CMSでも、PHPで動くサイトはすべて対象です。

ログイン不要で攻撃され、公表当日から悪用が始まっている

PHP2Shellは、ログインなしで外部から任意のプログラムを実行される恐れがあります。セキュリティ企業watchTowrは、PHPが修正版を出した2026年10月21日には、既に攻撃を観測しています（watchTowr FAQ）。

PHP-FPM、Apacheのmod_php、LiteSpeedなど、WebサーバーとPHPの組み合わせを問わず影響します。PHP公式は「設定変更だけでは完全には防げない」としており、根本対策は修正済みのPHPへの更新です。

古いPHPのままの独自CMSほど危ない

独自CMSは、制作当時のPHPに合わせて作られ、その後は誰も触っていないというケースが多くあります。PHP7.4やそれ以前で動き続けているサイトも珍しくありません。

PHP公式が修正版を出したのは8.2以降だけで、8.1以前は「サポート終了版」です。レンタルサーバー各社が応急的な修正を当てていますが、今後新しい脆弱性が見つかったときも同じ対応があるとは限りません。

＝＝＝

自社サイトが攻撃対象になる前に、まずは脆弱性の影響範囲を把握することが重要です。自社での判断が難しい場合は、サイト引越し屋さんへお気軽にご相談ください。

>>無料ご相談窓口はこちらをクリック

なぜPHP8.2以上なのか。ただし目標は8.3以上がおすすめ

PHP2Shellの公式修正版が出ているのは、PHP8.2、8.3、8.4、8.5の4系統だけです。つまり「公式に守られている状態」に戻すには、PHP8.2以上へ上げる必要があります。

PHPの系統	PHP2Shellの修正版	セキュリティサポート終了
8.5	8.5.12	2029年12月31日
8.4	8.4.27	2028年12月31日
8.3	8.3.36	2027年12月31日
8.2	8.2.35	2026年12月31日
8.1以前	公式リリースなし	終了済み

出典：PHP公式：サポート中のバージョン

注意したいのは、PHP8.2のサポートは2026年12月31日で終わることです。今から8.2へ上げても、約2か月後にはまたサポート外になります。

改修の手間は8.2でも8.3でも大きくは変わらないため、弊社では8.3以上を目標にすることをおすすめしています。共用レンタルサーバーなら、末尾の細かい番号（8.3.36など）はサーバー会社が更新するので、利用者は管理画面で「8.3」などの系統を選ぶだけです。

今のサーバーでバージョンアップする確認事項

独自CMSのPHPバージョンアップは、管理画面で切り替える作業そのものは数分です。時間がかかるのは、切り替えても壊れないかを先に確かめる部分です。次の4点を確認してから進めましょう。

今のPHPバージョンと、サーバーで選べるバージョン

まず、サーバーの管理画面で今のPHPバージョンを確認します。ドメインやディレクトリごとに別のバージョンが設定できるサーバーも多いので、独自CMSが置かれた場所の設定を見るのが大事です。

あわせて、そのサーバーでPHP8.3以上が選べるかも見ておきます。古いプランや古いサーバーでは、新しいPHPが選択肢にないことがあります。その場合は、今のサーバーのままのバージョンアップはできないので、後半の「バージョンアップが難しい場合」をご覧ください。

CMSのソースコードと、直せる人がいるか

独自CMSは、動かなくなったときにプログラムを直す必要があります。制作会社と連絡が取れるか、社内に中身が分かる人がいるかを確かめましょう。

ionCubeなどで暗号化されたファイルが含まれていると、その部分は開発元しか直せません。ファイルの先頭に「ionCube」「Zend Guard」などの文字がないかを確認しておきます。

テストできる環境を用意できるか

本番のPHPをいきなり切り替えるのは避けましょう。サブドメインや別ディレクトリにサイトとデータベースを複製し、そこだけPHPを上げて動作を見るのが安全です。

ディレクトリごとにPHPを変えられないサーバーでは、本番サーバーとは別でテスト用のサーバーに検証環境を作ります。

バックアップと、元に戻す手順

作業前に、ファイル一式とデータベースの両方をバックアップします。あわせて、不具合が出たら「管理画面で元のPHPに戻す」という手順を決めておきましょう。ただし、元のPHPに戻すのはあくまで一時しのぎです。古いPHPのままにしておく期間は、できるだけ短くしましょう。

＝＝＝

独自CMSは仕様書がないケースや過去の開発者不在が多く、不用意な更新はサイト停止に直結します。安全な互換性調査から改修まで、プロのエンジニアが丸ごとサポートします。

>>無料ご相談窓口はこちらをクリック

独自CMSのPHPバージョンアップ手順

作業は「検証環境で直す → 本番へ反映する → 本番で確認する」の順で進めます。PHPを一気に最新版へ上げても構いませんが、エラーが多い場合は7.4→8.0→8.3のように段階を分けると原因を絞りやすくなります。

1. 検証環境を作ってPHPを上げる
2. エラーを表示させて全画面を確認する
3. エラーが出た箇所を直す
4. 本番へ反映してPHPを切り替える
5. 切り替え後1〜2週間はエラーログを見る

STEP1 検証環境を作ってPHPを上げる

本番のファイルとデータベースを検証環境へ複製し、設定ファイルの接続先やURLを検証用に書き換えます。そのうえで、検証環境のPHPだけを目標バージョンに切り替えます。
検証環境が検索エンジンに拾われないよう、Basic認証をかけておきましょう。

STEP2 エラーを表示させて全画面を確認する

検証環境ではエラーログを有効にし、画面が真っ白になったときの原因が分かるようにします。トップページだけでなく、次のような「動き」のある画面を一つずつ確かめます。

• 管理画面へのログイン、記事の登録・編集・削除
• 画像やファイルのアップロード
• 問い合わせフォームの送信と、自動返信メール
• 検索、一覧のページ送り、CSV出力などの機能
• cron（定期実行）で動いている処理

STEP3 エラーが出た箇所を直す

エラーログには、ファイル名と行番号が出ます。これをもとに、PHP8で使えなくなった書き方を一つずつ直していきます。

効率の良いチェック方法としては、独自CMSに対しPHPCompatibilityを用いることです。

PHP 8.3基準の検証を実施し。検出された互換性エラー・警告のなかから内訳は、mysql_* 関連の関数呼び出し、配列アクセス構文 {} 、動的プロパティ代入のように、静的解析ツールを併用することで目視チェックに比べ調査工数を短縮できます。

エラーが出ないことと、正しく動いていることは別です。金額の計算や日付の表示など、結果が正しいかも本番と見比べて確認しましょう。

STEP4 本番へ反映してPHPを切り替える

修正済みのプログラムを本番へ反映し、管理画面でPHPバージョンを切り替えます。アクセスが少ない時間帯に行い、すぐに②の項目を本番でも確認します。

STEP5 切り替え後1〜2週間はエラーログを見る

月末だけ動く集計や、まれにしか使われない画面は、切り替え当日には確認しきれません。しばらくはエラーログを定期的に確認し、新しいエラーが出ていないかを見ましょう。

＝＝＝

本番環境での直接更新は重大な障害リスクを伴います。テスト環境の構築やバックアップ作業に不安がある方は、サイト引越し屋さんの代行サービスをご検討ください。

>>無料ご相談窓口はこちらをクリック

PHP8系で動かなくなる典型的なコード

古い独自CMSをPHP8系へ上げるとき、つまずく箇所はある程度決まっています。エラーログに出た関数名を、下の表と照らし合わせてみてください。

古い書き方	使えなくなったバージョン	直し方
mysql_connect() など mysql_ 系関数	7.0で削除	mysqli か PDO に書き換える
ereg() split()	7.0で削除	preg_match() preg_split() に書き換える
each()	8.0で削除	foreach に書き換える
create_function()	8.0で削除	無名関数 function() {} にする
クラス名と同じ名前のコンストラクタ	8.0でコンストラクタ扱いされなくなる	__construct() に名前を変える
$str{0} の文字取り出し	8.0で削除	$str[0] にする
配列でない値への count()	8.0で致命的エラーになる	事前に is_array() で確かめる
動的プロパティの生成（未宣言プロパティへの代入）	8.2で非推奨（E_DEPRECATED警告）、将来的にFatal Error	クラス内で明示的にプロパティを定義するか、クラス定義の直前に #[AllowDynamicProperties] 属性を付与して一時抑止する

出典：PHP公式マニュアル：PHP 7.4.x から PHP 8.0.x への移行

PHP5系から上げる場合は、作り直しに近いこともある

PHP5系で作られたCMSは、mysql_ 系関数でデータベースを扱っていることがほとんどです。この場合、データベースを扱う処理をすべて書き換えることになり、改修の量が一気に増えます。

改修費用が作り直しと変わらないなら、WordPressへの移行も選択肢に入ります。先に修正が必要な箇所の数を洗い出してから、どちらが安いかを比べましょう。

警告が画面に出ていないかも確認する

PHP8系では、存在しない配列のキーを読んだときなどに出る「警告」が増えました。本番でこの警告が画面に表示されると、ファイルの場所などの内部情報が訪問者に見えてしまいます。

本番ではエラーを画面に表示せず、ログだけに記録する設定にしておきましょう。

＝＝＝

非推奨関数の影響やプラグイン・モジュールの競合など、予期せぬエラーの特定には専門知識が不可欠です。万が一のトラブル時も、サイト引越し屋さんなら迅速に復旧・対応可能です。

>>無料ご相談窓口はこちらをクリック

今のサーバーではバージョンアップが難しい場合の選択肢

次のような場合は、今のサーバーのままPHPを上げるのは現実的ではありません。

• 契約中のサーバーでPHP8.2以上を選べない
• 制作会社と連絡が取れず、プログラムを直せる人がいない
• 改修が大きく、今すぐには終わらない

古いPHPに修正を当てているサーバーへ移転する

今回のPHP2Shellでは、一部のレンタルサーバーが、サポート終了した古いPHPにも独自の修正を当てました。こうしたサーバーへ移れば、PHPを上げずに今回の脆弱性を回避できます。

詳しい手順は「【PHP2Shell対策】独自CMSをPHPそのままでサーバー移転する方法」で解説しています。ただし、これは時間を稼ぐための対策です。移転後も、PHP8.3以上への改修は計画しておきましょう。

WordPressへ作り直す

改修費用がかさむ場合や、独自CMSを保守できる人がいない場合は、WordPressへの移行も検討しましょう。WordPressなら、本体やプラグインの更新で新しいPHPへ追従しやすくなります。

参考までに、弊社が以前調査したPHP5.6の独自ネットショップでは、CGIとPHPが混在していたため、PHPバージョンアップは「極めて困難」と判断しました。

一方でWordPressへ作り直すと、商品点数も多く費用が掛かることに加え、セキュリティ的な観点からの保守費もかかることを考慮し、EC部分のみBASEに移行することなりました。

PHP2Shell公表後に弊社へ届いた相談と対応例

PHP2Shellが公表された2026年10月21日からの3日間だけでも、弊社にはPHPに関する相談が15件以上届きました。その中から、独自CMSのPHPバージョンアップを考えるうえで参考になる例を紹介します。

※掲載している事例は、プライバシー保護およびセキュリティ配慮のため、一部の構成や数値を一般化・マスキングして記載しています。

事例① PHP5.6で動く独自PHPサイト。サーバー側の修正だけでは安心できない

WordPressを使わず、PHPで作られたサイトを運営しているお客さまからのご相談です。エックスサーバー上で、PHPは5.6.40でした。

お客さまは、エックスサーバーが「5.6まで修正を当てた」と発表したのを見て安心していました。しかし、PHP公式の修正は8.2以上だけで、8.1以前への修正はサーバー会社が独自に調整したものです。その精度は外からは分からず、既知の別の脆弱性も残っています。

そこで弊社は、次の2つをご提案しました。

1. 本番で試しにPHP8.2以上へ切り替え、大きな表示エラーが出たらすぐ元に戻す
2. 検証用サイトを作り、エラーを直しながらバージョンアップする（修正箇所を確認してからお見積もり）

お客さまは「8.2への移行は必須と捉えている」として、まず①で影響を確かめ、必要なら②へ進む方針になりました。①は「戻せること」が前提なので、先に戻し方を確認しておくことが大切です。

事例② 本番でPHPを上げたら「重大なエラー」、しかも元に戻せない

PHP2Shellのニュースを見て、ご自身でサーバーの管理画面からPHPを上げた方からのご相談です。変更した直後、サイトに「このサイトで重大なエラーが発生しました。」と表示され、閲覧できなくなりました。

弊社でサーバーの設定を変更して表示を元に戻し、そのうえで本体・プラグイン・PHPをまとめて更新する流れになりました。

この例はWordPressですが、独自CMSでも起きることは同じです。「本番でいきなり切り替えない」「戻し方を先に確かめる」の2点は必ず守りましょう。

事例③ サーバーの管理画面が止まり、作業が予定どおり進まない

保守契約中のお客さまには、弊社からPHP8.3への更新を進めました。ただし公表直後は、サーバー管理画面が予防的に管理画面を止めたため、「当日23時までに完了」とお伝えしていた作業が翌日深夜までかかりました。

管理画面が再開した後もアクセスが集中し、設定変更ができない時間帯が続きました。大きな脆弱性が出てから動くと、こうした混雑に巻き込まれます。平時のうちに8.3以上へ上げておくことが、いちばんの対策です。

費用の目安

弊社のスポット対応（単発作業）では、WordPressの場合の目安を次のようにご案内しています。

作業	費用（税別）
PHPバージョンアップ	15,000円
テスト環境の構築・差分データ調整・本番公開	30,000円
特急対応	10,000円

独自CMSは作りがサイトごとに違うため、修正が必要な箇所を調査したうえでお見積もりします。

まとめ

PHP2Shellは、PHPで動くすべてのサイトが対象になる重大な脆弱性です。公式の修正版があるのはPHP8.2以上だけで、独自CMSもそこまで上げるのが根本的な対策です。8.2のサポートは2026年末で終わるため、目標は8.3以上がおすすめです。

作業で大事なのは、本番のPHPをいきなり切り替えないことです。検証環境でエラーを洗い出して直し、本番に反映したらしばらくエラーログを見守りましょう。

「うちのCMSはどのくらい直しが必要か」「バージョンアップと移転のどちらがいいか」で迷ったら、サイト引越し屋さんにご相談ください。事前調査で修正箇所を洗い出し、費用と期間の目安をお伝えします。