PHP2Shellで日本のサイトはなぜ止まったのか――見つけるのはAIの速さ、直すのは人の速さ

はじめに#

2026年10月21日、国内では官公庁や鉄道会社、ECサービスなどが相次いでWebサイトやサービスを止めました。多くは、プログラミング言語PHPそのものに見つかった2件の重大な脆弱性（攻撃に悪用できるソフトウェアの欠陥。通称「PHP2Shell」）への予防的な対応とみられます。高市早苗首相もXで「今夜に対応して頂きたい大至急のお願い」として、修正版を速やかに適用できるよう準備を求めました。速やかな適用が難しい場合は、Webサイトの一時停止も「リスクを低減させるための有効策の一つ」だとしています。

報道では「AIが見つけた脆弱性」として紹介されることの多い事案ですが、AIシステムの開発に携わる筆者が注目したのは、見つかった後に起きたことです。

本稿の主張はこうです。AIが速くしたのは、脆弱性を「見つける」ことと、手がかりから攻撃方法を「組み立て直す」ことです。一方、「どう直すかを決める」ことと、直したものを各組織が自分のサーバーに「当てる」（反映する）ことは、いまも人と組織の速さで進みます。10月21日、日本の多くの組織は、この差を「止める」ことで埋めるしかありませんでした。以下、2026年10月25日時点の公開情報をもとに整理します（英語の資料からの引用は筆者訳）。

対策だけを知りたい方は、「7. 速度差を縮める対策」からお読みください。

記事概要#

• 見つける：AIを使った調査で、3つの組織が独立に同じ問題にたどり着きました。公開前の警告を手がかりに、独力で再発見したとされる企業もあります。
• 直す：PHPの開発者は2024年に、2件のうち1件の兆候をつかんでいましたが、当時は具体的な攻撃方法が見つからず、その後もセキュリティチームは修正方針を数か月にわたって決めきれませんでした。
• 当てる：日本では、CVE番号が出回ってから修正版が出るまでの約23時間、多くの組織には当てるものがありませんでした。修正版が出た後も、再開や適用には1時間あまりから半日以上かかり、サポートが終わった古いPHPで動くサイトも多く残っています。
• 対策：誰が修正を当てるのかを把握し、止める基準を事前に決め、保守契約に修正の期限を書き込み、パスワードやAPIキーを変更することです。

1. 10月21日に何が起きたのか#

PHP2Shellは、PHPの内部処理にあった2件の不具合です。世界共通の管理番号（CVE番号）はCVE-2026-109618とCVE-2026-109619で、共通の評価基準ではどちらも10点満点中9.2とされています。外部の第三者が、ログインなしでサーバー上の任意のプログラムを実行できる恐れがあり、PHPの勧告によると、後者にはメモリの内容が外部に漏れる恐れもあります。

Webリクエストを処理するPHPは動かし方によらず影響を受け、PHPは「更新だけが安全な選択肢」だとしています。Google Cloudによると、影響はPHP 5.4以降の幅広いバージョンに及びます。修正版は8.5.12、8.4.27、8.3.36、8.2.35で、それぞれの系列でこれより前のバージョンが対象です。なお10月23日には、修正版でも特定の設定のときに影響する関連の脆弱性（CVE-2026-115560）が公表されました。こちらは次の定期リリースで修正される予定です（7章の「技術担当者向けの補足」を参照）。

主な経緯は次のとおりです（日時は日本時間。Amazonの観測日は出典どおり）。

以下では、この流れを①見つける、②攻撃方法を組み立てる、③どう直すかを決めて修正版を作る、④各組織が当てる、の4つの工程に分けて見ていきます。

2. 見つける：AIで「探す」と「たどり直す」が安くなった#

Califの調査は、OpenAIが2026年6月に始めた「Patch the Planet」の一環でした。重要なオープンソースソフトウェアをAIで調べる取り組みです。OpenAIによると、Califは同社のモデル「GPT-5.6 Sol」を使って重大な欠陥を見つけました。Califは、一般に提供されているモデルだけを使い、特別なツールは使っていないと説明しています。PHP Foundationによると、OpenAI自身も独立に同じ根本原因を報告しました（報告日は公表されていません）。Wizも、自社のツールとGoogleの「Gemini 4 Argon」、GPT-5.6 Solを使って8月19日に見つけ、24日に報告したとしています（OpenAIは、これも独立した発見だと説明しています）。

AIエージェントを開発する立場から見ると、脆弱性探しがAIに向いている理由ははっきりしています。「この入力で攻撃が成功するか」は、試せばすぐに結果が出ます。答え合わせを自動でできる作業は、計算機を増やすほど速く、並列に進められます。

