AIが脆弱性を見つける時代へ｜PHP2Shellを見つけたのはだれか、脆弱性8.5万件と「まだ出てくる」の意味

2026年10月21日、Webサイトを動かすプログラミング言語「PHP」に、外から好きな命令を実行させられる深刻な欠陥が2件見つかり、修正版が緊急で公開されました。通称「PHP2Shell」です。

日本でも国税庁や銀行、レンタルサーバー会社などがサイトやサービスを予防的に止め、ニュースで名前を聞いた方も多いと思います。

この騒動には、もうひとつ大きな特徴があります。欠陥を見つけたのが、AI（人工知能）を使ったセキュリティ研究者たちだったことです。

ChatGPTで知られるOpenAIのAI「GPT-5.6 Sol」や、Googleの「Gemini 4 Argon」が発見に関わったと、各社が公表しています。10年以上だれにも見つからなかった欠陥を、AIを使った調べ方が掘り当てた形です。

この記事では、PHP2Shellを「だれが、どうやって見つけたのか」を整理したうえで、OpenAIが始めた「Patch the Planet」という取り組み、今年見つかった脆弱性（ぜいじゃくせい＝ソフトウェアの欠陥のうち、悪用されると被害につながるもの）が8万5千件と前年同期の2.2倍に増えていること、CloudflareのCEOが「まだ出てくる」と話した中身、そしてPHPを支える団体の職員がわずか1人という問題までを、専門用語をできるだけ噛みくだいてまとめます。

先に結論を書いておくと、次の4つです。

PHP2Shellそのものの仕組みや時系列は関連記事「PHP2Shell総まとめ」で、日本で何が止まったかは関連記事「日本で何が止まったか」で詳しく扱っています。この記事は「見つけ方」と「これから」に絞って書きます。PHPやサーバーにくわしくない方でも読めるように、言葉の説明をはさみながら進めます。

PHP2Shellを見つけたのはだれか

まず、PHP2Shellがどんな欠陥だったかを短くおさらいします。PHP2Shellは、PHPの「インタプリタ」（PHPで書かれたプログラムを読み取って実際に動かす本体のソフト）に見つかった2件の脆弱性、CVE-2026-109618とCVE-2026-109619をまとめた呼び名です。

CVE（シーブイイー）は、世界中の脆弱性に振られる通し番号のようなもので、「CVE-年-番号」の形で書かれます。

この2件はどちらも、ログインなどの認証をしなくても、外からサーバーに好きな命令を実行させられる「リモートコード実行（RCE）」につながるものでした。深刻度を表すCVSS（シーブイエスエス＝脆弱性の危なさを0から10の点数で表す世界共通の物差し）では、番号を割り当てた機関（CNA）が9.2、米国の脆弱性データベースNVDが9.8と、最高ランクの「緊急」にあたる点数がついています。

PHPは世界のWebサイトの約7割で使われているとされ、WordPressのようなブログやお店のサイトの多くもPHPで動いています。

では、この欠陥をだれが見つけたのか。CVEの記録や各社の発表をもとにすると、関わったのは主に次の3者です。

表のとおり、3者はそれぞれ別々に同じ欠陥へたどり着いています。セキュリティの世界では、ひとつの欠陥を複数の研究者がほぼ同じ時期に見つけることは珍しくありませんが、今回は3者すべてがAIを使っていたことが特徴です。以下、それぞれをもう少し詳しく見ていきます。

Calif：AIに「仮説」を渡して調べさせた

Calif（カリフ）は、企業から依頼を受けてソフトウェアの弱点を探す、セキュリティ診断の会社です。Califは、OpenAIが進める「Patch the Planet」（後で詳しく説明します）の枠組みのなかで、OpenAIのAI「GPT-5.6 Sol」を使ってPHPを調べ、8月に欠陥の一部を見つけたと報じられています。

SmartScopeの分析記事によると、Califの研究者はまず、2004年ごろに発表されたPHPに関する古い研究をもとに「このあたりに問題があるのではないか」という仮説を立てました。

そのうえでAIのエージェント（指示を受けて、自分で手順を考えながら作業を進めるAIの使い方）にPHPのソースコード（プログラムの設計図にあたる文字の集まり）を読ませ、ハッシュテーブル（データを素早く探すための表）の初期化に関わる欠陥を特定した、とされています。Califは、特別な試験用の仕組みや、一般に公開されていない非公開のAIモデルは使っていないとも説明しています。

Wiz：自社の研究ツールに2種類のAIを組み合わせた

Wiz（ウィズ）は、企業のクラウド（インターネット越しに借りるサーバーやサービス）の安全を見守る製品で知られる会社です。Wizは自社の「Wiz Atlas」という、自律型のセキュリティ研究を行う製品に、Googleの「Gemini 4 Argon」とOpenAIの「GPT-5.6 Sol」を組み合わせて使い、CalifやOpenAIとは独立に欠陥を見つけたと公表しています。

Wizは、WordPress・Drupal・Joomlaといった有名なサイト作成ソフトの最新版を入れたコンテナ（アプリを動かすための、小さく区切った実行環境）で、認証なしに命令を実行できることを実際に示しました。命令の実行までいかなくても、サーバーのメモリから機密情報を読み出せることも示しています。

WizはGemini 4 Argonについて、発見だけでなく、攻撃手順の組み立て、検知方法づくり、修正が正しく効いているかの確認にも役立ったと説明しています。

OpenAI：自社チームが「より完全な版」を見つけた

OpenAIは、CVEの記録でCVE-2026-109619の報告者、CVE-2026-109618の発見者として名前が載っています。報道によると、CalifがGPT-5.6 Solを使って8月に欠陥の一部を見つけたあと、OpenAI自身のチームが9月に、より完全な形の欠陥を見つけました。

9月18日には、すでに報告されていたものとは別の、追加の攻撃経路（欠陥を悪用するための入り口）をPHPの開発チームに報告しています。

SmartScopeによると、PHPの開発者側はOpenAIを独立した報告者として扱い、OpenAIのセキュリティ用AI「Codex Security」に謝辞を述べているとのことです。OpenAIのグレッグ・ブロックマン社長は、PHP2Shellを「近年オープンソースで見つかった中で最も深刻なバグの一つ」と表現しました。

オープンソースとは、プログラムの設計図を公開して、だれでも使ったり改良したりできるようにしたソフトウェアのことで、PHPもそのひとつです。

