PHP2Shellで今起きていること、立場別にできる対策(10月24日時点)

2026年10月21日、PHPの開発元が重大な脆弱性2件(CVE-2026-109618、CVE-2026-109619)を修正した。通称は「PHP2Shell」。深刻度はどちらもCVSS v4.0で9.2で、認証なしで外部からコードを実行される恐れがある。

影響の大きさは、各国の動きに出ている。日本では首相がXで、パッチの適用を準備するよう呼びかけた。すぐに適用できなければサイトの一時停止も有効だ、とも書いている。欧州では、ドイツ・フィンランド・ベルギーが予防措置として政府のサイトやサービスを止めたと報じられた。

このサイトでも影響を確認した。結果は「影響なし」で、理由はPHPがどこにも動いていないからだ(詳しくは後半に書く)。ただ、確認のために調べた範囲だけでも、パッチを当てれば終わる話ではないことが分かった。この記事では、10月24日時点で起きている問題と、立場ごとに打てる対策を整理する。

先に書いておく。私は攻撃の再現も、パッチの適用もしていない。自分のサーバーでPHPを動かしていないからだ。以下の事実は、PHP公式・JPCERT/CC・IPA・CISA・各社の公式発表から取った。日付はすべて出典を参照した10月24日時点のもので、状況はまだ動いている。

何が起きたか

時系列で並べるとこうなる(時刻は出典の表記どおり)。

脆弱性の中身は2つある。CVE-2026-109618は、メモリ不足で処理が途中で止まったときに、初期化しきれていない内部データを正常なものとして扱ってしまう問題だ。CVE-2026-109619は、リクエストの内部状態が解放後も残り、同じワーカーが処理する次のリクエストで使われてしまう問題だ。

対象は、Webリクエストを処理するPHPのほぼすべてになる。PHP公式は、PHP-FPM、Apacheのmod_php、php-cgi、FrankenPHP、LiteSpeedを挙げていて、中でもmod_phpが最も危険だとしている。

重要なのは、脆弱性がPHP本体にあることだ。CloudflareとPHP公式は、サイトのコードやWordPressのプラグインを更新しても直らないと明記している。

このサイトのテーマに引きつけて1つ書いておく。Wizは、発見と攻撃コードの検証にGoogleのGemini 4 ArgonとOpenAIのGPT-5.6 Solを使い、研究者1人がおよそ1週間で作業を終えたと書いている。ただしこれはWiz自身の主張だ。見出しにある「インターネットの70%に影響」という数字も、算出の根拠は記事中に書かれていない。

いま起きている問題

公開より前に攻撃が始まっていた

AWSは、修正版公開の4日前にあたる10月17日に、攻撃の試みをハニーポットで観測している。攻撃者が公開前に情報をどう入手したかは不明だという。公開当日には複数の攻撃コード(PoC)が出回り、手口の異なる試行が続いた。AWSはこれを、複数の攻撃者が関わっている兆候と見ている。

ここから言えるのは、パッチを当てた時点で安心できるわけではない、ということだ。AWSは、調査の起点を公開日ではなく10月17日に置くよう勧めている。JPCERT/CCも、痕跡が見つからないからといって攻撃がなかったとは言えない、としている。

一方で、攻撃が成功したかの評価は割れている。AWSは、成功したかどうかは不明だとしている。CISAはアラートの時点で、実際の悪用の成功は確認していないと書いた。Rapid7によると、公開済みのPoCは特定のOS・PHPバージョン・Webサーバーの組み合わせでしか動かない。ここは煽らず、「試みはAWSなどが観測している、成功の規模は分からない」と受け取るのが正確だと思う。

バージョン番号では修正済みか判断できない

ここは混乱しやすい。たとえばConoHa WINGは、修正をバックポート(旧バージョンへの移植)で入れていて、表示上のバージョンは変わらない。公式発表では、修正適用後のバージョン番号が「8.2.34」「8.5.11」のように、修正版より古い番号のまま並んでいる。同社は、WordPressの「サイトヘルス」に出る番号も従来のままのことがある、と注意している。