この速さは、見つかった問題を「たどり直す」ときにも働きます。Chainguardは、修正済みのソフトウェア一式を予定より6時間以上早く公開しました。同社のCEOは、直前の金曜日に警告を受けた後、最先端のAIモデルなどを使って独力でこの脆弱性にたどり着いたと説明したと報じられています。同社は攻撃が始まったと判断して早めに公開したと説明し、PHP Foundationは協調した公開を損なったと批判しています。警告の内容は不明ですが、手がかりがあれば短期間でたどり着ける場合があることを示す例だと筆者は考えます。Amazonも、修正内容や注意喚起から攻撃コードを作る費用が、AIを使った分析で下がったと指摘しています。

今回は、CVE番号の流出や攻撃動画の誤公開といった人の側のつまずきも重なりました。PHP Foundationによると、動画はCalifが誤って公開したもので（削除後もコピーが広まりました）、攻撃コードの開発が早まる一因になったといいます。組み立て直す費用が下がった今、こうしたつまずきの代償は大きくなっていると筆者は考えます。

ただし、AIだけで何でも見つかるわけではありません。Califは、簡単な指示で「すべてのバグ」を掘り当てられるモデルは「少なくとも今のところ」ないとしています。過去の脆弱性の経緯をよく知るPHPに絞ったことを挙げて、「標的を知る」ことはいまも重要だと説明しています。それでもOpenAIは、同様の発見が今後数か月で急増すると見込んでいます。

3. 直す：止まっていたのは「決める」こと#

PHP Foundationによると、2件のうちメモリ不足時の処理の問題は、2024年に兆候がつかまれていました。同団体が契約する開発者が、外部監査で指摘された別の問題を直す中で気づいたものです。ただ当時は、攻撃に使える可能性が理論上は指摘されたものの、具体的な攻撃方法は見つからず、影響の明らかな他の問題が優先されました。

修正案は複数作られましたが、既存のサイトとの互換性を損なう案、サイトを止める攻撃の余地を新たに生む案、PHPに後付けする多くの拡張機能に変更を迫る案と、いずれも一長一短でした。全員の合意で決めるセキュリティチームは選びきれず、作業は数か月にわたって止まっては再開しました。PHP Foundationはこの遅れを「構造的な失敗（structural failure）」と呼び、意思決定の仕組みと資源不足が原因だったと認めています。

8月11日の報告後は最優先の課題となり、複数の開発者が専従で取り組みました。修正版の公開まで約10週間かかりましたが、配布元などに修正を事前に渡す工程も含め、協調して公開する際によく使われる90日という目安の範囲内で、この規模の修正としては標準的な期間だと筆者は考えます。

筆者が重要だと考えるのは、次の2点です。1つ目は、「見つける」と違い、「どう直すか」には試して確かめられる正解がないことです。PHP Foundationも、ツールにできないのは「エンジンの長年の設計判断について、正しい直し方を決めること」だと書いています。同団体は報告の検証などにAIを使っていますが、判断はすべて人が下しているといいます。

2つ目は、2024年に修正が後回しになった理由が「具体的な攻撃方法が見つかっていない」ことだった点です。その攻撃方法を、2026年にAIを使った調査が見つけました。「まだ攻撃方法がないから後回し」という判断は、AIによって通用しにくくなっています。これは、古いPHPを「今のところ問題ないから」と使い続けている企業にも当てはまります。

見つかる数が増えるほど、決める側の負担は重くなります。PHP Foundationは、7月以降に15件のCVEを公開し、無効や重複などの100件超の報告にも対応したとしています。同団体は意思決定の見直しと増員を進め、PHPに依存する企業や政府などに資金面の支援を求めています。

4. 当てる：日本の組織は「止める」で時間を買った#

修正版の前：当てるものがなかった#

10月21日に日本の組織が直面したのは、「当てるのが遅い」という問題ではありませんでした。CVE番号が出回った0時ごろから修正版が出た23時ごろまでの約23時間、多くの組織には当てるべき修正版そのものがなかったのです。Amazonによれば最初の攻撃コード（PoC）とされるものが現れた11時ごろから数えても、約12時間あります（PHP Foundationは、公開時点で実際に機能する攻撃コードは確認していないとしています）。

この間に確実に取れる手は、止めることでした。セキュリティブログ「piyolog」は、サービスやサイトを止めたり緊急メンテナンスを告知したりした組織として、各組織の告知から確認できた246組織を挙げています（25日時点。告知でPHPに触れていない組織も含み、その一部は報道がPHPへの対応として伝えたものです）。BASEは15時50分から、厚生労働省の介護サービス情報公表システムは16時から止めました（後者の告知は「緊急の脆弱性対応のため」としています）。報道によれば、地方銀行や証券会社の一部サービスにも停止が及びました。