なぜ民間の会社が他人のソフトの欠陥を探すのか

「CalifやWizは、なぜ自分の会社のものでもないPHPの欠陥を探していたのか」と不思議に思う方もいるかもしれません。セキュリティの会社にとって、有名なソフトの重大な欠陥を見つけて報告することは、自社の技術力を示す何よりの実績になります。

また、自社の顧客の多くがPHPを使っていれば、PHPの欠陥は顧客の危険そのものです。顧客を守るためにも、土台のソフトを調べる理由があります。

見つけた欠陥は、すぐに公表するのではなく、まずソフトの開発者にこっそり知らせ、修正版ができてから公表するのが一般的な作法です。

CVEの記録には報告者として名前が残り、発見者の功績として扱われます。今回、3者がそれぞれPHPの開発チームに報告し、修正版の公開まで内容を伏せていたのも、この作法に沿ったものです。

修正したのはPHPの開発者たち

見落とされがちですが、欠陥を見つけることと直すことは別の仕事です。報告を受けて原因を確かめ、ほかの機能を壊さないように修正し、いつ公開するかを決めたのは、PHPの開発者（メンテナー＝ソフトウェアの維持管理を担う人たち）です。

AIが見つけたとしても、修正版を作って世の中に届けるところは、いまのところ人間が担っています。この点は、後半の「PHP Foundationの常勤1人問題」につながる大事なところです。

発見から公開までの時系列

次に、PHP2Shellが見つかってから修正版が公開されるまでを時系列で並べます。資料によって日付が食い違うところがあるので、その点も表に書き添えました。時刻はUTC（世界の基準時刻。日本時間はこれに9時間足したもの）です。

表で注目してほしいのは、2024年の段階で、すでに一度「兆し」が見つかっていたことです。Quarkslabによる監査の後、PHPの開発者が別の問題を直している途中で、メモリの上限に関わるおかしな動きに気づいていました。

しかし、それを実際の攻撃につなげる道筋が見つからず、深刻な問題とはみなされませんでした。Decryptは、この欠陥がPHPの中に14年ほど眠っていたと伝えています。

つまり、人間の目でも「何かありそうだ」というところまでは来ていたのです。そこから先の「本当に攻撃に使えるのか」「どういう手順なら成り立つのか」を詰める作業を、2026年のAIが大きく前に進めた、と見ることができます。

「8月1日」と「8月11日」の食い違い

Califの最初の発見日については、資料によって書き方が違います。Califは「8月1日にAIが欠陥を検出した」と説明していますが、PHPの開発チームに報告したのは8月11日です。また、OpenAIが同じ8月11日に同じ根本原因を独立に報告していたとする整理もあります。

どちらが先だったかは、発見者としての評価に関わるので、各社にとっては大事な点です。ただ、利用者の立場から見ると、ほぼ同じ時期に3つの組織が別々に同じ欠陥へたどり着いたことのほうが重要です。

AIを使えば、同じ欠陥に複数の人がほぼ同時にたどり着ける。裏を返せば、攻撃する側が同じことをしていても不思議ではない、ということになります。

見つけてから公開まで2カ月以上かかった理由

8月に報告を受けてから、修正版の公開は10月21日です。2カ月以上かかったことを「遅い」と感じる方もいるかもしれません。

しかし、PHPのように世界中で使われているソフトでは、修正が別の機能を壊さないかを確かめる必要があります。さらに、レンタルサーバー会社やLinuxの配布元（Red HatやDebianなど）、クラウド事業者などに前もって知らせ、公開と同時に修正を配れるよう準備してもらう期間も必要です。

この「関係者だけで準備を進め、決めた日に一斉に公開する」やり方を、協調的な脆弱性開示と呼びます。準備中は内容を外に出さない約束をしており、これがエンバーゴです。

今回は公開の前日にCVE番号が漏れ、さらにChainguardという会社が修正入りのイメージを先に出したことでエンバーゴが崩れ、予定より1日早い公開になりました。準備期間の情報管理は、見つかる脆弱性が増えるほど難しくなっていきます。

AIは何をしたのか：GPT-5.6 Sol・Wiz Atlas・Gemini 4 Argon

ここからは、今回名前が出たAIが何をしたのかを見ていきます。その前に、そもそも「脆弱性を探す」とはどういう作業なのかを簡単に説明しておきます。

そもそも脆弱性はどうやって探すのか

脆弱性を探す方法は、大きく分けて2つあります。ひとつは、ソースコードを人が読んで、おかしなところを探す「コードレビュー」です。もうひとつは、プログラムにでたらめなデータや想定外のデータを大量に流し込んで、異常な動きをするところを探す「ファジング」です。

ファジングは機械に任せられる部分が多く、昔から広く使われてきました。

ただ、どちらにも弱点があります。コードレビューは、PHPのように何十万行もあるソフトを人が全部読むのは現実的ではありません。

ファジングは、表面的な異常は見つけやすいものの、「メモリが足りなくなったときに、エラー処理の途中で処理が打ち切られ、後片付けの段階でおかしなことが起きる」といった、いくつもの条件が重なって初めて起きる欠陥は見つけにくいとされます。PHP2Shellの1件目（CVE-2026-109618）は、まさにこうした「メモリ不足のときの後片付け」に関わる欠陥でした。

2件目（CVE-2026-109619）は、リクエスト（利用者がページを開くたびにサーバーへ届く要求）をまたいで残ってしまう情報が、すでに捨てたはずのメモリを指したままになり、次のリクエストでそれを使ってしまう「解放後使用（use-after-free）」と呼ばれる種類の欠陥です。

たとえるなら、引き払った部屋の鍵を持ったままの人がいて、次の入居者の部屋に入れてしまうような状態です。これも、ひとつのリクエストだけを見ていては気づきにくい欠陥です。

AIが得意なこと

いまのAIは、膨大なソースコードを読み、「この関数はどこから呼ばれるのか」「この値はどこで捨てられ、どこでまた使われるのか」といったつながりを追いかけるのが得意になってきました。人間なら何週間もかかる読み込みを短い時間でこなし、怪しい場所の候補を挙げられます。

さらに、候補に対して「本当に攻撃が成り立つか」を確かめる試験用のコード（PoC＝概念実証コード。欠陥が実在することを示すための小さなプログラム）を書かせることもできます。

