BLOGブログ
BLOG

PHPの脆弱性(PHP2Shell)とは? WordPressサイトの危険性と、今すぐできる対策

この記事は約 16 分で読めます

PHPの脆弱性(PHP2Shell)とは? WordPressサイトの危険性と、今すぐできる対策

2026年10月21日、PHPの公式サイトから、緊急の告知が出ました。PHP本体に、重大な脆弱性が2件見つかり、修正版が公開されたというお知らせです。

PHPは、Webサイトを動かすためのプログラム言語です。調査会社W3Techsの集計(2026年10月23日時点)では、サーバー側の言語が分かっているWebサイトの69.3%、およそ7割がPHPで動いています。WordPressもPHPで作られているため、WordPressでサイトを運営している方は、ほぼ全員が関係する話です。

この記事では、専門知識がなくても読めるように、たとえ話を使いながら、脆弱性の内容、危険な理由、確認の方法、対策、そしてkoko.netの対応をまとめます。

先に結論:知っておきたい3つのこと

  1. これは、PHP本体の問題です。WordPressやテーマ、プラグインの不具合が原因ではありません。
  2. ログインしていない第三者が、外から攻撃できる可能性があります。パスワードの強さや、二段階認証とは関係なく成立する攻撃です。
  3. 根本的な対策は、PHPを修正版に更新することです。WordPressの更新や、セキュリティプラグインだけでは、解決しません。

修正版は、PHP 8.5.12、8.4.27、8.3.36、8.2.35です。ご自身のサイトのPHPが、これより古ければ、更新が必要です。確認の手順は、のちほど説明します。

1. PHPの脆弱性(PHP2Shell)とは。

Webサイトを、レストランにたとえると

Webサイトの仕組みは、レストランによく似ています。

  • お客さんは、サイトを見に来る人です。
  • ホールは、WordPressです。メニューを見せたり、注文を受けたりします。ホールの店員さんにあたるのが、プラグインです。
  • 厨房は、PHPです。注文に応じて、料理(ページ)を実際に作ります。
  • 建物の鍵は、管理画面のパスワードや、セキュリティの設定です。

これまで、サイトの安全対策といえば、鍵を丈夫にしたり、ホールの店員さんの教育(プラグインの更新)を行ったりすることが中心でした。

今回の脆弱性は、そのどれにも当てはまりません。厨房の設備そのものに、欠陥が見つかったのです。

たとえば、玄関の鍵を何重にしても、厨房の裏口に、外から入れる隙間があったら、意味がありません。しかも、この隙間は、ホールを通らずに、厨房へ直接つながっています。受付(ログイン)で名前を書かなくても、入られる可能性があるのです。

「PHP2Shell」という名前の意味

この脆弱性は、通称「PHP2Shell」とも呼ばれています。PHPの欠陥を足がかりに、サーバーを外から操作できる入口(シェル)を作られてしまう恐れがある、という意味合いです。

正式には、2件の番号(CVE-2026-109618、CVE-2026-109619)で管理されています。深刻さを表す点数(CVSS v4.0)は、10点満点中の9.2です。最も深刻な「緊急(Critical)」の区分に入ります。

2. なぜ、こうした脆弱性が起きたのか

公式の告知にある2件の内容を、レストランのたとえで、順に説明します。

CVE-2026-109618:メモリ不足のときの、後片付けの不具合

厨房に注文が殺到して、手が回らなくなり、伝票を書きかけのまま、作業を中止したとします。その後の後片付けで、書きかけの伝票を、きちんと書かれたものとして扱ってしまうと、おかしな料理が出てきてしまいます。

PHPでも、サーバーのメモリが足りなくなった場面で、アクセスの情報が中途半端なまま作業が打ち切られ、その後の処理が、不完全な情報を正しいものとして扱ってしまう恐れがある、という内容です。

CVE-2026-109619:前のお客さんの情報が、残ってしまう

もう1件は、前のお客さんの伝票が、片付けられずに残っていて、次のお客さんの対応で、それを使ってしまう、という種類の不具合です。

PHPでも、前のアクセスで使った情報が、メモリを解放したあとも残り、同じ作業員(ワーカー)が処理する次のアクセスが、その古い情報を使ってしまう恐れがある、と説明されています。

なぜ、こうしたミスが起きるのか

