PHP の脆弱性（2026年10月・php2shell）、中小企業のHPで今やること（随時更新）

※2026年10月23日時点の情報です。状況が変わったら更新します。

2026年の PHP（HPを動かすプログラムの言語）では、5月から毎月のようにセキュリティの修正版が出ています。なかでも2026年10月21日に公表された2件は、ログインなしで外部からプログラムを実行される恐れがある、深刻度の高い脆弱性（ソフトウェアの欠陥）です。

自社のHPが対象かどうかは、PHP を誰が管理しているかと、使っているバージョンの2点で判断できます。2点を押さえると、サーバー会社に任せてよいのか、自社で動く必要があるのかを迷わず決められます。

本記事では、2026年10月の脆弱性（通称 php2shell）の内容・対象のバージョン・自社が対象かを確かめる4つの手順・今やることをまとめています。さらに、2026年のほかの修正版と、年末に迫る PHP 8.2 のサポート終了も紹介します。

PHP の脆弱性（2026年10月・php2shell）で何が起きたか

2026年10月の PHP の脆弱性は、CVE-2026-109618 と CVE-2026-109619 の2件です。PHP の開発元（The PHP Group）は2件とも深刻度を CVSS v4.0 で 9.2 とし、修正版 8.5.12／8.4.27／8.3.36／8.2.35 を公開しました。

PHP は、WordPress をはじめ多くのHP・ネットショップ・業務システムの土台です。被害を防ぐには、何が起きて、どのバージョンが直ったのかを正しく知ることが重要です。ここでは、概要を早見表で示したうえで、経緯・対象・構成・国内の動きの4つを解説します。

項目	内容（2026年10月23日時点）
脆弱性の番号	CVE-2026-109618、CVE-2026-109619（通称 php2shell）
何が起きるか	ログインなしで、外部から PHP の権限でプログラムを実行される恐れ
深刻度	2件とも CVSS v4.0 で 9.2
修正版	PHP 8.5.12／8.4.27／8.3.36／8.2.35
PHP 8.1 以前	公式のサポートが終了。通常の修正版は出ない
国内の注意喚起	IPA・JPCERT/CC が2026年10月22日に公開
唯一の対策	修正版への更新（設定変更などの緩和策は一部の攻撃経路にしか効かない）

※2026年10月23日時点・PHP 公式サイト、IPA、JPCERT/CC より

早見表のとおり、対策は修正版への更新だけです。以下では、修正版が出るまでの流れから順に解説します。

公表から修正版の公開までの流れ

PHP の脆弱性は、修正版の公開の前日に予告されました。深刻度が高く、利用者が準備できるよう、開発元が公開の日時を先に知らせたためです。

たとえば、日本時間では次の流れで進みました。

日付（日本時間）	できごと
2026年10月20日（現地時間）	PHP の開発元が「10月21日14時（協定世界時）に重大なセキュリティリリースを出す」と予告
10月21日	IPA が「事前準備のお願い」を公開。国内のサーバー会社が予防の緊急メンテナンスを始める
10月21日 22時30分過ぎ	予定の23時より早く、修正版と脆弱性の詳細が公開される
10月22日	IPA と JPCERT/CC が注意喚起を公開。レンタルサーバー各社が修正を適用

※2026年10月23日時点・PHP 公式サイト、IPA、ロリポップ！のお知らせより

ただし、修正版の公開は予告より早まりました。ロリポップ！は、公開後に脆弱性を狙ったとみられるアクセスの試みを確認したと報告しています（不正アクセスや情報漏えいは確認されていないとのことです）。

影響を受ける PHP のバージョンと修正版

PHP の脆弱性の影響を受けるのは、修正版より前のすべてのバージョンです。IPA の注意喚起によると、調査に関わった Wiz 社は PHP 5.4 以降のバージョンがいずれかの脆弱性の影響を受けるとしています（IPA）。

バージョンごとの修正の状況は、以下のとおりです。

使っている系統	修正版	公式のサポート
PHP 8.5	8.5.12 以降	あり
PHP 8.4	8.4.27 以降	あり
PHP 8.3	8.3.36 以降	あり
PHP 8.2	8.2.35 以降	2026年12月31日まで
PHP 7.4・8.0・8.1	通常の修正版なし（自分で PHP を組み立てる運用者向けの最小限の修正コードのみ）	終了
PHP 7.3 以前	なし	終了

