【解説】php2shellはなぜ14年見逃されたのか｜AIが掘り起こしたPHPの欠陥と、これからのサイト保守【2026年10月23日】

公開日
2026.10.23

2026年10月21日に修正版が公開された PHP 本体の重大な脆弱性「php2shell」（CVE-2026-109618 / CVE-2026-109619）は、新しく作り込まれた欠陥ではありません。発見者の調査によれば、攻撃につながる処理は 2012年の PHP 5.4.0 の時点ですでに存在しており、約14年間、誰にも「攻撃できる形」で見つけられないまま世界中のサーバーで動き続けていました。

それがなぜ今になって見つかったのか。答えの中心にあるのは AI です。2026年夏、AI を使った大規模なオープンソース監査のなかで攻撃経路が特定され、そこから約2か月半の水面下の修正作業、そして公開直前の情報流出という慌ただしい展開をたどりました。この記事では、PHP Foundation の公式発表など一次情報をもとに、php2shell が生まれ、見逃され、見つかるまでの経緯と、これから Web サイトの保守に何が起きるのかを整理します。

※本記事は 2026年10月23日時点の情報です。「今すぐ何をすればいいか」の対応手順は、前回の記事「【修正版公開】PHP脆弱性「php2shell」｜レンタルサーバー利用者が今やるべき5ステップ」にまとめています。

php2shell とは — 30秒でおさらい

php2shell は、PHP 本体のメモリ管理とエラー処理に見つかった、認証なしでサーバー上の任意コード実行（RCE）につながりうる脆弱性 2 件の通称です。深刻度はいずれも CVSS v4.0 で 9.2（Critical）。修正版は PHP 8.5.12・8.4.27・8.3.36・8.2.35 で、8.1 以前には公式の更新版が出ていません。

どちらも「ほぼすべてのリクエストが通る、PHP のいちばん土台の部分」にある問題です。この「土台にある」という性質が、後で見るように見逃され続けた理由にも、直すのに時間がかかった理由にもつながっています。

欠陥はいつからあったのか — 2004年から続く「メモリ上限」の系譜

発見者であるセキュリティ企業 Calif の調査では、今回見つかった攻撃経路のうち最も古いものは PHP 5.4.0（2012年3月リリース）までさかのぼるとされています。PHP 公式は影響を受ける最古のバージョンを明言していませんが、Cloudflare や watchTowr など複数の調査機関も「PHP 5.4 以降のほぼすべて」という同様の見方を示しています。

さらに、国内外の解説記事が整理している経緯をたどると、今回の問題は「メモリ上限に達したときの後始末」という、PHP が長年抱えてきた弱点の延長線上にあります。

つまり php2shell は、「同じ種類の弱点が、形を変えて何度も顔を出していた」ものの、決定的な攻撃経路だけが長く見つかっていなかった、という性格の脆弱性です。

なぜ14年間見つからなかったのか — 3つの理由

1. 「メモリが尽きた瞬間」という、狙って起こしにくい条件

今回の欠陥が表に出るのは、リクエストの処理中にメモリ上限へ「ちょうど悪い瞬間」に到達したときです。普段の運用でそうした状況はまず起きず、起きたとしても「メモリ不足のエラーが出た」で終わってしまいます。そこから攻撃につなげるには、どの処理の途中で、どのデータが中途半端な状態で残るのかを、PHP 内部の構造まで理解して組み立てる必要がありました。

2. 2024年に兆候は見えていたが、修正方針がまとまらなかった

実は、問題の兆候は 2024年に一度見つかっています。PHP Foundation が資金を出し、OSTIF の仲介でセキュリティ企業 Quarkslab が実施した外部監査の指摘を直していた開発者が、メモリ不足まわりの異常に気づいたのです。

しかし、このときは具体的な攻撃方法が見つからず、明らかに影響の大きい別の問題の対応が優先されました。さらに、メモリ管理とエラー処理という土台部分の修正は、互換性・性能・サードパーティ拡張への影響が避けられません。複数の修正案がそれぞれ別の弱点を抱えるなか、全員の合意を前提とするセキュリティチームは方針を決めきれず、作業は数か月にわたって止まっては再開することを繰り返しました。

PHP Foundation は公式ブログで、この状況を「セキュリティチームの意思決定の仕組みと、人員不足の両方が原因の構造的な失敗」と自ら認めています。

