My Alarm inc.
contact
AXコラム｜セキュリティ

PHPの脆弱性（PHP2Shell）で何をすれば良い？影響の確認方法と対応手順

公開 ／ 更新 ／ 情報の確認日：2026年10月22日 ／ 執筆：My Alarm株式会社

PHPの脆弱性 何をすれば良い？対応手順まとめ

2026年10月21日、PHP本体に重大な脆弱性が2件見つかったと公表されました。「PHP2Shell」と呼ばれ、悪用されるとログインしていない第三者がサーバー上で任意のコードを実行できるおそれがあります。WordPressをはじめ、PHPで動くWebサイトの多くが対象です。

この記事では、PHPの脆弱性について「何をすれば良いのか」を、サイト運営者の立場で順番に整理しました。自分のサイトが対象かどうかの確かめ方、今すぐやること、更新できない場合の考え方まで、IPA（情報処理推進機構）などの一次情報をもとに解説します。

結論：何をすれば良いか
  • PHPで動くサイトは、2026年10月21日公開の修正版（8.2.35／8.3.36／8.4.27／8.5.12）以降へ更新します。
  • レンタルサーバーを使っている場合は、まずサーバー会社の告知で対応状況を確認し、管理画面で自分のサイトのPHPバージョンを確かめます。
  • PHP 8.1以前で動いているサイトは修正の提供が限られます。サポート中の版へ上げるか、PHPを使わない構成への移行を検討してください。

あわせて読みたい

WordPress移行の費用相場と依頼先の選び方｜脱WordPressで安全な環境へ
この記事について

この記事は、WordPressからの移行サービスを提供しているMy Alarm株式会社が、IPA・PHP公式・セキュリティ企業の公開情報をもとにまとめたものです。情報は2026年10月22日時点のもので、状況は変わる可能性があります。最新の情報は記事末尾の出典元でご確認ください。

PHPの脆弱性「PHP2Shell」とは

PHP2Shellとは、2026年10月21日に公表されたPHP本体の2件の脆弱性（CVE-2026-109618、CVE-2026-109619）を組み合わせた攻撃の呼び名です。IPAは、悪用された場合に「遠隔の第三者によって、任意のコード実行が実行される可能性」があると注意を呼びかけています。

CVE番号原因深刻度（CVSS v4.0）
CVE-2026-109618メモリ不足（OOM）が起きたときのエラー処理の不備。後片付けの処理が壊れたデータを扱ってしまう9.2
CVE-2026-109619リクエスト処理の不備。前のリクエストの状態が次のリクエストに残ってしまう9.2

なぜ深刻なのか

厄介なのは、サイト側のログイン認証では防げないことです。セキュリティ企業Datadogの分析によると、攻撃のリクエストはWebアプリケーションのコードに届く前に、PHPがリクエストを受け取る段階で処理されます。会員ページやパスワード付きの管理画面があっても、入口は塞げません。また、画面に文字を表示するだけの単純なPHPファイルでも、攻撃の経路になりうると報告されています。

影響を受ける範囲も広いです。IPAは、調査に関わったWiz社の見解として「PHP 5.4以降のバージョンは、これらの脆弱性のいずれかの影響を少なくとも受ける」と紹介しています。攻撃もすでに始まっています。Datadogは、修正版が公開される4日前の10月17日に、悪用を試みる通信が観測されていたというAWSの報告を伝えています。

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

日付出来事
10月17日悪用を試みる通信が観測される（AWSの報告。Datadogによる）
10月21日IPAが「PHPのセキュリティリリース公開予定」として事前準備を呼びかけ
10月21日PHPが修正版（8.2.35／8.3.36／8.4.27／8.5.12）を公開。レンタルサーバー各社が緊急メンテナンスを開始
10月22日IPAが「PHPの脆弱性対策について」を公開し、対策の実施を呼びかけ

海外でも、米国のNSA（国家安全保障局）が、PHPを使うすべての組織に更新への備えを呼びかけ、すぐに更新できない場合はシステムをオフラインにするよう勧めています。国内では、noteのようにPHPを使っていないWebサービスが「影響なし」と告知する動きも出ています。

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

修正版はPHPのサポート中の系列ごとに公開されています。使っている系列の修正版以上になっていれば、今回の2件は修正済みです。

PHPの系列影響を受けるバージョン修正版
8.5系8.5.12より前8.5.12
8.4系8.4.27より前8.4.27
8.3系8.3.36より前8.3.36
8.2系8.2.35より前8.2.35
8.1系以前影響を受ける（サポート終了）通常の修正版なし

