PHPの緊急脆弱性（通称PHP2Shell、CVE-2026-109618 / CVE-2026-109619）について、仕組みと対応チェックリストをまとめた記事を書きました。
対応方法のまとめが主な内容だったのですが、その後も続いている反応の中で、気になる声がいくつも目につきました。

「もうPHPはやめておけ」

「今どきPHPの時点で古い」

「そういうレガシー言語の宿命だよね。。」

...果たして本当にそうでしょうか。

個人的には、この事件から読み取るべきメッセージはむしろ真逆だと考えています。
この脆弱性がPHPユーザーにしか関係ない話でも、「PHPを選んだのが悪い」という話でもない。もっと大きな地殻変動の最初の事例だと見るべきです。

この記事では、次の3点を整理します。

AIがC/C++製ランタイムのメモリバグを実用的な攻撃に変換できる時代になった
なぜ「PHP（や古いフレームワーク）を使っているのが悪い」という結論は的外れなのか
その上で、私たちが本当に投資すべきことは何か

AIはメモリバグを攻撃に変えるツールになった

まず前提として、脆弱性の世界には2段階あることを押さえておきましょう。

バグ（欠陥）を見つける
そのバグを攻撃に変換する（エクスプロイトを完成させる）

メモリ破壊系のバグでは、この2段階目が非常に高いハードルでした。例えば「解放済みのメモリをもう一度使ってしまう（use-after-free）」という欠陥が分かっていても、それをサーバー上での任意コード実行まで持っていくには、次のような膨大な試行錯誤が必要になります。

プロセスのメモリレイアウトを推測し、ヒープの状態を攻撃者の都合に合わせて準備する
ASLR（アドレス空間配置のランダム化）などの緩和機構を回避する
PHPのバージョン、実行形態（FPM / mod_php / CGI）、設定の違いごとに条件を合わせ込む

つまり「バグが見つかった」から「攻撃可能」までには、熟練した研究者が数ヶ月単位で向き合う深い谷があったのです。
実際、脆弱性研究者の世界では「再現はしたが武器化は諦めた」という報告が日常的にありました。
言い換えると、過去30年間で見つかってきた大量のメモリバグは、「見つかってはいるが、実用兵器にはなっていない」眠った状態で世界中に積み上がっていたわけです。

今回、何が起きたのか。
PHP2Shellの時系列を振り返ると、こうなっています。

2024年： PHPのコア開発者たちがこのメモリ問題の初期兆候に気づいていました。ただし攻撃経路（悪用の方法）が見つからず、修正は立ち往生したまま放置されていた
2026年夏：セキュリティ研究者がAIモデル（GPT-5.6 Sol など）を活用したソースコード解析によって、この「眠っていた欠陥」を実際に動くリモートコード実行の攻撃チェーンに変換することに成功。別の大手セキュリティ企業もAIエージェントを使って独立に発見・検証した
2026年10月：攻撃チェーンの情報がリークされ、PHP側が緊急リリースで対応

注目すべきは、欠陥そのものは2年前から知られていたという点です。変わったのは「1段階目（発見）」ではなく、「2段階目（武器化）」の難易度です。人間の研究者が2年かけても辿り着けなかった攻撃経路を、AIを活用した解析が数週間で完成させた。しかも複数の組織が独立に、です。

なぜこれが「時代の変化」なのか
ここまでの話を一般化すると、こうなります。

これまで私たちのセキュリティ評価は（暗黙にせよ）「武器化が難しいバグは、実害リスクが低い」という前提に支えられてきました。深刻度の判定、修正の優先順位付け、そして「まあ大丈夫だろう」という楽観の根拠は、多くの場合この前提の上に載っていました。

AIがその谷を埋められるようになった今、この前提は崩れました。