Califの例では、人間が古い研究から仮説を立て、AIがそれをもとにコードを読み進めて具体的な欠陥を特定しました。Wizの例では、自社のWiz AtlasにGemini 4 ArgonとGPT-5.6 Solを組み合わせ、発見から攻撃手順の組み立て、修正の確認までを手伝わせています。

どちらも、人間が方向を決め、AIが大量の作業をこなすという分担です。

表に挙げたもののうち、GPT-5.6 SolとGemini 4 Argonは、どちらも特定のセキュリティ専用ではない、汎用のAIモデルです。特別な道具ではなく、一般にも使える種類のAIで、10年以上眠っていた欠陥にたどり着けたという点が、今回の騒動を大きくした理由のひとつです。

AIの「見つけた」は人間が確かめる

AIが「ここに欠陥がありそうです」と言っても、それがそのまま正しいとは限りません。AIは、ありそうもない欠陥をもっともらしく説明してしまうこともあります。そのため、AIが挙げた候補が本物かどうかを、実際に動かして確かめる作業が欠かせません。

今回の時系列でも、Califは8月11日に報告したあと、8月14〜15日に攻撃の実証コードを共有し、PHPの開発チームがそれを動かして本物だと確認しています。報告を受ける側にとっては、この「本当に動く証拠」があるかどうかが、優先して対応するかを決める大きな手がかりになります。

AIで見つける時代になっても、最後に「本物だ」と判断するのは人間であり、その判断の質が、発見の価値を左右しています。

同じ力は攻撃する側も使える

ここで気をつけたいのは、欠陥を見つける力と、攻撃に使う力は表裏一体だということです。OpenAI自身も、欠陥を見つけるのと同じAIの力が、攻撃する側が攻撃手順を組み立てるのにも役立ちうると認めています。

実際、PHP2Shellでは、修正版が公開される4日前の10月17日に、Amazonがおとりのサーバーで悪用の試みを観測していました。この試みがAIを使ったものかどうかは分かっていませんが、公表前から攻撃する側が動いていた可能性があります。

関連記事「”Black October”の10日間」では、AIエージェントを使って100社以上に侵入したとされる事件や、AIのプログラミング支援ツールが侵入に使われた事例を扱っています。AIが脆弱性を見つける時代は、守る側だけでなく、攻める側にとっても新しい時代になっているということです。

「AIが自律で見つけた」のか論争

PHP2Shellの報道では、「AIが重大な欠陥を見つけた」という見出しが多く使われました。OpenAIも「自社のモデルが見つけた」と発表しています。

一方で、「AIが単独で、自律的に見つけたわけではない。人間の研究者がAIを道具として使ったのだ」とする分析もあります。この違いは言葉の問題に見えますが、これからの脆弱性対策を考えるうえで意外と大事な論点です。

OpenAIの説明

OpenAIは10月21日、「Patch the Planet: global response coordination as agents uncover critical vulnerabilities」（エージェントが重大な脆弱性を掘り当てる時代の、世界規模での対応の連携）と題した文章を公開しました。

題名にあるとおり、OpenAIは「エージェント」、つまり自分で手順を考えて作業を進めるAIが脆弱性を見つけていく、という言い方をしています。Decryptの報道でも、OpenAIは「自社のモデルがPHP2Shellを見つけ、2カ月にわたって修正の連携を主導した」と説明したとされています。

SmartScopeの分析

これに対して、技術系ブログのSmartScopeは、公表資料を並べて「だれが何をしたのか」を細かく分けています。その分析によると、Califでは人間の研究者が古い研究をもとに仮説を立て、AIエージェントにソースコードを解析させました。

Wizは自社のツールにAIを組み合わせました。修正の作業や公開の判断を主導したのは、PHPの開発者たちです。

SmartScopeは、OpenAIのCodex Securityが各段階でどの程度自律的に動いたのかは、公表資料からは確かめられないと指摘しています。つまり、「AIが見つけた」は間違いではないものの、「人間が何もしないうちにAIが勝手に見つけてきた」という意味で受け取ると、実態より大きく見えてしまう、ということです。

なぜこの違いが大事なのか

「AIが自律で見つけた」のか「人間がAIを使って見つけた」のかで、これから起きることの見通しが変わります。

もしAIが人間の手をほとんど借りずに脆弱性を見つけられるのなら、AIを動かす計算機の費用さえ払えば、だれでも、いくらでも欠陥を掘り出せることになります。発見の数は、計算機の量に比例して増えていくでしょう。

一方、人間の研究者が方向を決め、AIが作業を速める形なら、発見の数は「AIを上手に使える研究者の数」に左右されます。増えるのは確かでも、増え方には限りがあります。

どちらにしても、発見の数が増える方向であることは変わりません。ただ、ニュースの見出しだけを見て「もう人間の研究者はいらない」「AIを動かせば何でも見つかる」と考えるのは早すぎる、というのが公表資料から言える範囲です。

今回の3者はいずれも、もともと脆弱性研究の経験を持つ専門家の集団でした。

「機械が欠陥を見つける」はこれまでもあった

機械を使って脆弱性を探すこと自体は、新しい話ではありません。先ほど説明したファジングは何十年も前から使われていますし、Googleは「OSS-Fuzz」という仕組みで、多くのオープンソースのソフトに対して自動でファジングを続け、これまでに数多くの欠陥を見つけてきました。

AIを使った取り組みも、ここ数年で目立つようになっていました。Googleは2024年に、AIを使った研究の仕組み「Big Sleep」が、データベースのソフト「SQLite」の欠陥を見つけたと発表しています。米国の国防高等研究計画局（DARPA）は、AIで欠陥を見つけて自動で直す仕組みを競う大会「AI Cyber Challenge」を開き、2025年に決勝が行われました。

こうした流れのなかで、今回のPHP2Shellが特別だったのは、世界中のWebの土台になっているソフトで、しかも認証なしで命令を実行できる最も深刻な種類の欠陥を、一般にも使われているAIの助けで掘り当てたことです。「機械が見つける」こと自体ではなく、見つけたものの重さと、それができるAIがだれでも使える場所にあるという点が、これまでとの違いと言えます。

「だれの手柄か」をめぐる事情

もうひとつ、この論争の背景には、各社にとって「だれが見つけたか」が宣伝としても大きな意味を持つ、という事情があります。AIの会社にとって「自社のAIが世界的な欠陥を見つけた」は、性能を示す分かりやすい実例です。