※2026年10月23日時点・PHP 公式サイトより

ただし、古いバージョンほど安全なのではなく、直す手段が限られるだけです。PHP 7.4〜8.1 向けの修正コードは、管理画面で選べる通常の更新版ではありません。

影響を受ける構成とサイトの種類

PHP の脆弱性は、Webのリクエスト（閲覧やフォームの送信）を PHP で処理するすべての環境が対象です。開発元は、PHP-FPM・Apache の mod_php・php-cgi・FrankenPHP・LiteSpeed を挙げ、なかでも mod_php の危険度が高いとしています（PHP 公式サイト）。

たとえば、次のようなサイトやシステムが対象になります。

• WordPress などの CMS で作ったHP
• EC-CUBE・WooCommerce などのネットショップ
• PHP で作った予約フォーム・問い合わせフォーム
• 社内の業務システム・会員サイト

ただし、JPCERT/CC は、PHP を組み込んだ製品や Linux のディストリビューション（OSの配布元）が提供する PHP も影響を受ける可能性があるとしています。HP以外に PHP を使う仕組みがないかも、あわせて洗い出しましょう。

国内のサービスで相次いだ予防の緊急メンテナンス

PHP の脆弱性の公表前後には、国内のサーバー会社やWebサービスが、管理画面や一部の機能を予防のために止めました。修正版が出る前に攻撃が始まる恐れがあり、攻撃の入口を減らす必要があったためです。

たとえば、ロリポップ！は一部のサーバーで利用者のサイトの表示を止め、修正を当ててから再開しました。停止はサーバー単位だったため、PHP 8.2 以降のサイトや PHP を使わないサイトも一時的に表示できなかったと説明しています（ロリポップ！）。

ただし、メンテナンスで止まったことは、被害が出たことを意味しません。レンタルサーバー各社の対応は、PHP の脆弱性、レンタルサーバー各社の対応状況まとめで一覧にしています。

2026年の PHP の脆弱性とサポート期限

2026年の PHP は、10月の2件だけでなく、毎月のように修正版を出しています。さらに、PHP 8.2 のサポートが2026年12月31日で終わるため、10月の対応が済んでも年末にもう一度判断が必要です。

10月の脆弱性への対応は、年末に向けたバージョンの見直しとまとめて考えると効率的です。ここでは、2026年のセキュリティリリースの一覧と、サポート期限の2つを表で紹介します。

2026年に出た PHP のセキュリティリリース

2026年の PHP は、10月までに5回のセキュリティリリースを出しています。脆弱性が見つかるたびに、サポート中の系統（8.2〜8.5）へ修正版が出る仕組みだからです。

公開日（協定世界時）	修正版
2026年5月7日	8.2.31／8.3.31／8.4.21／8.5.6
2026年7月2日	8.2.32／8.3.32／8.4.23／8.5.8
2026年7月30日	8.2.33／8.3.33／8.4.24／8.5.9
2026年9月24日	8.2.34／8.3.35／8.4.26／8.5.11
2026年10月21日	8.2.35／8.3.36／8.4.27／8.5.12（php2shell の修正）

※2026年10月23日時点・PHP 公式サイト「News Archive 2026」より

一覧のとおり、サポート中の系統なら、修正版を当て続けるだけで既知の脆弱性をふさげます。ただし、サポートが終わった系統には一覧の修正版が出ません。

PHP 8.2 のサポートは2026年12月31日で終わる

PHP 8.2 は、2026年12月31日でセキュリティ修正の提供が終わります（PHP: Supported Versions）。2027年以降に見つかる脆弱性には、PHP 8.2 向けの修正版が出なくなるということです。

系統ごとのセキュリティ修正の期限は、以下のとおりです。

PHP のバージョン	セキュリティ修正の期限
8.1 以前	すでに終了
8.2	2026年12月31日
8.3	2027年12月31日
8.4	2028年12月31日
8.5	2029年12月31日