3. 世界の Web を支える割に、守り手が少ない

PHP は世界の Web サイトの大半を支える言語ですが、その開発を支える PHP Foundation は、英 The Guardian の報道によれば常勤・非常勤あわせて13人ほどで、寄付によって運営されています。PHP Foundation 自身も、「PHP のエンジン内部を深く理解しているエンジニアの不足」が最大の制約だと述べています。土台の奥深くにある問題ほど、調べられる人が限られるのです。

AI はどうやって見つけたのか — 2026年夏の発見

状況を動かしたのは、2026年に入って本格化した AI を使ったオープンソースの脆弱性調査でした。

注目したいのは、Calif 自身の説明です。同社は一般に提供されている AI モデルだけを使い、特別な仕組みは使っていないとしたうえで、「2004年の脆弱性の『取り残し』があるのではないか」という仮説を立て、AI に問いを重ねて数日で最初の経路にたどり着いたと述べています。そして「モデルの性能より、PHP の歴史を知っていたことのほうが重要だった」「単純な指示で『すべてのバグ』を掘り起こせるモデルは、少なくとも今はない」とも語っています。

一方の Wiz も、自社ツールと複数の AI モデルを組み合わせて、Calif の数週間後に独立して同じ問題にたどり着きました。別々のチームが、別々の AI を使って、ほぼ同時期に同じ14年前の欠陥を見つけた——この事実は、AI によって「古いコードの奥に眠る欠陥」を掘り起こすコストが大きく下がったことを示しています。

流出と前倒し — 公開直前の慌ただしい48時間

本来の計画では、修正版は日本時間 10月22日 23:00 に、関係各所と足並みをそろえて公開される予定でした（協調的開示）。しかし公開直前に、計画は大きく崩れます。

PHP Foundation は、Chainguard の先行公開を「一方的に公開制限を破り、多くの関係者が数週間かけて進めてきた協調的開示を無視した」と強い言葉で批判しています。Calif の動画についても、攻撃コードの開発を早めた一因になったとの見方を示しました。

一方で、PHP のセキュリティチームは「公開時点で、実際に動く攻撃コードは確認していない」としています。日本国内では、この「前倒し」と「中身の分からない流出情報」が重なったことで、レンタルサーバー各社の緊急メンテナンスや管理画面の一時停止が相次ぎ、多くのサイト運営者が状況をつかめないまま一夜を過ごすことになりました。

公開後に何が起きたか — 攻撃の「試み」は数百万件規模に

• Cloudflare：マシュー・プリンス CEO によると、同社ネットワークで観測した悪用の試みは、公表前の10時間で数千件、公表後45分で数万件、2時間以内に数十万件、その後数百万件に達した
• Amazon：公開後数時間で複数の攻撃コードが出回り、ほぼ即座に自社のセンサーへ使われたことを確認。複数の攻撃者によるものとみている
• CISA（米国）：10月22日時点で「悪用が確認された脆弱性カタログ（KEV）」には未登録
• Sansec：公開日の大規模な悪用を予想していたが、攻撃の成立には対象ごとの知識やサーバー条件が必要で、「1回のリクエストで誰でも乗っ取れる」型ではないとして、大量悪用の可能性は下がったとの見方

まとめると、「攻撃の試み」は世界中で急増している一方、「実際に侵害された」という確かな被害報告は、10月23日時点では公になっていません。ただし、古い PHP のまま放置されたサイトが狙われ続ける構図は変わらないため、楽観はできません。

これから何が起きるのか — 4つの変化

1. AI で見つかる脆弱性は、さらに増える

OpenAI は今回の件を「近年で最も影響の大きいセキュリティ問題の一つ」と位置づけたうえで、今後数か月で同様の発見が急増するとの見通しを示しています。PHP Foundation も、AI を使った研究によって報告数が増えていると明かしており、7月以降だけで100件を超える「無効・重複・再現できない」報告を処理してきたといいます。PHP に限らず、WordPress・各種ライブラリ・サーバーソフトなど、長年使われてきたソフトウェアの「古い欠陥」が次々に掘り起こされる時代に入ったと考えるべきでしょう。

2. 「修正版の公開」から「攻撃開始」までの時間が縮む