PHPの中心部は、C言語という、メモリを細かく自分で管理するプログラム言語で作られています。メモリの確保や解放を人間が一つひとつ指示するため、「片付け忘れ」や「順番の間違い」が起こりえます。経験を積んだ開発者でも、大規模なプログラムで、これを完全になくすことは難しいのです。

こうした脆弱性は、PHPに限らず、ほとんどのソフトウェアで定期的に起きます。大切なのは、見つかったときに、すばやく更新できる体制を整えておくことです。

公式の告知では、実際に攻撃が成立する例が確認されているとも説明され、すぐに更新するよう強く呼びかけられました。

3. なぜ危険なのか

理由1:ログインが要らない

ふつう、サイトを不正に操作するには、管理画面のIDとパスワードが必要です。今回は、その手前で攻撃が成立する可能性があり、パスワードを長くしても、二段階認証を設定しても、防げません。

理由2:WordPressが動き出す前に、攻撃が成立する

公式の告知では、特にApacheのmod_phpという方式で、サイトのプログラムが動くより前に、認証なしの攻撃が成立した例が確認されたと説明されています。レストランでいえば、ホールに入る前に、厨房へ入られてしまう状態です。

そのため、ホールの店員さんにあたるセキュリティプラグインでは、止められません。サイトの内側で働く対策は、サイトより前で起きる攻撃には、手が届かないのです。

理由3:サイトの持つ情報が、すべて対象になる

厨房を乗っ取られると、お店の金庫や帳簿にも、手が届きます。サイトでいえば、次のようなものです。

  • 管理者の権限(サイトを自由に書き換えられる力)
  • データベースの内容(会員情報、問い合わせ、注文の情報など)
  • 決済サービスや、メール、外部サービスとつなぐための鍵

理由4:被害が、お客さんや取引先にも広がる

  • サイトの改ざん、見知らぬ広告や、詐欺サイトへの転送
  • お客様の個人情報の漏えい
  • 迷惑メールの送信元として、悪用される
  • 検索結果に「危険なサイト」と表示され、アクセスが減る
  • 復旧にかかる費用と時間、そして信用の低下

「うちは小さなサイトだから」は通用しません

攻撃は、自動化されています。サイトの大きさや知名度に関係なく、古いPHPで動いているサイトを、機械的に探して試していきます。個人のブログも、小さなお店のサイトも、同じ条件で狙われます。

4. 自分のサイトは影響を受けるのか。確認の方法

影響を受けるかどうかは、サイトが動いているPHPのバージョンで決まります。

修正版のバージョン

PHPの系列修正版(これ以上なら対応済み)補足
8.58.5.12
8.48.4.27
8.38.3.36
8.28.2.352026年12月31日で、セキュリティ修正の提供が終了します
8.1以前修正版(リリース)は出ませんソースコード向けに最小限の修正が公開され、一部のサーバー会社などが独自に対応する場合もあります。対応の有無を確認するか、新しい系列への移行が必要です

たとえば、PHP 8.3.33で動いているサイトは、修正版の8.3.36より古いので、更新が必要です。

バージョンの確認方法

  1. レンタルサーバーの管理画面:「PHPバージョン」「PHP設定」などの項目に、表示されていることが多いです。
  2. WordPressの管理画面:「ツール」→「サイトヘルス」→「情報」→「サーバー」の中に、「PHPバージョン」が表示されています。
  3. 制作会社や、保守の担当者がいる場合:そのまま、聞いてみてください。

多くのレンタルサーバーでは、「8.3」などの系列は契約者が選べ、番号の最後(「.33」「.36」の部分)はサーバー会社が更新します。最後の番号が古いままのときは、サーバー会社の対応を待つか、問い合わせます。

古いPHPのサイトが、まだ多いのが実情です

W3Techsの集計(2026年10月23日時点)では、PHPを使うサイトの約35%が、PHP 7以前で動いています。PHP 7以前は、すでに公式のサポートが終了していて、今回のような緊急の修正が出ても、公式の更新は届きません。

5. 今すぐできるPHPの対策