世界中のC/C++製ソフトウェアに蓄積してきた「眠れるバグ」の山が、すべて再評価の対象になる
これから新しく見つかるバグも、発見から武器化までのリードタイムが劇的に短くなる
つまり「AIがメモリバグを武器に変換できる」とは、特定の攻撃手法の話ではありません。世界中のソフトウェアのセキュリティ前提が一段変わったという、もっと大きな話なのです。PHP2Shellはその最初の大規模な実例に過ぎず、次に同じことが起きるのはPHPとは限りません。

これはPHPの問題ではなく、「C/C++製ランタイム」全般の問題と言えます。
次に、言語の話を整理します。

PHPの中身はCである

「PHPの脆弱性」と聞くと、PHPという言語の仕様に欠陥があったように聞こえます。しかし今回問題があったのは、PHPインタプリタ本体、つまりC言語で書かれたソフトウェアのメモリ管理です。そしてこれはPHPに固有の構造ではありません。

言語	実装	メモリ破壊系バグのリスク
PHP	C	ある
Python（CPython）	C	ある
Node.js	C++（V8）	ある
Ruby	C	ある
Go / Rust / Java / C#	メモリセーフな言語	構造的に起きにくい

PythonのCPythonにもバッファオーバーフロー系のCVEは継続的に発見されていますし、Node.jsの心臓部であるV8は、Chromeのセキュリティ更新を見れば分かる通りメモリ破壊系バグの常連です（直近でもChromeのネットワークスタックのメモリ破壊によるRCE、CVSS 9.6が修正されています）。

「PHPからPythonやNodeに乗り換えればこの種のリスクは解決する」というのは、同じ構造の家に引っ越すだけ、というのが実態です。

「モダンな」エコシステムでも、致命的な脆弱性は恒常的に起きている。
さらに、メモリバグという切り口を離れても、「新しい技術を使っていれば安全」という仮説は実績によってすでに否定されています。

Java： 2021年のLog4Shell（CVE-2021-44228）はCVSS 10.0。PHP2Shell（9.2）より深刻度は上で、当時のエンタープライズ標準の、まったく「モダンな」Javaスタックを直撃しました
Node.jsエコシステム： 2026年だけでも、広く使われるテンプレートエンジンのRCE（CVE-2026-45618、公開PoCつき）や、ユーティリティパッケージ経由の任意JavaScript実行（CVE-2026-107700）が報告されています。どちらも「最新の」パッケージの話です
どのエコシステムにも、形の違いはあれ致命的な脆弱性は存在します。自分のスタックが今回の当事者でなかっただけの話を、「うちの選定が正しかった証拠」とは呼べません。

「PHPや古いフレームワークを使ってるから悪い」へ、3つの反論

前置きが長くなりました。本題です。「PHPを使っているのが悪い」「古いフレームワークが悪い」という主張には、事実として3つの誤りがあります。

反論①：「新しいものを使っていれば安全」は実績のある嘘
すでに挙げた通りです。Log4ShellはJavaの、2026年のRCE連発はNode.jsの話で、どちらも「今どきの」技術スタックです。そしてPHP2Shellの欠陥はPHP 5.4の頃から潜伏していた、つまり10年以上前から存在したバグが、いまになって急に武器化されたわけです。バグの「新しさ・古さ」ではなく「武器化可能かどうか」が変わっただけなので、「新しい言語にしておけば避けられた」という主張は成立しません。次はあなたの乗り換え先で起きるかもしれません。

反論②：PHPは放置された言語ではない
「PHPは化石」という印象をお持ちの人には意外かもしれませんが、事実を確認しましょう。

PHP 8.xは現在も活発に開発されており、PHP 8.6がすでにRC（リリース候補）段階にあります
今回の脆弱性でも、情報リークを受けて公式は公開予定を1日前倒しして緊急リリースし、主要Linuxディストリビューションには事前にパッチを配布していました
さらに、サポート対象外のEOLバージョン（7.4 / 8.0 / 8.1）向けにまで、例外的なソースバックポートを用意しています
脆弱性が発見されたこと自体ではなく、発覚後にどう動いたかで保守体制を評価すべきです。その観点でPHPの対応はむしろ迅速で手厚い部類です。

