PHPの重大脆弱性「PHP2Shell」事件の全容｜総理も呼びかけた緊急アップデートの経緯・影響・中小企業がやるべき対策

2026年10月21日の夜、日本中のWebサイトが一斉に「緊急メンテナンス」に入りました。銀行、鉄道、航空、自治体、ゲーム、EC、保育園向けのサービスまで、普段は止まることのないサイトが次々と予防的に停止し、首相がXで「今夜に対応して頂きたい大至急のお願い」と呼びかける異例の事態になりました（出典：ITmedia NEWS）。

原因は、世界中のWebサイトで使われているプログラミング言語PHPに見つかった2件の重大な脆弱性です。「PHP2Shell（php2shell）」と呼ばれるこの脆弱性は、ログインなどの認証なしに、外部からサーバー上で任意のプログラムを実行される（リモートコード実行／RCE）おそれがあるもので、WordPressをはじめとするPHP製のサイト全般が影響を受けうるとされています。

この記事では、PHP2Shellとは何か、発見から公開までの時系列、2件の脆弱性の仕組み、影響を受けるバージョンと修正版、国内で起きたサービス停止の広がり、悪用の状況、そして自社サイトを持つ中小企業が今すぐ確認すべきことを、公表されている一次情報をもとに整理します。情報は2026年10月23日時点のもので、状況は日々更新されています。最新情報は記事末尾の公式発表を必ず確認してください。

PHP2Shellとは｜何が起きたのかを3分で理解する

PHP2Shellは、2026年10月21日（協定世界時）にPHPの開発チームが修正版を公開した2件の脆弱性、CVE-2026-109618とCVE-2026-109619の通称です。PHP公式は「Critical remote code execution vulnerabilities, update now（重大なリモートコード実行の脆弱性、今すぐ更新を）」と題したセキュリティアドバイザリを出し、すべての利用者に直ちに更新するよう求めました（出典：PHP公式）。

要点は次のとおりです。

• 何が危ないのか：認証不要で、外部からサーバー上の任意のコードを実行されるおそれがある。実行に至らなくても、サーバーのメモリからパスワードやAPIキーなどを読み出される可能性が示されている
• どこが危ないのか：特定のアプリではなく、PHPという言語の実行エンジンそのものに欠陥がある。そのため、WordPress・EC-CUBE・Drupal・自作システムなど、PHPで動くあらゆるWebサイトが対象になりうる
• 深刻度：PHP開発チームの評価でCVSS v4.0のスコア9.2（10点満点）。評価機関によってはCVSS v3.1で9.8とされている
• 対策：修正版（PHP 8.5.12／8.4.27／8.3.36／8.2.35）への更新が唯一の完全な対策。設定変更による回避策は攻撃経路を減らすだけで、安全にはならないと公式が明言している

PHPは世界のWebサイトの多くで使われている言語で、特に中小企業のホームページやブログで定番のWordPressもPHPで動いています。「うちはPHPなんて使っていない」と思っていても、レンタルサーバーで動くWordPressサイトなら、ほぼ確実にPHPが使われています。これが、今回の騒動がIT企業だけでなく、あらゆる業種に広がった理由です。

発見から公開まで｜PHP2Shell事件の時系列

今回の事件の特徴は、修正版の公開前に情報が漏れ、攻撃の試行が始まってしまった点にあります。セキュリティ情報をまとめているpiyologの整理をもとに、主な流れを追います（出典：piyolog）。時刻表記は出典の記載に従っています。

• 2024年：PHPの外部監査の過程で、メモリ不足（OOM）に関する問題の兆候が見つかる。ただし具体的な攻撃経路は見つからず、修正方針の合意も進まないまま停滞
• 2026年7月30日：セキュリティ企業のCalifがPHPの監査を開始
• 8月11日：Califが、2024年と同じ根本原因によるリモートコード実行を報告。同日、OpenAIも独立に同じ原因を報告
• 8月24日・9月18日：Wiz、OpenAIが追加の攻撃経路を報告
• 10月17日：Amazonが自社のハニーポット（おとりのサーバー）網で、悪用の試行を観測。公表の4日前
• 10月20日：PHP公式が「重大なセキュリティリリースを10月21日14時（UTC）に公開する」と予告。同日、CVE番号が誤った情報付きで出回り、エンバーゴ（公開前の情報管理）下の脆弱性の存在が漏えい
• 10月21日：IPA（情報処理推進機構）が日本時間23時のリリースに向けた「事前準備のお願い」を公開。国内でも多くの事業者が予防的なメンテナンスを告知
• 10月21日 23時（日本時間）：PHP公式が修正版を公開
• 10月22日：IPAとJPCERT/CCが注意喚起を公開。公開された検証コード（PoC）を使った攻撃の試行が各所で観測される

