テック技報最新号へ →
セキュリティ

PHP「php2shell」：更新までのつなぎ対策を正しく入れる（upload_progress だけでは足りない）

CVE-2026-109618／109619（通称 php2shell）の根本対策は PHP の更新だけ。すぐ上げられないなら、公式の緩和策を複数組み合わせ、INI は php_admin で管理側から強制し、multipart の遮断やリクエストサイズ制限を前段で足す。

@flatt_security · 2026-10-24
#php#rce#php2shell#mitigation#waf#php-fpm#incident-response

何が起きているか

  • 2026-10-21 22:40 頃（JST）に PHP のセキュリティリリースが出た。2 件とも CVSS v4.0 で 9.2、一般的な構成（mod_php／php-fpm、WordPress／Laravel／Symfony など）で任意コード実行に至る。
    • CVE-2026-109618：OOM（メモリ不足）時の処理中断で、初期化途中のデータを後片付けが正しいものとして扱う。
    • CVE-2026-109619：解放済みのリクエスト用の状態が残り、同じワーカーの次のリクエストが使ってしまう。
  • 公表前から悪用の試行（Amazon のハニーポットで 10/17）があり、PoC も出回っている。国内サーバーへの攻撃も観測され、官公庁や企業がサイトを一時停止した。
  • 10/23 には関連する新しい CVE-2026-115560（session.serialize_handler＋ini_set＋upload progress の組み合わせ）も報告されている。暫定策は同じく session.upload_progress.enabled=0。

まずやること：更新

系列修正版
8.2.x8.2.35
8.3.x8.3.36
8.4.x8.4.27
8.5.x8.5.12
  • 8.1 以前はサポート切れで安全と言えない。ディストリが独自に修正版を出している場合はそれを使い、なければ移行する。米 CISA は「更新できない環境はオフライン化」を求めている。
  • 影響は 5.x〜8.x に広く及ぶ前提で考える（Flatt Security の見立て）。

更新までのつなぎ（全部入れても完全ではない）

公式の告知と GHSA の緩和策をまとめると次のとおり。

ini
session.upload_progress.enabled = 0   ; 109619 の確認済み session 経路だけ
memory_limit = -1                      ; 109618 の主な設定緩和。cgroup／コンテナのメモリ制限とセットで
fatal_error_backtraces = 0             ; PHP 8.5 のみ
post_max_size = 8M                     ; アップロード無し。アップロード有りなら 32M
upload_max_filesize = (post_max_size より小さく)
max_input_nesting_level = (下げる)
  • php-fpm でパフォーマンス低下を許容できるなら pm.max_requests = 1（ワーカー使い回しをやめる）。
  • 攻撃者が到達できる fatal error・実行時間超過、拡張やサーバーの終了処理で出る警告を潰す。
  • リクエストごとに適用される不正・非推奨の INI 設定を消す。error_reporting・display_errors・@ で隠しても意味がない。
  • memory_limit=-1 だけ入れると上限が外れるので、必ずコンテナ／cgroup 側でメモリを絞る。RLIMIT_AS／RLIMIT_DATA は使わない。

session.upload_progress.enabled=0 だけでは足りない理由: 塞げるのは 109619 の upload progress 経路だけで、109618（multipart 解析などでの OOM）は防げない。現在出回っている ASLR 回避型の PoC には効くという検証報告もあるが、それ以外の経路は残る。

設定は php_admin_* で書く

ini_set() や .user.ini に頼るなと公式が言っている。nix 氏の検証では次の結果だった。

  • php-fpm の php_flag[...]／php_value[...]、Apache の php_flag は、アプリ側の .user.ini／.htaccess で上書きされて元に戻る。
  • php_admin_flag／php_admin_value なら上書きされない。post_max_size も同様。
ini
; php-fpm プール設定
php_admin_flag[session.upload_progress.enabled] = off
php_admin_value[post_max_size] = 8M

入れたあとは全ワーカーを再起動し、ini_get() を返すページでリクエスト経由で有効値を確認する（CLI の php -i はプール設定を反映しないことがある）。nginx の fastcgi_param PHP_VALUE／PHP_ADMIN_VALUE や .htaccess で INI を流し込んでいる箇所も洗い出す。

前段で multipart とサイズを止める

  • multipart（ファイルアップロード・フォーム送信）を使わないなら、WAF やリバースプロキシで Content-Type に multipart を含むリクエストを遮断する。109618 の multipart 解析経路と 109619 の upload progress 経路の両方を、PHP に届く前に止められる。
    • AWS WAF なら content-type ヘッダーに multipart を含む ByteMatchStatement を Block。最初は Count で誤遮断がないか見て、期限を決めて Block に切り替える。
    • PHP 8.4 以降は request_parse_body() で PUT でも multipart を解析できるので、メソッドで絞らない。
    • アップロード機能がある Host／パスを例外にすると、そこは露出したまま残る。
  • ボディサイズは nginx の client_max_body_size、Apache の LimitRequestBody で絞る。AWS WAF はボディの先頭しか見られない（ALB は 8KB）ため、サイズ制限には向かない。
  • Cloudflare は無料プランを含め、マネージド WAF で既定の保護を入れたと案内している。ただし WAF は補助で、更新の代わりにはならない。

更新後・並行してやること

  • 攻撃を受けていないかアクセスログを調べる。侵害されていたら、サーバー内データの持ち出し範囲と、サーバーが持つ権限（IAM ロール、サービスアカウント、DB 認証情報）を確認して横展開を疑う。
  • ログが記録・保全されているか（改ざんされにくいか）を見直す。
  • 外部に公開していない管理画面系の PHP も対象に含める。

追記（2026-10-30）：機器の管理画面とカーネルも対象、ハンティングクエリーの扱い

  • アプライアンスの管理画面も PHP2Shell の対象: Dream Research の分析（10/26）では、外部公開された大手ベンダー製ファイアウォールの管理画面で PHP2Shell によりコードを実行し、Linux カーネルの権限昇格 Fragnesia（CVE-2026-46300）で root を奪取。FOFA で見つけた約 1 万 9000 台から 240 台へ絞って攻撃し、24 台と内部のファイアウォール管理サーバー 1 台で root を確認。侵害した機器には再起動後も残るトンネルが置かれ、LDAP サービスアカウントのパスワード復号と AD の全ユーザー・グループ列挙まで進んでいた。
    • ファイアウォールや NAS など「PHP で動く管理画面」を持つ機器も棚卸しし、管理画面をインターネットに出さない（接続元制限・VPN 経由）。ベンダーの修正版を確認する。
    • PHP の修正だけでなく、カーネルの権限昇格（Fragnesia）の修正も当てる。Web 側で RCE を許すと、カーネルの穴で root まで一気に行かれる。
    • 侵害が疑われる機器は、トンネル設定と LDAP などに使うサービスアカウントの認証情報を確認・交換する。
  • Unit 42 の事例記述は撤回: 10/23 に追記された欧州政府機関の事例（AI エージェントによる侵入後活動）は撤回され、初期侵入が PHP2Shell によるものかは確認できないとされた。Cortex XDR 向けの検索クエリーは掲載継続。そのうち「PHP の Web サーバー・ワーカー配下のコマンド実行」を探すクエリーは PHP2Shell 固有ではなく正常な動作でも一致するため、ヒットしたらそのアプリの通常動作かを確認する。
  • CISA は 10/26 に CVE-2026-109618・109619 を KEV へ追加（両 CVE の悪用の証拠に基づくもので、上記政府機関の侵入経路を示すものではない）。修正版は 8.5.12・8.4.27・8.3.36・8.2.35。

出典

X の元の投稿を開く