PHPの重大脆弱性「PHP2Shell」とは？企業のサイト・システム担当者が今すぐ確認すべきこと

2026年10月21日、Webサイトや業務システムで広く使われているプログラミング言語「PHP」に、極めて深刻な2件の脆弱性（通称：PHP2Shell）が公表されました。国内でも大手サービスが相次いで緊急メンテナンスを行い、政府機関が注意喚起を出す事態になっています。

この記事は、エンジニアではない企業のサイト・システム担当者の方に向けて、「結局、自社は何をすればいいのか」を最短で判断できるように書いています。そのままコピーして使える、保守会社・サーバー会社への確認依頼文も用意しました。

結論：担当者がまずやることは3つ

自社で直接サーバーを触る必要はありません。「把握」「確認依頼」「記録」の3つを今日中に始めてください。

• 把握：自社のWebサイト・業務システムのうち、PHPで動いているものを洗い出す（WordPressのサイトはすべて該当します）

• 確認依頼：それぞれの管理者（制作会社・保守会社・レンタルサーバー会社・情報システム部門）に、修正版への更新状況を確認する（依頼文テンプレートは後述）

• 記録：「いつ・誰に確認し・いつ対応が完了したか」を記録に残す

ポイントは、対応するのは基本的にシステムの管理者側だということです。担当者の仕事は、管理者が誰かを特定し、対応状況を確認し、未対応なら期限を切って依頼することです。逆に言えば、「誰が管理しているか分からないシステム」が今回いちばん危険です。

PHP2Shellとは何か：何が起きたのかを時系列で整理

認証なしで外部からサーバーを乗っ取られうる2件の欠陥が見つかり、修正版の公開と同時に世界中で攻撃の試みが観測されています。

今回公表されたのは、PHP本体の2件の脆弱性です。CVE（脆弱性の識別番号）では「CVE-2026-109618」「CVE-2026-109619」と呼ばれ、2件をあわせた通称が「PHP2Shell」です。深刻度は国際的な評価基準CVSS v4.0で9.2（クリティカル）。いずれも、ログインなどの認証を必要とせず、外部からサーバー上で任意のプログラムを実行される（＝サーバーを乗っ取られる）おそれがあります。

影響が大きい理由は、PHPの利用範囲の広さにあります。サーバー側の言語が判別できるWebサイトのうち約7割がPHPで動いているとされ（W3Techsの統計）、WordPressで作られたサイトやECサイト、社内の業務システムの多くが該当します。国内でもサービスの一時停止が相次ぎ、復旧に時間がかかる例も報道されています。

詳しい技術的な内容は、PHP公式の発表（php.net）とJPCERT/CCの注意喚起を参照してください。本記事の内容は2026年10月27日時点の公開情報に基づいています。

自社が対象かを確認する3ステップ

「PHPを使っているか」「バージョンは修正版か」「管理者は誰か」の順に確認します。分からなければ、分かる人に聞くところまでが確認です。

ステップ1：PHPで動いているものを洗い出す

まず、自社が関係するWebサイト・システムを一覧にします。次のものはPHPで動いている可能性が高い、または確実に該当します。

• WordPressで作られたサイト（コーポレートサイト、採用サイト、オウンドメディアなど）→ 確実に該当

• EC-CUBEなどPHP製パッケージのECサイト → 確実に該当

• 制作会社・開発会社に構築してもらったWebサイトや業務システム → 要確認

• レンタルサーバーで運用しているサイト全般 → 要確認

自社で判別できなくても問題ありません。「どの技術で動いているか」を管理者に確認する項目として、次のステップの依頼に含めれば十分です。

ステップ2：バージョンが修正版以降かを確認する

修正が入ったのは PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 以降です。確認時の注意点が2つあります。

• バージョン番号が古いままでも、対応済みの場合があります。サーバーのOS（Linuxディストリビューション）やレンタルサーバー事業者が、番号を変えずに修正だけを取り込む運用（バックポート)をしていることがあるためです。番号だけで判断せず、事業者や保守会社の告知・回答で確認してください。

• PHP 8.1以前（7系を含む）はサポートが終了しており、通常の修正版が出ていません。該当する場合の考え方は後述の章で説明します。

