いったい、何が起きてるの？「PHPの脆弱性対応」って言われてもよくわかんないんだけど

※本記事は2026年10月23日17時点の情報です。
状況は今後も更新される可能性があります。

2026年10月、PHPの歴史において最大級と言われる重大脆弱性「PHP2Shell」が発覚し、世界中のWeb担当者を巻き込む騒動となりました。
国内でも19以上の組織が緊急メンテナンスに入るなど、他人事では済まされない事態となっています。

本記事は、WEBディレクターである筆者がAIアシスタントのClaudeと交わした、実際のやり取りをベースにしています。
経緯の整理から、なぜここまで大騒ぎになったのか、そして明日から何をすべきかまで、気になったことをそのままぶつけてみました。

今回のPHPの脆弱性騒ぎの経緯や流れ

　さて、今日はPHPの脆弱性の話しについて質疑応答していこうか。まずは、今回のPHPの脆弱性騒ぎの経緯や流れが知りたい。
今回の脆弱性は「PHP2Shell」という通称で呼ばれています。
Wiz Researchの技術解説によると、CVE識別子ではCVE-2026-109618およびCVE-2026-109619として知られ、特定の条件下で認証を受けていない攻撃者による遠隔コード実行(RCE)を可能にするという、Webサーバーにとって最悪クラスの脆弱性です。両方ともCVSS v4.0で9.2という非常に高い深刻度評価がつきました。

最大のポイントは、脆弱性がPHPエンジン自体にあるという点です。
そのため、Sansecの分析によれば、Magento、Shopware、WooCommerce、WordPress、Drupal、Joomlaなど、自社コードがどれだけ綺麗に書かれていても影響を受けてしまいます。

タイムラインで見る発覚までの流れ

• 2024年:PHP Foundationが主導した外部セキュリティ監査の過程で、原因となる問題が発見される
• 2026年8月1日〜24日:複数の研究チームが独立してRCE経路を発見し、PHP側への報告が始まる(協調的開示がスタート)
• 10月17日:Amazonのハニーポットが、公式開示より4日も前に攻撃試行を記録
• 10月20日:本来秘匿されるべき情報がHacker News経由でオンラインに漏洩
• 10月21日 14:00 UTC:PHPが修正版(8.5.12、8.4.27、8.3.36、8.2.35)を緊急公開

2つの脆弱性の中身も整理しておきます。
Datadog Security Labsの解説によれば、CVE-2026-109618は、メモリ不足(OOM)処理中に内部データが未初期化のまま処理が中断され、後続のクリーンアップ処理がその不正なデータを正常なものとして扱ってしまう不具合です。CVE-2026-109619は、リクエスト固有の内部状態がメモリ解放後も残存し、同じワーカーが次のリクエストを処理する際にその古い状態を使ってしまう「use-after-free」系の不具合です。どちらも、最終的にはサーバー上で任意のコードを実行されてしまう可能性があります。

パッチ公開前の「漏洩」、本当は2箇所で起きていた

　誰かがX上にパッチ公開前に公開した、という話しを聞いたが本当なの?
結論から言うと、「Xが発端」というのは正確ではありません。
実際の発端は「Hacker News」というエンジニア向けフォーラムでした。Infosecurity Magazineの報道によると、本来は公開予定日の2日前まで秘密が保たれていましたが、2026年10月20日、あるユーザーの投稿によって本来伏せられているはずだったCVE識別子が明らかになってしまいました。しかもこの投稿には、誤ったCVSSスコア(10.0。実際は9.2)や誤った公表予定日など、不正確な情報も含まれていました。つまり起点はHacker Newsの投稿で、そこからソーシャルメディアにも話が広がった、というのが正確な流れです。

さらに話をややこしくしたのが、セキュリティ企業C社による独自判断です。
Unite.AIの報道によれば、協調公開予定時刻の6時間以上前に、同社が修正を含むビルド済みイメージを一方的に公開してしまいました。つまり今回の騒動は、「匿名のフォーラム投稿による漏洩」と「セキュリティ企業による独自判断でのフライング公開」という、2つの異なる出来事が重なって発生したものだったのです。