「8.2.35未満だから危ない」と番号だけで判断すると、修正済みのサーバーを未修正と誤解する。逆に、番号が新しくても、その環境のパッチが本当に当たったかは提供元の発表で確かめるしかない。

8.1以前は公式の修正版がない

PHP 8.1以前はサポートが終わっていて、修正版は出ていない。PHP公式は、7.4・8.0・8.1向けにソースのバックポートを用意した。ただしJPCERT/CCはこれを「最小限の緩和策」と書いている。PHP公式によると、8.2も2026年12月31日にサポートが終わり、以後はセキュリティ修正が出ない。古いPHPを使い続けている環境では、今回をしのいでも次の脆弱性で同じことが起きる。

暫定策には落とし穴がある

すぐにパッチを当てられない場合の暫定策が、PHP公式とRapid7から出ている。ただ、効かない設定のしかたもある。

• session.upload_progress.enabled=0 は、php.iniなど、ワーカーが起動する前に読まれる場所で設定する。アプリ側の ini_set() や .user.ini では不十分(Rapid7)
• メモリ不足の経路への対策は、管理者側で memory_limit=-1 を強制する方法。ただし RLIMIT_AS や RLIMIT_DATA によるメモリ制限は、かえって脆弱な経路を誘発する恐れがあるので使わない
• PHP 8.5では fatal_error_backtraces=0 も挙げられている
• 設定を変えたら、すべてのワーカーを再起動する。PHP公式の暫定策は、どれも「restart every worker」までが手順になっている

どれも露出を減らすだけで、PHP公式の言葉では、更新だけが完全な対策だ。

修正版を当てても残る関連脆弱性がある

10月23日に、PHP公式は別の脆弱性CVE-2026-115560について情報を出した。Cloudflareによると、これは修正済みの8.5.12でも影響を受ける。修正は次の定期リリースになる予定で、それまでの対策はやはり session.upload_progress.enabled=0 だ。

ただし、条件はかなり限られる。設定ファイルで session.serialize_handler を php_binary か php_serialize にしたうえで、実行時に ini_set() で php に切り替えてから session_start() を呼び、かつアップロード進捗の機能が有効な場合に限られる。21日の暫定策で同じ設定を入れた環境では、追加の作業は要らないとPHP公式は書いている。

WAFは回避が試みられている

Cloudflareは、修正版の公開前から、Freeを含む全プランにWAFの保護ルールを入れた。ただ同社によると、攻撃者はルールをすり抜けようとペイロードを変え続けている。session.upload_progress.name を既定値から変えている環境では、このルールが働かないとも書いている。CloudflareもWAFはパッチの代わりではないとしている。

対応する側のサービスも止まった

国内のレンタルサーバーでは、修正版の公開前から予防的に管理画面などを止めた会社がある。エックスサーバーは10月21日16時から公式サイトや管理画面へのアクセスを止め、22日から順次再開した。さくらインターネットは21日22時30分から会員関連の機能などを止めた。利用者から見ると、自分で設定を変えたくても管理画面が使えない時間があったことになる。

立場別にできる対策

まず、PHPがどこで動いているかを洗い出す

最初の作業はこれになる。自分のサイトだけでなく、問い合わせフォーム、予約システム、社内向けの管理画面、昔作って放置しているテスト環境も含めて洗い出す。CISAもまず棚卸しを挙げていて、PHPは他のソフトに組み込まれていて見えにくいことがあると注意している。

共有レンタルサーバーを使っている場合

共有レンタルサーバーでは、PHPはサーバー会社が管理している。私が公式発表を確認できた3社では、いずれも会社側で修正を適用済みだった。表の2列とも、各社の発表を要約したものだ。

ここに載せていない会社は、自分が使っている会社のお知らせを直接確認してほしい。注意点は3つある。