※2026年10月時点・PHP 公式サイトより

PHP 8.2 以前のHPは、10月の修正が済んでも年明けには「修正が出ないバージョン」になります。期限と移行の手順はPHP 8.2 のサポートは12月31日で終了。中小企業のHPでやることで解説しています。

自社のHPが PHP の脆弱性の対象か確かめる方法【4STEP】

自社のHPが PHP の脆弱性の対象かは、4つの手順で確かめられます。HPの置き場所によって、修正するのがサーバー会社なのか自社なのかが変わるためです。

確認には、管理画面のログイン情報か、サーバー会社からの請求書・メールがあると早く進みます。ここでは、PHP を使っているか・誰が管理しているか・バージョン・判定の4STEPを順に解説します。

STEP	確かめること	目安の時間
1	HPが PHP で動いているか	5分
2	PHP を誰が管理しているか	10〜30分
3	PHP のバージョン	5分
4	判定表に当てはめる	5分

【STEP1】HPが PHP で動いているかを確かめる

HPが WordPress で作られていれば、PHP で動いています。WordPress は PHP で書かれたソフトウェアだからです。

たとえば、HPのアドレスの後ろに /wp-admin/ を付けて開き、WordPress のログイン画面が出れば WordPress です。WordPress 以外でも、問い合わせフォーム・予約システム・ネットショップがあれば PHP を使っていることがあります。

ただし、自社で判断できない場合は、HPを作った制作会社に「PHP を使っていますか」と聞くのが確実です。

【STEP2】PHP を誰が管理しているかを確かめる

PHP を修正するのは、サーバーを管理している会社や人です。WordPress の管理画面からは、サーバーの PHP を直せないためです。

HPの置き場所ごとの担当を、以下の表で比較します。

HPの置き場所	PHP を修正するのは	まず確かめること
レンタルサーバー（エックスサーバー・さくらのレンタルサーバ・ロリポップ！など）	サーバー会社	契約先のお知らせで修正が済んだか
VPS・クラウド・自社サーバー	自社または委託先	PHP が修正版になっているか
制作会社のサーバー	制作会社	制作会社に対応状況を問い合わせる
Wix・ペライチ・STUDIO・Shopify など	サービスの提供元	原則、利用者の作業はない
PHP を使わない静的なHTMLだけのHP	―	対象外。ただし同じサーバーの別のサイトに注意

置き場所が分からない場合は、請求書やサーバー会社からのメールを探しましょう。手がかりがなければ、サーバー・ドメインの契約者を調べる方法（whois）が参考になります。

BASE・Shopify などでショップを開いている方は、BASE・Shopify は PHP の脆弱性（php2shell）と関係ある？ で確かめることをまとめています。

【STEP3】PHP のバージョンを確かめる

PHP のバージョンは、WordPress の管理画面で確かめられます。「ツール」→「サイトヘルス」→「情報」→「サーバー」の順に開くと、PHP のバージョンが表示されます（2026年10月時点）。

たとえば「8.2.34」と表示されたら、使っている系統は PHP 8.2 です。サーバー会社の管理画面でも、ドメインごとの PHP のバージョンを確認できます。

ただし、レンタルサーバーでは、番号が変わらないまま修正だけが当たっている場合があります。手順の詳細は自社HPの PHP バージョンを確認する方法で解説しています。

【STEP4】バージョンを判定表に当てはめる

確かめたバージョンを判定表に当てはめると、次にやることが決まります。系統と番号の組み合わせで、修正の有無とサポートの状況が分かるためです。

確かめた PHP のバージョン	判断
8.5.12／8.4.27／8.3.36 以上	10月の修正は入っている
8.2.35 以上	10月の修正は入っている。ただし12月31日でサポート終了
8.2〜8.5 で、上より古い番号	レンタルサーバーなら契約先のお知らせを確認。VPS・自社サーバーなら更新が必要
8.1 以前	公式の修正版はない。サーバー会社の修正は応急処置。8.3 以降への移行を計画

判定表で「更新が必要」「移行を計画」に当てはまった場合は、次の章の手順に進みましょう。

PHP の脆弱性で今やること【優先順位つき】

