2026年10月21日、Webサイトの裏側で動くプログラミング言語「PHP」の本体に、認証なしでサーバーを乗っ取られうる重大な脆弱性が2件あることが公表されました。PHP公式は同日に修正版を出し「直ちに更新するように」と呼びかけています*2。この脆弱性を最初に報告したのはセキュリティ企業のCalifで、OpenAIは「CalifがGPT-5.6 Solを使って重大な欠陥を見つけた」と発表しています*1。
PHPはサーバー側の言語が分かっているWebサイトの69.3%で使われており*7、WordPressで作った企業サイトやECサイトも当てはまります。先に結論を言うと、自社サイトがPHPで動いているなら、今日やるべきことは「PHP本体の更新」の一つだけです。プラグインやテーマの更新では塞がりません。そして今回の件は、AIが脆弱性を見つける速さに、企業の更新体制が追いつけるかが問われ始めた合図だと私は見ています。
この話題は、私もXで紹介しました。
今なら、生成AIの基礎知識から社内導入の6ステップ・定着のポイントまでを1冊にまとめた「はじめての生成AI社内導入ガイド」を無料で配布中!何から始めればいいか分からない方でも、これ1冊で導入の流れがつかめます。
目次
php2shellとは|PHPの心臓部で見つかった2つの脆弱性
今回の脆弱性は「php2shell」と呼ばれています。WordPressのプラグインのような周辺の部品ではなく、PHPという言語そのものの中にあった欠陥です。そのため、サイトのプログラムに問題がなくても、古いPHPの上で動いているだけで影響を受けえます。