「15分」が勝負、という話の正体

　なるほど。2箇所で起きていたのか。Xだと誰かが承認欲求のために先行で公開してしまった、と言っていたけど。その結果、先に対策がわかってしまい?「15分」が勝負的なことも言われていたけど、ここの説明をお願い
これは漏洩のタイミングの話ではなく、正式パッチが公開された後の話です。
オランダのセキュリティ企業Sansecの警告によれば、パッチが公開されてから15分以内に大規模な攻撃が始まる可能性があるとされていました。なぜこんなに短いのか。背景にあるのが「パッチ差分解析(パッチディフィング)」と呼ばれる手法です。パッチが公開されると、攻撃者は修正前後のソースコードを比較するだけで、どこがどう変わったかが分かり、そこから脆弱性の正体を逆算できてしまいます。
ITdailyの記事では、AIの後押しもあり、CVE開示から実際の悪用開始までの時間は、数週間から数日、そして今や数時間というレベルにまで短縮されていると指摘されています。つまり「15分」は、漏洩で前倒しになったパッチが公開された瞬間から、この差分解析によって攻撃が可能になるまでの、推定猶予時間を指していたわけです。

続報:投稿者本人が謝罪していた

当初、X上では「漏洩は承認欲求による犯行では」という憶測も飛び交っていましたが、10月23日になって本人による謝罪がGIGAZINEに掲載されています。
GIGAZINEの報道によれば、Hacker Newsに最初に投稿したユーザー本人が改めて同フォーラムに登場し、「情報公開のスケジュールに影響を与え、作業負荷を増加させたことを承知している。本当に申し訳ない」と謝罪しました。本人の説明では、投稿時点でこの脆弱性に情報公開禁止期間(エンバーゴ)が設定されていることを知らず、情報提供者からも「エンバーゴはない」と聞いていたとのことです。フリーランスのコンサルタントで、今回の騒動に関係するどの団体とも提携関係はないとも説明しています。「愉快犯」「売名目的」といった見方が一部で囁かれていましたが、本人が説明している動機は、悪意ではなく単純な情報不足による過失だった、ということになります。

なぜここまで一気に大騒ぎになったのか

　15分というのはそれだったのか。各社一斉にメンテナンス入ったもんね。今回、ここまで一気に大騒ぎになった理由としては幾つかの要素が揃ってしまったからだとは思うけど、どういった要素が重なって、ここまで大きな事態になったのか?
単体なら「よくある脆弱性」でも、重なったことで最悪のシナリオになった要素がいくつもありました。

①脆弱性そのものの性質
リスクが最も高いmod_php構成では、未認証のリクエストだけでアプリケーション側のコードが実行される前に攻撃が成立することが実証されています。どれだけアプリ側のセキュリティを固めていても意味がない、という点が通常の脆弱性と一線を画していました。

②影響範囲の広さ
Palo Alto Networksの調査では、インターネットに露出した該当インスタンスが2,260万件以上確認されています。「特定のプラグインが悪い」のではなく「土台そのもの」が悪いという構造が、被害範囲を一気に広げました。

③開示プロセスの二重崩壊
Hacker Newsでの事前漏洩と、Chainguardによるフライング公開。「誰が、いつ、何を知っているか」が非常に混乱した状態のまま、パッチ公開を迎えることになりました。

④すでに先行していた攻撃
Amazonの脅威インテリジェンス部門の報告では、正式開示の4日も前となる10月17日の時点で、すでに悪用試行を観測していたとされています。つまり、一部の攻撃者はすでに独自に脆弱性を把握し、動き出していた可能性が高いのです。

