2026年10月に公開されたPHPコアの致命的RCE「php2shell」(CVE-2026-109618/109619)。公開前リークという異例の展開の中、25サイトを収容する本番サーバーで実際に行った緩和・検証・パッチ適用の全記録と、現場で効いた5つの判断を公開する。
3行まとめ
- 2026年10月21日23時（JST）、PHPコアの致命的RCE 2件（通称php2shell）の修正版が公開。CVE-2026-109618 / CVE-2026-109619、公式評価CVSS 9.2。修正版は 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35
- 計画公開前に情報がリークし、「リリース15分後に大規模攻撃が始まる」と予測される異例の展開に。PHP 8.1以前のEOL版には公式パッチが出ない
- 弊社は約25サイトを収容する本番サーバーを運用中。公開3時間半前の緩和策適用から、翌朝の全サイトパッチ完了までの実際の対応を時系列で公開する
本記事について
本記事は弊社が実際に行った対応の記録である。脆弱性の技術的詳細はPHP公式アドバイザリを一次情報とし、本記事では「現場で何を・どの順番で・なぜやったか」に焦点を当てる。
php2shellとは何だったのか
10月20日、セキュリティリサーチャーの投稿をきっかけに「PHPコアにCVSS 10.0のRCEがあり、翌日パッチが出る」という情報が計画公開前に拡散した。リークされたexploitツールのバナーには「PHP 5.4以降すべてに有効」とあり、WordPress・Laravel・Drupal・MagentoなどPHPで動くWeb全般が対象になり得るとして騒ぎになった。
公式リリースで確定した内容は次の2件である。
CVE-2026-109618 — OOM処理経由のデータ破損RCE メモリ不足でPHPの処理が中断された際、内部のリクエストデータが一部しか初期化されない状態が生じ、後続処理が無効なデータを有効なものとして扱ってしまう。攻撃者は巨大なリクエストでメモリ不足を意図的に誘発できる。
CVE-2026-109619 — 残留グローバル状態によるRCE リクエストが所有する内部状態が、メモリ解放後もFPMワーカー内に残存することがあり、同じワーカーで処理される次のリクエストが再初期化前にその「古い状態」を使ってしまう。
公式は mod_php（Apacheモジュール）構成を最もリスクが高いと明記している。実証されたexploitは、アプリケーションコードの実行前・未認証の段階で成立するとされる。PHP-FPM化がそのまま被害可能性の低減になった形だ。
対応タイムライン（実録）
現場で効いた5つの判断
1. リリースを待たずに緩和策を入れた
リーク済み＝攻撃側も準備済み、という前提で動いた。当時「非公式・保証なし」とされていた session.upload_progress.enabled = 0 は、結果的に公式推奨の緩和策そのものだった。確度より速度を優先してよい場面はある。
; 99-php2shell-mitigation.ini（全PHP系統のconf.dへ）
session.upload_progress.enabled = 0
session.use_strict_mode = 1
注意点が2つ。この設定は ini_set() や .user.ini では効かない（リクエスト解析前に適用される必要があるため）。そして反映にはreloadではなくワーカーの再起動が必要である。
2. 「23時に作業する」ではなく「届いたら動く」
php.netのリリースと、各ディストリ・パネルのパッケージ配信には必ずラグがある。今回は sury（Debian/Ubuntu系の定番PHPリポジトリ）で約5時間、Plesk版は執筆時点でもまだ配信されていない。時刻ではなくパッケージ到着をトリガーに自動適用する仕組みを作ったことで、深夜3:49の配信に人間が起きずに追従できた。
3. ミラーの503は「自分だけではない」
リリース直後のリポジトリは世界中のサーバーが一斉に殴るため、503が頻発する。手でリトライし続けるのは不毛なので、5分間隔の自動リトライに任せるのが正解だった。
4. ベンダーが遅いなら、動けるルートに切り替える
ホスティングパネル（Plesk等）同梱のPHPは、独自ビルドのため配信がOSリポジトリより遅れがちだ。悪用開始の報告が出ている状況で配信時期未定の待ちは許容できないと判断し、パネル版PHPで動いていた全ドメインを、パッチ済みのOS版PHP（FPM）ハンドラへ暫定切替した。
切替はカナリア（影響の小さいサブドメイン）→メインサイト→残り一括、の順。事前に両ビルドの拡張モジュール差分を洗い出し、不足分（intl / xml / imagick など24個）を先に導入しておいたことで、全サイト無停止で移行できた。
5. 「影響が出たか」はパッチ後に必ず確認する
パッチを当てて終わりではなく、攻撃が「既に」成立していないかの確認までが対応である。今回チェックしたのは次の4点：FPMのクラッシュ痕跡（この脆弱性のexploitはワーカーを不安定にしやすい）、メモリ枯渇エラーの急増（OOM誘発攻撃の痕跡）、巨大POSTリクエストの有無、そして直近で変更されたPHPファイルの精査。疑わしいファイルはデプロイ元のソースとハッシュ比較で白黒をつけた。結果はすべてクリーンだった。
あなたのサーバーでやるべきこと
EOL版PHPの延命は今回で限界が見えた
今回、約88万台のEOLホストが未修正のまま取り残されると試算されている。PHP 7.4や8.0を「動いているから」で残しているサイトは、次の同規模の脆弱性で確実に標的になる。バージョンアップは「いつかやる保守」ではなく「攻撃対象から外れるための作業」である。
セキュリティ対策、後回しにしていませんか？
セキュリティ対策
脆弱性診断からSSL設定・サーバー強化まで対応します
※ 通常1営業日以内にご返信します
まとめ
php2shellは「リーク→緊急リリース→即悪用」という、防御側に時間が与えられない型の事件だった。それでも今回、被害ゼロで完走できた要因を挙げるなら——日頃からFPM化・バージョン統一を進めていたこと（攻撃面の縮小）、リリース前に緩和策を先行させたこと（時間稼ぎ）、配信ラグを自動化で吸収したこと（人間の睡眠時間と無関係に追従）の3つに尽きる。
セキュリティ対応の勝負は、脆弱性が公開されたその日ではなく、平時の構成で半分決まっている。
参考リンク