• バージョン番号だけで判断しない(前述)。会社の発表で「対象バージョンに適用済み」かを見る
• 古いPHP(8.1以前)を選んでいるなら、今回は会社のバックポートで守られていても、サポート中の版へ移る計画を立てる。テーマやプラグインが動かなくなることがあるので、バックアップを取ってから試す
• プラグインの更新は別途必要だが、それで今回の脆弱性が直るわけではない

なお、同じ会社でもVPSは別扱いだ。エックスサーバーもさくらも、VPSのPHPは利用者が管理するものとして、修正を適用していないと明記している。

VPSやクラウドで自分でPHPを管理している場合

サーバー会社は直してくれない。手順は次のとおり。

1. 修正版に更新する。OSのパッケージで入れているなら、ディストリビューションのセキュリティ更新を当てる
2. CVE-2026-115560の対策として、php.iniかFPMのプール設定で session.upload_progress.enabled=0 にし、すべてのワーカーを再起動する(アップロードの進捗表示を使っている機能があれば、止まらないか確認する)
3. すぐに更新できないなら、前述の暫定策を入れる。AWSは、影響を確認したうえでマルチパートのファイルアップロードをブロックする案も挙げている。IPAは、有効な対策がとれない場合は外部からのアクセスの遮断やサービスの一時停止も判断するよう求めている

Cloudflareを経由している場合

Freeプランは、操作しなくても保護ルールが入っている。Pro以上のプランでは、Managed Rulesetがブロックで動いているかの確認が要る。ブロックの実績は、ダッシュボードの Security > Security Analytics > Events で見られる。1つ補足しておく。Cloudflareの記事には書かれていないが、WAFはCloudflareを通る通信を検査する仕組みなので、オリジンのサーバーに直接届く経路が残っていれば、そこは検査されないはずだ。そしてここでも、パッチの代わりにはならない。

すでに攻撃を受けていないか調べる

パッチの前に侵入されていた場合、更新しても侵入の結果は残る。AWSとJPCERT/CCが挙げている調べどころをまとめるとこうなる(2〜4項目めはWizも同じ兆候を挙げている)。

• 10月17日以降のアクセスログで、PHP_SESSION_UPLOAD_PROGRESS を含むファイルアップロードのPOSTがないか(AWS)
• 異常に長い、または形式のおかしい PHPSESSID のCookieを返していないか(JPCERT/CC)
• 不審な multipart/form-data のリクエストの前後に、メモリ上限のエラーやHTTP 500が出ていないか(JPCERT/CC)
• PHPのワーカーが、予期しない異常終了や頻繁な再起動をしていないか(JPCERT/CC)
• 見覚えのないプロセスの実行、外部への通信、ファイルの作成がないか(JPCERT/CC)

Wizは、この攻撃はアプリより下の層で起きるので、アプリのログにはほとんど痕跡が残らないかもしれないと書いている。見るべきはWebサーバーやOSのログになる。侵害が疑われたら、ログを保全してから調査や隔離に進む(JPCERT/CC)。

このサイトで確認したこと

最後に、自分のサイトで何を確認したかを書いておく。このサイトは、自作の静的サイトジェネレータで生成したHTMLを、Cloudflare Pagesで配信している。確認したのは3点だ。

• ビルドはNode.js(TypeScript)で動き、PHPは使っていない
• Cloudflare Pages上でサーバー側の処理を動かす仕組み(Pages Functions)も置いていない
• このサイトのビルドや記事作りに使っているPCにもPHPは入っていない(php コマンドが見つからない)

PHPがどこにも動いていないので、更新するものも、止めるものもなかった。確認にかかったのは、設定ファイルを数個開いて検索するくらいの作業だった。

静的サイトにしておけば安全だ、と言うつもりはない。問い合わせフォームもコメント欄もない、そういう機能を持たない構成を選んだ結果として、今回は守るべき入口がなかっただけだ。同じ確認をするなら、最初の「どこでPHPが動いているか」だけは、どの構成でもやっておく価値がある。

CVE-2026-115560の修正を含むPHPの定期リリースは、まだ出ていない。出たら、この記事の該当部分を更新する。