⑤「老舗のバグ」×「AIによる超高速化」
OpenAI社長グレッグ・ブロックマン氏の発言によれば、脆弱性の経路はPHP 5.4.0、2012年リリースの時点まで遡ります。14年近く誰にも気づかれずに潜んでいたバグが、AIによる悪用の超高速化という時代背景と重なったことで、一気に危険度が跳ね上がりました。

AIは諸刃の剣、そしてそもそもPHPとは何か

　なるほど。AIの台頭で一気に便利にはなったが、セキュリティリスクも高まったってことだね。ARTEXも然り。そもそも、PHPとはなんだろうか?
テレビでは「鍵」という紹介をされていたが、少し違う認識。サーバーサイドプログラムであり、jsのようにブラウザサイドで動く言語ではなく、サーバーサイドで動く言語であるがゆえに早くて便利だが、その分、危険性?注意しないと行けない部分も多い?といった感覚だけど

ARTEXの件、ちょうど同じ時期に話題になっていました。
中国で開発された自律型AIペネトレーションツール「ARTEX」が、日本企業への不正アクセスに使われていたことが確認されています。PHP2Shellが「AIが脆弱性を見つけて守る側を助けた」事例だとすれば、ARTEXは「AIが脆弱性を見つけて攻める側に使われた」事例で、まさに同じコインの表裏です。

さて、PHPについて。
結論から言うと、「鍵」という説明よりご自身の理解の方がずっと正確です。
PHPは「Hypertext Preprocessor」の略で、主にWebページを動的に生成するために使われる、サーバーサイドで動くスクリプト言語です。

ブラウザとサーバーの間で何が起きているか
ここがJavaScriptとの一番の違いです。
ユーザーがブラウザでアクセスすると、サーバー側でPHPのインタプリタがリクエストを解釈し、データベースにアクセスしたり計算したりしてHTMLを組み立てます。組み立て終わったHTML(完成品)だけがブラウザに返され、ブラウザはそれを表示するだけです。PHPのコード自体は一切ブラウザに届かず、ブラウザ側で実行されることもありません。

一方JavaScriptは、基本的にブラウザ側でダウンロードされて実行されます。「サーバーサイドだから早い」というより、PHPとJSはそもそも担当する仕事が違う、というのが正確な表現です。PHPが普及した理由は速度うんぬんより、HTMLに直接埋め込んで書けて学習コストが低いこと、ほぼ全てのレンタルサーバーで標準的に使えること、WordPressをはじめ巨大なエコシステムがあることが大きいです。

なぜ「危険度」が一段階違うのか
JavaScriptの脆弱性(XSSなど)は、基本的にブラウザという箱(サンドボックス)の中で悪さをされる話で、被害はそのユーザーのブラウザ・セッションに留まりやすいものです。
対してPHPの脆弱性は、サーバーそのものの中で悪さをされる話です。PHPはサーバー上でファイルを読み書きしたり、データベースに繋がったり、他のプログラムを呼び出したりする権限を持っているため、ここが突破されるとサーバー全体の制御を奪われかねません。

「鍵」という表現について
テレビの「鍵」という説明は、おそらく脆弱性(鍵穴・抜け道)のイメージを、PHPという言語そのものの説明と混同して単純化してしまったものと考えられます。
PHPは単なる一つの鍵穴というより、サーバーという建物を管理している中心人物(管理人)に近い存在です。そこが崩れると被害が建物全体に及ぶ、というスケール感の違いがポイントです。

家なら土地ごと乗っ取られる、ではなぜ一斉に長期メンテナンスになるのか

　XSS(クロスサイトスクリプティング)だね。jsの脆弱性はそのブラウザやそのPC(そこからサーバー繋いだり、汚染されたファイルをアップしたら同じことだけど)の範囲だけど、PHPの場合は、仮に家なら土地ごと乗っ取られるってことだね。では、このPHPのバージョンアップをおこなうために、なんでこんなに一斉にメンテナンスモードになって長期間、サービスが使えない状態になっているんだろう?一般のユーザーさんからすると同じPHPでバージョンの数字も近い数字なのにこんなに時間かかるものなの？って感覚あるよね

