PHPの緊急脆弱性php2shellとは｜Webサイト・機器の運営者が今すぐやるべき確認と対策

自分のサイトやシステムはPHPで動いているけれど、今回の騒ぎが自分にも関係あるのか判断できない。そんな不安を抱えている方は多いと思います。

私は現役のセキュリティコンサルで、情報処理安全確保支援士（RISS）を取得しています。元SIerとしてインフラとサーバーの現場で脆弱性対応を回してきました。今回は慌てず優先順位をつける目線で、Webサイトや機器の運営者が最低限やるべき確認と対策を整理します。

何が起きたのか（まず結論）

2026年10月、PHP本体に深刻度が緊急の脆弱性が2件見つかりました。通称php2shellと呼ばれています。

• 識別番号はCVE-2026-109618とCVE-2026-109619の2件です。
• 深刻度はCVSS v4.0で9.2（Critical）とされています。
• 認証なしのリモートコード実行（RCE）の恐れがあります。つまりログインなしで、外部からサーバー上でコードを実行されうるということです。

技術的に何が危ないのか（かみ砕いて）

怖いのは、攻撃がアプリのコードが動き出す前の段階で成立する点です。

• CVE-2026-109618は、メモリ不足で処理が途中で止まった際に起きます。初期化が終わっていない内部データを、正常なものとして後の処理に回してしまう不具合です。
• CVE-2026-109619は、直前のリクエストで解放したメモリへの参照が残る不具合です。同じワーカーが処理する次のリクエストが、その古い参照をたどってしまいます（use-after-free、解放後の参照）。
• 攻撃はHTTPリクエストの本文を解析する段階で成立します。だからアップロード画面やお問い合わせフォームの有無は関係ありません。

公式の勧告では、Apache mod_phpが最もリスクが高く、認証なしの攻撃が実証済みとされています。PHP-FPMはCVE-2026-109618の完全な攻撃は未実証ですが、CVE-2026-109619は条件が揃えば通る経路が確認されています。

アプリやCMSの更新では直らない理由

今回の脆弱性はアプリやCMSではなくPHP本体にあります。そのため、PHPを使う全てのWebシステムが対象になりえます。

• アプリやCMS、プラグインを最新にしても、この脆弱性は直りません。
• セキュリティ対策のソフトを入れても、根本的には防げません。
• 対処はPHP本体を修正版へ更新することに尽きます。

修正版はPHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35で、2026年10月21日に公開されました（予告は10月20日UTC）。8.1以前には公式の修正版がなく、7.4 / 8.0 / 8.1向けには最小限の修正ソースのみが提供されています。

ブラウザで使う機器やシステムも対象になりうる

見落としやすいのが、表に見えるサイト以外の機器やシステムです。IT業界では、物理的な機械（サーバー本体やネットワーク機器など）の管理画面（Web UI）にPHPが使われているケースがあると聞きます。

私はインフラとサーバーの現場に長くいましたが、普段ブラウザ経由で運用している機器ほど、中で何が動いているかを意識しないものです。だからこそ、一度棚卸しをしておく価値があります。

• 社内のネットワーク機器やストレージの管理画面。
• 監視ツールやバックアップ装置の設定画面。
• 自前で立てた業務システムや社内ツール。

これらがPHPを使っていないか、つまり今回の対象ではないかを、一つひとつ確認したほうが安全です。表に出ているサイトだけ直して、裏の機器が穴のまま残る事態は避けたいところです。

サイトやシステムの運営者が今すぐ確認すべきこと

まず自分のPHPバージョンを確認し、修正版以上かを見るのが最優先です。

• バージョン確認: サーバーにログインできるなら php -v で確認できます。レンタルサーバーやホスティングを使っているなら、管理画面のPHP設定や、会社からの告知で現在の系統を確認します。
• 修正版以上かを見て、8.1以前なら8.2以降へ切り替えます。

レンタルサーバーの場合。契約している会社の最新の告知で、自分のプランやPHP系統が修正対象かを確認します。管理画面で古いPHP系統を選んだままだと、会社側が修正しても効果が出ない場合があります。

VPSやクラウドの場合。OSのパッケージを更新したうえで、PHP-FPMやApacheのワーカーを全て再起動します。再起動しないと、古いプロセスが動き続けて更新が反映されません。

すぐに更新できない場合は、該当するシステムや機器を一時的に停止する（サービスを止める）ことも現実的な選択肢です。実際、更新の段取りが整うまで思い切って止める運用者も少なくありません。止めてしまえば、その間は攻撃経路そのものがなくなります。

更新のあとは侵害チェックをします。見覚えのないPHPファイル、不明な管理者ユーザー、巨大なmultipartリクエストやワーカーの異常終了が続いていないかを確認します。バックアップは、侵害チェックを終えたあとのものを保管するのが安全です。

「AIが15分で乗っ取り」は本当か（誇張と現実）

結論から言うと、「リリースから15分でAIが攻撃コードを作り乗っ取る」という話は、そのままでは正確ではありません。

• 元はセキュリティ企業Sansecの、リリースから15分以内に攻撃が始まると予想する、という警告でした。
• それが伝言ゲームで、15分で一斉に乗っ取られるという時刻付きの予言に変化していきました。
• 実際には、一斉に乗っ取られる時刻まで断定できる根拠はありません。

ただし、パッチの差分から攻撃コードを作ること自体は、一般論として可能です。そしてAIがその作業を速める現実はあります（私見ですが、今回の脆弱性自体もAIを使った調査で発見されています）。だからこそ、煽られず、でも油断せず、早期に更新するのが正解です。情報は伝聞ではなく、php.netの勧告とGitHubのセキュリティ勧告を直接確認することをおすすめします。

根本対策はEOL版を使わないこと

今回のような事態に強くなる根本対策は、普段からサポート中のPHPを使い、EOL版（サポート終了版）を避けることです。

バージョン	状態（目安）
8.1	サポート終了（EOL）
8.2	セキュリティ修正のみ（2026年12月31日終了予定）
8.3	アクティブサポート〜2025年12月31日、セキュリティ修正〜2027年12月31日
8.4	アクティブサポート〜2026年12月31日
8.5	最新

普段から8.3以降を使い、EOL版を避けておくこと。これが、次に緊急脆弱性が来たときに慌てずに済む一番の備えです。

まとめ

• 今回のphp2shellはPHP本体の緊急脆弱性で、アプリやCMSの更新では直りません。
• まずPHPバージョンを確認し、修正版（8.5.12 / 8.4.27 / 8.3.36 / 8.2.35）以上へ更新します。
• サイトだけでなく、ブラウザで使う機器や社内システムも対象でないか確認します。
• すぐに更新できないなら、一時的に止めるのも現実的な判断です。
• 煽り情報に振り回されず、一次情報を確認して早期に更新するのが現実的です。

あわせて読みたい

• 利用者側の守りも固めたい方へ → 自分の情報は自分で守る 個人情報の守り方
• 現場目線のセキュリティ実務を知りたい方へ → インフラ屋の実戦セキュリティ
• この分野を仕事にしたい方へ → セキュリティコンサルタントになるには