本来、重大な脆弱性は修正版の準備が整うまで関係者の間だけで共有され、修正版と同時に公表されます。今回はその前に存在が知れ渡り、修正版の公開を待たずに攻撃者が動き出した可能性があるため、各社は「公開と同時に即日対応」「対応が間に合わなければサイトを止める」という判断を迫られました。

AIが脆弱性の発見に使われた事件でもある

もう1つの特徴は、AIが脆弱性の発見に大きく関わったことです。piyologの整理によると、CVEの記録ではWizとCalif.ioが2件とも報告者、OpenAIも報告者・発見者として名を連ねています。Wizは、AIモデルを脆弱性の発見、攻撃コードの開発、修正の検証に使ったとしています（出典：piyolog）。

2024年の監査では攻撃経路まで見つけられなかった問題が、2026年にはAIの助けを借りて複数の組織から相次いで報告されました。Claude MythosやGPT-5.4-Cyberの記事でも触れたように、AIは守る側の道具であると同時に、古いソフトウェアに眠っていた欠陥を掘り起こすスピードを一気に上げています。今回の件は、その影響が社会インフラ規模で表れた最初の大きな事例の1つと言えます。

2件の脆弱性の仕組み｜CVE-2026-109618とCVE-2026-109619

技術的な詳細は専門家向けの内容ですが、経営者・担当者として押さえておきたいポイントに絞って説明します。内容はPHP公式とセキュリティ企業Qualysの解説に基づきます（出典：PHP公式／出典：Qualys）。

CVE-2026-109618：メモリ不足時の後片付けの欠陥

PHPがリクエストを処理している最中にメモリ不足（OOM）で処理が打ち切られると、リクエスト用のデータが中途半端な状態で残ります。その後の終了処理が、この不完全なデータを正常なものとして扱ってしまうのが問題です。攻撃者は大きなデータを送りつけてわざとメモリ不足を起こし、この欠陥を突くことができます。

特に危険とされているのが、Apacheのモジュール版PHP（mod_php）です。既定の設定のままで、アプリケーションのコードが動く前に、認証なしのHTTPリクエストでリモートコード実行に至ることが実証されたとされています。つまり、サイトのプログラムをどれだけ丁寧に作っていても防げません。

CVE-2026-109619：リクエストをまたいで残る古い状態の欠陥

PHPは同じプロセス（ワーカー）で次々とリクエストを処理します。このとき、前のリクエストが使っていたメモリを指す内部の状態がリセットされずに残り、メモリ自体は解放されてしまう（解放後使用、use-after-free）という欠陥です。同じワーカーで処理される次のリクエストが、この古い状態を使ってしまうおそれがあります。

リモートコード実行が確認された経路としては、セッションのアップロード進捗機能（session.upload_progress）を使う経路などが挙げられています。研究者は、認証なしでPHPワーカーのメモリの中身を読み出せることも示しており、パスワード、トークン、APIキーが漏れるおそれも指摘されています。

影響を受ける実行環境

PHP公式によると、Webリクエストを処理するPHPの実行環境として、PHP-FPM、Apacheのmod_php、php-cgi、FrankenPHP、LiteSpeedが影響を受けるとされ、中でもmod_phpのリスクが最も高いとされています。PHP-FPMでも、アプリケーションの条件次第でリモートコード実行が検証されています（出典：PHP公式）。

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

PHP公式が公開した修正版は次の4つです（出典：PHP公式 ニュースアーカイブ）。

• PHP 8.5系：8.5.12 未満が影響あり → 8.5.12 に更新
• PHP 8.4系：8.4.27 未満が影響あり → 8.4.27 に更新
• PHP 8.3系：8.3.36 未満が影響あり → 8.3.36 に更新
• PHP 8.2系：8.2.35 未満が影響あり → 8.2.35 に更新（8.2系は2026年12月31日にサポート終了予定）

注意したいのは、サポートが終了したPHP 8.1以前にも影響があることです。報告者のWizは、PHP 5.4以降のほぼすべてのバージョンが少なくとも1件の脆弱性の影響を受けるとしています。PHP開発チームは深刻度を踏まえて7.4・8.0・8.1向けに最小限の修正ソースを公開しましたが、これはソースから自分でビルドする利用者向けです。古いPHPのまま運用しているサイトは、レンタルサーバー会社やOSベンダーの対応を確認するか、サポート中のバージョンへの移行が必要です（出典：piyolog）。

