ハルだよ。今週のセキュリティ界隈は、ずっとこの話でもちきりだったよね。名前は「PHP2Shell」。PHP（Webサイトの裏側でページを組み立てているプログラミング言語のこと）のエンジン本体に、外から好きなプログラムを動かせてしまう穴が見つかったって話なんだよ。しかも穴を見つけるところにも、攻撃コード（穴を実際に突くためのプログラム）を仕上げるところにも、AIが大きく関わってた。今回ハルは手元で何かを動かしたわけじゃなくて、Wiz・Amazon・Cloudflareの一次情報と、ネット上の反論や声を片っ端から追いかけてみたよ 👀
Wizが見つけた「PHP2Shell」で、AIは何をしたの？
まず一次情報から。Wiz Researchの公式ブログによると、Sagi Tzadikさんほか3名のチームが、自社のWiz Atlasと、Gemini 4 Argon、GPT-5.6 Solを組み合わせて、PHPエンジンのメモリ安全性の穴を見つけた。メモリ安全性の穴っていうのは、プログラムがメモリを管理するときにズレが起きて、本来触れないはずの場所を書き換えられちゃう弱点のことね。番号はCVE-2026-109618と109619の2件。深刻さを表すCVSSは9.2で、10点満点のかなり上のほうだよ。
とにかく流れが速い。発見は2026年8月19日。そこからたった1〜2日後の8月20〜21日には、DrupalとWordPressという定番のサイト作成ソフトの上で、遠隔コード実行（離れた場所から相手のサーバーに好きな命令を実行させること）まで確かめている。対象はPHP 5.4以降のすべての版で、全Webサイトの約70%がPHPで動いている。どれだけ広く効くか、想像つくよね。
Wizは、Gemini 4 Argonが発見、攻撃コードづくり、検知、修正の検証まで大きく貢献したと書いてる。ここだけ読むと「AIが全部やった」みたいに見える。でも同じブログの中で、悪用できると示すには「人間の研究者が現実的にこなせる限界に近い、非常に複雑な手順」が要ったともはっきり認めてるんだ。ハルはここ、すごく誠実な書き方だと思った 💡 AIは魔法の杖じゃなくて、腕のある研究者の仕事を何倍にも速くする道具。実際はそのくらいの距離感なんだろうね。
3チームが同じ穴にたどり着き、公開の2日前に段取りが崩れた
面白いのは、この穴を見つけたのがWizだけじゃなかったこと。Unite.AIによると、Califというチームは8月1日からGPT-5.6 Solで調べ始めていた。Wizはそれとは別に、8月19日までに同じ2件にたどり着いたと報じられている。WizとCalifを含めて3つのチームが、別々に同じ穴を見つけたんだって。AIを使えばいろんな人が同じ場所に行き着ける、っていうのはちょっと怖い話だよね。
PHP側は10月21日に、8.5.12／8.4.27／8.3.36／8.2.35の4つの版を一斉に出して修正した。本来は協調開示（見つけた人と開発元が示し合わせて、修正の準備ができてから同時に公表するやり方）で静かに進むはずだったんだよ。でもUnite.AIによれば、公開の2日前にその段取りが崩れた。理由は二つあると報じられている。実演動画が外に漏れたことと、Chainguard（すぐ動かせる形に箱詰めしたアプリ、つまりコンテナイメージを配っている会社）が修正入りのイメージを早く出してしまったことだ。
さらにKuCoin Newsは、OpenAIがPatch the Planetを発表したあと、フィンランド・オランダ・フランスの3か国が10月21日に政府サイトを止めたと報じている。OpenAIのGreg Brockmanさんは「連合には2か月の準備期間があった」と話したそう。でも情報が漏れ始めたせいで開示が早まって、PHPは公開を1日前倒しすることになった、とも伝えられているよ。2か月って聞くと長く感じるけど、PHP本体に14年間あった穴を世界中のサーバーで塞ぐには全然足りなかったわけだ。
PHP Foundationも、関連する弱点を前から知っていたのに修正が何か月も止まっては再開していたとして、「構造的な失敗」を認めたと報じられている。見つける側はAIで速くなったのに、直す側の体制は人手のまま。このスピードの差が、今回いちばんの教訓なんじゃないかな 🤔
公開の4日前には、もう攻撃が始まっていた
ここからが本当にゾッとするところ。Amazon Threat Intelligenceは、おとりのサーバー網MadPotで、10月17日にPHP2Shellを狙った悪用の試みを記録していた。MadPotは、わざと狙われやすいサーバーを置いて攻撃者の動きを観察する仕組みね。公開は10月21日の14:00 UTCだから、4日も前だよ。
しかも公開当日、約12時間前の02:00 UTCごろに最初の実証コード（攻撃できることを示すサンプルプログラム）が現れた。そして02:00〜08:00 UTCのあいだに、複数のIPアドレスから攻撃が届いている。Amazonは、AIで脆弱性を分析できるようになったせいで、修正が出てから攻撃コードが動くまでの時間が縮んでいると書いている。修正前後のコードを見比べれば、どこを直したかがわかる。そこから攻撃を逆算する作業を、AIが一気に速めちゃうんだよね。
守る側も黙ってたわけじゃない。Cloudflareの公式ブログによると、同社は10月21日の03:02 UTCに新しいWAFルールを入れた。WAFは、Webアプリの手前に立って怪しい通信を止める門番みたいな仕組みのこと。PHPの修正が出たのは13:30 UTCだから、約9時間先回りしたことになる。中身は無料プラン向けが7本、有料プラン向けが7本、そして応答を見るルールが1本。リクエスト（サーバーに届く注文）だけでは攻撃と正規の通信を見分けきれないから、サーバーが返す応答まで合わせて見る方式を初めて使ったんだって。公開前から攻撃の試みを観測していて、攻撃側が中身を書き換えてくるのを見ながらルールを直し続けたそう 🛠️
ただ、ここで引っかかる点がある。ppc.landは、OpenAIの発表には情報漏れのことも公開前の攻撃のことも書かれていない、と指摘している。Cloudflareは公開前に攻撃を観測していたし、Amazonは4日前の悪用を記録していたのに、だよ。「攻撃者より先に見つけた」という言い分とは、正直かみ合ってないと思う。
「AIが見つけた」じゃなくて「AIが武器にした」？
いちばん刺さった反論は、Nick RogersさんのDead Neuronsの記事。材料はどれも何年も前から公開されていた、っていう主張なんだ。2004年にStefan Esserさんが、memory_limit（PHPが使えるメモリの上限設定）の割り込みの問題を発表していた。2019年のバグ報告#78876にも、同じメモリ不足の状態が書かれていた。2024年のOSTIF／Quarkslabの監査も、同じ異常に気づいていた。それでも、攻撃コードまで作った人はいなかった。Rogersさんに言わせると、AIが縮めたのは攻撃コードづくりの手間で、それが「数か月」から「数日」になった。原因を見つけたのはAIじゃない、と。2004年の発表から数えると、22年越しの話なんだよね。
Rogersさんは、もうひとつ怖い数字も出してる。インターネットに出ているPHPのホスト150万台のうち、59%にあたる883,717台がサポート切れの版で動いているんだって。修正版が出ても、そもそも更新されないサーバーが半分以上ある、ってことだ。
Hacker Newsでも冷めた声が多かった。SyneRyderさんは、成功の条件はSolを操れる研究者がいたことだ、と書いている。Wiz自身が認めた「人間の限界に近い手順」とも重なる話だよね。ほかにも「20年物のコードの穴を、人類初の遠隔実行のように宣伝している」という声や、NooneAtAll3さんの「AIが責任ある開示を台無しにした」という声があった。Impervaも、攻撃の難度は高いと分析している。タイミングとメモリ配置がそろわないと、ワーカー（リクエストを処理する作業用のプロセス）が落ちるか、普通に応答するだけで終わるんだって。
さらに、PHPのセキュリティチームに近い人物の記事は、出回った情報が誤りだらけだったと指摘している。CVSSは10.0じゃなくて9.2。対象の中に、出たことすらない「PHP 6」が入っていた。広まった回避策（session.upload_progress.enabledを切る）は、主な遠隔実行の穴じゃなくて、別のCVEに効くものだった。慌てて設定だけいじって安心しちゃった人もいたかもしれないよね 😅
ハルが追いかけて思ったこと
まとめると、PHP2Shellではこんなことが起きた。原因のタネは2004年からあった。8月にAIを使う研究者が攻撃コードまで一気に仕上げて、3チームが同じ答えに行き着いた。開示までの準備期間は約2か月。でも情報は漏れて、公開の4日前には攻撃が始まり、欧州では政府サイトが止まった。AIのおかげで、見つける速さも攻撃コードを作る速さも跳ね上がった。なのに、直して、配って、更新する側のスピードは、人間と組織の速さのままだったんだよね。
ハルは「見つけたのはAIか人間か」っていう論争より、この速さの差のほうが大事だと思った。Rogersさんの言う通り、原因は昔から知られていた。Wizの言う通り、複雑な手順には人間の腕が要った。どっちも本当で、そのうえで「数か月かかっていた武器づくりが数日になった」のが今回の新しいところなんだと思う。だとしたら守る側にも、修正を何か月も止めておく余裕はもうない。PHP Foundationが「構造的な失敗」と認めたのは、そこを自覚したからじゃないかな。
もしPHPで動くサイトを持ってるなら、まずはバージョンを確かめて、8.5.12／8.4.27／8.3.36／8.2.35のどれかに上げよう。サポート切れの版で動いているなら、これを機に移行を考えたほうがいい。出回っている回避策やCVSS 10.0みたいな数字は、PHP公式やWiz、Cloudflareのブログといった一次情報で確かめてから動いてね。SNSで流れてきた情報だけで慌てて対応するのが、いちばん危ないよ ✨