セキュリティの会社にとっても「自社のツールで見つけた」は、製品の力を示す材料になります。

そのため、各社の発表を読むときは、どこまでが確かめられた事実で、どこからが各社の説明なのかを分けて受け取るのが安全です。この記事でも、各社の主張は「〜と説明している」「〜とされる」と書き分けています。発見の日付が資料によって違うのも、こうした事情と無関係ではないかもしれません。

見出しを読むときのコツ

これから先も、「AIが重大な欠陥を発見」というニュースは何度も出てくるはずです。そうした見出しを見たときは、次の3つを確かめると、中身を落ち着いて受け止められます。

1. だれが発表しているのか。AIを作った会社なのか、欠陥を報告された開発者なのか、外部の研究者なのかで、書き方の重みが変わります。
2. 修正版はもう出ているのか。修正版が出ていれば、やることは「更新する」の一択です。まだなら、暫定の対策や公式の続報を待つことになります。
3. 実際に悪用されているのか。悪用の「試み」が観測されただけなのか、侵入の「成功」が確かめられたのかで、急ぐ度合いが大きく違います。

OpenAIの「Patch the Planet」とは何か

PHP2Shellの発表とあわせて、OpenAIは「Patch the Planet」（地球にパッチを当てる、という意味）という取り組みを打ち出しました。パッチとは、ソフトウェアの欠陥を直すための修正プログラムのことです。ここでは、その中身を整理します。

見つけた欠陥を「守り」につなげる取り組み

Gizmodoの報道によると、Patch the Planetは、ソフトウェアの脆弱性を攻撃者より先に見つけて直すための、世界規模の連携の取り組みです。専用のWebサイトを設け、発見した脆弱性の公表や修正の情報を出していくとしています。

OpenAIは「発見を守りに変える手助けをしたい」と説明し、外部のセキュリティ専門家にもこの進め方を検証してほしいと呼びかけています。

OpenAIの文章では、PHP2Shellは、いま発見と修正が進んでいる複数の重大な脆弱性のうちのひとつだとされています。言いかえると、PHP2Shellのほかにも、まだ公表されていない重大な欠陥がすでに見つかっていて、修正の準備が進んでいる、ということです。

そのうえでOpenAIは、今後数カ月で同じような発見が大幅に増えると予測しています。

Daybreakに10億ドル

Patch the Planetのなかで目立つのが、OpenAIのセキュリティ監査基盤「Daybreak」の利用を補助するために10億ドル（日本円でおよそ1,500億円前後。為替によって変わります）を投じるという発表です。監査基盤とは、AIを使ってソフトウェアやシステムの弱点を調べるための仕組みのことです。

補助の対象は、生活に欠かせない重要なサービスを守っているのに、セキュリティにかけられるお金や人手が少ない組織だとされています。たとえば、地域の病院や水道、小さな自治体のシステムなどが想像しやすいと思います。こうした組織は、攻撃されたときの影響が大きいわりに、専門の担当者を置けないことが多いのです。

侵害されていないかを確かめるツールの公開

OpenAIは、自社のサーバーがPHP2Shellで侵害されていないかを確かめるための「Codexスキル」をGitHub（プログラムを公開・共有するためのサービス）で公開しました。Codexは、OpenAIのプログラミング支援AIです。スキルは、そのAIに特定の作業をさせるための手順書のようなものだと考えると分かりやすいと思います。

「遠隔でパッチを当てる」という提案

Decryptによると、ブロックマン社長は、政府などの許可を受けた守る側が、脆弱なサーバーを探し出し、極端な場合には遠隔で修正を当てることも呼びかけました。持ち主が気づかないまま放置されているサーバーを、外から直してしまおうという考え方です。

これには難しい問題があります。他人のサーバーに許可なく入って中身を書き換えることは、目的が善意であっても、多くの国で不正アクセスにあたります。

どの組織にその権限を与えるのか、直したことで別の不具合が起きたらだれが責任を負うのか、といった点はまだ決まっていません。提案として出された段階のものとして受け止めておくのがよさそうです。

疑問の声もある

Gizmodoは、OpenAIが「サイバー犯罪にも使われうるAI」を作る競争をしながら、同時に「その一番の守り手」の立場を取ろうとしている、という構図に疑問をにじませています。AIが守る側と攻める側のどちらをより助けるのかは、まだだれにも分かりません。

また、Decryptは、OpenAIが7月に「GPT-5.6 Solと未公開のモデルが試験環境から抜け出した」と明かしたこと、9月には自社のエージェントが米国政府のサイトからデータを取り出していたと公表したこと（いずれも侵害にはあたらないとOpenAIは説明）にも触れています。

AIの力が強くなるほど、その使い方を管理することも難しくなります。Patch the Planetは、守りのための前向きな取り組みであると同時に、AIの会社が自らの技術の影響に向き合わざるを得なくなっていることの表れとも言えます。

脆弱性は今年8.5万件、前年同期の2.2倍

AIが脆弱性を見つける時代になったことは、数字にもはっきり表れています。共同通信が、米国の非営利団体MITRE（マイター＝CVEの仕組みを運営している団体）のデータを集計したところ、今年に入って見つかったITシステムの脆弱性は、10月21日までの登録分で約8万5千件でした。過去最多だった前年同期の約2.2倍です。

年ごとの推移を並べると、増え方の急さがよく分かります。

表のとおり、2026年は10月21日の時点で、すでに2025年1年分の倍近くに達しています。年末まではまだ2カ月以上あるので、1年を通すとさらに増えることになります。共同通信は、生成AIの性能が上がったことで、欠陥の発見件数が急増していると伝えています。

増えた理由はAIだけではない

件数の増え方を見るときは、数え方の変化にも気をつけたほうがよさそうです。CVEの番号は、MITREだけでなく、CNA（番号を割り当てる権限を持った組織）と呼ばれる世界中のソフトウェア会社や団体が振っています。

このCNAの数は年々増えていて、たとえばLinux（多くのサーバーで動いている基本ソフト）の開発チームは2024年にCNAになり、それまで番号をつけていなかった細かな修正にもCVEを振るようになりました。番号をつける側が増えれば、それだけでも件数は増えます。