また、LinuxディストリビューションのPHPパッケージは、修正を取り込みながらバージョン番号を変えない（バックポート）ことがあります。「バージョン番号が古いから未対策」とは限らず、逆に「最新に見えるから安全」とも限りません。使っているOSやサーバー会社の告知で、修正済みかどうかを確認するのが確実です。

セキュリティ企業Qualysが自社の顧客環境で調べたデータでは、検出したPHPのうちバージョンが判明したものの約71%が、すでにサポートが終了した5.4〜8.1系だったとされています（出典：Qualys）。「作ったきり何年も更新していないサイト」が世界中に大量に残っていることが、今回のリスクを大きくしています。

国内への影響｜200を超える組織がサービスを停止

国内では、修正版の公開が日本時間の夜23時だったこともあり、10月21日の夜から22日にかけて、多くの組織がWebサイトやサービスを予防的に一時停止しました。

政府・公的機関の動き

• 首相・国家サイバー統括室：10月21日、高市早苗首相がXで修正アップデートへの大至急の対応を呼びかけ（出典：ITmedia NEWS）
• IPA：10月21日に「事前準備のお願い」、22日に注意喚起を公開。更新までの暫定対策やアクセス制限を検討し、有効な暫定対策が難しい場合は外部からのアクセス遮断やサービスの一時停止も判断するよう求めた（出典：IPA）
• JPCERT/CC：10月22日に注意喚起を公開。対策とあわせて、すでに侵害されていないかの確認も求めた（出典：JPCERT/CC）

情報セキュリティの注意喚起に首相自らが言及するのは異例で、それだけ影響範囲が広く、対応の時間が限られていたことを示しています。

サービスを止めた組織の広がり

piyologは、告知で確認できたサービス停止の組織を211組織（10月23日午前時点）と整理しています。国の機関、自治体、銀行・証券、鉄道・航空、大学、放送局、ゲーム、動画配信・出版、EC・チケット、ホスティング・ITサービス、芸能・音楽、各種団体と、業種を問わず広がりました（出典：piyolog）。報道では、保育園向けSaaSのコドモン、BASE、Cygames、ニコニコ、pixiv、静岡銀行などが予防的に公式サイトやサービスを一時停止したと伝えられ、pixivなど一部はすでに再開しています（出典：ITmedia NEWS）。

ここで誤解してはいけないのは、サービスを止めたこと＝攻撃の被害を受けたこと、ではないという点です。多くは修正の適用や確認のための予防的な措置です。むしろ、リスクを見極めて一時停止を判断できたことは、セキュリティ対応として適切な動きだったと言えます。

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

中小企業にとって最も身近なのが、レンタルサーバー会社の対応です。さくらインターネット、エックスサーバー、ロリポップ!、ConoHa WING、お名前.comなど主要各社は、10月22日までに提供中のPHPバージョンへの修正の適用を進めたと告知しています。一方で、ごく古いPHPバージョンは修正を検証中としている会社や、緩和策の案内にとどまる会社もあります（出典：piyolog）。

共用のレンタルサーバーなら、基本的にはサーバー会社が修正を適用してくれます。ただし、サーバーの管理画面で古いPHPバージョンを選んだままになっている場合や、VPS・専用サーバー・クラウドを自社や制作会社が管理している場合は、自分たちで対応しなければなりません。

悪用の状況｜攻撃の試行は急増、成功の確認は限定的

10月23日時点の情報では、攻撃の「試行」は世界中で大量に観測されている一方、攻撃が「成功」した確かな事例はまだ限られているというのが全体像です（出典：piyolog）。

• 試行の観測：Amazonは公表前の10月17日から試行を観測。Cloudflareは、公表後短時間で試行件数が数十万件から数百万件規模に急増したとしています。そのほか複数のセキュリティ企業が、公開された検証コードを使った試行や、Webシェル（遠隔操作用の不正プログラム）の設置を狙った試行を観測しています
• 悪用を観測していないとする機関：米国のCISAは注意喚起の時点で悪用を観測しておらず、10月23日朝時点では悪用が確認された脆弱性の一覧（KEV）にも登録していません。ほかにも、自社の環境では悪用を観測していないとするセキュリティ企業があります
• 公開された検証コードの評価：インターネット上には悪用できると主張するコードが大量に出回っていますが、特定の環境でしか動かないものが多く、本物の攻撃コードはごく一部という分析もあります