まさにその通りの例えです。
JSの脆弱性が「ブラウザというその場だけ」の被害に留まりやすいのに対し、PHPの脆弱性は「土地ごと乗っ取られる」規模の被害につながりうる、というのが今回の脆弱性の恐ろしさでした。

バージョン番号の「近さ」と「作業の軽さ」は別物です。
末尾の番号(パッチバージョン)は「後方互換性を壊さない小さな修正」を意味するルールです。理屈上は数字が1つ増えるだけですが、実際の本番環境では、サーバーのバイナリを差し替え、関連プロセスを再起動し、キャッシュを作り直す、という「反映作業そのもの」に時間がかかります。負荷分散された何十台・何百台というサーバーを順番に安全に反映していく台数の多さが、そのまま作業時間に直結します。

今回特に長引いた理由は、コードを直すだけでは終わらない特殊事情にあります。
CVE-2026-109619は「古いメモリ上のデータが、次のリクエスト処理に紛れ込んでしまう」という性質のバグでした。パッチを当てても、すでに稼働中のプロセスのメモリの中に怪しい状態が残ったままの可能性があるため、すべてのプロセスを再起動してメモリの中身を丸ごと入れ替える必要があります。

さらに深刻なのが情報漏えいの可能性です。Wiz Researchは、パスワード、認証トークン、APIキー、証明書などが露出しうることを実演しています。「パッチを当てて再起動すれば終わり」ではなく、すでに攻撃者に情報を覗き見られていないかを確認し、心配なら認証情報をローテーション(作り直し)する、という作業まで発生しうるわけです。

英国のNCSC(国家サイバーセキュリティセンター)は、すぐに修正できないシステムについてはオフラインにすることを検討するよう各組織に呼びかけていました。今回は「動かしたまま直す」のではなく「一旦止めて、確認してから直す」という、より慎重な判断を取った組織が多くありました。

また、PHPプロジェクトはすでにPHP 8.1以前をサポートしておらず、これらのバージョンには公式パッチが提供されません。古いPHPをまだ使っている組織は、小さな一歩ではなく、メジャーバージョンをまたぐ大移行を迫られたケースもありました。

「塩漬けPHP」と、トップ自らの緊急発信

　そうだね。8.1系の場合は8.3系まであげないといけないし。それの対応で追われている企業もいるだろうね。それより古いPHPに関しては今まで放置していたか、プラグインやフレームワークが動かなくなる=修正費用がかかるという理由で手をつけられなかったのだろう。今回の件で、日本企業の「システム保守」や「バージョン管理」、脆弱性への捉え方が変わるといいな。今までは「運良く」改ざんされなかっただけだよ、的なね。今回、高市総理からも対応を求める投稿があったことは大きくエンジニアたちの支援になったみたいだね。(なお、僕は過去に在籍していた会社で改ざん経験ありです)

「運良く改ざんされなかっただけ」は、技術的にも正確な表現

これは比喩ではなく、わりと文字通りの話です。
前述の通り、Palo Alto Networksは2,260万件以上のインターネットに露出したPHPインスタンスを確認しており、これだけの母数があれば、攻撃者が無差別にスキャンした際、自社サイトが「たまたま」後回しにされただけ、というケースは十分にあり得ます。特に今回のようなエンジン自体の脆弱性は、個別サイトの作り込みの良し悪しとは無関係に効いてしまうため、「うちはちゃんと作っているから大丈夫」という自己評価が、実際の安全性と連動しない典型例でした。

なぜ「塩漬けPHP」が生まれやすいのか(構造の話)