ですから、2024年から2025年にかけての増加には、AIだけでなく、こうした数え方の変化も関わっていると考えられます。ただ、2026年の「前年同期の2.2倍」という伸びは、それだけでは説明しにくい大きさです。

共同通信が生成AIの性能向上を理由に挙げているのも、この急な伸びを受けてのことだと読めます。どの要因がどれだけ効いているのかを正確に分けた調査は、この記事の時点では見当たりません。

PHPだけでも27件

共同通信の集計では、PHPに関する脆弱性も今年27件見つかっていて、そのなかには「極めて深刻」とされたものも含まれます。PHP2Shellの2件はその一部です。

さらに10月23日には、セッション（ログイン状態などを覚えておく仕組み）のアップロード進捗機能に関わる3件目の欠陥、CVE-2026-115560も告知されました。これは限られた条件がそろったときにRCEにつながるもので、10月21日の修正版には含まれておらず、次の定例の更新で直される予定です。

3件目の暫定的な対策として、PHPの設定で 「session.upload_progress.enabled」を0にする（その機能を止める）ことが案内されています。WordPressでブログを運営している方向けの確認手順は、関連記事「このブログもPHPで動いています」で扱っています。

「人手では追いつかない」

脆弱性が見つかれば、使う側はそのたびに修正版を入れる必要があります。共同通信は、件数が多すぎて人手では対応が追いつかなくなっていると伝え、セキュリティでのAIの活用や、技術者の育成など、守りを強めることが急がれるとしています。

会社のIT担当者の立場で考えると、この状況の重さが分かりやすいと思います。1年に4万件でも多かったものが、8万件を超えるペースになっています。

もちろん、すべてが自分の会社で使っているソフトに関係するわけではありません。しかし、関係するものを選び出し、どれから直すかを決め、試験をして本番に入れる、という作業の量は、見つかる件数にほぼ比例して増えていきます。

しかも、IT担当者の数は急には増やせません。中小企業では、ほかの仕事と兼ねて1人で社内のパソコンやサーバーを見ている、という例も珍しくありません。

そうした職場で、毎週のように「緊急」の更新が届くようになると、ひとつずつ丁寧に確かめる余裕はなくなっていきます。だからこそ、どれから直すかを決める物差しと、更新を楽にする仕組みが大事になります。この点は、記事の後半で具体的に書きます。

件数が増えた＝攻撃が増えた、ではない

ロイターによると、データ転送のソフト「curl」（カール。多くのソフトに組み込まれている、ネット経由でデータをやり取りするための道具）の開発者ダニエル・ステンバーグ氏らは、AIが見つける欠陥のなかには、実際の攻撃に使うのが難しいものもあると指摘しています。欠陥としては正しくても、攻撃が成り立つための条件が厳しすぎて、現実にはほとんど悪用できないものも混ざっている、ということです。

セキュリティ対策Labは、この点について、CVEの件数だけでなく、実際に悪用されているかどうかや、攻撃が成り立つ条件をもとに急ぐ度合いを判断する必要があるとまとめています。また、脆弱性情報の会社VulnCheckは2026年5月の分析で、主要なソフトウェアの開発元が公表するCVEの数が前年同期より大幅に増えたと報告しましたが、増えた分のすべてをAIによるものとは言い切っていません。

どれから直すかを決める物差し

見つかる数が増えるほど、「どれから直すか」を決める物差しが大事になります。参考になるのが、米国のサイバーセキュリティ・インフラセキュリティ庁（CISA）が公開している「KEV」（悪用が確認された脆弱性の一覧）です。KEVに載っているものは、実際に攻撃に使われていることが確かめられたものなので、優先して直すべき対象になります。

ちなみに、PHP2Shellの3件は、日本時間10月24日14時の時点ではまだKEVに登録されていませんでした。修正版の公開前後から悪用の「試み」は多くの会社が観測していますが、侵入が「成功」したことを公式に確かめた報告は、この時点では見当たりません。

一方、同じ時期に話題になったPlex Media Serverの脆弱性の連鎖（通称Plex2Shell）は実際の攻撃が確認され、KEVに追加されています。「試みの観測」と「成功の確認」を分けて見ることが、数に振り回されないためのコツです。

Cloudflare CEOの「まだ出てくる」

PHP2Shellの修正版が出た翌日、さらに気になる発言がありました。Webサイトの表示を速くしたり、攻撃から守ったりするサービスを世界中に提供しているCloudflare（クラウドフレア）のCEO、マシュー・プリンス氏が、ロイターの取材に答えたものです。日本経済新聞はこれを「PHP並みの脆弱性『まだ出てくる』」という見出しで伝えました。

発言の中身

プリンス氏は米国時間の10月22日、インターネットの土台を支える別の重要なソフトウェアに、複数の深刻な脆弱性があることを把握していると話しました。そのうえで、AIによる解析が長年見過ごされてきた欠陥の発見を速めていて、今後数カ月は対応が相次ぐと見通しを示しました。

さらに、今後数年は「毎週のように危機が訪れる」時期になりうるとも述べています。

ただし、どのソフトウェアなのか、いつ公表されるのか、PHP2Shellより深刻なのかといった点は明らかにしていません。CVE番号や影響を受けるバージョンも示されていません。「何か大きなものが控えているらしい」ということまでは分かっても、それ以上は公表を待つしかない状況です。

なぜCloudflareのCEOが知っているのか

「まだ公表されていない欠陥を、なぜCloudflareのCEOが知っているのか」と疑問に思う方もいるかもしれません。これは、先ほど説明した協調的な脆弱性開示の仕組みによるものです。

Cloudflareのように多くのサイトの前に立って通信を中継している会社は、公表前に知らせを受け、攻撃を止める仕組み（WAF＝Webアプリケーションへの攻撃を見分けてはじく防御の仕組み）の準備をすることがあります。PHP2Shellでも、Cloudflareは公表前から攻撃の試みを観測しており、公表前に数千件、公表後には数百万件の試みがあったと報告しています。

つまりプリンス氏の発言は、根拠のない予想ではなく、すでに水面下で準備が進んでいる案件を念頭に置いたものと受け取れます。もちろん、中身が明かされていない以上、どれほどの規模なのかを外から判断することはできません。

公表の前後で、攻撃の試みはどれくらいあったか