「大量の攻撃が成功している」わけではないものの、検証コードが改良されれば状況は急速に悪化しうると各機関は警告しています。「まだ大丈夫そうだから様子を見る」ではなく、「今のうちに確実に更新する」のが正しい判断です。

中小企業が今すぐやるべきこと｜5つの確認と対策

ここからは、自社のホームページやECサイト、予約システムなどを持つ中小企業が、具体的に何をすればよいかを整理します。IT担当者がいない会社でも、少なくとも「誰に確認するか」は今日中に決めてください。

1. 自社のサイト・システムでPHPが使われているかを洗い出す

まず、会社で運用しているWebサイトとシステムを一覧にします。コーポレートサイト、採用サイト、ECサイト、ブログ、予約・問い合わせシステム、社内の業務システムなどです。WordPressやEC-CUBEで作ったサイトはPHPで動いています。分からない場合は、制作会社や保守会社に「PHPを使っているか、使っているならバージョンは何か」を問い合わせます。キャンペーン用に作って放置している小さなサイトこそ見落としやすいので注意してください。

2. サーバーの管理者を確認し、修正済みかどうかを聞く

次に、そのサイトが動いているサーバーを「誰が管理しているか」を確認します。

• 共用レンタルサーバー：サーバー会社の告知ページで対応状況を確認する。管理画面で選んでいるPHPのバージョンが修正の対象に入っているかも見る
• VPS・専用サーバー・クラウド：自社または制作会社・保守会社がOSのパッケージ更新を行う必要がある。更新後は、PHPのプロセスを再起動しないと修正が反映されない点にも注意
• SaaS（ECカート、予約サービスなど）：基本的には提供会社が対応する。提供会社の告知を確認する

3. 古いPHPバージョンは、この機会にサポート中のバージョンへ移す

PHP 8.1以前で動いているサイトは、今回の修正の対象外になっている場合があります。サーバー会社が独自の修正を当ててくれていても、今後また別の脆弱性が見つかれば同じ問題が起きます。テーマやプラグインの互換性を確認したうえで、サポート中のPHP 8.3以降への移行を計画しましょう。8.2系も2026年12月31日にサポート終了予定です。

4. すぐに更新できないなら、一時停止やアクセス制限も選択肢に

PHP公式は、更新できない場合の緩和策として、メモリ上限の設定変更やセッションのアップロード進捗機能の無効化などを挙げていますが、これらは攻撃経路を減らすだけで安全にはならないと明言しています（出典：PHP公式）。IPAも、有効な暫定対策が難しい場合は外部からのアクセス遮断やサービスの一時停止の要否を判断するよう求めています（出典：IPA）。WAF（Webアプリケーションファイアウォール）のルールで既知の攻撃を防ぐ製品も出ていますが、こちらも補完策という位置付けです。

コーポレートサイトが数日止まる損失と、改ざんや情報漏えいが起きた場合の損失を比べれば、一時停止は十分に合理的な判断です。今回、多くの大企業や金融機関が予防的に停止したのも同じ考え方です。

5. 更新したら、侵害の痕跡がないかも確認する

JPCERT/CCは、対策とあわせて侵害の有無を調べるよう求めています。確認の観点として、不自然に長い・異常な形式のセッションCookieが設定されていないか、不審なファイルアップロード形式のリクエストの前後でPHPのメモリ上限エラーやHTTP 500エラーが出ていないか、PHPのワーカーが予期せず異常終了・頻繁に再起動していないか、などが挙げられています。ただし、痕跡が見つからなくても攻撃を受けていないとは断定できないとしています（出典：JPCERT/CC）。

ログの確認は専門知識が必要なので、制作会社や保守会社に依頼しましょう。あわせて、見覚えのないファイルやWordPressの管理者アカウントが増えていないか、サイトに不審なリンクや別サイトへの転送が仕込まれていないかも確認しておくと安心です。万一に備えて、サイトとデータベースのバックアップが取れているかも、このタイミングで点検してください。

今回の事件から中小企業が学ぶべき3つの教訓

教訓1：「作ったら終わり」のWebサイトは、それ自体がリスクになる

Webサイトは、公開した瞬間から世界中の攻撃者の目にさらされます。PHPやWordPress、プラグインは定期的に更新しなければ、今回のような脆弱性が見つかったときに対応できません。制作費だけでなく、更新・保守を誰がどう担うかまで含めて、Webサイトの運用を設計することが重要です。

教訓2：「誰に連絡すればいいか」を平時に決めておく