8.1以前の系列は、すでにサポートが終わっています。Datadogによると、PHPのセキュリティチームは7.4・8.0・8.1向けに最小限の修正をソースコードで公開しましたが、実際に使える形で届くかどうかはサーバー会社やOSの提供元しだいです。古い系列を使っている場合は、提供元の告知を確認するか、サポート中の系列へ上げる必要があります。

Webサイトで動くPHPはすべて対象

PHPの公式発表は、Apacheのモジュール、PHP-FPM、php-cgi、FrankenPHP、LiteSpeedなど、Webのリクエストを処理するすべての形態が影響を受けるとしています。サーバーにログインして php -v で確認したバージョンと、Webサイトを実際に動かしているPHPのバージョンが違うこともあるため注意してください。

自分のサイトが対象か確かめる方法

確認したいのは「Webサイトを動かしているPHPのバージョン」です。サイトの置き場所ごとに確かめ方が違います。

レンタルサーバーの場合

サーバー会社の管理画面（サーバーパネルなど）に、ドメインごとのPHPバージョン設定があります。複数のサイトを置いている場合は、ドメインごとに違うバージョンが設定されていることがあるので、すべて確認してください。あわせて、サーバー会社が出している告知で、修正版やパッチの適用が済んでいるかを確かめます。

WordPressの場合

WordPressの管理画面で「ツール」→「サイトヘルス」→「情報」タブを開き、「サーバー」の項目を見ると、サイトを動かしているPHPのバージョンが表示されます。ここに出る番号が、上の表の修正版以上かどうかを確認してください。

自社サーバー・VPS・クラウドの場合

Webサーバー経由で実行されているPHPのバージョンを確認します。コンテナでアプリを動かしている場合は、コンテナの中に入っているPHPも対象です。Linuxのディストリビューションが配布するPHPは、バージョン番号を変えずに修正だけを取り込むことがあるため、番号だけで判断せず、提供元のセキュリティ情報も確認してください。

PHPを使っているか分からない場合

制作会社に任せていて仕組みが分からない場合は、まず制作会社かサーバーの管理者に確認するのが確実です。目安として、次のようなサイトはPHPで動いている可能性が高いです。

  • WordPressで作ったサイト（WordPress自体がPHPで動きます）
  • EC-CUBEなどPHP製のECサイトや、LaravelなどPHPのフレームワークで作ったシステム
  • 見た目は普通のHTMLのページでも、お問い合わせフォームの送信処理だけPHPで動いているサイト

3つ目は見落としがちです。ページ自体はHTMLでも、フォームの送信先がPHPのファイルになっていれば、そのサーバーではPHPが動いています。

今すぐやること（対応手順）

やることは一つです。PHPを修正版に更新し、更新が反映されたことを確かめます。手順に分けると次のとおりです。

  1. PHPを修正版以上に更新する自社で管理しているサーバーは、提供元の更新を適用します。レンタルサーバーは、サーバー会社が自動で適用しているか、利用者が管理画面でバージョンを切り替える必要があるかを告知で確認します。
  2. PHPのプロセスを再起動する更新しても、古いPHPのまま動き続けているプロセスが残ると修正が効きません。PHP-FPMなどのプロセスをすべて再起動し、コンテナは作り直して入れ替えます。
  3. サイトの表示と動作を確かめるPHPのバージョンを上げると、古いテーマやプラグインが動かなくなることがあります。トップページ、主要なページ、お問い合わせフォーム、管理画面へのログインを一通り確認してください。
  4. 攻撃の痕跡がないか確認するDatadogは、大きなフォーム送信、リクエストの受付中に起きたメモリ不足のエラー、身に覚えのないシェルのプロセスなどを手がかりに調べるよう勧めています。公表前から悪用の試みがあったため、更新が済んでもログは確認しておくと安心です。

レンタルサーバー各社の対応状況

国内のレンタルサーバー各社は、10月21日から22日にかけて緊急メンテナンスを行い、修正版やパッチの適用を進めました。セキュリティ診断会社のまとめ（10月22日時点）によると、たとえば次のような告知が出ています。

  • エックスサーバー：予防措置として公式サイトや管理画面を一時停止し、利用者のサーバーに修正パッチを順次適用。22日朝の更新でPHP 8.2〜8.5への適用完了を告知
  • ConoHa WING：今のPHPバージョンのままパッチを適用し、利用者の作業は不要と告知
  • ロリポップ！：予防措置としてサービスサイトや利用者ページを一時停止

対応の内容や完了時期は、サーバー会社ごとに違います。状況も日々更新されています。最新の情報は、契約しているサーバー会社の公式告知で確認してください。8.1以前のような古いバージョンを選んでいるサイトは、パッチの対象外になることがあります。注意してください。

CONSULTATION

PHPの更新、自社だけで対応できますか？