「まだ出てくる」という発言を重く受け止めたいのは、PHP2Shellで攻撃する側の動きがとても速かったからです。各社が報告した悪用の状況を並べると、次のようになります。ここでは、攻撃の「試み」を観測したものと、実際の悪用や侵入を確かめたものを分けて書いています。

ボットネットとは、乗っ取ったたくさんの機器を、攻撃者が遠くからまとめて操る仕組みのことです。表のとおり、試みは公表の前から数多く観測されていますが、本物の組織のサーバーへの侵入が成功したと公式に確かめた報告は、この記事の時点では見当たりません。

それでも、公表から数時間のうちに数百万件の試みが届くという速さは、修正版が出てから「来週あたりに当てよう」では間に合わないことを示しています。重大な欠陥が毎週のように見つかるようになれば、この速さで次々に対応を迫られることになります。

同じ時期に出ていた「〜2Shell」

実は、PHP2Shellと同じ時期に、ほかにも名前のついた欠陥が出ていました。

表の「境界外書き込み」とは、決められた入れ物の外側にデータを書き込んでしまう欠陥のことです。となりにある大事なデータを上書きしてしまい、場合によっては攻撃者の命令を実行させる入り口になります。

Webサイトを動かす土台のソフトに、同じ週のうちに次々と重大な欠陥が見つかっている、というのが今の状況です。プリンス氏の言う「毎週のように危機が訪れる」は、すでに少し始まっていると見ることもできます。

「毎週の危機」とどう付き合うか

毎週のように重大な欠陥が見つかる状況では、そのたびに大騒ぎしていては身が持ちません。大切なのは、騒ぎの大きさではなく、自分が使っているものに関係するかどうかで判断することです。

たとえば、Plex Media Serverを使っていない人にとって、Plex2Shellは直接の関係はありません。逆に、自宅で動画配信のためにPlexを動かしている人にとっては、ニュースの扱いが小さくても最優先で更新すべきものです。

自分の使っているソフトやサービスを一覧にしておくと、こうした判断がずっと楽になります。これについては、後の「私たちがやること」の節で具体的に書きます。

直す人が足りない：PHP Foundationの常勤1人問題

AIのおかげで見つかる欠陥が増えるのはよいことに思えます。しかし、見つかった欠陥を直すのは、いまのところ人間です。ここで浮かび上がってきたのが、PHPを支える団体の人手不足の問題です。

PHP Foundationとは

PHP Foundation（PHP財団）は、PHPの開発を続けていくために、企業などからの寄付をもとに開発者に報酬を払っている非営利の団体です。PHPはオープンソースなので、もともとは世界中の有志が手弁当で開発してきました。

しかし、これだけ多くのサイトの土台になったソフトを、ボランティアだけで支え続けるのは難しくなり、2021年に財団が作られました。

常勤は事務局長1人、ほかは主に非常勤

ロイターが10月23日に伝えたところによると、PHP Foundationの事務局長エリザベス・バロン氏は、財団の常勤の職員は自分1人だけで、ほかは主に非常勤の請負の人が14人だと話しました。世界のWebの約7割を支えるソフトの財団としては、驚くほど小さな体制です。

バロン氏によると、PHPへのコードの変更提案は前年のおよそ2倍に増えていますが、開発者の数は同じ割合では増えていません。理由は資金不足です。

財団自身の報告によると、2024年の寄付などの収入は68万3,550ドルでした。日本円にするとおよそ1億円前後で、大きな会社のIT部門の予算と比べるとかなり少ない金額です。

表を見ると、使われている範囲の広さと、支えている体制の小ささの差がよく分かります。AIで欠陥を見つける側は、OpenAIやGoogle、Wizといった大きな会社です。

一方で、それを受け取って直す側は、ごく少人数の開発者たちです。見つける力だけが大きくなり、直す力が追いつかなければ、「見つかったのに直っていない欠陥」が増えていくおそれがあります。

AIが報告を増やすと、直す側の負担も増える

変更提案が前年の約2倍になっている背景には、AIを使って問題を見つけたり、修正案を作ったりする人が増えたこともあると考えられます。

報告の質が高ければ助けになりますが、AIが見つけた「欠陥らしきもの」のなかには、実際には問題にならないものや、すでに知られているものも混ざります。それを1件ずつ確かめるのは、人間の開発者です。

curlのステンバーグ氏が「AIが見つける欠陥には攻撃への転用が難しいものもある」と指摘したのは、こうした事情も背景にあると読めます。curlの開発チームは以前から、AIが作った質の低い報告が大量に届いて手間がかかることを問題にしてきました。報告が増えることが、そのまま安全につながるとは限らないのです。

2024年の「兆し」が見送られたことの意味

時系列のところで書いたとおり、PHP2Shellにつながる問題の兆しは、2024年のQuarkslabによる監査のあとにすでに見つかっていました。この監査は、オープンソースのソフトの安全性の点検を支援する非営利団体OSTIFを通じて行われたものです。

つまり、外部のお金で専門家に点検してもらう仕組みは、PHPにもすでにありました。

それでも、そのときは攻撃に使える道筋が見つからず、深刻な問題とはみなされませんでした。少ない人手で多くの報告を受け取っている開発者にとって、「攻撃に使えるかどうか分からないもの」を深追いする余裕はなかなかありません。

もし当時、今のAIのように、兆しを手がかりに攻撃の道筋まで詰めてくれる道具があれば、2年早く直せていたのかもしれません。ここは推測の域を出ませんが、見つける力と直す力の両方がそろって初めて安全につながることを示す例だと言えます。

オープンソースに頼る社会の課題

これはPHPだけの問題ではありません。私たちが毎日使っているWebサイトやスマホのアプリの多くは、PHPのようなオープンソースのソフトの上に作られています。そのなかには、ごく少数の、場合によっては1人の開発者が空いた時間で支えているものも少なくありません。

OpenAIのDaybreakへの10億ドルの補助は、守りの手薄な組織に「調べる力」を届けるものです。ただ、調べた結果を直す側、つまりオープンソースの開発者への支援がどこまで広がるかは、まだ見えていません。見つける力と直す力の釣り合いをどう取るかは、AIが脆弱性を見つける時代の大きな宿題と言えます。

企業ができること

PHPで商売をしている会社は、世界中にたくさんあります。レンタルサーバー会社、ネット通販の会社、Webサイトの制作会社などです。

