2026年10月20日、プログラミング言語PHPの本体に、認証を受けていない攻撃者から遠隔コード実行（RCE）を許す2件の脆弱性が公表されました。まとめて PHP2Shell と呼ばれています。CVSS v4.0の深刻度は9.2。公開の翌日には修正版が出て、日本でも多くのサービスが緊急メンテナンスに入りました。
当社も対応しました。結論から書くと、作業のほとんどはコンテナイメージの置き換えで完了しています。ただしこれは「運が良かった」話ではなく、日頃の運用がそのまま効いた例だと考えています。そして同じ週に、セキュリティ製品を持つことと守れることの違いを示す出来事も起きていました。
PHP2Shellとは何だったのか
対象は CVE-2026-109618 と CVE-2026-109619 の2件です。どちらもPHPの内部のメモリ管理とエラー処理に原因があります。
CVE-2026-109618 は、メモリ不足（OOM）が起きたときの後処理の問題です。リクエストの途中でメモリの確保に失敗すると、内部データの初期化が終わらないまま処理が中断されます。その状態のデータが、終了処理で正常なものとして扱われてしまうと、メモリ破損につながります。CVE-2026-109619 は、リクエストをまたいで内部状態が残る問題です。解放済みのメモリへの参照がワーカープロセスに残り、次のリクエストで使われると、Use After Free になります。
厄介なのは影響の広さです。PHPは、サーバー側の言語が判明しているウェブサイトの約69%で使われているとされます。実行環境は PHP-FPM、mod_php、php-cgi が対象で、とくに Apache の mod_php は危険度が高い と評価されました。アプリケーションのコードが動き出す前の段階で、認証を必要とせずに攻撃が成立する手法が実証されています。アプリ側でどんなに作り込んでいても、その手前で破られる、という性質です。影響するバージョンは PHP 5.4 から 8.5 まで。一部の問題は2012年の PHP 5.4 の時点から存在していました。
修正版は 2026年10月21日に公開された PHP 8.2.35、8.3.36、8.4.27、8.5.12 です。PHP 7.4、8.0、8.1 はすでに公式サポートが終了しており、限定的なソースコードの修正パッチのみが提供されました。正式な更新は出ていません。
対応を難しくした3つのこと
1. 公開日が前倒しになった
当初は10月22日に修正版と詳細が公表される予定でした。しかし20日にHacker Newsなどで脆弱性の存在とCVE識別子が広がり、さらにPoC（概念実証）の動画が誤って公開されて拡散します。修正版の公開は21日に前倒しされました。
「22日に向けて段取りを組む」という進め方は、この時点で成立しません。予定を前提にせず、いつ公開されても動ける状態が必要でした。
2. 緩和策は時間を稼ぐだけ
すぐに更新できない場合の緩和策として、メモリ使用量の制限の解除、リクエストサイズの制限、ファイルアップロードの進捗管理機能の無効化が示されました。ただしこれらは、確認されている攻撃経路の一部を塞ぐものです。脆弱性そのものを解消するには、修正版への更新が必要だと明確に説明されています。製品や設定で「とりあえず塞ぐ」には限界があります。
3. 1回の更新で終わらなかった
10月23日には、セッションのアップロード進捗機能に関する別の脆弱性（CVE-2026-115560）が公表されました。21日の修正版では解消されていません。回避策は session.upload_progress.enabled = 0 に設定すること。つまり、最初の対応のあとにもう一度、影響範囲を調べて手を入れる必要がありました。
当社で起きたこと
当社では、ほぼ全てのシステムがコンテナ化されています。今回の対応は、PHPを含むベースイメージの更新から、再ビルド、再デプロイという流れで、大部分はイメージを差し替えるだけで完了しました。
ただし、すべてが自動で終わったわけではありません。軽微な個別アップデートも発生しています。 コンテナの外にある環境や、イメージの更新だけでは済まない箇所については、個別に手を入れる必要がありました。ここを「例外だから」と放置すると、次の脆弱性で同じ作業が繰り返されます。
これは自慢ではなく、条件が揃っていたという話です。次の3つが揃っていなければ、同じようには進みません。
- どのシステムが、どのPHPのバージョンを使っているかを即座に説明できる（台帳がある）
- 大半を同じ手順で差し替えられる（ビルドとデプロイが自動化されている）
- 差し替えたあと、問題があれば元に戻せる（ロールバックできる）
逆に、その例外がゼロになることはありません。コンテナ化していないシステムが1つでも残れば、そこは個別の手作業になります。台帳から漏れた1台が、いちばん危ない。今回のように「今日中に全部」が求められる場面では、その1台のために全体の判断が鈍ります。
セキュリティ製品を入れれば防げるのか
同じ時期に、この問いに向き合う出来事がありました。GMOインターネットグループは2022年1月にイエラエセキュリティを子会社化し、脆弱性診断やSOCといったセキュリティの機能をグループ内に持っています。それでも2026年10月、グループのサービスへの不正アクセスで、対象となり得るサーバーが26,739件、70社以上の証券・FX事業者の口座情報が関係する事態になり、攻撃者から金銭の要求を受けました。社内の技術者からは、事前に改善すべき課題の指摘があったと社長がブログで述べた、と報じられています。
外部から詳細は分かりませんし、これは特定の企業を評価する話ではありません。ただ、セキュリティの会社をグループに持っていることと、自社が守れていることは別だ、という構造はここに出ています。製品や組織は、運用が追いついていなければ効きません。
WAFのような製品は、更新までの時間を稼ぐ道具です。今回も各社が保護の適用を急ぎましたが、根本の解決はバージョンの更新でした。稼いだ時間でパッチを当てる。当てられなければ、時間を稼いでも意味がありません。
対策の本体は運用
本来のセキュリティ対策は、次の2つに集約されます。
- 守りやすいシステムを作る — 攻撃面を減らす、古い実行環境を残さない、権限を絞る、変更を小さく出す
- 脆弱性が出たときに速やかにパッチを当てられる — 台帳、影響調査、検証、適用、記録
そしてパッチは、アプリケーションだけでもインフラだけでも足りません。アプリの依存ライブラリの更新と、OS・ミドルウェア・ベースイメージの更新の両方が、同じ運用サイクルに載っている必要があります。片方が止まれば、そこが穴になります。
今回のPHP2Shellで差がついたのは、おそらくここです。何を導入しているかではなく、どれだけ早く、漏れなく、戻せる形で当てられるか。それが試された出来事でした。
セキュリティ対策とは、製品を導入することではなく、変化に追随できる運用を回し続けること。
RHEMS Japanが支援できること
当社は、この運用サイクルを作るところから支援しています。棚卸しで対象を洗い出し、影響範囲を調べ、検証してから当て、記録を残す。この一連を、属人的な作業ではなく仕組みとして回す形にします。
コンテナ基盤の運用、パッチ適用の自動化、ロールバックできる形でのリリース、そして「当てられる状態」を保つための監視と台帳の整備。製品の選定より先に、その製品が効く前提を整えるのが私たちの役割です。
「何を入れれば安全か」ではなく「どう運用すれば追随できるか」。そこを一緒に設計したい方は、お問い合わせください。
参考
- IPA「PHPの脆弱性対策について（CVE-2026-109618、CVE-2026-109619：PHP2shell）」
- PHP公式アナウンス（2026年10月20日・21日）／The PHP Foundation ブログ
- Wiz「PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet」
- Amazon Threat Intelligence「PHP2Shell exploitation prior to public disclosure in MadPot」
- 各社報道（GMOインターネットグループの不正アクセスに関する2026年10月の報道）
本記事は2026年10月28日時点で公開されている情報に基づいています。脆弱性の評価や対応方針は、利用中の環境によって異なります。実際の対応は、ベンダーの一次情報と自社の構成を確認したうえで判断してください。