PHPのバージョンを上げたらサイトが表示されなくなった、古いWordPressで更新できない。そんなときはご相談ください。WordPressから、PHPを使わない安全な環境への移行もお手伝いしています。

初期費用 5万〜10万円（税別）運用保守 月額10,000円（税別）

安全な環境への移行を相談する

あなたのWordPress、いまの状態を確認しませんか？

URLとメールアドレスを入れるだけで、本体・プラグイン・PHPの既知の脆弱性を無料でチェックできます。

WordPressを無料で診断する

すぐに更新できない場合の暫定策

IPAは、更新や移行が終わるまで脆弱な状態のまま放置せず、暫定対策やアクセス制限を検討するよう求めています。有効な暫定対策が難しい場合は、被害や業務への影響をふまえて、外部からのアクセスを遮断する、サービスを一時停止するといった判断も必要だとしています。

PHPの公式発表やDatadogの解説では、次のような緩和策が示されています。いずれもサーバーの設定を変更できる管理者向けの内容で、レンタルサーバーの利用者は基本的にサーバー会社の対応を待つことになります。

  • 公開範囲を絞る：社内向けの管理画面など、外部に公開する必要がないものはアクセスを制限します。
  • PHPの手前で止める：リバースプロキシなど、PHPより前の段階で不審なリクエストを止める設定を入れます。
  • CVE-2026-109618向け：memory_limit=-1 をアプリ側から上書きできない形で設定し、Webサーバー側のリクエストサイズの上限やコンテナのメモリ上限と組み合わせます。ファイルのアップロードが不要なら post_max_size を小さく（8Mなど）します。RLIMIT_AS などのプロセスの上限で代用すると、かえって脆弱性の条件を作ってしまうため使いません。
  • CVE-2026-109619向け：session.upload_progress.enabled=0 を設定し、PHP 8.5では fatal_error_backtraces=0 もあわせて設定します。設定後はPHPのプロセスをすべて再起動します。
暫定策では完全に防げません

Datadogは「修正版への更新だけが確実な対策」とし、ネット上で広まっている設定変更だけでは十分に守れないと指摘しています。暫定策は、修正版へ更新するまでの時間稼ぎと考えてください。

PHP 8.1以前・長く更新していないサイトはどうするか

いちばん悩ましいのは、8.1以前のPHPで動いているサイトや、何年もPHPを更新していないサイトです。IPAも、長く更新していないシステムでは、アプリケーションの改修や動作確認が必要になるうえ、開発時の資料やノウハウの不足、担当者の不在、保守契約の終了などで対策が難しくなっている場合があると指摘しています。

そのうえでIPAは、更新や移行を進める体制を確保できる見通しが立たない場合、今のシステムを使い続けることを前提にせず、保守を受けられる製品・サービスへの移行や機能の縮小、公開の終了まで含めて検討するよう求めています。選択肢を整理すると次のようになります。

選択肢向いているケース注意点
サポート中のPHPへ更新して使い続ける会員機能や予約、決済などサーバー側の処理が必要なサイトテーマやプラグイン、独自のプログラムの改修が必要になることがある。今後も定期的な更新が続く
PHPを使わない構成へ移行する会社案内、サービス紹介、採用ページなど、情報を載せることが中心のサイト更新の方法が変わる。お問い合わせフォームなどの仕組みを置き換える必要がある
公開を終了する役目を終えたキャンペーンサイトや、使われていない旧サイト必要なデータを保存し、移転先や代わりの窓口を案内する

特に、古いPHPのまま止まっているWordPressサイトでは、PHPを上げるとテーマやプラグインが動かなくなり、それらを直すとさらに別の更新が必要になる、という連鎖が起きがちです。直す費用が作り直す費用に近づくこともあるため、両方の見積もりを比べてから判断すると失敗が少なくなります。

WordPressサイトで気をつけること

WordPressはPHPで動いています。つまり、WordPressのサイトは基本的にすべて今回の対象です。ここで混同しやすいのが、WordPress本体の更新との違いです。

  • WordPress本体やプラグインを更新しても、今回のPHPの脆弱性は直りません。直すにはPHP自体の更新が必要です。
  • 反対に、PHPを更新しても、WordPress本体やプラグインの脆弱性は別に対応が必要です。2026年7月にはWordPress本体でも、管理者権限なしでコードを実行される深刻な脆弱性（wp2shell）が公表され、IPAが注意喚起を出しています。
  • PHPのバージョンを上げたあとは、表示の崩れ、お問い合わせフォームの送信、管理画面へのログインを確認してください。

WordPressのサイトを安全に保つには、WordPress本体、テーマ、プラグイン、PHP、サーバーと、複数の層の更新を続ける必要があります。この手間と費用をどう見積もるかが、WordPressを使い続けるかどうかを考える出発点になります。保守を外部に頼む場合の費用はWordPress保守費用の相場で解説しています。