これは日本企業特有というより、レガシーシステム全般が抱える構造的な問題だと思います。
動いているものを触りたくない心理:エラーが起きていない=問題ない、という感覚。特に「保守」という言葉自体が、本来は「予防的に手を入れ続けること」を指すはずなのに、現場では「壊れたら直す」という受け身な運用に矮小化されがちです
バージョンアップの費用対効果が説明しにくい:新機能が増えるわけでも、画面が変わるわけでもない。経営層に「このためにいくら払うのか」を説明する際、「セキュリティのため」は一番通りにくい稟議の典型です
フレームワーク・プラグインの依存関係が雪だるま式に膨らむ:PHP本体だけでなく、動いている独自コードやプラグインが古いバージョン前提で書かれていると、PHPを上げただけで芋づる式に動かなくなる。これが「8.1→8.3への移行」のようなメジャーバージョンまたぎで特に顕著になります

今回の件が「潮目」になるとしたら

今回、構造的に効いてくる可能性があるのは、次の2点だと感じています。

・「エンジン自体の脆弱性」という前例ができたこと:
これまでの脆弱性対応は「このプラグインが危ない」「このライブラリを上げる」という局所対応で済むケースが大半でした。今回は「土台そのもの」が対象になったことで、部分最適な保守では防げないという実例が、エンジニアだけでなく経営層にも伝わりやすい形で可視化されました

・首相本人が直接「今夜中に」と発信したこと:
高市早苗首相は2026年10月21日、自身のX(@takaichi_sanae)で「皆様に、今夜に対応して頂きたい大至急のお願いです」と投稿し、多くのウェブサイトで使われているPHPの重大な脆弱性について、直ちに更新するよう国民に向けて直接呼びかけました。
通常、こうした注意喚起はNISCなどの行政機関が担う領域ですが、普段から記者会見よりもXでの発信を重視するスタイルを取っている首相らしく、本人が直接「今夜中に」と緊急性を訴えたことは、現場のエンジニアが「対応は後回しでいい」と社内で言い訳する余地を狭める、強い後押しになったと見られます。

一方で、こうした「大騒ぎ」の後に起きがちなのは、喉元過ぎれば熱さを忘れる現象です。
今回のパッチ適用自体は多くの企業が急いで行ったはずですが、それが「定期的なバージョン管理のプロセスを見直す」という恒久対応にまでつながるかどうかは、正直まだ分かりません。

実際に改ざん・侵害された事例はあったのか

　塩漬けPHP。面白い表現だね。確かに、そのとおりだ。今回のPHPの脆弱性を突かれて改ざんや問題となったWEBサイトはある？具体的な企業名はなくて構わないよ。業種と事象だけ知りたい。
調べた範囲では、「改ざんされた」と明確に確認された事例は、まだ公に詳しく報じられていません。ここは正直にお伝えしつつ、分かっている範囲を整理します。

まず大前提:「攻撃を受けた」と「改ざんされた」は別物
10/21のパッチ公開から2日しか経っていない今の時点(10/23)では、報じられている情報の大半は「攻撃の試み(スキャン・侵入の試行)が観測された」という段階で、「実際にサイトが乗っ取られ、改ざんされた」という確定情報は限定的です。多くのセキュリティ企業が「悪用の兆候を観測した」と報告している一方、実際に侵害が成立したかどうかの全容は、まだ調査中というのが実情です。

業種別に見た「停止」と「確認された攻撃」の違い
① 政府・自治体系(予防的停止が中心)
ベルギーのサイバーセキュリティセンターは、ベルギー国内のサイトへの攻撃は記録していないと説明しており、これは各国政府機関のサイト停止が「確認された被害」ではなく「リスクを理由にした予防措置」だったことを示しています。ドイツのラインラント=プファルツ州政府が運営する複数のウェブサイト(マインツ市公式サイト含む)も、2026年10月20日にオフラインになりました。これも同様に、確認された改ざんというより予防的な措置です。

② ホスティング・CMS系(「保護済み」を強調する動き)
Automattic(WordPress.comの運営元)は、WordPress.com、WordPress VIP、WP Cloud、Pressable上のサイトはすでにPHP2Shellから保護されており、顧客側の対応は不要だと説明しています。これは裏を返せば、「大手ホスティングは先手を打てたが、自前でサーバーを運用している中小規模のサイトほどリスクが残っていた」ということを示唆しています。