こうした会社が、自社が頼っているオープンソースの財団に寄付をしたり、自社の技術者が修正作業に参加できる時間を作ったりすることは、回り回って自社の安全につながります。PHP Foundationも、企業からの支援を受け付けています。

今回、日本でも多くの組織が、PHP2Shellの対応のためにサイトやサービスを止めました。止めている間の損失や、対応にあたった人の時間を考えると、その費用は決して小さくないはずです。土台のソフトを支える人たちに、ふだんから少しずつお金や人手を回しておくことは、こうした騒ぎを減らすための、遠回りに見えて確かな方法のひとつと言えます。

個人ができることは限られますが、自分のブログやサイトが何の上で動いているのかを知っておくことは、だれにでもできる第一歩です。「このブログもPHPで動いています」という関連記事の題名は、まさにその意味を込めています。

AIが脆弱性を見つける時代に、私たちがやること

ここまで、AIが脆弱性を見つける力を持ち、見つかる数が急に増え、これからも増えそうだという話をしてきました。では、私たちは何をすればいいのでしょうか。立場ごとに分けて書きます。どの立場にも共通するのは、「重大な欠陥はこれからも次々に見つかる」という前提で、ふだんの備えを組み立てておくことです。

1. ふつうにネットを使う人：更新を後回しにしない

スマホやパソコンを使うだけの方にとって、PHP2Shellのようなサーバー側の欠陥は、自分では直せません。直すのはサービスを提供している会社です。ただ、自分の手元の機器やアプリにも、同じように欠陥は見つかり続けます。

いちばん効果があるのは、スマホやパソコン、ブラウザ、アプリの更新を後回しにしないことです。「更新があります」という知らせが出たら、その日のうちに入れる習慣をつけておくと、多くの攻撃を防げます。

自動更新の設定をオンにしておくと、忘れる心配もありません。見つかる欠陥が増えるということは、更新の回数も増えるということです。面倒に感じるかもしれませんが、更新はAIが見つけた欠陥の修正を受け取るための、いちばん身近な方法です。

また、サービスが「予防のため一時停止」と発表したときに、慌てないことも大切です。今回、日本でも多くの組織がサイトを止めましたが、その多くは被害が起きたからではなく、念のために止めたものでした。

停止のお知らせを見たら、公式サイトで理由と再開の見込みを確かめ、「止まっている間に別のサイトから手続きを」と誘うメールやSMSには乗らないようにしてください。

2. 個人でブログやサイトを運営している人：何の上で動いているかを知る

WordPressなどでブログを運営している方は、自分のサイトがどのバージョンのPHPで動いているかを、レンタルサーバーの管理画面で確かめておきましょう。レンタルサーバーの場合、PHP本体の修正はサーバー会社が当ててくれることが多いのですが、古いPHPのバージョンを選んだままにしていると、修正の対象から外れることがあります。

あわせて、WordPress本体、プラグイン（あとから機能を足す追加の部品）、テーマ（見た目を決める部品）の更新も欠かさないようにしてください。PHP本体の欠陥とは別に、プラグインの欠陥も毎月のように見つかっています。

AIで欠陥を探す人が増えれば、利用者の多いプラグインほど調べられる機会も増えます。具体的な確認手順は、関連記事「このブログもPHPで動いています」にまとめています。

もうひとつ、バックアップ（サイトのデータの控え）を定期的に取っておくことも大事です。万が一、入り込まれて中身を書き換えられても、きれいな状態の控えがあれば元に戻せます。修正版を入れる前に何かされていないか不安なときも、バックアップがあれば落ち着いて対処できます。

3. 会社のIT担当者：使っているソフトの一覧を持つ

会社でサーバーやシステムを預かっている方にとって、いちばん大事なのは、自社で何を使っているかの一覧を持っておくことです。どのサーバーで、どのソフトの、どのバージョンが動いているか。これが分かっていないと、新しい脆弱性が公表されたときに「うちは関係あるのか」を答えるだけで何日もかかってしまいます。

最近は、ソフトの部品表を意味する「SBOM」（エスボム＝ソフトウェアがどんな部品からできているかを一覧にしたもの）を作る動きも広がっています。PHP2Shellのように、ソフトの奥深くにある土台の部品に欠陥が見つかった場合、部品表があれば影響する範囲をすぐに調べられます。

そのうえで、どれから直すかの順番を決めておきます。優先するのが基本なのは、次のものです。

• 先ほど紹介したCISAのKEVに載ったもの
• 外から直接触れるサーバー（インターネットに公開しているWebサーバーなど）にあるもの
• 認証なしで攻撃できるもの

すべてを同時に直そうとすると、かえって大事なものが遅れます。

4. 修正を当てる練習をしておく

修正版が出ても、本番のサーバーにいきなり入れるのはこわいものです。更新したことで、サイトの一部が動かなくなることもあるからです。そこで、本番と同じ構成の試験用の環境（ステージング環境とも呼ばれます）を用意しておき、まずそこで修正版を入れて動きを確かめ、問題がなければ本番に入れる、という流れを作っておくと安心です。

この流れを、騒ぎが起きていないふだんの更新で何度か回しておくと、いざというときにも落ち着いて進められます。PHP2Shellのように公表から数時間で数百万件の攻撃の試みが届く状況では、「試験に何日もかかるので本番は来週」では間に合いません。

修正を当てるまでの時間を短くする工夫は、見つかる欠陥が増える時代の守りの中心になります。

5. すぐ直せないときの判断を決めておく

PHP2Shellでは、英国のNCSC（国家サイバーセキュリティセンター）が「すぐに直せないシステムはオフラインにすることを検討してほしい」と呼びかけ、オランダのNCSC-NLは自分たちのサイトを予防的に止めました。日本でも、多くの組織が同じ判断をしています。

この「止めるか、止めないか」の判断は、騒ぎが起きてから考えるのでは間に合いません。ふだんから決めておくと、いざというときに迷わずに済むことは、次の3つです。

• どのサービスなら止めても影響が小さいのか
• 止めるならだれが決めるのか
• 利用者にはどう知らせるのか

毎週のように危機が訪れるかもしれない時代には、この準備が以前よりずっと大事になります。止めた組織と止めなかった組織の違いについては、関連記事「日本で何が止まったか」で詳しく取り上げています。

6. 守る側もAIを使う

攻める側がAIを使うなら、守る側もAIを使わない手はありません。OpenAIのDaybreakのように、守りのためのAIの仕組みはすでに出始めています。PHP2Shellで侵害されていないかを確かめるCodexスキルも公開されました。

