2026年10月21日、PHPの開発チームは異例の緊急リリースを出した。PHP本体に潜んでいた2件の重大な脆弱性、通称「PHP2Shell」の修正版である。これらはAIの支援によって発見されたとされ、公式発表の前に詳細が外部へ漏れ、公開の数日前から攻撃の試みが観測されていたという。「AIが見つけた欠陥を、攻撃者が先に突き始めた」という、これまでにない形の事件である。今回は、わかっている事実と、まだ確定していない点を分けながら整理する。
何が起きたのか: PHP本体の2件の脆弱性
Wizの公開した分析によれば、PHP2Shellは次の2件のCVEからなり、いずれもCVSS（深刻度の指標）は最大9.2とされている。
- CVE-2026-109618: アップロード進捗の処理に使われるアンシリアライザの use-after-free。認証なしで、PHPワーカーのプロセスメモリ（パスワード、トークン、APIキーなど）を遠隔から読み出せる
- CVE-2026-109619: 致命的エラー時のバックトレース処理に起因する use-after-free と、OPcacheの型混乱
共通する原因は、メモリ不足などで異常終了したリクエストの後に古い内部状態が残り、後続の処理がそれを再利用してしまう点にある。Wizは、メモリ開示と組み合わせることでアドレスの不確実性を取り除き、WordPress・Drupal・Joomlaに対する認証不要のリモートコード実行を実証したという。重要なのは、問題がアプリケーションではなくPHPエンジン自体にあることだ。そのため、特定のCMSだけでなく、一般的なPHPアプリケーションが影響を受けうる。
修正版は、Help Net Securityの報道によれば、PHP 8.5.12・8.4.27・8.3.36・8.2.35である。PHPセキュリティチームは7.4・8.0・8.1向けの最小限のバックポートも公開したとされるが、サポートが終了した系統を使い続けている環境では、ディストリビューションや延長サポートを提供するベンダー経由での対応が必要になる。
AIはどう関わったのか
発見の経緯は、情報源によって書き方が異なる。Fortuneの報道を整理すると、複数の組織が8月ごろに、それぞれ独立してAIを使って同じ領域の問題にたどり着いている。
- Calif（AIレッドチーム企業）: 8月1日、GPT-5.6 Solを使って最初の問題を発見し、OpenAIに報告。OpenAIの「Patch the Planet」構想への参加がきっかけで、PHPを調査対象に選んだという
- OpenAI: 報告を受けて独自に調査して追加の要素を見つけ、関係者を集める調整役を担った
- Wiz: 8月19日、Gemini 4 Argon・GPT-5.6 Sol・自社のWiz Atlasを組み合わせて独立に発見し、8月24日にPHPのセキュリティチームへ報告した
注目すべきは、この欠陥が14年間存在していたことだ。2024年にも限定的な形で見つかっていたが、重大とは見なされなかったとされる。AIが変えたのは、欠陥の存在そのものではなく、「弱点を理解し、実際に動く攻撃コードに仕上げる」工程のハードルである。Wizも、攻撃の連鎖を組み立てる作業でフロンティアAIモデルがその障壁を大きく下げたと説明している。同じ月に複数の組織が別々にたどり着いたという事実は、攻撃者側も同じ道具で同じ場所に到達しうることを示唆している。
個人的に重要だと感じるのは、AIの役割が「弱点の指摘」にとどまっていない点だ。Wizは実際にWordPress・Drupal・Joomlaで認証不要のリモートコード実行を再現してみせた。「ここが危ない可能性がある」と述べるだけでなく、「実際にこう攻撃できる」という再現性を示せるようになったことが、AIの能力が生きている部分だと思う。これまでのセキュリティは、起こりうる可能性への防御や、過去の事例を踏まえた対策が中心だった。今後は予測に加えて、実際の攻撃をAIが先に再現し、攻撃者より前に対応できる、という方向へ重心が移っていくのではないか。
差を生むのはAIの性能か、使い手か
ここで気になるのは、こうした成果の差がAIモデルの性能差から生まれているのか、それとも使う人の視点や技量から生まれているのか、という点だ。
材料はいくつかある。AnthropicのMythosは、サイバー能力の高さを理由に、2026年4月の時点でProject Glasswingを通じて検証済みの組織に限定して提供された。重要なソフトウェアを守る側が先に備えられるようにする狙いである。一方、今回のPHP2Shellに使われたGPT-5.6 Solは、Amazon Bedrockなどを通じて一般に利用できるモデルだ。Gemini 4 Argonは、一般提供の開始が10月であり、8月の発見よりは後になる。つまり、限定提供の高性能モデルだけが成果を出したわけではなく、複数の組織が異なるモデルで同じ欠陥に到達している。ただし、これだけで「性能差は関係ない」とまでは言えず、現時点では判断材料が足りない。
私の考えでは、ここが今後の対応を分ける。もし差が主にモデルの性能に由来するのであれば、Mythosのように企業や防御側を優先して提供するやり方で、時間を稼ぐことができる。しかし、差が使い手の視点や技量に由来するのであれば、モデルを囲い込むだけでは足りず、AIを使いこなして脆弱性を見つけ、検証できる人材や仕組みという、新しいセキュリティ対応能力そのものが必要になる。
漏洩と「公開の4日前」の攻撃
今回の事件を特徴づけているのは、非公開期間（エンバーゴ）が守られなかった点だ。
SecurityWeekの報道によれば、2件のCVEの詳細は、協調開示と公式パッチの前にオンラインへ漏れた。Fortuneによれば、詳細が報じられたのは10月20日の夜で、PHP側は予定していたリリースを前倒しして21日に修正版を出した。漏洩元や経路は、確認できた範囲では明らかになっていない。
ただ、この経路がAIを介したものか、人間によるものかで、必要な対策は大きく変わると思う。もし人間による流出であれば、システムによる防御というより個人の意識の問題になるため、対応はずっと難しい。今後のセキュリティの要は、AIよりも、むしろ人間の側にあるのではないか。
攻撃の観測時期については、情報源ごとに温度差がある。Help Net Securityは、Amazon Threat Intelligenceが自社のハニーポット網で10月17日に悪用の試みを記録したと伝えている。公開の4日前で、この時点では脆弱性はまだエンバーゴ中だった。試みは匿名化サービスのIPアドレス経由で、攻撃者がどのように情報を入手したのかは不明である。一方、同じ時期にHuntressなどは、漏洩の直後の時点で実環境での悪用を確認できていないとしていた。
その後の拡大は急だった。Fortuneによれば、Cloudflareは情報が出回ってから45分で「数万回」の攻撃試行を観測し、2時間で数十万回、21日夕方までに数百万回に達したという。AWSは「実環境で広く悪用されている」と報告している。なお、被害を受けたと主張する事業者の話も出ているが、これは確認が取れていない。
「ウェブの70%」という数字をどう読むか
見出しでは「インターネットの70%に影響」といった表現が目立つ。この数字はWizの分析に由来するとされるが、Fortuneの記事では算出方法は示されていない。関連する数字としては、WordPressが全サイトの約40%を動かしているというReutersの推計や、Palo Alto Networksが約2,260万の潜在的な脆弱インスタンスを特定したという話が挙げられている。「PHPが広く使われている」こと自体は確かだが、「70%が今すぐ危険」という意味ではない。実際に危険かどうかは、動かしているPHPのバージョンと、パッチを当てたかどうかで決まる。
サイト運営者はどう備えるか
対策の基本は、修正版へ更新することに尽きる。Wizも、パッチの適用が完全な修正になる唯一の方法だと明記している。
- 自分でサーバーを管理している場合は、使用中のPHPのバージョンを確認し、修正版（8.2〜8.5系なら上記のバージョン）へ更新する
- レンタルサーバーやマネージドなホスティングでは、事業者がいつPHPを更新するかを確認する。自分で更新できない場合は、事業者の告知や対応状況を確かめる
- すぐに更新できない場合のWAF（Cloudflare・Fastly・Vercelなどが提供するもの）は、あくまで暫定措置であり、根本的な解決ではない
- 脆弱性はパッチ前に悪用されうるため、更新後も、異常なHTTP 500の連続や、不審に大きい
PHPSESSIDのCookie、原因不明のPHPワーカーの入れ替わりといった兆候がないかを確認する
まとめ
PHP2Shellが突きつけているのは、「AIが脆弱性を見つける」こと自体より、発見から悪用までの時間がAIによって縮んでいるという現実である。守る側は協調開示という手順を踏んで修正を準備したが、その非公開期間のどこかで情報が漏れ、攻撃者側は公開前から動いていた。誰が漏らしたのか、攻撃者がAIを使っていたのかは、現時点で確認できていない。ただ、複数の組織が同じ月にAIで同じバグへ到達していたという事実を踏まえれば、「見つける力」は守る側だけのものではなくなっている。
今後は、パッチが公開されてから適用されるまでの時間が、これまで以上に勝負を分けるだろう。更新を後回しにできる時代は終わりつつある、と感じる。
これまでは後回しにしてもなんとかなっていたが、これからは少しの見送りが取り返しのつかない影響につながりかねない。対応に携わる人の負担は増える一方である。それでも、一度AIが普及してしまった以上、攻撃者がAIを使うことは避けられない。だとすれば鍵になるのは、攻撃者以上に、防御する側がAIによってどこまで対応をカバーできるかではないか。攻撃の再現を先回りして行い、更新作業を支え、異常の兆候を拾う——そうした場面でAIを味方につけられるかどうかが、これからの防御の差になっていくと思う。