Amazon は、AI によって修正の差分やアドバイザリを解析するコストが下がったため、修正版の公開から実用的な攻撃コードが出るまでの時間は今後さらに短くなると予想しています。また「公開制限（エンバーゴ）が守ってくれるのは、ほかの誰かが同じバグを見つけるまで」とも指摘しています。今回のように、公開日より前から攻撃が始まっている前提で備える必要があります。

3. 脆弱性公開のルールそのものが見直される

PHP Foundation は再発防止策として、セキュリティチームの意思決定を多数決でも進められる形に改め、難しい判断を伴う重大案件には早い段階から財団の幹部が関わる方針を示しました。報告の検証や重複の整理には AI を使いつつ、「すべての判断は人が行い、すべての修正に人が取り組む」としています。OpenAI も、AI 時代の重大な脆弱性をどう知らせるべきか（流出時の日程変更、事前通知の範囲など）について業界に意見を求めており、協調的開示の仕組みは今後変わっていく可能性があります。

4. オープンソースを「誰が支えるのか」が問われる

PHP Foundation は、PHP の上でビジネスをしている企業、ホスティング事業者、ディストリビューション、そして政府に対し、継続的な資金支援を呼びかけています。今回、複数のエンジニアが週末も含めて昼夜を問わず修正に取り組めたのは、財団の資金があったからだといいます。世界中のサイトが無料で使っている土台を、誰がどう支えるのか——php2shell はその問いを改めて突きつけました。

制作会社の現場から — 「古い PHP」を上げると何が起きたか

私たちシエロデザインでも、修正版の公開直後から、保守しているクライアントサイトの PHP を順次確認・更新しました。現場で見えたのは、「PHP を上げること」自体より、「上げたときに古いコードが動かなくなること」が本当の壁になるという実態です。

• 7.x のまま止まっていたサイトが少なくない：制作から年数が経ったサイトほど、サーバーの PHP が古いバージョンのまま固定されていました。今回、公式の修正版が出ない 8.1 以前のサイトは、まず移行先の 8.3 で動くかの確認から始める必要がありました
• 古いプラグインや独自コードが 8.3 で止まる：PHP 8 で廃止された書き方（文字列の {} での参照、create_function()、get_magic_quotes_gpc() など）が、更新の止まったプラグインやテーマ、自作のメールフォームに残っており、そのままでは画面が真っ白になるケースがありました。1行単位の修正で動くものがほとんどでしたが、事前の洗い出しが欠かせません
• サーバーによって切り替え方がまったく違う：管理画面のボタン1つで切り替わるサーバーもあれば、.htaccess や php.ini の記述で指定するサーバーもあります。管理画面の表示と実際に動いている PHP が一致しないこともあり、「末尾の数字まで実機で確認する」ことが重要でした
• 「表示はOK」でも「メールが届かない」：PHP 8 系への移行後、古いメールフォームのヘッダーの書き方が原因で送信メールが届かなくなる例もありました。表示確認だけでなく、フォームの送信テストまでが移行作業です

今回の件で改めて感じたのは、「普段から PHP を新しい版に保っているサイトほど、緊急時の対応が早い」ということです。8.3 以上で運用していたサイトは、サーバー会社の更新を確認するだけでほぼ済みました。一方、古い版のまま止まっていたサイトは、脆弱性対応と PHP 移行を同時に、しかも急ぎで行う必要がありました。

サイト運営者がこれから意識したいこと

1. PHP のバージョンを「年1回は見直す」：PHP 8.2 は 2026年12月31日でサポートが終わります。8.3 以上を基準に、次の移行時期をあらかじめ決めておくと、緊急時に慌てずに済みます
2. WordPress の更新と、サーバー側の更新は別物と考える：今回のように土台の PHP に問題がある場合、WordPress やプラグインの更新だけでは守れません
3. 「公開日＝攻撃開始日」ではない前提で備える：重大な脆弱性では、公開前から攻撃が始まっていることがあります。修正版が出たら「数日以内」ではなく「当日中」に動ける体制が理想です
4. 保守の範囲を確認しておく：保守契約に「サーバー側の PHP 更新」や「更新後の動作確認」が含まれているか、一度確認しておくと安心です

FAQ — よくある質問

Q. php2shell は、最近のアップデートで入ったバグですか？
A. いいえ。発見者の Calif によれば、攻撃につながる処理は 2012年の PHP 5.4.0 の時点で存在していました。約14年間、攻撃できる形で見つかっていなかった古い欠陥です。