ステップ3：管理者ごとに確認先を整理する

対応の依頼先は運用形態で変わります。

そのまま使える：保守会社・サーバー会社への確認依頼文

下のテンプレートをコピーし、社名・対象・期日を入れて送ってください。回答の「見極めポイント」もあわせて確認します。

件名：PHPの重大な脆弱性（PHP2Shell）への対応状況の確認

いつもお世話になっております。株式会社◯◯の◯◯です。

2026年10月21日に修正版が公開されたPHPの脆弱性
（CVE-2026-109618、CVE-2026-109619）について、
貴社にて運用・保守いただいている下記環境の状況を確認させてください。

対象：（サイト名／システム名／URL）

1. 上記環境でPHPを使用していますか。
   使用している場合、現在のバージョンを教えてください。
2. 今回の脆弱性の修正は適用済みですか。適用日も教えてください。
   （バージョン番号を変えない修正取り込みの場合はその旨を）
3. 未適用の場合、適用予定日と、それまでの暫定対策を教えてください。
4. 修正版の公開から適用までの期間について、不審なアクセスや
   異常がなかったか、確認できる範囲で教えてください。

お手数ですが、◯月◯日までにご回答をお願いいたします。

「対応済みです」と回答が来たら、それで安心してよいですか？

適用日まで確認してください。修正版の公開（10月21日）から適用までに日数が空いている場合、その間に攻撃を受けていないかの確認（ログの点検など）もあわせて依頼できると確実です。

返答が曖昧、または返答がない場合は？

「PHPのバージョン」「適用日」という具体的な言葉で再度確認してください。それでも状況が分からない場合、そのシステムは管理体制自体に課題があります。別の開発会社にセカンドオピニオンとして現状調査を依頼することも検討してください。

すぐに更新できない場合の緩和策と、その限界

設定変更などの緩和策は公表されていますが、いずれも部分的な対処です。根本対策は修正版への更新しかありません。

業務都合などですぐに更新できない環境向けに、PHP公式からいくつかの緩和策が示されています。管理者向けの情報ですが、「緩和策を適用した」という報告を受けたときに、それが暫定対応にすぎないと理解しておくために概要を記載します。

• セッションのアップロード進捗機能の無効化（session.upload_progress.enabled=0）

• Webサーバー・プロキシ側でのリクエストサイズの制限

• メモリ上限設定の変更など、構成に応じた個別の設定

ただし、JPCERT/CCの注意喚起でも明記されているとおり、これらは特定の攻撃経路を塞ぐだけで、脆弱性そのものの対策にはなりません。「WAF（Webアプリケーションファイアウォール）を入れているから大丈夫」という判断も危険です。今回は公開前からWAFの回避を試みる動きが観測されており、時間稼ぎ以上の効果は期待できません。緩和策で凌いでいる環境には、必ず更新の期日を設定してください。

サポートが終了したPHP（8.1以前）で動くシステムはどうするか

今回、通常の修正版が提供されたのはPHP 8.2〜8.5だけです。それより古いPHPで動くシステムは、今回を「延命をやめる判断材料」にすべきです。

数年前に構築した業務システムやWebサイトでは、サポートが終了したPHP 7系・8.1以前がそのまま動いているケースが珍しくありません。今回の脆弱性について、これらのバージョンには最小限の修正がソースコード形式で提供されるにとどまり、通常の更新手段では対応できません（レンタルサーバーやOSベンダーが独自に修正を取り込んで提供する場合はあります）。

該当するシステムがある場合の考え方は次のとおりです。

1. 短期（今週）：管理者に、ベンダー独自の修正提供の有無と、外部からアクセスできる経路の有無を確認する。外部公開されている場合はアクセス制限などの暫定措置を検討する

2. 中期（今月〜）：サポート中のPHPへのバージョンアップ、またはシステム自体の刷新を計画に乗せる。古いPHPからのバージョンアップは互換性の確認と改修を伴うため、「パッチを当てる」感覚では進まない点に注意

3. 継続：システムごとに「使っている技術のサポート期限」を把握し、期限切れの前に更新する運用に切り替える

