PHPの脆弱性、独立した2社のAI監査が同じ日に到達

2026年10月21日の深夜、スマホに「緊急メンテナンスのお知らせ」が立て続けに届いた人もいるはずだ。ニコニコ、pixiv、BASE、さくらのレンタルサーバ。¹ 使っているサービスが次々と止まるのは、どこか1社の不備ではない。PHPというプログラミング言語そのものに、重大な脆弱性が見つかったからだ。²

脆弱性には「php2shell」という通称が付き、CVE番号はCVE-2026-109618とCVE-2026-109619。³⁴ 報道の一部には「AIが見つけた」ともある。サーバーの奥深くにある欠陥の発見に、なぜAIが関係するのか。

何が起きているのか

緊急メンテナンスの理由は、PHPコア本体に見つかった2件の重大な脆弱性だ。PHP Foundationの公式ブログによると、CVE-2026-109618はメモリ不足のタイミングを突く経路になる。CVE-2026-109619は古い内部状態を使い回す経路だ。どちらもリモートから任意のコードを実行できる。深刻度はいずれもCVSS v4で9.2、5段階の最上位「Critical」にあたる。GitHub公式アドバイザリが確定させた数字だ。

Wizの報告によれば、PHPは世界のウェブサイトの約70%で使われ、PHP 5.4以降のほぼ全バージョンが対象になる。自分のアプリのコードが安全でも、PHP本体がこの欠陥を抱えていれば影響を受ける。修正済みのPHP 8.5.12、8.4.27、8.3.36、8.2.35は、2026年10月21日にすでに公開された。php.netのChangeLogで確認できる。

では、なぜ1件のリクエスト処理の不具合が、他の利用者のリクエストにまで影響するのか。

なぜ次のリクエストまで巻き込まれるのか

攻撃者がやっていることは意外と単純だ。ファイルアップロードのデータを、PHPに設定されたメモリの上限(memory_limit)へわざと到達させるように送りつける。公式ブログはこれを、メモリ不足による致命的エラーのタイミングを突く攻撃と説明する。

PHPの1回のリクエストは、本来は処理が終われば何も残らない使い捨ての仕組みのはずだ。ところが、メモリ不足で処理が強制的に中断された瞬間、内部ではまだ初期化の途中だったデータが、完成した有効なデータであるかのように扱われてしまう。Apache+mod_php環境では、アプリ側の処理に入る前の段階ですでにコード実行が成立する例が、デフォルト設定のまま実証された。PHP-FPMでも、アプリケーション層の経路でコード実行が確認されている。

本来は後に何も残らないはずの1回限りの処理が、中断というわずかな隙を突かれて、他の誰かのリクエストにまで影響を持ち越す土台になっていた。

この種の欠陥が見つかること自体は、珍しい話ではない。では、なぜ今回に限って「AIが見つけた」と繰り返し報じられているのか。

なぜAIが見つけたとされるのか

ここまでの経緯は、実は2024年から始まっている。外部監査団体Quarkslabが、OSTIF経由でドイツ政府系のSovereign Tech Agencyの資金を受けて監査を行っていた。ちょうど同じ頃、PHPコア開発者自身もメモリ不足の問題の最初の兆候に気づいていた。だが他の問題に注目が集まり、優先度は下がった。修正案は後方互換性を壊す、別の不具合を生む、拡張機能に影響するなど、それぞれに問題を抱え、合意形成が数か月進まなかった。公式ブログはこれを、自ら「構造的な失敗」だったと認めている。

動き出したのは2026年だ。OpenAIは同年6月22日、Trail of Bitsと共同で「Patch the Planet」という取り組みを発表した。AIを使った脆弱性調査と専門家によるレビューを組み合わせ、影響の大きいオープンソースソフトウェアを支援する枠組みで、HackerOneやCalifも協力する。Trail of Bitsの発表にある。ここから10月のパッチ公開までを時系列で並べると、次のようになる。