海外でも、オランダでは国家サイバーセキュリティセンター（NCSC）が予防措置として自らのサイトを一時停止し、政府ポータルなどもこれに続いたと報じられています。日本だけの反応ではありません。IPAも22日の注意喚起で、有効な暫定対策が難しい場合は、外部からのアクセス遮断やサービスの一時停止が必要か判断するよう求めています。その後、NCSCは23日に、悪用は複雑で、大規模に悪用される可能性は当初の見立てより小さいとの見方を示しました。ただ、それは修正版の公開後に分かったことです。筆者は、21日の時点で止めた判断は妥当だったと考えます。一方で、多くの組織がその判断を公開直前の数時間で下さなければならなかったことから、止める基準を事前に決めておくことの大切さが分かります。

修正版の後：1時間あまりから半日以上#

修正版が出た後の速さは、組織によって分かれました。Chatworkは21日23時ごろから緊急メンテナンスを行い、22日0時15分ごろに終えました。コドモンは、修正プログラムの適用と安全確認を終えたとして、3時22分に一部を除くサービスを再開しています。エックスサーバーは22日1時10分に適用を始め、6時45分にPHP 8.2〜8.5の全対象サーバーへの適用を終えたと案内しています（7.4〜8.1は12時、5.6〜7.3は14時に完了）。多数のサーバーを抱えるこの事業者では、修正版の公開から、サポート中のバージョンへの適用だけで約8時間、古いバージョンまで含めると約15時間かかったことになります。

取り残されるサイト#

問題は、その外側に取り残されたサイトです。GMOプライム・ストラテジーは、東証上場企業3,941社の公式・グループ・関連サイト（約2.5万サイト）を4月に調べ、2026年6月に結果を公表しました。PHPのバージョンを外部から確認できた2,654サイトのうち、70.1%がサポートの終了したバージョンで動いていました。同じ調査では、WordPressの修正版公開から約1週間後も、サポート対象の6.x系サイトの17.7%が最新のマイナー更新を当てていませんでした。

世界全体でも、W3Techsの10月25日時点の集計では、PHPを使うサイトのうちPHP 7が26.8%、PHP 5が7.7%です。サポートが終わったPHP 8.0と8.1を加えると、約半数（筆者の試算で約48%）がサポート終了版です。PHP 8.2も12月31日でサポートが終わります。今回は7.4〜8.1向けにも最小限の修正コードが公開されましたが、通常の修正版はなく、自ら組み込むか配布元などの対応を待つ必要があります。

攻撃と適用には、速さの単位の違いもあります。米Rapid7が2026年7〜9月期に新たに悪用を確認した深刻度の高い脆弱性（43件）では、公になってから悪用までが平均3日でした。一方、トレンドマイクロが自社製品の利用環境から集計したデータでは、日本の組織の平均パッチ適用時間は27.5日（2024年2〜12月）で、地域別では欧州に次ぐ速さでした。同社の2024年上半期の集計では36.4日で、地域別で最も長いとされており、集計によって順位は変わります。対象も測り方も違うので単純には比べられませんが、攻撃は「日」、適用は「週」の単位で動いています。日本だけの問題というより、構造的な問題だと筆者は考えます。

当てる速さは、委託先にも左右されます。サーバー会社の対応完了を待って再開するとした組織もありました（Webセキュリティ診断センターのまとめ）。

5. 速度差をまとめると#

①見つける、②攻撃方法を組み立てる、はAIで速く安くなりました。③どう直すかを決める、④各組織が当てる、は人と組織の速さのままです。攻撃の試みは②の速さで、修正版より先に動き出します。図4は、10月21日の動きを3つの流れで並べたものです。

修正版がない約23時間のうち、約12時間は、攻撃コード（PoC）とされるものがすでに出回っていました。この差が埋まらない限り、10月21日のような夜は繰り返されると筆者は考えます。

6. よくある疑問#

Q1. 今回の攻撃にAIは使われたのですか？

A. 公開情報からは断定できません。米The Recordによると、watchTowrは、AIの助けを借りて作られたPoCツールによる攻撃の試みを観測しているとしつつ、21日時点では「成功した者はまだいない」と述べています。Rapid7の2026年7〜9月期の報告でも、AIを運用面の要素として挙げた脅威報告は8%で、記録された事例では標的や目的を決めていたのは人でした。今回の攻撃側のAI活用は、示唆はあるものの未確認です。