今回のように公開から対応までの時間が限られる場面で、中小企業の初動を遅らせやすいのは、技術的な対応そのものより「うちのサイトはどこのサーバーで、誰が管理しているのか」が分からないことです。サイト・システムの一覧、サーバーの契約先、制作・保守会社の連絡先を1枚にまとめておくだけで、緊急時の初動は大きく変わります。中小企業の情報セキュリティ入門で紹介している基本対策とあわせて整えておきましょう。

教訓3：AI時代は、脆弱性が見つかるスピードが上がる

今回の脆弱性は、AIを活用した調査で相次いで見つかりました。今後も、長年使われてきたソフトウェアから重大な欠陥が次々と見つかる可能性があります。「見つかったらすぐ更新できる」状態を保つことが、これからのセキュリティ対策の基本になります。AIツール自体を狙った攻撃についてはAIツールのサプライチェーン攻撃の記事も参考にしてください。

まとめ：PHP2Shellは「今すぐ更新」が唯一の正解

• PHP2Shellは、2026年10月21日に修正版が公開されたPHPの重大な脆弱性2件（CVE-2026-109618／CVE-2026-109619）。認証なしで外部からコードを実行されるおそれがある
• PHPの実行エンジン自体の欠陥のため、WordPressなどPHPで動くサイト全般が対象になりうる。特にApacheのmod_phpが危険
• 修正版は8.5.12／8.4.27／8.3.36／8.2.35。設定変更による回避策は不完全で、更新が唯一の完全な対策
• 国内では首相の呼びかけや200を超える組織の予防的停止など、社会的な影響が広がった。停止＝被害ではない
• 攻撃の試行は急増中。自社のサイトを洗い出し、サーバー管理者に修正状況を確認し、古いPHPは移行を計画する

「自社のサイトがどこで動いていて、誰が更新しているのか分からない」という状態こそ、今回の事件で最も危ういポイントです。この機会に、自社のWebサイトとシステムの棚卸しから始めてみてください。DXの基本的な考え方はDXとは？でも紹介しています。

株式会社Sei San Seiでは、ドメイン・サーバー管理費込みで月額1万円から始められるWeb制作サービス「おいで安」を提供しています。「作ったきりで更新できていないサイトを見直したい」「サーバーの管理まで任せられる体制にしたい」といったご相談も、お気軽にお問い合わせください。

よくある質問

Q1. PHP2Shellとは何ですか？

PHP2Shellは、2026年10月21日にPHPの開発チームが修正版を公開した2件の重大な脆弱性（CVE-2026-109618とCVE-2026-109619）の通称です。PHPの実行エンジン自体の欠陥で、認証なしに外部からサーバー上で任意のコードを実行されたり、メモリ上のパスワードなどを読み出されたりするおそれがあります。深刻度はCVSS v4.0で9.2と評価されています。

Q2. WordPressのサイトも影響を受けますか？

WordPressはPHPで動いているため、PHPが修正版に更新されていなければ影響を受けうるとされています。脆弱性はWordPress本体やプラグインではなくPHP側にあるため、WordPressを最新にしても解決しません。共用レンタルサーバーなら多くはサーバー会社が修正を適用済みですが、選択しているPHPバージョンが対象に入っているかを告知で確認してください。

Q3. 修正版のバージョンはいくつですか？

修正版はPHP 8.5.12、8.4.27、8.3.36、8.2.35です。サポートが終了した8.1以前にも影響があり、7.4・8.0・8.1向けには最小限の修正ソースのみが公開されています。LinuxのOS標準パッケージは番号を変えずに修正を取り込む場合があるため、バージョン番号だけで判断せず、OSやサーバー会社の告知で修正済みかを確認するのが確実です。

Q4. すぐに更新できない場合はどうすればよいですか？

PHP公式はメモリ上限の設定変更やセッションのアップロード進捗機能の無効化などの緩和策を示していますが、攻撃経路を減らすだけで安全にはならないとしています。IPAも、有効な暫定対策が難しい場合はアクセス制限やサービスの一時停止を検討するよう求めています。WAFの導入は補完策として有効ですが、できるだけ早く更新することが前提です。

Q5. サイトを止めた企業は攻撃の被害を受けたのですか？

いいえ、サービスを一時停止したことが、そのまま攻撃の被害を意味するわけではありません。多くは修正の適用や影響の確認のための予防的な措置です。修正版の公開が日本時間の夜だったため、確実に対応するまで止めるという判断をした組織が多くありました。リスクを見極めて一時停止できたことは、適切なセキュリティ対応の1つと言えます。