③ 実際に悪用が「確認された」とする報告
セキュリティ企業のPatchstackは、複数の実際の悪用インシデントを確認したと発表しています。ただし、この報告ではどの業種・どの規模のサイトが対象だったかという具体的な内訳までは公開されていません。

なぜ「業種別の詳細」がまだ出てこないのか

被害企業側の開示には時間がかかる:フォレンジック調査(侵入経路の特定、影響範囲の確認)には通常数週間〜数カ月かかります
法的な開示義務のタイミング:個人情報漏えいが絡む場合は規制当局への報告義務がありますが、それも即日ではありません
「停止した」≠「侵害された」の混同が報道でも起きやすい:今回のように「念のため止めた」組織と「実際にやられた」組織が、ニュース上では同列に並んでしまいがちです

被害企業側の開示には通常数週間から数カ月かかるため、この種の脆弱性は、パッチ公開から数週間から1カ月後くらいに、ようやく個別の被害事例がポツポツ報じられ始めるのが典型的なパターンです。本稿執筆時点で、どの業種・どの規模の組織が実際に改ざんや情報漏えいの被害を受けたかという具体的な内訳は、まだ明らかになっていません。

放置するとどうなるの？

　なるほど、攻撃された＝乗っ取られた、改ざんされたは別モノだね。一社あったけど、PHPの脆弱性ではなかった、と訂正しているから、今のところ、これが原因で改ざんされた、などは国内はないかな。ただ、昨今の攻撃状況を見ると、おそらく現場では攻撃は始まってるとは思うけどね。今回の脆弱性を放置した場合に起きる事象はどんなことが起きる？
これまでの情報を整理し直すと、放置した場合のリスクは段階を追って悪化していくという構造になっています。

第1段階:メモリの中身が覗き見される
パッチを当てずに放置した場合、最初に起こりうるのは「情報漏えい」です。Wiz Researchは、アプリケーションの種類を問わず、PHPワーカーのメモリの中身を暴露できることを実演しており、そこにはパスワード、認証トークン、APIキー、証明書などが含まれうるとしています。
これは別に「乗っ取られた」わけではなく、サーバーの頭の中(メモリ)を盗み見される段階です。しかし、ここで漏れた認証情報が後の本格侵入に使われる可能性があるため、実は一番見落とされやすい危険な入り口でもあります。

第2段階:任意のコードを実行される(RCE成立)
ここからが本番です。CVE-2026-109618はWebワーカーのアカウント権限でリモートコード実行を獲得するために悪用可能で、CVE-2026-109619もWebワーカーの権限で未認証のまま解放済みメモリの再利用、メモリ漏えい、リモートコード実行を可能にします。
この「Webワーカーの権限」というのがポイントで、サーバーの管理者権限(root)とまではいかなくても、PHPが実行できることは何でもできてしまう状態になります。

第3段階:何に使われるか(攻撃者視点での「成果」)
ここで一度コードが実行できる状態になると、攻撃者が実際にやることは、だいたい以下のパターンに分かれます。

• Webシェルの設置:今後いつでも出入りできる裏口を作る。パッチを当てても、この裏口自体は残ったままになりうるため、「パッチは脆弱性そのものを修正するが、攻撃者がすでに確立してしまったアクセス権までは必ずしも取り除かない」という点が、セキュリティ企業から繰り返し警告されています。
• サイト改ざん:サーバーを乗っ取り、機密データを盗み出し、その上で稼働しているウェブサイトを改ざんすることが、今回の脆弱性で可能だとWiz Researchは実証しています。
• データベースへの侵入:PHPは通常データベースへの接続情報を持っているため、顧客情報・会員情報などが芋づる式に抜かれる
• 横展開(ラテラルムーブメント):そのサーバーを足がかりに、同じネットワーク内の他のサーバーへ侵入を広げる
• サービス妨害(DoS):単純にサーバーを落とす、処理不能にする