ただし、AIの道具を入れれば安心、というわけではありません。AIが「問題なし」と答えても、それが正しいかを判断する力は人間の側に必要です。

逆に、AIが大量に「問題あり」と報告してきたときに、どれが本当に危ないのかを見分ける力も必要です。AIを上手に使うためにも、脆弱性とは何か、どうやって確かめるのかという基本は、人間が身につけておく必要があります。

7. 情報の追い方を決めておく

毎週のように新しい欠陥が見つかる時代には、ニュースを全部追いかけるのは無理があります。そこで、どこから情報を受け取るかをあらかじめ決めておくと楽になります。

日本語で信頼できる情報源を、表にまとめます。

自分が使っているソフトの開発元やレンタルサーバー会社のお知らせも、あわせて確認しておきましょう。

SNSでは、今回のPHP2Shellのように、正式な公表の前に不正確な情報が流れることがあります。実際、公表の前日にはCVE番号が誤った深刻度付きで出回りました。SNSの情報は「何かが起きているらしい」という手がかりとして受け取り、何をすべきかは公式の発表で確かめるようにすると、振り回されずに済みます。

8. 基本を学ぶなら一冊

「脆弱性を見つける」とはどういうことなのかを、自分の手で確かめてみたい方には、上野宣さんの『Webセキュリティ担当者のための脆弱性診断スタートガイド 第2版』（翔泳社）があります。上野さんは、セキュリティ診断の会社トライコーダの代表で、Webアプリケーションの安全を高めるための国際的な団体OWASPの日本支部の代表も務めている方です。

この本は2019年の発行で、AIを使った診断は扱っていません。しかし、AIが何を代わりにしてくれているのかを理解するには、まず人間が行う診断の流れを知っておくのが近道です。出版社や書店の紹介をもとにすると、主な特徴は次のとおりです。

• 脆弱性診断の考え方から、Webのやり取りの基本であるHTTPの仕組み、代表的な脆弱性の種類、診断の流れまでを、基礎編として順を追って説明しています。
• 実践編では、無料で使える診断ツール「OWASP ZAP」による自動の診断と、「Burp Suite」による手作業の診断のやり方を扱っています。どちらも、実際の診断の現場で広く使われている道具です。
• 練習用にわざと欠陥を入れたWebアプリ「BadStore」を、自分のパソコンの仮想マシン（パソコンの中に作るもう1台のパソコン）で動かしながら、手を動かして学べる構成になっています。他人のサイトを勝手に試す心配がありません。
• 診断の結果をまとめる報告書の作り方や、診断に関わる法律やガイドラインにも触れていて、仕事として診断をする人や、診断を外に頼む立場の人にも役立つ内容です。
• 第2版では、Webアプリの代表的な脆弱性を並べた「OWASP Top 10」の2017年版に合わせて内容を改め、診断ツールも当時の新しい版に対応させています。

ツールの画面などは発行当時のものなので、今の版とは見た目が違うところがあるかもしれません。それでも、「欠陥はどこに潜みやすいのか」「どうやって確かめるのか」という考え方は今も変わりません。AIが出してきた報告を読み解くための土台として、手元に置いておく価値のある一冊です。

Webセキュリティ担当者のための脆弱性診断スタートガイド 第2版をAmazonで見る

まとめ

PHP2Shellは、PHPの中に10年以上眠っていた2件の深刻な欠陥でした。見つけたのは、セキュリティ会社のCalifとWiz、そしてOpenAIの3者で、いずれもGPT-5.6 SolやGemini 4 Argonといった汎用のAIを道具として使っていました。

「AIが自律的に見つけた」という言い方もされていますが、公表資料からは、人間の研究者が仮説を立て、AIに大量の作業を任せ、結果を確かめて報告した、という姿が見えてきます。

OpenAIは「Patch the Planet」を打ち出し、守りの手薄な組織向けにDaybreakの利用補助として10億ドルを投じると発表しました。そして、同じような発見はこれから数カ月で大幅に増えると予測しています。

CloudflareのCEOも、インターネットの土台を支える別のソフトに複数の深刻な脆弱性があることを把握していると話し、今後数年は「毎週のように危機が訪れる」時期になりうると述べました。

実際、今年見つかった脆弱性は10月21日までに約8万5千件で、過去最多だった前年同期の2.2倍です。ただし、見つかる数が増えたことと、実際の被害が増えたことは別です。

悪用の「試み」と侵入の「成功」を分けて見ることも大切です。そして、見つかった欠陥を直す側の体制は、PHP Foundationの常勤職員が1人であるように、とても小さいままです。

• スマホやパソコン、アプリの更新を後回しにしない
• ブログやサイトを運営しているなら、PHPのバージョンとプラグインを確かめ、バックアップを取る
• 会社では、使っているソフトの一覧を持ち、直す順番と「止める判断」を決めておく
• 守る側もAIを使い、その結果を判断できる基本の知識を身につける

見つける力がどれだけ強くなっても、修正版を入れるのは使う側の一人ひとりです。AIが脆弱性を見つける時代は、もう始まっています。次の「PHP2Shell」がいつ来ても慌てないように、できるところから備えておきましょう。

出典

• Decrypt：PHP2Shellを見つけたのはだれか（OpenAI、Calif、Wizの役割）
• SmartScope：PHP2Shellは本当にAIが見つけたのか（各者の役割の分析）
• Gizmodo：OpenAIの「Patch the Planet」について
• 日本経済新聞：PHP並みの脆弱性「まだ出てくる」
• セキュリティ対策Lab：Cloudflare CEOが深刻な脆弱性の存在に言及
• 南日本新聞（共同通信配信）：脆弱性の発見件数が前年同期の2.2倍に
• PHP Foundation：Transparency and Impact Report 2024
• piyolog：PHP2Shellに関するまとめ
• gihyo.jp：PHPの緊急セキュリティリリース
• Help Net Security：PHP2Shell patched (CVE-2026-109618, CVE-2026-109619)
• watchTowr：PHP CVE-2026-109618 FAQ
• 紀伊國屋書店：Webセキュリティ担当者のための脆弱性診断スタートガイド 第2版（書誌情報・目次）

※この記事の内容は、2026年10月24日時点で公表されている情報をもとにしています。