Q. AI が見つけたというのは本当ですか？
A. はい。Calif は OpenAI の「Patch the Planet」の一環として、一般提供されている AI モデルを使って攻撃経路を見つけたと説明しています。Wiz も複数の AI モデルを組み合わせて独立に発見しました。ただし Calif は、決め手は AI の性能より PHP の過去の脆弱性の歴史を知っていたことだったとしています。

Q. 2024年に兆候が見つかっていたのに、なぜ直されなかったのですか？
A. 当時は具体的な攻撃方法が見つからず、ほかの問題の対応が優先されました。また、土台部分の修正は互換性や性能への影響が大きく、修正方針がまとまりませんでした。PHP Foundation はこれを「意思決定の仕組みと人員不足による構造的な失敗」と認め、意思決定の方法を見直しています。

Q. 今後も同じような脆弱性は出てきますか？
A. その可能性は高いと考えられます。OpenAI は今後数か月で同様の発見が急増するとの見通しを示しており、PHP Foundation も AI による報告が増えているとしています。PHP に限らず、長く使われてきたソフトウェアの古い欠陥が見つかるペースは上がっていくでしょう。

Q. 自社サイトはまず何をすればいいですか？
A. サイトの PHP バージョンを確認し、修正版（8.5.12／8.4.27／8.3.36／8.2.35）になっているかを確かめてください。8.1 以前の場合は、8.3 以上への移行が必要です。具体的な手順は前回の記事で解説しています。

Q. 古いサイトなので、PHP を上げると壊れそうで不安です。
A. 古いテーマやプラグイン、独自のメールフォームは、PHP 8 系で動かなくなることがあります。ただ、多くは数行の修正で対応できます。事前にコードを確認し、表示・管理画面・フォーム送信までテストしてから本番を切り替えるのが安全です。

まとめ

php2shell は、2012年から PHP の土台に潜んでいた欠陥が、2026年の AI を使った大規模監査によって掘り起こされたものです。2024年には兆候が見えていながら、攻撃方法が見つからず、修正方針もまとまらないまま時間が過ぎました。そして公開直前の情報流出が、世界中のサイト運営者を慌ただしい一夜に巻き込みました。

この出来事が示しているのは、「古いから安全」「誰も見つけていないから大丈夫」が通用しない時代になったということです。AI によって脆弱性の発見も、攻撃コードの作成も速くなっていきます。サイトを守る側にできることは、PHP をはじめとする土台を普段から新しい版に保ち、いざというときにすぐ動ける状態にしておくことです。

シエロデザインでは、WordPress サイトの保守運用や、古い PHP からの移行（テーマ・プラグイン・メールフォームの PHP 8 対応を含む）のご相談を承っています。「自社サイトの PHP がいくつか分からない」という段階からでも対応できますので、お気軽にお問い合わせください。

参考・出典

• The PHP Foundation「Today’s PHP Security Release, and How We’re Strengthening PHP Security」
• php.net「News Archive 2026」（セキュリティリリース告知）
• OpenAI「Patch the Planet: a Daybreak initiative to support open source maintainers」
• AWS ブログ「Amazon Threat Intelligence が PHP2Shell の脆弱性公開前の悪用を MadPot で特定」
• Cloudflare Blog「Cloudflare deploys protections against php2shell vulnerability」
• Sansec「PHP2Shell: PHP RCE (CVE-2026-109618, CVE-2026-109619)」
• Tenable「php2shell: Frequently Asked Questions」
• The Next Web「PHP rushes out emergency patches for two critical bugs AI found first」
• ITmedia NEWS「PHP『緊急』脆弱性悪用の試み、数百万件に CloudflareのCEOが報告」
• innovatopia「【解説】PHP2Shell、AIが見つけたPHPの重大脆弱性 CVE番号の流出で公開を前倒し」
• Wikipedia「PHP2Shell」

次に読む

• 【修正版公開】PHP脆弱性「php2shell」CVE-2026-109618/109619｜レンタルサーバー利用者が今やるべき5ステップ

この記事を書いた人

WEBディレクター

佐藤 広樹 Sato

仕事を通じて出会った方から「人から学ぶ」ことを大切に、AIやWEBから得られない知見を吸収するよう意識しています。

スタッフ紹介はこちら →