「フレームワークが古い」という批判についても同様です。LaravelもSymfonyも継続的にメジャーバージョンをリリースしている現役のモダンフレームワークですし、PHPはサーバーサイド言語が判明しているWebサイトの約7割で使われ、WordPress単体で全Webサイトの約4割を支えています。「使われているものが悪い」という主張が正しければ、インターネットの大半が悪いことになってしまいます。それは批判ではなく、単に現実を無視した主張です。

反論③：今回の事件で「悪かった」のは言語ではなく運用

ここまでを整理すると、こうなります。

メモリバグのリスクはPHP固有ではなく、C/C++実装のランタイムに共通する。
「モダンな」エコシステムにも、別の形の致命的脆弱性は恒常的に存在する。
PHP自身の保守体制は正常に機能している

では、今回の事件で本当に危険だったのは何か。それはサポート切れ（EOL）バージョンを使い続けていた環境と、パッチを適用する体制が整っていなかった組織です。

被害が最も深刻に想定されるシーンを見返すと、「PHP 8.1以前のEOLバージョンで更新のめどが立たない」「PHPをrootで動かしている改めようのないレガシー構成」といった、言語選定ではなく運用側の問題が並んでいます。逆に、サポート対象のPHP 8.2〜8.5をまじめに追いかけていた人は、パッケージを更新してワーカーを再起動するだけで対応完了でした。

言うまでもなく、EOLバージョンを放置する運用は、PHPをやめて別の言語に乗り換えても持ち越されます。言語を変えて運用が変わらなければ、次のイベントで同じ轍を踏むだけです。

では今後どうしていけばいいのか

「PHPが悪い」という議論からはいったん離れて、本当に効く投資は次の3つだと私は考えています。

サポートされたバージョンを使い続ける体制
当たり前ですがEOLは放置してはいけません。
「アプリが動くからOK」「面倒だからアプデしたくない」という理由でのバージョン固定を恒久措置にしない。
パッチを日単位で適用できる仕組み
今回、対応の速さはそのまま被曝量を決めました。リークから公式パッチまでの間にも、攻撃の準備は進んでいました
パッケージ管理の整備、コンテナイメージの自動再ビルド、ステージング環境での事前検証パイプライン
「四半期に1回まとめて更新」のような運用は、今回のような事件で致命的な遅れになります
攻撃されても被害を小さくする設計
PHPプロセスをrootで動かさない。必要最小権限のユーザーで実行する
DBユーザーの権限最小化、アプリケーションと管理画面・DBのネットワーク分離
ログの保全と監視。今回、
攻撃が成功してもワーカーがクラッシュせず200を返すケースがあると判明したことは、記憶に新しいはずです

メモリセーフ言語への移行について

「ならGoやRust（あるいはJava / C#）に移行すべきでは？」という話は当然出てきます。
米国政府もメモリセーフな言語への移行を促す報告書を公表しており、長期的な流れとしては正しいと思います。
メモリ破壊系バグというカテゴリ自体が、構造的に起きにくい言語で書かれたランタイムに移行していくでしょう。
私もこの流れには賛成です。

ただし、それは「今回の脆弱性への対策」とは別の時間軸の話です。メモリセーフ言語でも、依存ライブラリの脆弱性（Log4Shellはまさにこれ）も、ロジックのバグも、サプライチェーン攻撃も防げません。そして既存システムの移行コストは数年規模です。

現実的な割り切りは、新規開発や大規模リプレイスのタイミングで選定肢に含める程度で、今回の事件を理由に既存資産をパニックで書き換える話ではない、というのが私の考えです。

おわりに

今回の事件で失われたのは「PHPの信用」ではなく、「眠っているバグは無害であろう」という世界の前提です。次に同じことが起きるのはPHPとは限りません。Pythonかもしれないし、Nodeかもしれないし、「PHP時代の負債を捨てて乗り換えた」その言語かもしれません。

そのとき、言語のせいにする組織と、準備をしていた組織の差は、数日のパッチ作業では埋まりません。分かれるのは日々の運用です。