• 2026年7月30日: Califが招待を受け、PHPの監査を開始(Calif公式ブログ)
• 2026年8月11日: CalifとOpenAIが、互いに連絡を取り合わないまま、同じ根本原因のコード実行の脆弱性を同じ日に報告(Calif公式ブログ)
• 2026年8月24日: Wiz Researchが別の攻撃経路を報告(公式ブログ)
• 2026年9月18日: OpenAI自身がさらに別の経路を報告(公式ブログ)

自分が最初に驚いたのは、8月11日の一致だ。2社が示し合わせたわけではない。独立に動いていたAI主導の監査が、同じ古いバグの系譜へ、ほぼ同時にたどり着いたということになる。これ以降、この一連のメモリ不整合の修正がPHPチームの最優先事項になった。

Wizは発見と検証に、自社の「Wiz Atlas」に加えて「Gemini 4 Argon」や「GPT-5.6 Sol」を使ったと説明する。PHPのバージョンや設定、メモリの配置ごとに攻撃コードを自動で調整し、失敗すれば原因を分析してやり直す。この作業をAIに任せたという。Wiz公式ブログ。GitHubの公式アドバイザリの報告者欄にも、Calif・Wiz・OpenAIに連なる名前が並ぶ。GitHub公式アドバイザリ。

1年以上動かなかった修正が、1か月半のあいだに3回も新しい攻撃経路を突きつけられたことになる。この短期間の積み重ねは、PHPの運営体制に何を残したのか。

財団は意思決定の方式を変えた

公式ブログによると、PHP財団は2026年5月に「Ecosystem Security Team」を新設した。7月にAlexandre Daubois氏、9月にDaniel Scherzer氏がここに加わっている。AIセキュリティエンジニアのVolker Dusch氏は、PHPセキュリティチームと財団の間をつなぐ役を担った。そして、セキュリティ判断の決め方そのものを「合意形成」から「多数決」に切り替えたという。

自分がここで腑に落ちたのは、2024年の停滞の原因が技術力の不足ではなく、合意に時間がかかりすぎたことだったという点だ。AI主導の監査が機械の速度で報告を積み上げる一方、人間側の意思決定が従来のペースのままでは、修正はいつまでも追いつかない。多数決への切り替えは、その速度差を埋めるための対応として読める。

一方で、速さは別の問題も生んだ。10月20日UTCには、CVE番号とCVSSスコアがフォーラムやSNSに流出した。このとき「CVSS10.0」という誤った数値と、誤ったリリース予定時刻も一緒に広まった。財団が確定させた深刻度は、10.0ではなく9.2だ。

差は大きくないが、深夜に数字だけを見て「満点の脆弱性」と身構えた人には、この訂正に意味がある。財団は誤情報の拡散を受けて事前告知を前倒しし、リリースも10月22日の予定から10月21日14:00 UTCへ早めた。自分がPHPを使っているなら、ここから先は訂正の読み方より、手元の対応のほうが大事になる。

まとめ

PHPコアの脆弱性「php2shell」は、メモリ不足による内部状態の壊れを悪用し、リモートからコードを実行できるようにする欠陥だった。修正は2024年に兆候が見つかりながら、合意形成が進まず止まっていた。これを動かしたのは、AI主導の監査だった。OpenAIの「Patch the Planet」の枠組みの下、CalifとWizが独立に進めた監査が、1か月半のあいだに3回、同じバグの系譜へ到達している。PHP財団はこれを受けて、セキュリティ判断の決め方を合意形成から多数決へ切り替えている。

自分のサイトやサービスがPHPで動いている場合、確認することは次の2つになる。

レンタルサーバーやクラウドを使っている場合は、利用中の事業者が緊急メンテナンスやアップデートの案内を出していないか、まず確認するとよい。

Footnotes

1. https://gigazine.net/news/20261021-php-php2shell-maintenance/ ↩

2. https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/ ↩

3. https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w ↩

4. https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp ↩