手順

  1. PHPのバージョンを確認します。前の見出しの方法で調べます。
  2. 修正版より古ければ、サーバー会社の案内を確認します。お知らせやサポートのページに、更新の予定が出ていれば、それを待ちます。出ていなければ、問い合わせます。
  3. バージョンを切り替えられる場合は、新しい系列へ切り替えます。8.3や8.4などがお勧めです。切り替える前に、必ずサイトのバックアップを取ります。
  4. 切り替えたあと、サイトの動作を確認します。表示、問い合わせフォーム、ログイン、ネットショップなら購入の流れを、一通り試します。
  5. 管理者ユーザーの一覧を確認します。見覚えのないユーザーがいないか、見てください。

サーバー会社への問い合わせ例

PHP 8.3.33で稼働しています。PHPの緊急の脆弱性(CVE-2026-109618、CVE-2026-109619)の修正版(8.3.36以上)が適用される予定を教えてください。適用までの間にできる対策があれば、あわせて教えてください。

お使いのバージョンに合わせて、数字の部分を書き換えてください。

更新で、サイトが動かなくなることはあるのか

古いテーマやプラグインは、新しいPHPで動かないことがあります。特に、PHP 7系から8系への切り替えでは、注意が必要です。切り替える前にバックアップを取り、できれば本番とは別の場所で動作を確認してください。表示が崩れたときは、前の系列に一度戻してもかまいませんが、修正版でない系列のまま長く放置するのは危険です。早めに原因を調べてください。

更新がすぐにできない場合の、暫定的な対策

PHP公式の告知では、更新できない場合の緩和策も紹介されています。ただし、これはあくまで応急処置です。完全な解決策にはなりません。

  • PHPの設定「session.upload_progress.enabled」を、0(無効)にします。設定したあとは、PHPの再起動が必要です。
  • PHPの設定「post_max_size」を小さくします。ファイルのアップロードが不要なら8MB、必要でも32MBが目安とされています。
  • サーバー側で、リクエスト(アクセス)の大きさなどを制限します。

これらは、サーバーの管理者が行う設定で、レンタルサーバーでは、契約者が変更できないことが多くあります。「.user.ini」や、サイトのプログラムの中からの設定では、効きません。設定できるかどうかも含めて、サーバー会社にご相談ください。

どうしても更新できず、重要な情報を扱っているサイトの場合は、更新できるまで、一時的に公開を止めるという判断もあります。

6. 今後のための対策

今回のように、突然、緊急の更新が必要になることは、これからも起こります。慌てないための準備を、まとめます。

1. 更新の担当者と、緊急時の連絡先を決める

サーバー、PHP、WordPress、テーマ、プラグイン。それぞれを誰が更新するのかを、はっきりさせておきます。制作会社に任せているつもりが、保守の契約に含まれていなかった、というすれ違いはよくあります。契約の内容を、一度確認してください。

2. PHPの「寿命」を把握する

PHPの各系列には、セキュリティ修正が提供される期限があります。期限が切れたPHPは、今回のような緊急の修正が出ても、更新されません。

  • PHP 8.2:2026年12月31日まで
  • PHP 8.3:2027年12月31日まで
  • PHP 8.4:2028年12月31日まで
  • PHP 8.5:2029年12月31日まで

お使いの系列の期限を、カレンダーに入れておくと、慌てずに済みます。期限の半年前には、次の系列への移行を考え始めるのがお勧めです。

3. バックアップを取り、戻せるかを確かめる

バックアップは、万一のときの最後の砦です。週に1回以上、サーバーとは別の場所に保存し、実際に戻せるかどうかも、一度試しておきましょう。取っていたのに戻せなかった、という話も珍しくありません。

4. 管理者のパスワードと、二段階認証を見直す

今回の脆弱性には効きませんが、他の多くの攻撃には有効です。パスワードは、使い回さず、長いものにします。可能なら、二段階認証も設定します。

5. 使っていないプラグインとテーマを減らす

入っているものが多いほど、更新の手間も、弱点も、増えます。使っていないものは、無効にするだけでなく、削除します。

6. 異変にすぐ気づける仕組みを入れる

完全に防ぐことは、誰にもできません。だからこそ、異変にいち早く気づく仕組みが役に立ちます。管理者ユーザーの追加、見慣れない場所からのログイン、重要なファイルの変更を、メールなどで知らせる仕組みがあれば、被害を小さくできます。

7. サーバー選びの基準に、更新への対応を加える

