PHP脆弱性の対処ガイド：確認からPHP卒業まで

PHPの脆弱性、何から手をつければよいのか？

確認、更新、応急処置、侵入の点検。この4つのステップを順番にやれば大丈夫です。4か国の資料は、言い方こそ違っても同じ順番を勧めています。

近所で空き巣が出ていると聞いたとしましょう。まず、わが家の鍵がどんなものかを見ます。弱い鍵なら新しいものに替えます。替えるまでは、かんぬきを掛けておきます。そして、もう誰かが入っていないか家の中を見て回ります。PHPへの対処も、これとまったく同じです。

1. 確認：Webで実際に使っているPHPのバージョンと、サーバーを管理しているのは誰か
2. 更新：修正版（8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 以降）に上げ、必ず再起動
3. 応急処置：すぐに上げられないなら、PHPの設定ファイル（php.ini）とWAF（Webアプリケーションファイアウォール）で時間を稼ぐ
4. 侵入の点検：直す前に入られた跡がないかを見て、パスワードまで替える
5. 根本解決：会社紹介のサイトなら、PHPを使わない形も検討

共用レンタルサーバー（1台のサーバーを複数の会社で分け合う借りものサーバー）なら、ステップ2は多くのサーバー会社が代わりに済ませたと公表しています。入居者がビルのボイラーを自分で直さないのと同じです。まず、契約しているサーバー会社のお知らせを確かめるのが第一歩です。

上から一つずつで大丈夫です。

直す方法は更新ひとつだけ。ほかはすべて、時間を稼ぐための手段です。

PHPの公式発表も、一時的な設定は特定の攻撃経路を減らすだけで、環境を安全にするものではないと明言しています。¹

ヤンのまとめ順番があれば、あわてることはありません。ただし、鍵を替えるステップ2を飛ばして、かんぬきを掛けるステップ3で止まってはいけません。

ステップ1：うちのサイトの「本当の」PHPバージョンは、どう確かめるのか？

Webサイトを実際に動かしているPHPを見る必要があります。

サーバーで php -v と打って出てくるのはコマンド用のPHPで、ホームページが使うPHP-FPM（ホームページへのリクエストを受けてPHPを実行するプログラム）やWebサーバーのPHPとは違うことがあります。³ 家に時計がいくつもあるとき、居間の時計が合っていても台所の時計まで合っているとは限りません。韓国のセキュリティ企業Xintは、確認用のPHPファイルを他人に推測されにくい名前で置いてWebから開き、確認が済んだらすぐに消すよう案内しています。⁴

もうひとつの落とし穴はバージョン番号です。番号は外に貼った名札にすぎず、中身をすべて語ってはくれません。UbuntuやRed Hatのようなディストリビューション（サーバー用OSをまとめて配っているところ）は、番号はそのままで修正だけを入れるため、番号が古く見えても修正済みのことがあります。その場合は、パッケージの変更履歴（changelog）にCVE番号（脆弱性ごとに付く世界共通の番号）があるかで確かめます。^5·6

サーバー会社ごとの確認・変更メニューと、切り替える前の落とし穴は改善編「PHPのバージョン、どこで見てどう変える？」でまとめます。

ヤンのまとめ番号ひとつで「大丈夫」「危ない」を決めないでください。最初に聞くべきは「うちのサーバーは誰が面倒を見ているのか」です。その答えが出れば、残りはぐっと楽になります。

ステップ2：更新したのに、なぜ再起動まで必要なのか？

すでに動いているPHPのプログラム（ワーカー）が、古いコードを握ったままだからです。⁶

薬は買っておくだけでは効きません。飲んで初めて効きます。新しいPHPを入れても、いま働いているワーカーは古いPHPのまま働き続けます。再起動とは、そのワーカーたちを新しいPHPに入れ替えることです。

韓国のセキュリティ企業ジニアンスは、Debian・Ubuntuなら sudo apt update && sudo apt upgrade、RHEL系なら sudo dnf update 'php*' で上げたあと（このコマンドはPHP以外のプログラムも一緒に上げます）、PHP-FPMやApacheを必ず再起動するよう案内しています。⁹ コンテナ（プログラムを箱ごと包んで動かす方式）は箱の中を直せないので、新しいPHPのイメージで作り直して配置し直す必要があります。¹⁰

8.1以前には公式の修正版がありません。サポート中のバージョンに切り替えるか、ディストリビューションが古い番号に修正だけを入れた版（バックポート）を使う必要があります。¹

共用レンタルサーバーは、会社が代わりに済ませていることが多いです。たとえばエックスサーバーは、提供するPHP 5.6〜8.5への修正パッチの適用が完了しており、急いでPHPのバージョンを変える必要はないと案内しました（2026年10月22日時点）。ただしVPSについては、自社では修正パッチを適用していないとしています。¹¹ サポートが終わった古いバージョンを使っているなら、管理画面からバージョンを切り替えます。エックスサーバーでは、サーバーパネルの「PHP Ver.切替」からドメインごとに変えられます。¹²

ヤンのまとめ「上げた」と「終わった」は別の言葉です。再起動して、Webでもう一度確かめて、ようやく終わりです。

ステップ3：すぐに上げられないときは、何をすればよいのか？

PHPの設定ファイル（php.ini）やPHP-FPMの設定に一時的な設定を入れて、ワーカーを再起動します。ただし、完全な防御ではありません。¹

