2026年10月21日、PHPの公式サイトから、緊急の告知が出ました。PHP本体に、重大な脆弱性が2件見つかり、修正版が公開されたというお知らせです。
PHPは、Webサイトを動かすためのプログラム言語です。調査会社W3Techsの集計(2026年10月23日時点)では、サーバー側の言語が分かっているWebサイトの69.3%、およそ7割がPHPで動いています。WordPressもPHPで作られているため、WordPressでサイトを運営している方は、ほぼ全員が関係する話です。
この記事では、専門知識がなくても読めるように、たとえ話を使いながら、脆弱性の内容、危険な理由、確認の方法、対策、そしてkoko.netの対応をまとめます。
先に結論:知っておきたい3つのこと
- これは、PHP本体の問題です。WordPressやテーマ、プラグインの不具合が原因ではありません。
- ログインしていない第三者が、外から攻撃できる可能性があります。パスワードの強さや、二段階認証とは関係なく成立する攻撃です。
- 根本的な対策は、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.5 | 8.5.12 | |
| 8.4 | 8.4.27 | |
| 8.3 | 8.3.36 | |
| 8.2 | 8.2.35 | 2026年12月31日で、セキュリティ修正の提供が終了します |
| 8.1以前 | 修正版(リリース)は出ません | ソースコード向けに最小限の修正が公開され、一部のサーバー会社などが独自に対応する場合もあります。対応の有無を確認するか、新しい系列への移行が必要です |
たとえば、PHP 8.3.33で動いているサイトは、修正版の8.3.36より古いので、更新が必要です。
バージョンの確認方法
- レンタルサーバーの管理画面:「PHPバージョン」「PHP設定」などの項目に、表示されていることが多いです。
- WordPressの管理画面:「ツール」→「サイトヘルス」→「情報」→「サーバー」の中に、「PHPバージョン」が表示されています。
- 制作会社や、保守の担当者がいる場合:そのまま、聞いてみてください。
多くのレンタルサーバーでは、「8.3」などの系列は契約者が選べ、番号の最後(「.33」「.36」の部分)はサーバー会社が更新します。最後の番号が古いままのときは、サーバー会社の対応を待つか、問い合わせます。
古いPHPのサイトが、まだ多いのが実情です
W3Techsの集計(2026年10月23日時点)では、PHPを使うサイトの約35%が、PHP 7以前で動いています。PHP 7以前は、すでに公式のサポートが終了していて、今回のような緊急の修正が出ても、公式の更新は届きません。
5. 今すぐできるPHPの対策
手順
- PHPのバージョンを確認します。前の見出しの方法で調べます。
- 修正版より古ければ、サーバー会社の案内を確認します。お知らせやサポートのページに、更新の予定が出ていれば、それを待ちます。出ていなければ、問い合わせます。
- バージョンを切り替えられる場合は、新しい系列へ切り替えます。8.3や8.4などがお勧めです。切り替える前に、必ずサイトのバックアップを取ります。
- 切り替えたあと、サイトの動作を確認します。表示、問い合わせフォーム、ログイン、ネットショップなら購入の流れを、一通り試します。
- 管理者ユーザーの一覧を確認します。見覚えのないユーザーがいないか、見てください。
サーバー会社への問い合わせ例
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つ)
- サイトのPHPのバージョンを、確認する。
- 修正版より古ければ、バックアップを取ったうえで、バージョンを切り替えるか、サーバー会社に問い合わせる。
- 更新の担当者と、緊急時の連絡先を、決める。
PHPのバージョン確認や、更新のご相談、サイトの見守りについて、koko.netでもお受けしています。お困りのときは、無料相談(お問い合わせフォーム)から、お気軽にご連絡ください。
この記事は、2026年10月23日時点の情報をもとに書いています。最新の状況は、PHP公式サイトなどでご確認ください。