第4段階:気づかないまま「踏み台」にされる
実は一番厄介なのがこのパターンです。改ざんのように見た目が変わるわけではないので、気づかれないまま、サーバーが以下のような形で悪用され続けるケースがあります。

• スパムメールの送信元にされる
• 他サイトへの攻撃の踏み台(中継地点)にされる
• 仮想通貨のマイニングに計算資源を使われる
• ボットネットの一部に組み込まれる

これは「改ざんされていないから大丈夫」という誤った安心感につながりやすく、実際には被害が進行している、という状況を生みます。

時間軸で見ると、どのくらいで危険域に入るか
watchTowrはすでにCVE-2026-109618とCVE-2026-109619の両方で、実際の悪用を確認したと報告しています。これまで整理してきた通り、パッチ差分解析によって、公開から15分程度で大規模な攻撃が始まる可能性があると警告されていました。つまり、「まだ様子見でいいか」という猶予は、実質的にほぼなかったというのが今回の特殊性です。

家に例えると、こういうことだ

　改ざん＝乗っ取られたあと、よりも怖い事象があるんだね。住宅に例えると、wi-fiタダ乗りとか、屋根裏に住まわれているとか、盗聴器を仕掛けられた、実は家の名義人が変わっていた、電気や水道を途中から盗まれていた、など、そんな辺りかな。脆弱性＝家の壁に穴が空いている→そこから侵入されて、いろんなことをされてしまう、的な。
この例え、本当によくできています。1つずつ技術的な実態と照らし合わせてみます。

盗聴器の例えは特に的確です。Wiz Researchが実演したメモリ漏えいは、アプリケーションの種類を問わず起こりうるもので、パスワードや認証トークンが対象になります。盗聴器と違うのは、「盗聴器を見つけて撤去した(パッチを当てた)」としても、すでに盗み聞きされた会話の内容(漏れたパスワード)はもう取り返しがつかないという点です。だからこそパッチ適用後の認証情報ローテーションが必要になるわけです。

「名義変更」にも2パターンあります。分かりやすい乗っ取りは、表札(サイトの見た目)が変わる、つまり改ざんです。分かりにくい乗っ取りは、表札はそのまま、実際の権利証(管理者アカウント)だけこっそり書き換えられている状態――外から見ると何も変わっていないのに、裏では別人が家の主になっているケースです。後者の方が圧倒的に厄介で、気づかれないまま踏み台にされるパターンの正体はこちらです。

脆弱性とは、気づかぬうちに空いてしまった壁の穴です。そこから侵入者が入り込んでも、家具が壊されたり窓ガラスが割れたりすれば(改ざん)すぐに気づけます。しかし本当に怖いのは、何も壊されず、盗聴器を仕掛けられ、合鍵を増やされ、電気や水道を静かに使われ続けている状態――つまり「何も起きていないように見えること」自体が、実は一番危険なサインなのです。

費用と対応期間――車検前の見積に近い話

　よく聞かれるんだけど、費用は?どのくらいで対応終わる?これはそのサイトの作り方や規模、PHPのバージョンをどこまでアップするのか、サーバーの仕様、様々な要因要素あって一概に言えないんだよね。
費用・期間を左右する要因は、主に次の5つです。

• バージョンの「距離」:パッチバージョンのみの更新なら軽作業だが、メジャーバージョンをまたぐ場合は言語仕様自体が変わっている箇所が多く、実質的な改修プロジェクトになる
• サイトの「作られ方」:既製CMS+公式プラグインのみなら比較的低リスク。フルスクラッチの独自システムは全コードの精査が必須
• テスト環境の有無:ステージング環境があれば検証してから本番反映できるが、本番環境しかない場合は慎重に進める分、時間がかかる
• サーバー形態:共用サーバーかVPS・専用サーバーかで、対応すべき範囲が変わる
• 外部連携の有無:決済代行や外部API連携がある場合、そちら側の動作確認も必要になる