PHP の脆弱性で最初にやることは、修正が当たったかを確かめることです。修正の確認が済んだら、古いバージョンの移行・侵入の痕跡の確認・体制づくりの順に進めます。

作業の多くはサーバー会社や制作会社が担いますが、確認と判断は自社の役目です。ここでは、優先度の高い順に6つの作業を紹介します。

優先度	やること	対象
1	契約先のお知らせで修正の状況を確かめる	すべて
2	担当者・管理会社に5項目を確認する	制作会社・委託先に任せている場合
3	8.3 以降への切り替えを計画する	PHP 8.2 以前
4	修正版へ更新する	VPS・自社サーバー
5	侵入の痕跡がないかを確かめる	すべて
6	更新を続けられる体制と予算を決める	すべて

契約先のお知らせで修正の状況を確かめる

レンタルサーバーを使っている場合は、契約先のお知らせを読むことが最初の作業です。利用者の作業が要らない会社と、PHP の切り替えを頼む会社に分かれているためです。

たとえば、ConoHa WING・お名前.com レンタルサーバー・mixhost は利用者の作業を不要としています。一方、ロリポップ！と heteml は PHP 8.2 以降への切り替えと、サイトの動作確認を利用者に頼んでいます（2026年10月23日時点・各社のお知らせより）。

ただし、契約時のメールアドレスが退職者のものだと、サーバー会社からの連絡が届きません。連絡先が今の担当者になっているかも確かめましょう。

担当者・管理会社に確認する5項目

HPの管理を制作会社や委託先に任せている場合は、対応状況を問い合わせます。サーバーの中身は委託先しか確かめられないことが多いためです。

問い合わせで確認する項目は、以下のとおりです。

1. 使っている PHP のバージョン
2. CVE-2026-109618・CVE-2026-109619 の修正が当たっているか
3. 修正が済むまでの応急措置と、サイトを一時的に止める必要があるか
4. PHP 8.2 以前の場合、8.3 以降へ移す予定と時期
5. ほかに PHP を使っているサイトやシステムがないか

5項目の回答が得られない場合は、別の専門家に相談することも検討してください。

PHP 8.1 以前なら 8.3 以降への切り替えを計画する

PHP 8.1 以前のHPは、8.3 以降への切り替えを計画することが重要です。サーバー会社が当てた修正は応急処置で、今後見つかる脆弱性には対応できない可能性があるからです。

たとえば、ロリポップ！は PHP 8.1 以下への今回の対策を応急的なものと位置づけ、8.2 以降への移行を強くすすめています。ただし PHP 8.2 も12月31日でサポートが終わるため、切り替えるなら 8.3 以降を選ぶと次の期限まで1年の余裕ができます。

ただし、古いテーマやプラグインは新しい PHP で動かず、表示が崩れることがあります。切り替えの前にWordPress のバックアップの取り方と、戻せるかの確認を済ませ、崩れたときはPHP を上げたらサイトが崩れた。原因と戻し方を参照してください。

VPS・自社サーバーは修正版へ更新する

VPS・クラウド・自社サーバーで PHP を動かしている場合は、自社か委託先が修正版へ更新します。サーバー会社は、利用者が自分で入れた PHP までは直さないためです。

たとえば、さくらインターネットは、さくらの VPS のサービス自体は影響を受けないとしつつ、VPS の中で動かしている PHP は最新版へ更新するよう求めています。OS の配布元が出す修正パッケージを使う場合は、配布元の情報も確かめます。

ただし、設定変更による緩和策は更新の代わりになりません。JPCERT/CC は、緩和策は特定の攻撃経路に対処するだけで、対策はアップデートのみとしています。

侵入の痕跡がないかを確かめる

修正が済んだあとも、修正前に入り込まれていないかを確かめることが重要です。修正は欠陥をふさぐだけで、すでに置かれた不正なプログラムは消さないためです。

JPCERT/CC が挙げる確認の観点は、以下のとおりです（JPCERT/CC）。

• 異常に長い、または不自然な形式の PHPSESSID（セッションの識別子）の Cookie
• 不審な multipart/form-data のリクエストと、その前後の PHP のメモリ上限エラーや HTTP 500 エラー
• PHP のプロセスの異常終了や頻繁な再起動
• 不審なプロセスの実行・外部への通信・ファイルの作成