サポート切れの技術で動くシステムは、今回のような騒動のたびに「修正が来ない側」に取り残されます。放置のリスクと、バージョンアップ・リプレイスどちらを選ぶかの判断基準はサポート終了のPHPを使い続けるリスク｜バージョンアップとリプレイスの判断基準で詳しく整理しています。リプレイスに進む場合の進め方は業務システムのリプレイスを検討するタイミングと進め方を参照してください。

「PHPをやめるべき」なのか：開発会社としての考え方

今回の件は「PHPをやめる理由」にはなりません。見直すべきは言語ではなく、「誰が、いつ、更新するか」が決まっていない運用体制です。

これだけの騒動になると、「PHPは危ないのでは」「別の技術に乗り換えるべきでは」という声が出てきます。PHPを使ったシステム開発を手がける会社として、私たちの考えを記しておきます。

重大な脆弱性は、特定の言語に固有の問題ではありません。過去にも、通信の暗号化に使われるOpenSSL（2014年のHeartbleed）や、Java系システムのログ機能（2021年のLog4Shell)など、世界中のシステムの土台になっている技術で同規模の脆弱性が見つかっています。どの技術を選んでも、この種の事態はいずれ起こるものとして備えるしかありません。

むしろ今回のPHP開発チームの対応は、事前予告のうえで4つの系統の修正版を同時公開し、追加の注意点や緩和策まで公表するという、迅速で透明性の高いものでした。利用者の多い技術は、それだけ発見と修正の体制も厚いという側面があります。

実際に今回、対応の明暗を分けたのは使っている言語ではなく運用体制です。修正版の公開当日に更新を終えた企業と、復旧の見通しが立たない企業の差は、次の3点に集約されます。

• サポート中のバージョンを使い続ける計画（EOL管理）があったか

• セキュリティ更新を担当する保守契約・担当者が決まっていたか

• 更新を当てても壊れないと確認できる環境（テスト環境）があったか

この3つが揃っていれば、今回のような事態でも「告知を見て、当日中に更新し、記録を残す」だけで終わります。揃っていない場合、言語を乗り換えたところで同じことが繰り返されます。開発会社に構築を依頼する際は、納品後の保守体制まで含めて確認することをおすすめします。確認の観点は「納品して終わり」の開発会社を避けるための質問リストにまとめています。

よくある質問

WordPressのサイトしかありませんが、対応は必要ですか？

必要です。今回の脆弱性はWordPress自体ではなく、その土台のPHP本体の問題のため、WordPressやプラグインの更新では解決しません。レンタルサーバーを使っている場合は、サーバー事業者の告知でPHP側の対応状況を確認してください。

すでに攻撃を受けていないか確認できますか？

外から見ただけでは分かりません。サーバーのアクセスログの点検、心当たりのないファイルや管理者アカウントの有無の確認が必要で、これは管理者・専門家の作業です。修正版の適用が公開から数日以上遅れた環境では、更新と同時に点検も依頼してください。

社内からしか使えない業務システムも対応が必要ですか？

必要です。優先度は外部公開システムより下げて構いませんが、社内ネットワークに入り込んだ攻撃者の足がかりになるため、放置はできません。外部公開分の確認が済み次第、同じ手順で更新を依頼してください。

まとめ：この騒動を「体制を整える機会」にする

最後に、この記事の要点をまとめます。

• PHP2Shellは認証不要でサーバーを乗っ取られうる重大な脆弱性。修正版はPHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35

• 担当者がやることは「PHPで動くものの把握」「管理者への確認依頼」「記録」の3つ。依頼文はこの記事のテンプレートをそのまま使えます

• 緩和策やWAFは時間稼ぎ。根本対策は修正版への更新のみ

• サポート切れのPHPで動くシステムは、バージョンアップかリプレイスの計画を始める

• 見直すべきは言語ではなく運用体制。EOL管理・保守契約・テスト環境の3点が明暗を分けました

「自社のシステムが何で動いているか分からない」「保守契約がどうなっているか曖昧」という状態に気づいたことが、今回の騒動のいちばんの収穫かもしれません。現状の調査やバージョンアップ、保守体制の整備は、開発会社に相談できるテーマです。創新ラボでも、PHP・Laravelで構築されたシステムの現状調査からバージョンアップ、リプレイスまでご相談を承っています。