雨の夜、割れた窓にビニールを貼るようなものです。今夜の雨は防げますが、ガラスを入れ替えたわけではありません。

WAFは、怪しいリクエストを門の前で止める警備員です。これも時間を稼いでくれます。Cloudflareは無料プランを含む全顧客に防御ルールを適用しました。ただし、アップロード進捗機能の名前（session.upload_progress.name）を変えているサイトは、このルールでは防げないと説明しています。¹³

韓国のセキュリティ企業PLURAは、アップロードが不要なアドレスに届くファイル送信形式（multipart）のリクエストを止めるよう勧めています。¹⁴ それでも米国CISAは、WAFはあくまで一時的な保護で、修正できないならオフラインにすることまで勧めています。¹⁵ 警備員がいても、扉は直さなければなりません。

ヤンのまとめ応急処置を入れた日に、「いつまでに、誰が更新するか」も一緒に決めてください。終わる日が決まっていてこそ「応急」です。

ステップ4：もう入られていないかは、どう確かめるのか？

ログ、プロセス、ファイル。この3か所を見ます。

空き巣が入った家には跡が残ります。玄関の足跡、家の中の見知らぬ人、なかったはずの物です。サーバーでは、ログ（サーバーが残す出入りの記録）、プロセス（いまサーバーで動いているプログラム）、ファイルがその3つです。4か国の資料がそろって挙げた確認項目は次のとおりです。

1. ログ：PHP_SESSION_UPLOAD_PROGRESSを含むmultipartリクエスト、アップロード機能のないアドレスに届いたmultipartリクエスト、その前後のメモリエラーやHTTP 500^16·17·18
2. プロセス：PHPのワーカーの下で、sh・bash・curl・wgetのようなプログラムが実行された跡^15·17
3. ファイル：最近変わったPHPファイル、アップロード用フォルダにある見覚えのないPHPファイル。中国には、Webシェル（外からサーバーを操るためにこっそり置かれる裏口ファイル）を探す検査ツールの使い方を公開した資料もあります。こうしたツールも、出どころと動作を確かめてから使ってください^17·19
4. パスワード・キー：異常がなくても、データベースや管理者のパスワード、APIキーを替えます。韓国の情報保護機関KISAも、そう勧めています²

確認の順番は、リスク編4本目「パッチの前に侵入されていたら？攻撃の痕跡三つ」で詳しく説明しています。サーバーに直接入らずに社長が見られる場所と、見つけたときの順番は、改善編「うちのサイトに裏口が残っていないか？」で扱います。

ヤンのまとめ跡がないからといって「誰も来なかった」とは言い切れません。鍵を替えるのに大きな手間はかかりません。だから、パスワードの変更だけは皆さんにお勧めしています。

更新のあとでサイトが崩れたら、どうするのか？

原因になったプラグインやテーマを見つけて止めるか替えれば、たいていは元に戻ります。WordPressはデバッグログ（debug.log）を有効にすると、どのファイルがエラーを出したかを教えてくれます。²¹

だからこそ、更新の前にバックアップを取り、できればテスト環境で先に試すことが、各資料に共通する勧めです。バックアップは、戻ってくるための橋です。橋を架けてから渡る川は怖くありません。

同じ系統の中のセキュリティ修正（例：8.3.x → 8.3.36）なら、たいていサイトは崩れません。問題が起きやすいのは、7.xから8.xへの移行のように大きなバージョンを変えるときです。

画面が真っ白になったときに元に戻す順番は、改善編「PHPを上げたら画面が真っ白に？」でまとめます。

ヤンのまとめ「サイトが崩れるかもしれない」と先延ばしにするのが、いちばん危険です。バックアップさえあれば、昨日に戻れます。

根本解決：PHPを使わないサイトに変えると、どうなるのか？

PHPの更新・再起動・点検が要らなくなります。その代わり、フォーム・検索・コメントのようにPHPが担っていた仕事は、別の方法で解決する必要があります。

PHPで動くサイトは、お客さんが来るたびに厨房で料理を作り直すレストランです。PHPを使わない静的サイト（あらかじめ作ったHTMLファイルを見せるだけのサイト）は、作り置きのお弁当を渡すお店です。火を使わないので、火事の心配がありません。その代わり、お客さんごとに違う料理を出すのは苦手です。

WordPressのサイトをHTMLファイルに書き出すSimply Staticのようなツールがあり、Cloudflareはそうして作ったファイルを自社サービスに載せる方法を公式文書で案内しています。^22·23 中国では、WordPressの記事をHugoという静的サイトのツールに移し、本番サーバーからPHPをなくした事例も紹介されています。²⁴

無料のツールだけではフォーム・検索・コメントが動かず、記事を直すたびに書き出し直す必要があるという限界も、公式文書に書かれています。^22·23 あたたかいデジタルのPHPフリーは、この移行と移行後の運用をお引き受けするサービスです。

移し方、載せる先の料金、お問い合わせフォームの代わりは、改善編「WordPressを静的サイトに移すと？方法と費用」でまとめます。

ヤンのまとめすべてのサイトが移るべきだとは思いません。ただ、会社紹介のサイトなら、毎年繰り返されるステップ1〜4そのものをなくす道もあります。扉をしっかり閉める方法もあれば、守るべき扉を減らす方法もあるのです。