「PHP騒動」雑感
今週は、さすがにこのことに言及しないわけにはいかないだろう。PHP2Shellである。いやはや騒がしい一週間であった。
僕自身が管理しているサイトやサービスのいくつかも無関係ではなかったし、同業者同士の情報共有やディスカッション、あるいはそれ以外の友人からの問い合わせも相次いだ。
修正パッチの提供が予告されていた十月二十一日の夜、二十三時になる前にパッとメシを食おうと横浜の中華屋に入って五目炒飯と餃子を食べていると、背後のテレビから「PHP」という単語が聞こえてきた。えっ！？と驚いて振り向くと、そこにはまごうことなきPHP2Shellの問題が映し出されていた。
その少し前にSNSで「高市首相がXで対応を呼びかけている」というのを見かけて「いよいよただならぬことになってきたなあ」とは思っていたが、まさか夜のニュース番組でプログラミング言語の脆弱性が話題になる日が来るとは。思わず目が点になってしまった。何年か前にもApache Log4jというソフトウェアでLog4Shellと呼ばれる脆弱性が見つかり、業界内では大きな問題になったことがあったが、ここまで世間一般の耳目を集めるようなことにはならなかったはずだ。
うーむ、もはやインターネットは完全にこの世と一体化してしまったんだなあ。
テレビの中で話す解説者を眺めながら五目炒飯をもぞもぞと噛み締め、至極当然の事実を、僕はこのときようやく観念して受け入れた。この期に及んでまだ僕は心のどこかで、自分の愛するインターネットの世界が、現実世界とは別のところにある場所だと思っていたかったのだ。
ブブッ、と机の上に置いたスマホが小さく震えた。見ると友人から、
「予防的措置としてサービス停止したのだが、メンテナンス画面のバグを見つけてヒイヒイ言っている」
と連絡が入っていた。
二十三時まであと三十分だ。僕は皿にくっついた最後の餃子を掻っ込み、胸につかえるものを感じながら店を後にした。
相次ぐ大手企業の個人情報漏洩事件
PHP2Shell以前から、ここ最近は「インターネットがヤバい」というムードが既に醸成されていた。
かれこれ一ヶ月ほど前から、大手企業から相次いで個人情報が漏洩した（あるいはその可能性がある）という発表が続いていたためだ。これらはPHP2Shellとは直接的には無関係だが、そんなことを知る由もない多くの人たちはこうした報道の延長に「PHP騒動」を見たことだろう。
九月十六日には画像共有サービスのGyazoが情報流出を発表し、十八日にはニチレイが七月に受けたサイバー攻撃によって約五万四千件の個人情報が漏洩したと発表した。そして二十五日にはあのタイムズカーの第一報が出た。タイムズカーの件は、その後の調査で約六〇〇万件規模のアカウント情報に加え、運転免許証などの本人確認書類の画像にも影響が及んだと分かり、多くの注目と批難を集めることとなる。（ただし、画像は暗号化して保存されており、流出したことは直ちに内容が解読されていることを意味しない。）
その後も、セイコーマート、焼肉きんぐ、大和証券、シチズン、旭化成、損保ジャパン、ローソン、第一興商、ブックオフ、日本郵便、バーガーキングなどなど、買い物、飲食、移動、仕事に関わる聞き覚えのある企業が次々と個人情報の漏洩可能性があることを発表する日々が続いた。
参考：個人情報の漏洩・恐れを公表した企業など 随時更新（日本経済新聞）
僕たちが生活のあちこちで預けた情報について、次々に「漏洩しました」という知らせが届く日々。どう考えても異様な毎日を過ごしているのだが、こうも続くと感覚が麻痺してしまい、一つひとつの知らせを自分の身に関わることとして受け止めるのも難しくなる。
自分の個人情報が漏洩したことによって、自分の身に何が起き得るのか。被害の輪郭がよく分からないまま、「インターネットは大丈夫なのか」という不安が市井に広がっていった。そして同時に、その背景にあるものとして「AIの影響」が想像されるようになっていったように思う。
さて、なぜこうした個人情報の漏洩事件が相次いだのだろうか。そこにAIの影響はあるのだろうか。本題（PHP2Shell）に入る前に、この件についても僕が知っている範囲で触れておこう。
まず「漏洩事件が相次いだ」と書いたが、実際に攻撃を受けた時期と、それが公表された時期は分けて考える必要がある。発表された事案の中には、以前に受けた攻撃について調査を進め、被害の範囲が明らかになったところで公表したものもある。
また、共通の委託先や外部サービスが侵害されれば、その利用企業がそれぞれ発表することになる。他社の被害や専門機関の注意喚起を受けて点検を行い、それまで気づいていなかった被害が見つかったケースもあるだろう。同時期に発表が続いたために、あたかも「いま集中して攻撃が行われている」ような印象になってしまっているが、少なくとも公表されている内容からはそのような状況とは言い切れない。
AIについては、実際に攻撃への利用が確認されているが、公表された分析によれば、既知の脆弱性や認証・権限確認の不備など、以前から対策が必要とされてきた弱点を探し、攻撃を試みるために使われていた。
つまり「AIによって、これまで不可能だった高度な攻撃が一斉に始まった」というわけではなく、むしろ、従来からある弱点を探し、標的に合わせて攻撃を試みる作業が「AIによって効率化されている」と見るほうが公表情報に即しているだろう。もちろん、だからといって安心できるわけではないが、脅威の程度や性格は正しく捉えておきたい。
PHP2Shellとは何だったのか
脆弱性の概要
動的なWebサイトでは、サーバーが利用者からの要求を受け取り、必要な情報を取り出したり、入力を処理したりして、その結果をブラウザに返している。PHPとは、そのサーバー側の処理を書くためのプログラミング言語であり、書かれたプログラムを動かすソフトウェア、つまり実行環境の名称でもある。
例えば、「利用者が読みたい記事の年月を指定したら、該当する記事をデータベースから取り出して表示する」というプログラムを書いたとする。このプログラムがPHPで書かれている場合、それを動かすサーバーには、実行環境としてのPHPが必要になる。単にサーバーにファイルが置いてあるだけでは動かない。PHPで記述されたファイルは、サーバー側に読み取って実行するためのPHPというソフトウェアがインストールされている必要がある。
PHP2Shellというのは、この実行環境としてのPHPに見つかった脆弱性の総称だ。ある条件が揃ったとき、ログインしていない外部の人間が、サーバー上で不正にプログラムを実行できてしまうというもので、極めて重大かつ深刻性が高い部類のものである。
具体的な問題は、PHPにおけるメモリの管理やエラーが起きたときの処理にあった。
メモリとは、処理の途中で情報を置いておく作業場所のことだ。通常、使い終えた領域は適切に解放され、別の処理に再利用される。ところが、メモリ不足などで処理が中断された際に、内部の状態が不完全なまま残ったり、すでに使い終えた領域を後の処理が参照したりする問題があった。
これを巧みに利用されると、単にエラーになるだけでなく、不正にプログラムを実行することができてしまうのだという。（ただし、実際の攻撃成立条件は、サーバーの構成や設定、そこで動いているプログラムによって異なる。また、Sansecは情報公開当初、大規模攻撃を強く警戒していたが、現在は「攻撃成立には対象固有の知識や条件が必要で、当初想定したような大量悪用は起きにくい」と評価を修正している。）
ここまでの説明で分かるように、これは個々のサイトのプログラムの問題ではなく、その下で動く共通基盤の問題だ。つまり自分たちの書いたプログラムの内容に関わらず、PHPを使っていれば基本的には対策が必要になる。
十月二十一日の日本時間二十三時頃、修正版のPHPが公開され（PHP 8.2.35、8.3.36、8.4.27、8.5.12）、サイトの管理者は、利用中のPHPを脆弱性が修正されたバージョンへ更新する必要に迫られた。例えばPHP 8.3.35を使っていれば、同じ8.3系統の修正版である8.3.36へ更新する、という作業だ。（必ずしも最新の8.5系統へ移行する必要はない。使っている系統の中のパッチが当てられたバージョンに更新すればよい。）
高市首相がXで「大至急のお願い」をしていた具体的内容がこれである。
魂のアップデート作業
「PHPを更新する」という作業は、スマホのアプリのアップデートのように、単に新しいものをインストールして終わりというわけにはいかない。その上で動いているサイトやサービスが「更新後もこれまで通りに動くこと」をきちんと確かめ、必要に応じてプログラムを修正する必要がある。この検証作業が特に大変なのだ。
画面が表示されることに加え、ログイン、検索、フォームの送信、購入や決済、メールの配信、定期的に動く処理、外部サービスとの連携など、そのサイトに必要な機能の動きを確かめていく必要がある。どこまで確認すべきかは変更内容とシステムによるが、単に「ページが表示されているからOK」とはいかない。ユーザーの権限や入力内容によって結果が変わる処理もあるし、エラーが起きた場合の動きも確認しなければならない。事業に用いられているサイトでは、誤作動が利益に大きく影響するため、その検証はより慎重かつ徹底して行わなわれることとなる。
一方、動作検証の手前のPHPの更新そのものは、比較的簡単に済む場合もある。レンタルサーバーなどでは事業者が更新を担ってくれることもあるし、自分たちで実行環境を管理している場合でも、「同じバージョン系列の修正版への更新」であれば、自動化された仕組みなどを使って対応できることもある。
とりわけしんどいケースは「長く更新していなかったシステムを新しいバージョンへ移す」場合だ。例えば、PHP 5系や7系から8系へ移行するようなメジャーアップデートとなれば、その間に積み重なった仕様の変更を考えなければならない。メジャーバージョンをまたぐ場合、PHPの仕様が大きく変わることがある。以前は使えていた機能が削除されていたり、同じ書き方でも処理の結果が変わったりする。いわゆる「互換性」の問題だ。古いプログラムは、新しい実行環境のもとでこれまで通り動くとは限らない。必要に応じてコードを書き直す必要がある。
また、PHPを利用するケースの一つにWordPressを使ったサイト構築があるが、この場合はそのWordPress環境や、WordPressのテーマ、プラグインなどが新しいPHPに対応しているかどうかが懸念事項となる。必要ならそれらも更新しなければならないし、開発が止まっていて対応版が出ていないプラグインなら、代替となるものを探して置き換えたり、自分たちで修正したりする必要がある。
もちろん、二〇二六年十月時点で、PHP 8.1以前のバージョンはサポートが終了しているのだが、実態として、サポートが切れたバージョンを使い続けているサイトというのは数多く存在する。クライアントから保守管理費が出ない。開発した会社との契約が終わっている。担当者が辞めて、どこを直せば何に影響するか分からない。古い業務システムとつながっていて、自分たちの都合だけでは変更できない。事情はさまざまだが、こうした状況下では「PHPを更新する」という作業は、止まっていたプロジェクトを掘り起こすような仕事になる。
そして、一連の更新作業に必要なリソースを用意するのが難しい場合は「そこまでしてこのシステムを維持するべきか」という判断に迫られる。旅行ゲーム「ワールドクエスト」がサービス終了を宣言したのはまさにこうした判断の結果だろう。
脆弱性発表の背景
さて、このPHP2Shellという問題は、何も十月二十一日に突然見つかったわけではない。PHP財団の説明によれば、今回の脆弱性の一方につながる兆候は、二〇二四年に把握されていた。
ただ、その時点では、遠隔から不正なプログラムを実行する具体的な経路は見つかっていなかった。修正案にも互換性などの難しい問題があり、対応が停滞してしまったという。（財団自身、この遅れには意思決定の仕組みと資源不足による構造的な問題があったことを認めている。）
事の深刻さが明らかになったのは今年の夏だ。監査を行っていた研究者たちから、実際に攻撃が成立するという報告が寄せられ、修正と公開に向けた調整が進められることとなった。この一連の研究や調査には、AIが活用されている。セキュリティ企業CalifはOpenAIのGPT-5.6 Solを使い、WizもGoogleのGeminiなど複数のAIを用いて、欠陥の発見や、実際に攻撃が成立するかどうかという検証を進めたと発表している。
つまり、このケースにおいてAIは、長く残っていた弱点の危険性を明らかにし、修正を確かめるために使われたのである。この点から、PHP2ShellはAIのポジティブな可能性が示された大きな事例ともいえるだろう。
「脆弱性が見つかったのなら、すぐに発表すればよいではないか」と思うかもしれないが、修正する手段がないうちに脆弱性の存在だけを公開すれば、かえって攻撃の手がかりを与えることになってしまう。そこで、必要な関係者にだけ先に情報を共有し、修正版や防御策を十分に準備してから一般公開する「CVD（Coordinated Vulnerability Disclosure、協調的脆弱性開示）という対応が取られることとなった。
CVDに従って水面下で準備が進められ、当初は十月二十二日に公式発表が行われるはずだったのだが、どういうわけか情報が外に漏れてしまった。公式発表を待たずして、ネット上にはPHPの脆弱性の存在を示す情報が出回りはじめたのだ。（AWSが観測記録を調べたところ、十月十七日の時点で、すでにこの脆弱性を悪用して攻撃を試みた痕跡が残っていたという。）
これを受けて事前予告が公開され、修正版と詳細情報の公開も一日前倒しされた。日本時間十月二十一日の早朝、正式な問題の発表と、その日の二十三時にパッチが配布されること、サイトの管理者はその適用を可及的速やかに行うことなどが呼びかけられた。
そこから、各社で慌ただしく対応が始まった。システムの状況を確認し、更新の手順を確かめ、更新後に何を検証するかを決める。それらの影響を整理して経営層に報告する。問題の発表を受け、予防的措置としてサービスを停止したところも少なくなかった（APIなども含めて外部からのアクセスを遮断すれば、修正までの間、攻撃を受けるリスクを抑えることができる）。
細かな事情はそれぞれの企業で異なるが、その日やりとりしていた友人たちはだいたい似たような一日を過ごし、それぞれの現場で準備を進めながら、同じ二十三時を待つこととなった。
余談だが、この日まったく専門外の友人が心配して連絡してきたのだが、そこには「多くのサイトがハッキングされているのではないか」という誤解があった。各サービスが停止している様子を見てそのように思ってしまったようだった。
なるほどー、そういう誤解があってもおかしくないよなあーと頭を抱えてしまった。普段使用するサービスが軒並み停止していたし、サービスによってはメンテナンス画面が表示されていないものもあったので、パニックになってしまった人も少なくなかったようだ。SNSでは「スマホの電源を切るべきか？」という、まるで見当違いの心配をする投稿が話題となっていたらしい。
AIが作り、AIが守れば、もっと安全になるのか
さて、ここからはエンジニアや開発の仕事に携わる友人たちと各所でディスカッションした内容について、備忘録的に書いておこうと思う。もちろん、ここに書いたことをもとにさらに話を深めていきたいと思っているので、友人各位はぜひ声をかけてほしい。
まず、楽観的な見方としてよく耳にしたのは、いま攻撃されているのは人間が作ってきたシステムであり、今後はAIが作り、AIが守るようになっていくので、もっと安全になるのではないか、というものだった。人間が長年見落としていた不備をAIが見つけているのだから、それを修正し、最初から安全に作るためにもAIを使えばよい。いまは、その移行に伴う混乱の時期なのではないか、と。
僕も、そうであってほしいとは思う。既に説明した通り、今回のPHP2Shellにしても、AIが欠陥の危険性を明らかにした事例である。AIによって調査や検証の負担が減り、これまで手が回らなかったところまで確かめられるようになるなら、それは歓迎したい。
しかし、防御する側がAIを使うなら、攻撃する側も使う。双方の能力が上がるのだから、これだけで「全体として安全になる」という結論は導けない。そう言うためには、AIによる防御の改善が、攻撃能力の向上を上回る理由が必要になる。
例えば、防御する側は、自分たちのシステムについて詳しい情報を持っているという利点がある、とか。自分たちのプログラムの中身や設定、日々のアクセス記録などを調べ、どこに問題があるかを確かめることができるというのは、外から手がかりを探す攻撃者に比べれば、調査に使える材料が多い点で優位といえるだろう。こうした立場や条件の違いを冷静に考えていけば、AI同士の攻守における防御側の優位性を唱えることはできるかもしれない。
ただしかし、それでも「AIが守るから安心」とするのは、やはり結論が早いような気がする。
まず「人間の見落としをAIが発見できたこと」と「AI自身が見落としをしないこと」は別の話だろう。既存のプログラムの弱点を探す能力が高いからといって、新しいシステムを安全に設計できることまで証明されたわけではない。「人間が作ったものに欠陥があった」という話が「AIが作れば欠陥がなくなる」という話に接続されるには、論理的な飛躍がある。
そもそも、AIによって作る作業が容易になるなら、作られるものの数も増えるだろう。これは僕も歓迎している変化だが、一つひとつのプログラムに欠陥が生じる確率が下がっても、公開する機能や外部との接続が増えれば、全体として守る範囲は広がる。
以前なら費用がかかるので諦めていた機能を、AIならすぐ作れるから追加する。便利なので外部サービスとも接続する。せっかくだから利用者の情報も保存する。その積み重ねによって、保守管理する対象は増えていく。一件あたりの保守にかかる手間が減っても、持ち続けるものが増えれば、全体としては負担が増えてしまうかもしれない。
（追記：この記事を見たエンジニアの友人から、スピードという点で攻撃者が有利な状況にあるだろう、という見解が送られてきた。AIによって脆弱性発見から攻撃手段の構築までのスピードが速くなっており、また手当たり次第の攻撃も効率化できてしまっているのに対し、防御側はそれに相当するスピードでは対応できていない、という指摘だ。）
こうした状況において、まず間違いなく言えることは、モノを作った後に必要になる「保守」という仕事について、人々がもっとよく理解しなければならない、ということだ。そしてそこに「十分なコストをかける必要がある」と腹をくくらなければならない。
コードは、最初にどれだけきちんと作られたものだとしても、そのプログラムがいつまでも安全に問題なく動くとは限らない。接続している外部サービスの仕様が変わる、使っているプラグインのサポートが終わる、利用者が増えてサーバーの負荷が高まる、当初は想定していなかった使い方をされる、新しい攻撃方法が見つかる、などなど。プログラムを一行も変えていなくても、周囲の環境が変化するので、それに合わせてコードをメンテナンスする必要がある。
Web上にモノを作るプロジェクトを行うときは、そういった保守のための体制や費用を組み込まなければならない。バイブコーディングでどんどんモノを作るにしても（僕はバイブコーディングの普及で制作者が増えることは好ましいと思っている）、それを公開して使い続けるなら、そのための備えをしておく必要がある。
もちろん、保守の仕事にもAIを使えばよいと思う。ただ、「AIが守るから大丈夫でしょう」というのは、具体的な見通しになっていない。実際に保守に対してこの規模の予算を割き、こういった人員を割いて体制を用意するとか、事故後の負担に備えて保険への加入を検討するとか、そういった大枠の話があった上で、AIを使って保守コストを抑えるよう工夫するとか、人力では難しかった防御を実現していくといった個別の議論がある。僕たちは、そういう具体的な話し合いを積み重ねることで、安心を獲得していくべきだ。
僕が楽観論に乗りきれないのは、事態のあれこれを確かめる前に、まず安心するところまで話が進んでしまうという点にある。こうしたカオスな局面では、人は安心させてくれる言説に縋ってしまうものだ。僕も例外ではないが「そうあってほしい」という願いを「そうなるはずだ」という見通しにすり替えないように気をつけたい。AIや技術の進歩への期待は持ちたいが、期待は決して備えになるわけではないからだ。
