- PHPの脆弱性がWebサイトにもたらすリスクと、深刻度（CVSS）の読み方
- 2026年10月に予告された緊急脆弱性2件について、確認できている事実と未確定の情報
- 自社サイトが影響を受けるかを確かめる手順（PHPバージョンの確認方法・更新の担当者）
- 修正版の公開前後にやることのチェックリストと、サイトを一時停止すべきかの判断基準
- サイトを止める場合に検索順位への影響を抑える方法（SEOの観点）
2026年10月20日（日本時間では21日未明）、PHPの開発チームが「緊急」レベルの脆弱性2件を修正するセキュリティリリースを予告しました。修正版は日本時間の10月21日夜に公開されました。PHPは企業サイトやWordPressの土台として広く使われているため、「自社のサイトは大丈夫なのか」「制作会社からサイトを止めるよう提案されたが、どう判断すればよいのか」と不安を感じている運営担当者の方も多いと思います。
一方で、ネット上には公式発表と推測が混ざった情報も出回っています。判断を誤らないためには、何が確定していて何がまだ分からないのかを切り分けたうえで、自社の状況に当てはめることが欠かせません。
この記事では、PHPの脆弱性の基本から、今回の緊急脆弱性で確認できている事実、自社サイトへの影響の確かめ方、修正版の公開前後にやること、サイトを一時停止すべきかの判断基準までを、サイト運営担当者・制作担当者・経営層のどなたが読んでも使える形で整理しました。マーケティング支援会社として、サイトを止める場合の検索順位への影響と、その抑え方にも触れています。
※2026年10月21日23時40分（日本時間）更新：PHP公式が修正版（8.5.12／8.4.27／8.3.36／8.2.35）を公開したため、影響範囲・修正版・PHP 8.1以前の扱い・暫定的な緩和策を正式情報に更新しました。
【最新状況】2026年10月のPHP緊急脆弱性：公式発表の内容
PHP公式は日本時間10月21日夜、2件の脆弱性を修正したPHP 8.5.12・8.4.27・8.3.36・8.2.35を公開しました。Webリクエストを処理するすべてのPHP環境が対象で、PHP 8.1以前には公式の修正版は提供されません。
| 項目 | 内容 | 出所 |
|---|---|---|
| 修正版 | PHP 8.5.12／8.4.27／8.3.36／8.2.35（2026年10月21日公開） | PHP公式 |
| 脆弱性 | CVE-2026-109618（メモリ不足時の処理に起因）、CVE-2026-109619（解放後に残った内部状態に起因）。いずれも遠隔からのコード実行（RCE）につながる | PHP公式 |
| 深刻度 | いずれもCVSS v4.0で9.2（最も深刻な区分） | PHP公式 |
| 影響を受ける環境 | Webリクエストを処理するすべてのPHP環境（PHP-FPM、Apacheのmod_php、php-cgiなど）。特にmod_phpはリスクが高いとされる | PHP公式 |
| PHP 8.1以前 | 公式の修正版は提供されない。7.4・8.0・8.1向けには、ソースから自分でビルドする人向けの最小限の修正のみ公開 | PHP公式 |
| 悪用状況 | 攻撃が成立することは実証済み。実際の攻撃が確認されたとの公式発表は、本記事の更新時点ではない | PHP公式、Help Net Security |
注目すべきなのは、予定より前に脆弱性の情報が外部に漏れたと報じられている点です。セキュリティ企業のGMO Flatt Securityは、攻撃に使えるとされるコードがネット上で出回り始めていると伝えています。PHP公式も、攻撃が成立することはすでに実証されているとしています。修正版の公開後は、修正内容の差分から攻撃手法が割り出されやすくなるため、公開から適用までの時間をどれだけ短くできるかが重要になります。
こういう時は、まず「公式に確定した情報」と「推測や二次情報」を分けて整理するのがおすすめです。社内や取引先に共有するときも、出所をセットで伝えるだけで、判断のブレがかなり減ります。
PHPの脆弱性とは？サイト運営者が知っておきたい基本
PHPの脆弱性とは、Webサイトを動かすプログラム言語「PHP」本体の欠陥のことです。PHPで動くサイトであれば、サイト側のつくりに関係なく影響を受ける可能性があります。
PHPはWebサイトの約7割で使われている
PHPは、Webサイトの裏側（サーバー側）で動くプログラムを書くための言語です。ブログや企業サイトで広く使われているCMSのWordPress、ECサイト構築によく使われるEC-CUBE、業務システムでよく使われるLaravelなども、PHPで動いています。
Web技術の利用状況を調べているW3Techsによると、サーバー側の言語が判明しているサイトのうち69.3%がPHPを使っています（2026年10月21日時点）。サイトの閲覧者がPHPを意識することはほとんどありませんが、PHP本体に欠陥があると、その上で動く数多くのサイトに影響が広がります。
脆弱性を突かれると何が起きるのか
今回のように「遠隔からコードを実行される」タイプの脆弱性を突かれると、攻撃者はサーバー上で好きな命令を動かせる状態になります。具体的には、次のような被害につながるおそれがあります。
- 情報漏えい：問い合わせフォームの送信内容、会員情報、データベースの中身が抜き取られる
- 改ざん：ページが書き換えられ、閲覧者が不正なサイトに誘導される
- 不正プログラムの設置：外部から再侵入するための仕掛け（Webシェルなど）を置かれる
- 踏み台化：自社サーバーが他社への攻撃やスパム送信に使われる
- 検索結果の汚染：検索エンジン経由で別サイトへ誘導されるように仕込まれる
最後の検索結果の汚染は、マーケティングの観点でも見逃せません。2024年には大分大学のサーバーがPHPの脆弱性を突かれてファイルを改ざんされ、Googleの検索結果から海外サイトへ誘導される状態になっていたことが公表されています。同大学は個人情報の漏えいはないとしつつ、そのサーバーの運用を終了して再構築しました。被害は情報漏えいだけでなく、検索での信頼やブランドにも及ぶということです。
「CVSS 9.2」はどのくらい深刻なのか
CVSSは、脆弱性の深刻度を0〜10の数値で示す国際的な共通指標です。9.0以上は最も深刻な「Critical（緊急）」に分類されます。今回の2件はいずれも9.2で、この最上位の区分に入ります。
ただし、CVSSは脆弱性そのものの性質を評価した数値であり、個々のサイトがどれだけ危ないかを直接示すものではありません。実際のリスクは、使っているPHPのバージョンや設定、サイトが扱う情報の重要度によって変わります。数値だけで「止める・止めない」を決めず、次の章以降の手順で自社の状況を確認することが大切です。
脆弱性のニュースは数字が先に一人歩きしがちです。大事なのは「自社に当てはまるかどうか」で、そこを確かめずに慌てて動くと、止めなくていいサイトまで止めてしまうこともあります。
自社サイトが影響を受けるかを確認する方法
確認すべきは「PHPを使っているか」「どのバージョンか」「誰が更新するのか」の3点です。この3点がそろえば、修正版が出たときにすぐ動けます。
ステップ1：自社サイトがPHPで動いているか確認する
次のどれかに当てはまる場合は、PHPで動いている可能性が高いと考えてください。本番サイトだけでなく、検証環境、過去のキャンペーンサイト、使っていない管理画面なども洗い出しの対象です。IPAは、ソフトウェア製品やネットワーク機器の内部でPHPが使われている場合もあるため、マニュアルや提供元の情報を確認するよう呼びかけています。
- WordPressで作ったサイト・ブログ
- EC-CUBEなどで構築したECサイト
- Laravel・CakePHP・Symfonyなどで開発した独自システムや会員サイト
- 問い合わせフォームや予約フォームをPHPで自作しているサイト
一方、ShopifyやWix、BASEのように、サーバーの管理をサービス提供会社が担うクラウド型のサービスでは、利用者がPHPを更新する作業は基本的に発生しません。気になる場合は、各サービスのお知らせを確認しましょう。
ステップ2：PHPのバージョンを確認する
PHPのバージョンは、サイトの種類や環境に応じて次の方法で確認できます。
| 環境 | 確認方法 |
|---|---|
| WordPress | 管理画面の「ツール」→「サイトヘルス」→「情報」タブ→「サーバー」の欄に表示される |
| レンタルサーバー | サーバー会社の管理画面（コントロールパネル）の「PHP設定」「PHPバージョン切替」などの項目で確認できることが多い |
| VPS・クラウド・自社サーバー | サーバーにログインし、コマンド「php -v」を実行する |
| 制作会社・保守会社に運用を任せている | 担当者に、サイトごとのPHPバージョンを確認する |
バージョンは「8.3.○○」のように表示されます。最初の2つの数字（8.3など）が、次の章で説明するサポート期限の判断に使う「系列」です。
ステップ3：PHPを更新するのは誰かを確認する
同じPHPでも、サーバーの契約形態によって更新の担当者が変わります。ここが曖昧なままだと、「誰かがやってくれると思っていた」という状態で時間だけが過ぎてしまいます。
| サーバーの形態 | 更新するのは主に誰か | 運営担当者がやること |
|---|---|---|
| 共用レンタルサーバー | サーバー会社（ただし、利用するPHPバージョンを利用者が選ぶ方式もある） | サーバー会社のお知らせを確認し、利用者側の操作が必要かを確かめる |
| VPS・クラウド（IaaS） | 自社または保守を委託している会社 | 担当者と更新のタイミング、停止時間を決める |
| 制作会社・保守会社が運用 | 契約内容による | 保守契約の範囲にPHPの更新が含まれるか確認する |
| 社内サーバー | 自社の情報システム担当 | 対象サーバーの一覧と更新手順を準備する |
ご相談を受けていて多いのは、「サイトの中身は社内、サーバーは制作会社任せ」で責任の境目があいまいなケースです。今回のような緊急時に誰が動くのか、平時から決めておくだけで初動の速さがまったく変わります。
サポートが終了した古いPHPを使っている場合のリスク
サポートが終了した系列のPHPには、原則として公式の修正版が提供されません。今回もPHP公式は8.1以前向けの修正版を出していないため、こうした系列は更新だけでは対処できません。
PHPは系列（8.2、8.3など）ごとにサポート期限が決まっています。PHP公式が公表しているサポート期限は次のとおりです。
| 系列 | セキュリティサポート終了日 | 状態（2026年10月時点） |
|---|---|---|
| 8.5 | 2029年12月31日 | サポート中 |
| 8.4 | 2028年12月31日 | サポート中 |
| 8.3 | 2027年12月31日 | サポート中 |
| 8.2 | 2026年12月31日 | サポート中（残り約2カ月） |
| 8.1以前 | 終了済み | 今回もPHP公式の修正版は提供されない（7.4〜8.1向けには、ソースから自分でビルドする人向けの最小限の修正のみ公開） |
問題は、古い系列を使い続けているサイトが少なくないことです。W3Techsの調査では、PHP 8を使うサイトのうち8.1が15.2%、8.0が5.8%を占めています（2026年10月21日時点）。また、WordPressの開発チームが2026年1月に公表したデータでは、WordPressサイトの約2割がPHP 7.4で動いていました。
過去の例も参考になります。2024年に見つかったPHPの脆弱性（CVE-2024-4577）では、IPAが国内で複数の組織が攻撃を受け、Webシェルを設置される被害を確認したと公表しました。このときIPAは、サポートが終了したPHP 5・7・8.0も影響を受けるとされているため、サポートされている系列へ移行するよう呼びかけています。
今回の脆弱性について、PHP公式は8.1以前向けの更新を提供しないと明言しています。Linuxディストリビューションや長期サポートを提供するベンダーが独自に修正を出している場合もあるため、利用しているサーバー会社やベンダーに確認しつつ、サポート中の系列（8.3以降が目安）への移行を急いで計画することをおすすめします。PHPの系列を上げると、古いテーマやプラグイン、独自プログラムが動かなくなることがあるため、事前の動作確認が必要です。
修正版の公開前・公開後にやることチェックリスト
公開前は「すぐ当てられる準備」、公開後は「当てて、反映を確かめて、異常がないか点検する」が基本の流れです。
修正版の公開前にやること
- PHPで動いているサイト・システムを洗い出し、一覧にする
- それぞれのPHPバージョンと、更新の担当者を確認する
- 夜間や翌朝でも連絡がつく手段と、作業の判断者を決めておく
- サイトのファイルとデータベースのバックアップを取り、戻し方を確認しておく
- 更新後に動作確認するページ（トップ、問い合わせフォーム、ログイン、カートなど）を決めておく
- 更新に伴って停止する時間帯と、利用者へのお知らせ文を用意しておく
- WAF（Webアプリケーションファイアウォール）を使っている場合は、提供元が対応ルールを出すか確認する
修正版の公開後にやること
- PHP公式の発表で、影響を受けるバージョンと修正版のバージョンを確認する
- 修正版を適用する（レンタルサーバーの場合はサーバー会社の対応状況を確認する）
- サーバー上で実際に動いているPHPが修正版に切り替わったことを確認する（更新作業の完了と、本番への反映は別物と考える）
- 決めておいたページで動作確認をする
- 修正版の公開前後に、見覚えのないファイルの追加や管理者アカウントの追加がないかを点検する
- 委託先から作業完了の報告を受け、更新日時を記録しておく
暫定的な緩和策の位置づけ
PHP公式は、すぐに更新できない場合の一時的な措置として、Session Upload Progress機能の無効化（session.upload_progress.enabled=0）、メモリ上限やPOSTサイズの設定見直し、Webサーバー側でのリクエストサイズの制限などを挙げています。ただし、これらは攻撃の経路を減らすだけで完全な対策ではなく、更新だけが根本的な解決策だと明記しています。エラー表示を隠すといった対応には効果がないともしています。
WAFも同様で、時間稼ぎにはなっても修正版の代わりにはなりません。緩和策は「すぐに更新できない場合のつなぎ」と位置づけ、設定変更そのものも影響範囲を確認したうえで、制作・保守担当者と相談して実施してください。
「アップデートしました」という報告だけで安心せず、実際に動いているバージョンまで確認するのがポイントです。運用の現場では、更新したつもりで反映されていなかった、ということが意外と起こります。
サイトを一時停止（閉鎖）すべきか？判断の基準
サイトの一時停止は有効な選択肢のひとつですが、すべてのサイトに一律で必要なわけではありません。「修正版をすぐ当てられるか」と「漏れたら困る情報を扱っているか」の2軸で判断するのが現実的です。
CERT-EU（EU機関向けのセキュリティ組織）は、修正版をすぐに適用できない場合に、インターネットに公開しているアプリケーションを外部から切り離すことも検討するよう求めています。つまり、停止は「修正版をすぐ当てられない場合の守り方」として位置づけられています。
| 修正版をすぐ適用できる | 修正版をすぐ適用できない（サポート終了の系列、更新体制がない等） | |
|---|---|---|
| 個人情報・決済・会員情報を扱う | 停止せず、公開直後に適用。適用までの時間帯だけ停止する選択肢もある | 一時停止や外部からのアクセス制限を優先的に検討する |
| 情報発信が中心（会社案内・ブログ等） | 停止せず、公開直後に適用 | 停止の検討に加え、改ざん時の影響（検索結果の汚染など）も踏まえて判断する |
判断にあたっては、次の点も材料にしてください。
- 停止による損失：EC・予約・問い合わせなど、止めると売上や機会損失が出るか
- 扱っている情報の重さ：漏えいした場合の顧客への影響と、報告・対応の負担
- 再開の条件：何が確認できたら再開するのか（修正版の適用完了、動作確認、異常の有無の点検など）
- 停止の範囲：サイト全体ではなく、フォームや会員機能など一部だけを止める方法はないか
サイトの停止は売上や顧客対応に直結するため、最終的には経営判断になります。制作会社や保守会社から停止を提案された場合は、「どのバージョンで動いているか」「修正版をいつ適用できるか」「何をもって再開するか」をあわせて確認すると、判断しやすくなります。
「止めるか、止めないか」の二択で考えると判断が難しくなります。止める範囲、止める期間、再開の条件まで決めておけば、経営層にも説明しやすくなりますし、止めた後に再開の判断で迷うこともなくなります。
サイトを止める場合に知っておきたいSEOへの影響と止め方
短期間の停止であれば、止め方さえ正しければ検索順位への影響は抑えられます。ポイントは「503」というステータスで止めること、そして停止を長引かせないことです。
一時停止はHTTPステータス「503」で行う
Googleは、サイト全体を一時的に止める場合、HTTPステータスコード「503（一時的に利用できない）」と案内ページを返す方法を推奨しています。503は「今は一時的に使えない」という合図なので、検索エンジンに「サイトがなくなった」と判断されにくくなります。
反対に、トップページを「閉店しました」という通常のページ（ステータス200）に差し替えたり、ファイルを削除して「404（見つからない）」を返したりすると、検索エンジンが内容の変更やページの削除と受け取るおそれがあります。停止作業を制作会社に依頼する場合は、503で止めるよう伝えておくと安心です。
503での停止は1〜2日程度にとどめる
Googleは、503による全体停止は1〜2日程度の緊急時に限るべきだとしており、長くても数日を上限とする扱いです。検索結果から完全に消えてしまうと、再開後に元の状態へ戻るまで時間がかかり、早める方法もないとしています。停止が長引きそうな場合は、フォームや会員機能だけを止めて、会社情報などのページは公開を続けるといった部分的な制限に切り替えることを検討しましょう。
robots.txtはそのままにしておく
停止中も、クロール（検索エンジンの巡回）を制御するファイル「robots.txt」は、通常どおり巡回を許可する状態にしておく必要があります。Googleは、robots.txt自体が503を返したり、すべての巡回を拒否する設定にしたりすると、クロール全体が止まったり、検索結果から削除されたりするおそれがあると説明しています。
再開後はSearch Consoleで状態を確認する
再開後は、Google Search Consoleで、ページのインデックス状況に大きな変化がないか、「セキュリティの問題」に警告が出ていないかを確認しましょう。万一改ざんを受けていた場合、検索結果に警告が表示されたり、身に覚えのないページがインデックスされたりすることがあります。
SEOの支援をしていると、サイトを止めたこと自体よりも「止め方」で順位を落としてしまうケースを見かけます。セキュリティの判断とあわせて、検索エンジンへの見せ方も一緒に決めておくと、再開後の立ち上がりがスムーズです。
制作会社・サーバー会社に確認すべきこと
外部に運用を任せている場合は、次の質問をまとめて送ると、やり取りの往復を減らせます。
- 当社のサイト・システムはPHPで動いているか。動いている場合、それぞれのバージョンは何か
- 今回のPHPのセキュリティリリース（10月21日公開の8.5.12／8.4.27／8.3.36／8.2.35）を把握しているか
- PHPの更新は保守契約の範囲に含まれるか
- 修正版の適用はいつ頃になる見込みか。作業中にサイトが止まる時間はあるか
- 作業前のバックアップは取得しているか
- サポートが終了したバージョンを使っている場合、どう対応する予定か
- サイトを一時停止する場合、503で止める形にできるか
- 作業が完了したら、適用後のバージョンを含めて報告してもらえるか
相手を責めるためではなく、備えを確認するための質問だと一言添えると、協力を得やすくなります。
サイトの運用体制や、緊急時の対応手順の見直しをご相談ください
TSRコンサルティングでは、Webサイトの制作・運用からSEOまで、サイトを「集客の資産」として育てるための支援を行っています。
「サイトの管理体制が属人的になっている」「緊急時に誰が何をするか決まっていない」「サイトを止めた後の検索順位が心配」といったお悩みがあれば、お気軽にご相談ください。
まとめ
- 2026年10月に予告されたPHPの脆弱性2件は、いずれもCVSS 9.2の「緊急」で、10月21日夜に修正版（8.5.12／8.4.27／8.3.36／8.2.35）が公開された。Webリクエストを処理するすべてのPHP環境が対象
- まずは「PHPを使っているか」「どのバージョンか」「誰が更新するのか」を確認し、修正版が出たらすぐ適用できる準備を整える
- サポート終了の系列（8.1以前）には公式の修正版が提供されないため、一時停止やアクセス制限、系列の移行を検討する
- サイトを止める場合は、503で短期間にとどめ、robots.txtはそのままにすることで、検索順位への影響を抑えられる
よくある質問
PHPの脆弱性は、WordPressのサイトにも影響しますか？
WordPressはPHPで動いているため、PHP本体の脆弱性の影響を受ける可能性があります。WordPressやプラグインを最新にしても、PHP本体の欠陥は直りません。管理画面の「サイトヘルス」でPHPのバージョンを確認し、PHP自体の更新が必要です。
レンタルサーバーを使っていれば、自分で何もしなくてよいですか？
多くの場合、PHPの更新はサーバー会社が行いますが、利用するPHPバージョンを利用者が選ぶ方式もあります。古いバージョンを選んだままだと修正版が適用されないこともあるため、サーバー会社のお知らせと、自分のサイトの設定を確認しましょう。
自社のサイトがどのPHPバージョンで動いているか、どうすれば分かりますか？
WordPressなら「ツール」→「サイトヘルス」→「情報」→「サーバー」で確認できます。レンタルサーバーなら管理画面のPHP設定、自社サーバーならコマンド「php -v」で確認できます。運用を委託している場合は、担当者に問い合わせるのが確実です。
すぐに修正版を適用できない場合はどうすればよいですか？
外部からのアクセス制限やサイトの一時停止を検討してください。暫定的な緩和策も公表されていますが、効果は確定していません。あくまでつなぎと考え、サポート中の系列への移行を含めて早めに計画を立てることが大切です。
サイトを一時停止すると、検索順位は下がりますか？
1〜2日程度の短期間であれば、HTTPステータス「503」で止めることで影響を抑えられます。一方、停止が長引いたり、ページを削除したり、robots.txtで巡回を拒否したりすると、検索結果から外れて回復に時間がかかるおそれがあります。
関連記事
参考情報
- PHP公式：Upcoming Critical PHP Security Release（php.announce）
- PHP公式：2026年のニュース（8.5.12／8.4.27／8.3.36／8.2.35のリリースとセキュリティアドバイザリ）
- PHP公式：Supported Versions
- IPA：【事前準備のお願い】PHPのセキュリティリリース公開予定について
- CERT-EU：Security Advisory 2026-018
- GMO Flatt Security Blog：PHPの重大な脆弱性「php2shell」の概要と対応指針
- ITmedia NEWS：PHPに「緊急」レベルの脆弱性2件 修正版を日本時間21日深夜に公開へ
- IPA：PHPの脆弱性（CVE-2024-4577）を狙う攻撃について
- ITmedia NEWS：大分大学のサーバで改ざん被害 PHPの脆弱性突かれGoogle検索結果汚染
- W3Techs：Usage statistics of PHP version 8
- Make WordPress Core：Dropping support for PHP 7.2 and 7.3
- Google検索セントラル：ウェブサイトを一時停止または無効にする
- Help Net Security：PHP2Shell: Critical PHP vulnerabilities patched, update now!