Q2. AIが攻撃者より先に見つけたのなら、守る側が有利ではないのですか？

A. OpenAIは「私たちの知る限り、攻撃者より先にフロンティアAIがこれらの脆弱性を見つけた」としていますが、第三者が確かめたものではありません。また、少なくともメモリ不足時の処理の問題については、最初の兆候をつかんだのは2024年の人の開発者でした。守る側が得た約10週間の余裕は修正の準備に使われ、最後は公開前の情報の流出もあって、公開が1日前倒しになりました。余裕を生かせるかどうかは、直す速さと当てる速さで決まります。

Q3. 国内で被害は出ているのですか？

A. Webセキュリティ診断センターのまとめ（25日時点）によると、国内でPHP2Shellが原因だと当事者が公表した被害はありません。オランダのNCSCも23日、オランダ国外で悪用の可能性を伝える報告を1件把握しているものの、攻撃の成功は確認されていないとしています。コドモンなど停止した組織の一部も、告知の時点では不正アクセスや情報漏えいは確認されていないとしています。なお、22日に「PHPの脆弱性を標的としたサイバー攻撃」による不正アクセスを公表したバルテックは、その後これを「誤報」と訂正し、自社サービス自体の脆弱性を突かれたものだと説明しています。また、メモリの内容を読まれた場合は痕跡が残りにくいと考えられるため、「確認されていない」が「なかった」とは限りません。

7. 速度差を縮める対策#

①見つける速さと②組み立てる速さは、企業には変えられません。変えられるのは、④当てる速さと、④が間に合わないときの備えです。

今週中にやること（担当者がいなくてもできる）#

1. 自社のWebサイトとシステム（予約、EC、業務システムを含む）を書き出し、それぞれ誰が管理しているか（レンタルサーバー会社、制作会社、クラウドサービス、自社）を1行で書く
2. レンタルサーバーでWordPressを使っているなら、事業者の告知を確認し、WordPressの「ツール」→「サイトヘルス」→「情報」→「サーバー」でPHPのバージョンを確かめる。8.1以前なら、バックアップとWordPress・プラグインの更新をしてから切り替える（8.2も12月31日でサポートが終わります）
3. 制作会社やクラウドサービスに任せているなら、下の文面で問い合わせる
4. 管理画面やデータベースのパスワード、生成AIなど外部サービスのAPIキー（外部サービスを使うための合鍵にあたる文字列）を変更し、APIキーには利用上限額を設定する

問い合わせ文の例：

件名：PHPの脆弱性（10月21日公開）への対応状況のご確認
弊社が利用している〇〇について、10月21日に公開されたPHPの脆弱性（CVE-2026-109618、CVE-2026-109619）への対応状況を教えてください。
1. 〇〇ではPHPを使っていますか。使っている場合、バージョンは何ですか。
2. 修正版の適用はいつ完了しましたか（未完了の場合は予定日時）。
3. 10月17日以降の不正アクセスの調査と、パスワードやAPIキーなどの変更は実施しましたか。

今月中に決めておくこと（次の緊急時に備える）#

5. 止める基準を3段階で決める：全部止める／個人情報を扱う部分（問い合わせフォームや会員ログインなど）だけ止める／様子を見る。決める人と、その代理も決める
6. 夜間・休日の連絡先（サーバー会社や制作会社の緊急窓口）と、確認する情報源（IPA、JPCERT/CC、契約先の障害情報ページ）を1枚にまとめる
7. 保守契約に「緊急の脆弱性は○時間以内に修正を当て、報告する」と書き込む
8. 修正が出るまでの時間稼ぎとして、WAF（攻撃らしい通信を手前で止める仕組み）を検討する。今回Cloudflareは、修正版の公開より前の21日12時ごろから、無料プランを含むWAFの利用者向けに防御ルールを自動で適用しました（ただし、完全な対策ではなく、PHPの更新は引き続き必要です）

技術担当者向けの補足#

• 修正版を適用した後、PHPのワーカーを再起動する
• 少なくとも10月17日以降のログで、「PHP_SESSION_UPLOAD_PROGRESS」を含むPOSTリクエストや、Webサーバーからの不審なプロセス起動、ファイルの変更を確認する（Amazon、Huntressの推奨）
• メモリの内容が漏れた場合はディスクに痕跡が残りにくいと考えられるため、データベースの認証情報、APIキー、フレームワークのセッション用秘密鍵、クラウドの認証情報の変更を検討する
• 修正版を当てたうえで、セッションの保存形式（session.serialize_handler）を実行時に切り替えているアプリケーションでは、次の定期リリースまでsession.upload_progress.enabledを0にする（10月23日に公表された関連の脆弱性CVE-2026-115560への対応。修正版にも影響します）
• 一時的な設定変更（memory_limitやsession.upload_progress.enabledの変更）だけでは、PHP2Shellに対して安全にならない。修正を当てられない環境は、外部から切り離すことを検討する