そうだね。例えるなら車検前の見積に近いのか。定期点検なんかもこまめに、毎月何かしらを点検していればある程度予測(今回は緊急事態すぎて当てはまらないけど。命に関わるリコールが発生した的な感じかな。)出来るかもしれないが、例えば2年に1回の車検で、ある程度の距離を走行して、買ってから年数も経ってたりすると経年劣化もあって、整備士さんも「見てみないとなんとも・・・」って状態になる。また厄介なのが、新しいパーツに交換して終わりってわけじゃないんだよね。新しいパーツにしたら、古い他のパーツがおかしくなったり、クルマ自体から異音がするといったようなことが起きるんだよね。

リコールの例え、今回の立ち位置をかなり正確に捉えています。
普段からこまめに点検(定期的なマイナーアップデート)していれば、ある程度の予測が立てられます。しかし今回はそれが通用しない「命に関わるリコール」のようなケースでした。
年式や走行距離を問わず全車が対象になるのと同じで、PHP2ShellもPHP 5.4.0から最新版まで、ほぼ全バージョンが影響範囲に含まれていました。「うちは新しいバージョンだから大丈夫」が通用しない脆弱性だったのです。

そして、長期間ノーメンテで走行距離(稼働年数・蓄積したカスタマイズ)がかさみ、経年劣化(サポート切れのライブラリ・古い書き方のコード)が進んでいると、整備士も「開けてみないと分からない」としか言えなくなります。

「新しいパーツに交換したら別の場所がおかしくなる」というのも、今回の罠そのものです。
これはソフトウェア業界で「デグレード(デグレ)」や「後方互換性の崩壊」と呼ばれる現象です。PHP8で非推奨(deprecated)になった書き方が、警告止まりだったのがエラーで完全停止に変わったり、あるプラグインをPHP8対応版に上げたら別のプラグインとの組み合わせで動かなくなったり、文字列や配列の扱いなど言語の細かい挙動が変わったことで画面には出ないが裏側の計算結果だけがズレる(気づくのが一番遅れるパターン)、といったことが起こります。車で言うなら、「ブレーキパッドを新品にしたら、今度は古いブレーキオイルとの相性で異音がし出した」みたいな状態に近いです。パーツ単体は正常でも、組み合わせ全体のバランスが崩れるわけです。

まず何をすればいいのか――初動7ステップ

　最後にPHP脆弱性対応にはまず、何をしたらいい?

1. 現状を洗い出す(インベントリ):自社・自社サイトで、どこにPHPが使われているかをまず把握する。本番サイトだけでなく、管理画面や社内ツール、検証用のサブドメインまで洗い出す。
2. 優先順位をつける:インターネットに公開されているシステムを最優先にする。
3. 公式の修正版に更新する:設定変更などの暫定策だけでは不十分な場合が多いため、PHP本体を正式な修正バージョンに更新する。
4. 関連プロセスを再起動し、反映を確認する:ファイルを差し替えただけでは古いプロセスがメモリ上で動き続けていることがある。
5. すでに侵害されていないか調査する:見慣れないファイル、身に覚えのない管理者アカウント、不審なアクセスログがないかをチェックする。
6. 必要に応じて認証情報を作り直す:侵害の形跡がある場合、または情報漏えいの可能性を否定できない場合は、該当する認証情報を再発行する。
7. 今後の保守体制を見直す:定期的なバージョン確認・更新の仕組みを保守契約やルーティン業務に組み込む。

①〜④が今回の緊急対応、⑤⑥が念のための調査、⑦が次に向けた仕組み化、という3つのフェーズです。特に重要なのは④で終わらせないこと。パッチを当てて再起動しただけで安心してしまうと、情報漏えいや裏口設置のリスクを見落としたままになりかねません。そして⑦こそが本質です。今回の対応は、あくまで今回限りの延命措置。次の「車検」が来たときにまた同じように慌てないためには、ここを仕組み化できるかどうかが分かれ目になります。