番号はCVE-2026-109618とCVE-2026-109619の2件で、深刻度はどちらもCVSS v4.0で9.2です*2。PHP公式はそれぞれを「メモリ不足による破損を使った遠隔コード実行」「古い状態が残ることを使った遠隔コード実行」と説明しています*2。
| 項目 | 内容 |
|---|---|
| 呼び名 | php2shell(PHP2Shell) |
| CVE番号 | CVE-2026-109618/CVE-2026-109619 |
| 深刻度 | どちらもCVSS v4.0で9.2(Critical) |
| 起きうること | ログインなしでサーバー上の任意のプログラムを動かされる(遠隔コード実行)。他の利用者のデータがメモリから漏れる経路もある |
| 影響する版 | PHP 5.4以降のほぼすべて |
| 影響する動かし方 | PHP-FPM・mod_php・php-cgi・FrankenPHP・LiteSpeed(mod_phpが最も危険) |
| 修正版 | 8.5.12/8.4.27/8.3.36/8.2.35(2026年10月21日公開) |
| 8.1以前 | PHP公式からの更新版は出ない |
仕組みを平たく言うと、PHPがメモリ不足などで処理を途中で止めたとき、後片付けが終わらないまま「もう使わないはずのメモリ」が残ってしまう問題です。次のリクエストがそのメモリを正しいデータだと思って使うことで、攻撃者が送り込んだ内容が実行されたり、他人のパスワードやトークンが漏れたりします*4。
Wizは最新版のWordPress・Drupal・Joomlaのコンテナで、ログインなしの遠隔コード実行ができることを実証しました*4。Califも、MagentoやMediaWiki・phpMyAdmin・Nextcloud・Laravelなど幅広い製品で同じことを確認しています*5。どれも研究者による実証で、「この製品が実際に攻撃された」という意味ではない点は区別しておきます。
OpenAIとは|Patch the Planetで「守る側にAIを配る」
OpenAIはChatGPTを開発する米国のAI企業です。今回の発表で名前が出たのは、同社の最新モデルGPT-5.6 Solです*1。GPT-5.6の全体像は、以下の記事で解説しています。
GPT-5.6完全ガイド|Sol/Terra/Lunaの違い・料金・Claude Fable 5との使い分けまで徹底解説
今回の主役はモデルそのものより、OpenAIが進める「Patch the Planet」という取り組みです。広く使われているオープンソースの脆弱性を、AIを使う研究者と開発元・セキュリティ企業・政府機関で協力して見つけ、公開前に直しておく枠組みです。
OpenAIは発表で「この2か月、PHPの重大な脆弱性に対処するため、開発者・研究者・セキュリティ事業者の連合を率いてきた」と説明しています*1。修正そのものはPHPの開発者が主導し、OpenAIはWizやCloudflareなどと並んで調査・技術支援・調整を担ったという整理です*1。
| OpenAIが担ったこと | 中身 |
|---|---|
| モデルと専門家の提供 | Patch the Planetを通じてセキュリティの知見とモデルへのアクセスを提供し、修正の検証にも協力 |
| 事業者との調整 | インフラ事業者と組んで、公開前に防御策(WAFのルールなど)を準備 |
| 政府機関との連携 | ホワイトハウスのSuper Intelligence Force・国家サイバー長官室(ONCD)・CISAなど米政府の複数部門と、海外の機関に働きかけ |
| 利用者向けの道具 | 自社のPHPの版が危ないかを調べるチェッカーを、Codexのskillとして公開 |
| 守る側への支援 | 資源の少ない重要サービスの組織を中心に、Daybreak(セキュリティ用途のAI)の利用へ10億ドルの助成を約束 |
OpenAIは今回の件を「近年で最も影響の大きいセキュリティ問題の一つ」と表現しました*1。同時に「同じ能力は、攻撃者が攻撃ツールを素早く作ることにも使える」とも書いています*1。さらに「これは既に見つけて修正を進めている重大な脆弱性のうちの一部で、同様の発見は今後数か月で急増すると見ている」と明かしています*1。企業にとっては、こちらの一文のほうが重い意味を持つと私は考えます。
発見から公開までの流れ|AIが見つけて人が直した2か月半
時系列で並べると、AIが見つけたあとに人が直すまでの時間がよく分かります。日付は各社の公表資料にもとづきます。
| 日付(2026年) | 出来事 | 出典 |
|---|---|---|
| 7月30日 | CalifがPatch the Planetの一環としてPHPの調査を開始 | Calif・PHP Foundation |
| 8月1日 | Califが最初の手がかり(メモリ不足時の異常)を発見 | Calif |
| 8月11日 | CalifがPHPに最初のバグを報告。同日にOpenAIも同じ根本原因を独自に報告 | Calif・PHP Foundation |
| 8月19日 | WizがWiz Atlas・Gemini 4 Argon・GPT-5.6 Solを使い独自に発見 | Wiz |
| 8月24日 | WizがPHPのセキュリティチームに報告 | Wiz |
| 9月18日 | OpenAIが追加の攻撃経路を報告 | PHP Foundation |
| 10月20日 | CVE番号などが公開前に出回る。PHPが事前告知を出し公開日を前倒し | PHP Foundation |
| 10月21日 | PHPが修正版を公開。OpenAI・Wiz・Califが詳細を公表 | php.net・OpenAI・Wiz・Calif |
修正版が出る直前の10月21日夜、私もXで「今夜23時に修正版が出る」と注意を呼びかけました。
注目したいのは、Wizが使ったAIにOpenAIだけでなくGoogleのGemini 4 Argonも含まれている点です。Wizは「Gemini 4 Argonが発見・攻撃コードの作成・検知・修正の検証に大きく貢献した」と書いています*4。特定の1社のAIだけが見つけたのではなく、複数の最先端モデルが同じ穴にたどり着いたと見るのが正確です。
またCalifは、最初の発見について「特別な仕組みや、一般に使えないモデルは使っていない」と書いています*5。つまり研究者が普通に使えるAIで、これだけの穴が見つかる時代になったということです。これは守る側にとっての追い風であると同時に、攻撃する側も同じ道具を持っているという意味でもあります。
修正が難しかった理由
X投稿では「心臓部を大きく作り直す必要があるほど」と書きましたが、PHP Foundationの説明をもう少し正確に紹介します。2つのバグは、ほぼすべてのリクエストが通るメモリ管理とエラー処理の部分にあります。そのため直し方の案はどれも「互換性を壊す」「新たなサービス妨害(DoS)の恐れを生む」「多数の外部拡張機能に変更が要る」のいずれかの弱点を抱えていた、と説明されています*3。
実はこの問題の兆候は2024年の監査で既に見つかっていましたが、修正の方針が決まらず止まっていたことも明かされました。PHP Foundationはこれを「判断の仕組みと人手不足による構造的な失敗」と認め、多数決で決められるよう手続きを改めるとしています*3。AIが見つけても、直すのは人です。直す側の体制が弱いと、穴は残り続けます。
影響を受けるサイトの見分け方|自社が当てはまるか確認する
経営者や情報システムの担当者がまず知りたいのは「うちは関係あるのか」だと思います。判断の目安を表にまとめました。
| 自社の状況 | 影響 | やること |
|---|---|---|
| WordPressで作った自社サイト・オウンドメディア | PHPの版が古ければ受ける | サーバーのPHPの版を確認し更新 |
| レンタルサーバー・マネージドWordPress | 事業者が更新するまで受けうる | 事業者の告知を確認し、対応時期を問い合わせる |
| 自社でサーバーやコンテナを運用 | 受ける | PHPを修正版に上げ、コンテナは作り直して再配置 |
| PHP 8.1以前のまま | 公式の更新版が出ない | 8.2以降への移行を最優先で計画 |
| Shopifyなど外部のSaaSだけ | 自社で直す部分はない | 連携しているPHP製の自社システムがないか確認 |
PHP 8.2系は2026年12月31日でサポートが終わると公式に告知されています*2。今回8.2.35に上げて終わりにするのではなく、来年に向けて8.3以降への移行計画も立てておくのが安全です。
社外の制作会社にサイトを任せている場合も少なくありません。その場合は「PHPの版」「誰がいつ更新するか」「更新後に動作確認をしたか」の3点をメールで確認するだけでも、状況はかなり見えてきます。
PHPの版を確かめる方法
WordPressなら、管理画面の「ツール」→「サイトヘルス」→「情報」→「サーバー」でPHPの版を確認できます。レンタルサーバーの場合は、管理画面のPHP設定の画面に版が表示されていることが多いです。
注意したいのは、サーバーに入って php -v で表示される版と、Webサイトを実際に動かしているPHP-FPMの版が違う場合があることです。Sansecも、設定の確認は「コマンドラインではなく、PHP-FPMが処理したリクエストの中で行う」よう勧めています*8。OpenAIは版の判定を手伝うチェッカーをCodexのskillとして公開しているので、開発チームがいる企業は併せて使うと確認が早くなります*1。
自社のWebサイトや業務システムにAIを組み込みたいが、セキュリティや運用体制まで含めて設計したいという方もいるはずです。法人向けAIリスキリングサービスの導入社数No.1*の弊社デジライズが、AIコンサルティング&開発のサービス資料を無料でお送りしています。既製のAIサービスでは要件が満たせず、自社に合わせたシステム構築や環境の検討が必要な場合の進め方をまとめています。
※出典:株式会社東京商工リサーチ「法人向けリスキリングサービスに関する調査」(2026年5月/調査期間:2026年3月26日〜4月17日/調査方法:デスクリサーチおよびヒアリング/2026年3月末時点)
企業がやるべき対策|今日・今週・今月に分けて考える
PHP公式は「完全な回避策はなく、更新だけが安全な選択」と明言しています*2。そのうえで、すぐに更新できない場合のつなぎの手当ても公開されています。優先順位を時間軸で整理しました。
今日やること
- PHP本体の更新 — 8.5.12・8.4.27・8.3.36・8.2.35のいずれかへ上げる。サイトのプログラムやプラグインの更新では塞がらない
- 事業者への確認 — レンタルサーバーやクラウドの管理画面で、PHPがいつ更新されるかを確認する
- WAFの確認 — Cloudflareは無料プランを含む全プランで、10月21日3時2分(UTC)から既定で防御ルールを有効にしています*6。有料プランは遮断モードになっているかを確かめる
更新までのつなぎとして、アップロード進捗機能を切る・メモリ上限を外すといった設定変更が紹介されています。ただしPHP公式は、これらは「被害の可能性を減らすが、安全にはならない」としています*2。メモリ上限を外すと、1つのリクエストがサーバーのメモリを使い切る別のリスクも生まれます。Sansecは、WordPressなどのメンテナンスモードも、PHPがその前にリクエストを処理してしまうため防御にならないと注意しています*8。
サイトを運営していない一般の方に向けた注意点も、Xにまとめています。
今週やること
- 痕跡の確認 — Wizは、不審なmultipart形式のリクエストの直後にメモリ上限エラーや500エラーが続く、異常に大きいPHPSESSIDのcookieが返る、といった兆候を挙げています*4
- 鍵と認証情報の入れ替え — メモリから他人のパスワードやトークンが漏れる経路があるため、更新前に外部へ公開していたサーバーでは、APIキーや管理者パスワードの入れ替えを検討する
- 社内のPHP資産の棚卸し — 公式サイト以外に、キャンペーンLP・社内ポータル・古い問い合わせフォームなど、忘れられたPHPのサーバーがないかを洗い出す
今月やること
- 更新の担当と期限を決める — 「重大な脆弱性が出たら何時間以内に誰が更新するか」を、外注先も含めて文書にしておく
- サポート切れの版をなくす — 8.1以前は公式の更新版が出ないため、移行計画を予算化する
- AIを使った点検を検討する — 自社のコードも、AIで脆弱性を点検する道具が現実的な選択肢になってきた
AIでコードの脆弱性を見つけて直す道具は、OpenAI以外からも出ています。Anthropicの取り組みは以下の記事で解説しています。
Claude Security公開─Opus 4.7がコードの脆弱性を自動発見・パッチ生成
GoogleのDeepMindが示した、脆弱性を自動で修正するAIの考え方は、以下の記事で解説しています。
【AI専門家が徹底解説】DeepMind「CodeMender」とは? コード脆弱性を自動修正するAIが示す新しいセキュリティの形
注意点|「AIが攻撃者より先に見つけた」をどう受け止めるか
OpenAIは「私たちの知る限り、最先端のAIが攻撃者より先にこれらの脆弱性を見つけ、守る側が準備する時間を生んだ」と書いています*1。私もXでこの点を一番大事なこととして紹介しました。ただ、企業の担当者として判断するなら、もう半分の事実も知っておく必要があります。
- 公開前に情報が漏れた — PHP Foundationによると、10月20日にCVE番号が出回り、Califが誤って実証動画を公開し、別の事業者が予定より早く修正済みイメージを出しました。ただし公開時点で動く攻撃コードは確認していないとしています*3
- 公開前から攻撃が来ていた — Cloudflareは「公式公開日より前に漏えいし、顧客を狙う攻撃の通信を観測した」と報告しています*6
- 攻撃側も同じAIを使える — 詳細と攻撃ツールが公開された今は、更新の遅れたサイトから狙われると見られます
つまり「AIのおかげで守る側が先手を取れた」のは事実ですが、その先手は2か月ほどの準備期間であり、公開後は時間との勝負になります。守る側がAIで先に見つけても、利用者側が更新しなければ穴は開いたままです。
もう一つの注意点は、脆弱性の報告が急増していることです。PHPのセキュリティチームは7月1日以降で15件のCVEを公表し、無効・重複・再現できない報告を100件以上処理したと明かしています*3。PHP Foundation自身もAnthropicのClaude MythosやOpenAIのツールでPHPを点検しています*3。オープンソースの開発者側の負担は増えており、企業が使っているソフトの更新頻度も上がっていくはずです。
AIが攻撃に使われる例は既に出ています。AIを悪用したサイバー攻撃の事例と、企業が見直すべき点は以下の記事で解説しています。
Claude CodeのAI主導サイバー攻撃から学ぶ:企業が見直すべき生成AIセキュリティ戦略
AI時代の脆弱性対応|企業が変えるべき3つの前提
今回の件から、私が企業に伝えたい前提の変化は3つあります。
- 「古いから安全」は通用しない — 今回の欠陥はPHP 5.4のころからあり、長年見過ごされてきました。AIは人が見落としてきた古いコードの穴も掘り起こします
- 更新の速さが防御力になる — 見つかる数が増えるほど、公開から更新までの時間が勝負になります。月1回の定期更新だけでは足りない場面が増えます
- AIを守りの道具として使う — 攻撃側だけがAIを使う状態が一番危険です。自社のコード点検やログ監視にAIを使う準備を始める価値があります
特に中小企業では、Webサイトを作った後の保守が契約に入っていないことがよくあります。今回のような件が今後数か月で増えるとOpenAIが見ている以上*1、保守の範囲と緊急時の連絡先を見直すよい機会です。
まとめ
- 何が起きたか — PHP本体に、ログインなしでサーバーを乗っ取られうる脆弱性が2件見つかり、10月21日に修正版が出た
- 誰が見つけたか — CalifがOpenAIのGPT-5.6 Solを使って最初に報告し、WizもGeminiとGPTを使って独自に見つけた
- 企業がやること — PHPを8.5.12・8.4.27・8.3.36・8.2.35へ更新する。プラグインの更新では塞がらない
- 受け止め方 — AIが先に見つけたのは事実だが、公開直前に漏えいと攻撃も起きた。更新の速さが防御力になる
私のおすすめは、この記事を読んだらまず自社サイトのPHPの版を確かめ、今日中に更新の段取りを付けることです。そのうえで、AIで脆弱性が見つかるペースは今後さらに上がると考えて、更新の担当と期限を決めておいてください。AIは攻撃にも防御にも使えます。守る側が先に使い、先に直す。そのための体制づくりを、今回をきっかけに始めてほしいと思います。
参考資料
- *1 OpenAI「Patch the Planet: global response coordination as agents uncover critical vulnerabilities」
- *2 PHP「Critical remote code execution vulnerabilities, update now」(2026年10月21日)
- *3 The PHP Foundation「Today’s PHP security release and how we’re strengthening PHP security」
- *4 Wiz「PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet」
- *5 Calif「A tale of two PHP remote vulnerabilities」
- *6 Cloudflare「Cloudflare deploys protections against php2shell vulnerability」
- *7 W3Techs「Usage statistics of PHP for websites」
- *8 Sansec「PHP2Shell: Critical PHP RCE (CVE-2026-109618, CVE-2026-109619)」