緊急の更新が出たとき、どれだけ早く対応し、どれだけ丁寧に知らせてくれるかは、サーバー会社によって違います。サーバーを選ぶときや、乗り換えを考えるときの、大切な基準になります。

7. koko.netの対応と対策

今回行った対応

  • 保守をお預かりしているサイトの、PHPを修正版に更新しました。
  • 更新後に、サイトの表示と動作を確認しました。

自社開発のセキュリティ機能「繕(TUKUROI)」

koko.netでは、WordPress用のオールインワンプラグイン「繕(つくろい/TUKUROI)」を開発しています。保守をお預かりしているサイトには、次の見守り機能を入れています。

  • PHPのバージョン確認:毎日、サイトのPHPが、修正版より古くないかを確認します。古いときは、管理画面とメールでお知らせします。
  • 即時通知:管理者ユーザーの追加や昇格、管理者のメールアドレスやパスワードの変更、いつもと違う場所からの管理者ログイン、wp-config.phpなど重要なファイルの変更、画像フォルダに置かれたPHPファイルなどを、メールでお知らせします。管理者の変化は、その場で。ファイルの変更は1時間以内、画像フォルダのPHPファイルは6時間以内が目安です。
  • 改ざんチェック:週に1回、WordPress本体とプラグインのファイルを、公式の正しいデータと照らし合わせて、書き換えられていないかを調べます。

できることと、できないこと

繕(TUKUROI)は、PHP本体の脆弱性そのものを、防ぐことはできません。レストランでいえば、厨房の設備の欠陥を、ホールから直すことはできないのと同じです。

繕の役目は、PHPの更新が必要なことと、万一の異変を、いち早く知らせることです。サーバーを完全に乗っ取られた場合や、痕跡を残さない攻撃は、見つけられないことがあります。

だからこそ、PHPを修正版に保つこと、バックアップ、更新の担当決めを、組み合わせて運用します。

保守契約のないサイトをお持ちの方へ

保守契約のないサイトは、サーバーのPHPの更新が、サーバーの契約者ご自身の作業になります。確認の方法が分からない、更新後の動作が心配、といったご相談は、お問い合わせフォームからご連絡ください。

8. よくある質問

Q1. WordPressを最新にすれば、防げますか?

防げません。今回の問題は、WordPressの土台にあたるPHPにあります。WordPressを最新にしても、PHPが古いままなら、状況は変わりません。WordPressの更新は、他の理由で大切なので、続けてください。

Q2. すでに攻撃されたかどうかを、確認できますか?

確実に判定するのは、専門家でも難しいことがあります。次のような兆候があれば、注意が必要です。

  • 管理画面に、見覚えのないユーザーがいる
  • サイトの表示が、突然おかしくなった、または、見知らぬ広告が出る
  • 身に覚えのないログインや、パスワード変更の通知メールが届いた
  • サーバーのファイルに、見覚えのないものが増えている

兆候があれば、すぐに、サーバー会社や制作会社などに連絡し、管理者のパスワードも変更してください。

Q3. PHP 7.4のままのサイトは、どうすればよいですか?

PHP 7.4は、公式のサポートが終了していて、今回の修正版(リリース)も出ていません。サーバー会社が独自に対応していることもあるため、まず確認し、そのうえで8.3以降への移行を、計画的に進めてください。古いテーマやプラグインが動かなくなる可能性があるため、早めの準備をお勧めします。

まとめと、ご相談について

今回の脆弱性は、PHP本体の問題で、ログインなしで外から攻撃される可能性があります。根本的な対策は、PHPを修正版に更新することです。PHP 8.1以前は、新しい系列への移行が必要です。

今日やること(3つ)

  1. サイトのPHPのバージョンを、確認する。
  2. 修正版より古ければ、バックアップを取ったうえで、バージョンを切り替えるか、サーバー会社に問い合わせる。
  3. 更新の担当者と、緊急時の連絡先を、決める。

PHPのバージョン確認や、更新のご相談、サイトの見守りについて、koko.netでもお受けしています。お困りのときは、無料相談(お問い合わせフォーム)から、お気軽にご連絡ください。

この記事は、2026年10月23日時点の情報をもとに書いています。最新の状況は、PHP公式サイトなどでご確認ください。

RECOMMEND

関連記事
あわせて読みたい

無料相談を申し込む