ただし、JPCERT/CC は、痕跡が見つからなくても攻撃を受けていないとは断定できないとしています。侵入が疑われるときはログを消さずに保全し、専門家に相談してください。

更新を続けられる体制と予算を決める

PHP の脆弱性への備えでは、更新を続けられる体制と予算を決めることも重要です。PHP は毎月のように修正版が出るうえ、系統ごとにサポートの期限があるからです。

たとえば、IPA は今回の注意喚起で、システムの担当者だけでなく事業責任者や経営層も含めて、更新・移行と保守に必要な人員・予算・体制を検討するよう呼びかけています。体制を確保できない場合は、保守できる製品への移行・機能の縮小・公開の終了も選択肢に入れるとしています。

ただし、社内に担当者を置けない会社も少なくありません。外部の保守会社に任せる場合の見方は、ホームページの保守は必要？ やらないとどうなるかで解説しています。

PHP の脆弱性でよくある誤解

PHP の脆弱性では、WordPress の更新や画面の表示を根拠に「大丈夫」と判断してしまう誤解がよくあります。誤った判断は、修正が当たっていないサーバーを放置する原因になります。

誤解の多くは、WordPress とサーバーの PHP の役割の違いから生まれます。ここでは、よくある誤解5つと実際を表で比較します。

よくある誤解	実際
WordPress を最新にしたから大丈夫	10月の脆弱性は PHP 本体の問題。WordPress の更新では直らない
表示されるバージョンが古いから未対策	番号を変えずに修正だけを当てるサーバー会社がある。お知らせで確かめる
番号が新しいから安全	PHP が直っても、WordPress やプラグインが古ければ別の入口が残る
WAF を入れているから更新しなくてよい	WAF（Webサイトへの攻撃を手前で止める仕組み）や緩和策は更新の代わりにならない
古い PHP は対象外	PHP 5.4 以降はいずれかの脆弱性の影響を受けるとされる。古いほど直す手段が少ない

※2026年10月23日時点・PHP 公式サイト、IPA、JPCERT/CC、各社のお知らせより

表の誤解に当てはまる判断をしていた場合は、自社のHPが対象か確かめる4STEPに戻りましょう。WAF の役割はWAF とは？ 中小企業のHPに要るかで説明しています。

あわせて読みたい
WordPress 本体の脆弱性「wp2shell」とは。自社サイトの確認手順

PHP の脆弱性で専門家に相談すべきとき

PHP の脆弱性への対応は、サーバーの所在や古いバージョンの移行でつまずくと、自社だけでは進められなくなります。古いサイトの PHP を切り替えると表示が崩れやすく、直すにはプログラムの知識が要るためです。

判断を先延ばしにすると、PHP 8.2 のサポート終了まで時間がなくなります。ここでは、専門家に相談したほうが安全な条件を4つ紹介します。

• HPがどこのサーバーにあるか、誰が管理しているか分からない
• PHP 7.x などの古いバージョンで動いていて、切り替えると崩れそう
• 制作会社と連絡が取れない、または回答が得られない
• ログに怪しい記録があり、侵入されたか判断できない

「自社が対象か分からない」「作業する人がいない」場合は、HPの移管・保守サービス『サイガード』の無料診断をご利用ください。URLを送るだけで、外から見える範囲をセキュリティの専門家が確認します。

まとめ

• 2026年10月21日に公表された PHP の脆弱性（CVE-2026-109618／109619）は、修正版 8.5.12／8.4.27／8.3.36／8.2.35 で直る
• WordPress の更新では直らない。レンタルサーバーはサーバー会社、VPS・自社サーバーは自社が PHP を修正する
• レンタルサーバーは番号が変わらないまま修正されていることがあるため、契約先のお知らせで確かめる
• PHP 8.1 以前の修正は応急処置で、PHP 8.2 も2026年12月31日でサポートが終わる。8.3 以降への移行を年内に計画する

まずは自社のHPの PHP のバージョンと管理者を確かめ、自力で難しい場合は専門家の無料診断を活用しましょう。