noteが「影響なし」だった理由と根本的な対策

今回、ブログサービスのnoteは、公式アカウントで「noteが提供するサービスでは、PHPを使用している箇所はありません」と告知し、影響はないと説明しました。理由は単純です。サーバー側でPHPを動かしていなければ、PHPの脆弱性はそもそも当てはまりません。

ここから分かるのは、サーバーで動いているプログラムが少ないほど、こうした脆弱性の影響を受ける範囲も狭くなるということです。会社案内やサービス紹介が中心のサイトであれば、ページをあらかじめHTMLとして書き出しておく「静的サイト」の構成にすることで、サーバー上でPHPやデータベースを動かさずに運用できます。

ただし、静的サイトにしても、お問い合わせフォームをPHPで動かしていれば、その部分は今回の対象になります。フォームを外部のサービスに置き換えるなど、PHPを残さない設計にすることが大切です。

My Alarmの「WordPress移行」とは、WordPressで作られたサイトを、PHPやデータベースをサーバー上で動かさない安全な環境へ移すサービスです。料金は初期費用5万〜10万円（税別）、運用保守は月額10,000円（税別）で、AIを使った開発で作業時間を短くしています。

移行の費用相場や移行先の選び方はWordPress移行の費用相場と依頼先で詳しく紹介しています。今回のような脆弱性のたびに更新に追われる状態から抜け出したい方は、お問い合わせからご相談ください。サービスの詳細はAI受託開発のページでも紹介しています。

WORDPRESS MIGRATION

脆弱性のたびに慌てないサイトへ

WordPressから、PHPやデータベースを使わない安全な環境へ移行します。今のサイトのデザインや掲載内容を引き継いで移せるかどうかも含めて、お見積りします。

初期費用 5万〜10万円（税別）運用保守 月額10,000円（税別）

安全な環境への移行を相談する

PHPの脆弱性に関するよくある質問

PHPの脆弱性（PHP2Shell）について、サイト運営者からよく聞かれる質問にお答えします。

PHP2Shellとは何ですか？

PHP2Shellとは、2026年10月21日に公表されたPHP本体の2件の脆弱性（CVE-2026-109618、CVE-2026-109619）の呼び名です。悪用されると、ログインしていない第三者がサーバー上で任意のコードを実行できるおそれがあります。修正版は8.2.35、8.3.36、8.4.27、8.5.12です。

レンタルサーバーを使っています。自分で何かする必要はありますか？

多くのレンタルサーバーでは、サーバー会社が修正パッチを適用しています。まず契約しているサーバー会社の告知を確認してください。古いPHPのバージョンを選んでいる場合や、サーバー会社から利用者に作業を依頼している場合は、管理画面でPHPのバージョンを切り替える必要があります。

WordPressを最新版にすれば解決しますか？

解決しません。今回はPHP本体の脆弱性なので、PHPを修正版に更新する必要があります。WordPress本体やプラグインの更新は、それとは別に続けてください。

PHP 7.4で動いているサイトはどうすれば良いですか？

PHP 7.4はサポートが終わっており、修正が届くかどうかはサーバー会社やOSの提供元しだいです。サポート中の8.2以降へ上げるのが基本ですが、テーマやプラグイン、独自のプログラムが新しいPHPで動くか確認が必要です。改修が難しい場合は、PHPを使わない構成への移行や、公開の終了も含めて検討してください。

session.upload_progress.enabled=0 にすれば安全ですか？

安全とはいえません。この設定はCVE-2026-109619への緩和策の一つで、DatadogはこれだけではPHP2Shellを十分に防げないと指摘しています。確実な対策は修正版への更新です。

HTMLだけの静的なサイトなら影響はありませんか？

サーバー上でPHPを動かしていなければ、今回の脆弱性の対象外です。ただし、お問い合わせフォームの送信処理などにPHPを使っている場合は、そのサーバーでPHPが動いているため対象になります。

まとめ

PHPの脆弱性「PHP2Shell」への対応は、PHPを修正版（8.2.35／8.3.36／8.4.27／8.5.12）以降へ更新することに尽きます。レンタルサーバーを使っている場合はサーバー会社の告知を確認し、自分のサイトのPHPバージョンを確かめてください。

一方で、8.1以前のPHPで動いているサイトや、長く更新していないWordPressサイトは、更新そのものが難しいことがあります。その場合は、IPAが示すとおり、今の仕組みを使い続けることを前提にせず、移行や公開終了も含めて考えるタイミングです。PHPを使わない構成に移せば、次に同じような脆弱性が見つかっても慌てずに済みます。

参考にした情報（確認日：2026年10月22日）

この記事は、次の公開情報をもとに作成しました。