個人の対策#

今回の対応の中心は、Webサイトを運営する事業者です。一般の利用者は、次の点に気をつけてください。

• パスワード変更などを求められたら、メールのリンクではなく公式アプリや公式サイトから対応する（サービスを装った偽メールに注意）
• 同じパスワードを使い回しているなら、この機会に分ける
• 自分でブログやサイトを運営しているなら、「今週中にやること」の2を確認する

最後に#

PHP2Shellは、「AIが脆弱性を見つけた事例」として伝えられています。けれども10月21日の日本で起きたのは、見つかった後の工程がどれだけ人と組織の速さに縛られているかを示す出来事でした。AIによる発見はこれからも増え、その多くは守る側にとって良い知らせです。ただ、見つかった問題は、直され、当てられて初めて守りになります。

対象はWebサーバーではなくAIそのものですが、筆者の所属するElithでも、AIセキュリティサービスと、AIセーフティプラットフォーム「GENFLUX」を提供しています。AIセキュリティサービスは、攻撃を想定した入力でAIシステムの弱点を洗い出すレッドチーミングと、運用中のAIの入出力を制御するガードレールを組み合わせたものです。見つけて終わりにせず、直して当てるまでを一続きで考える必要は、AIを守る場面でも変わりません。

次に同じような夜が来たとき、誰が止めると決め、誰に修正を頼み、何を確かめるのか。記憶が新しいうちに、それを1枚の紙に書いておくことをお勧めします。

参考資料#

• The PHP Foundation「Today's PHP Security Release, and How We're Strengthening PHP Security」（2026年10月21日）
• PHP「News Archive 2026」（2026年10月20〜23日の告知・修正版・勧告）
• PHP「Security advisory GHSA-6wmf-4rv5-p3rp」
• PHP「Supported Versions」
• Tenable「php2shell (CVE-2026-109618, CVE-2026-109619) FAQ」
• Google Cloud「Responding to core PHP vulnerabilities」
• Amazon Threat Intelligence「PHP2Shell exploitation prior to public disclosure in MadPot」
• Huntress「php2shell, Leaked Critical PHP Vulnerabilities」
• Socket「PHP Foundation Says Chainguard Broke Security Embargo」
• Wiz「PHP2Shell」（2026年10月21日）
• Calif「PHP2Shell」（2026年10月21日）
• OpenAI「Patch the Planet: global response coordination as agents uncover critical vulnerabilities」（2026年10月21日）
• OpenAI「Patch the Planet」（2026年6月22日）
• ITmedia NEWS「PHPの「重大」脆弱性はAIが見つけた」
• ITmedia NEWS「高市総理「大至急、PHPパッチ適用を」Xで異例の要請」
• The Record「Hundreds of websites taken offline」
• ロイター（KSL掲載）「Cyber agency warns websites may go dark as PHP prepares critical fix」
• Cloudflare「Cloudflare deploys protections against php2shell vulnerability」（2026年10月21日、23日更新）
• ASCII.jp「PHPの脆弱性を狙う攻撃、数百万件に急増」
• IPA「PHPの脆弱性対策について（CVE-2026-109618、CVE-2026-109619：PHP2shell）」（2026年10月22日）
• NCSC（オランダ）「Update: PHP vulnerabilities remain a reason for immediate patching」（2026年10月23日）
• piyolog「修正予告されたPHPの2件の深刻な脆弱性についてまとめてみた」
• Webセキュリティ診断センター「PHP脆弱性で停止・メンテ中の国内サービス一覧」
• エックスサーバー「予防的な安全対策に伴う公式サイト・管理画面等の一時停止のお知らせ」（2026年10月22日）
• コドモン「サービス再開のお知らせ」（2026年10月22日）
• バルテック「不正アクセスによるお客様情報流出の可能性および一部サービス停止のお知らせ」（2026年10月22日、23日訂正）
• GMOインターネットグループ（GMOプライム・ストラテジー）東証上場企業Webサイト調査（2026年6月24日）
• W3Techs「Usage statistics of PHP」
• Rapid7「Q3 2026 Threat Update」
• トレンドマイクロ「年間サイバーリスクレポート2025年版」（2025年4月16日）
• Safeguard「After PHP2Shell: how to check if your server was already compromised」
• トレンドマイクロ「世界サイバーリスクレポート2024年版」（2024年11月13日）