PHP2Shellの対策とPHP更新確認：静的サイトで公開面を減らす設計

PHP2Shellへの対策は、Webリクエストを処理するPHPに修正版、または配布元の修正を適用することです。2026年10月21日に公開された上流の修正版は8.2.35、8.3.36、8.4.27、8.5.12で、CLIの表示だけでなく実際のWeb実行環境と稼働プロセスを確認します。静的配信への変更は今後の公開面を減らす設計判断であり、現在動いているPHPの更新を先送りする理由にはなりません。

設計の節は、それらを踏まえた筆者側の検討です。

PHP2Shellとは？CVEと修正版を確認する

PHPのセキュリティ告知とIPAの注意喚起を要約すると、次の2件です。

いずれも条件がそろうと認証前のリモートコード実行につながります。サポート中の系列について、PHP CNAのCVE記録とChangeLogで確認できる範囲は以下です。

PHP 8.1以前は通常の上流サポートが終了しています。ただし今回は7.4、8.0、8.1向けの最小限のソース修正も例外的に提供されました。古い系列を「対象外」と解釈せず、ベンダーの修正とサポート中の系列への移行を確認します。

PHP-FPMやWordPressは影響を受ける？

PHP公式はPHP-FPM、Apacheのmod_php、php-cgi、FrankenPHP、LiteSpeedを含む、Webリクエストを処理するPHPをリスク対象に挙げています。WindowsのCGI構成だけを対象とする話ではありません。

mod_phpではアプリケーションのコードが動く前の攻撃が実証されています。OOMの公式アドバイザリはSAPIごとの経路を区別し、PHP Foundationはアプリケーション経由のPHP-FPMでのコード実行確認も報告しています。「FPMなら安全」とは判断できません。

stale stateのアドバイザリでは、同じワーカーが複数リクエストを扱う際の状態と設定が関係します。すべての構成で同一の攻撃が成立すると決めつけず、実行方式にかかわらず修正を優先します。

サーバーとDockerコンテナでPHPバージョンを確認する

管理権限のある環境で、まずCLIの情報を採取します。

php -vphp --iniphp -r 'echo PHP_VERSION, " ", PHP_SAPI, PHP_EOL;'

これらはCLIの確認です。Webサーバーが使うFPMプールやApacheモジュール、別バージョンの実行ファイルと一致するとは限りません。ドメインごとの割り当てと、配布パッケージの完全なリビジョンも記録します。

phpinfo()はバージョン、SAPI、設定を確認できますが、環境情報も表示します。確認用ページを一般公開せず、アクセス制限した経路や既存の内部診断機能を使い、確認後は不要な診断ページを残さない運用にします。

Dockerでは次のコマンドで稼働コンテナを一覧できます。

docker ps --format '{{.ID}}\t{{.Image}}\t{{.Names}}'

対象IDを選び、docker exec <container-id> php -vで内部のCLIを確認します。<container-id>は実際の値へ置き換えます。DockerfileのFROM、マルチステージの最終イメージ、稼働中コンテナを照合し、タグが同じでも古いイメージが残っていないか調べます。

PHPの更新方法を配布元ごとに選ぶ

配布元のバックポートでは上流番号が変わらないことがあります。ConoHa WINGの終報もその方式を明示しています。上流番号の大小だけで修正判定せず、提供元の証拠を残してください。

更新後はWeb実行環境へ反映し、旧ワーカーが残っていないことを確認します。複数レプリカや別ホスト、管理ツールに内蔵されたPHPも対象です。動作確認では表示だけでなく、認証、アップロード、フォーム、管理機能を通します。

更新までの暫定対策はどこまで有効？

公式資料は、更新だけが完全な対策であるとしています。PHPの告知には、攻撃経路を限定して減らす設定もあります。

• CVE-2026-109619：リクエスト解析より前に有効な設定でsession.upload_progress.enabled=0とし、全ワーカーを再起動します。PHP 8.5ではfatal_error_backtraces=0も対象です。ほかの経路は残ります。

• CVE-2026-109618：管理側でmemory_limit=-1を強制する方法が案内されていますが、下位のメモリ確保失敗は防げず、無制限化に伴う可用性対策が必要です。コンテナ等の外側の制限を設計し、RLIMIT_ASやRLIMIT_DATAで代用しません。

アプリ内のini_set()やFPMの.user.iniを、前者の早期設定の代わりにはできません。設定だけをコピーして完了扱いにせず、担当者が公式の前提条件を読んで更新までの期限を決めます。必要なら、IPAの案内に沿って外部アクセス制限や一時停止を検討します。

なお、PHPは10月23日に補足として、session.serialize_handlerを実行時に切り替えるなど限られた条件で成立する別の問題（CVE-2026-115560）に備え、次回の定例リリースまでsession.upload_progress.enabled=0を維持するよう案内しています（PHP公式の補足）。すでに上の設定を入れている場合は、そのままにします。

pixivは修正版が出るまでどう対応した？

pixivの対応記事によると、影響する可能性のあるサービスを10月21日19時からメンテナンスモードにし、修正版の適用後に再開しました。公式イメージの更新とソースビルドの両経路を用意した点は、更新経路の事前確認の例になります。メンテナンスモードが未実装のエンドポイントがあり、既存の実装を流用して補ったことも報告されています。

ここから得られる設計上の確認点は、止める操作がすべての公開経路へ届くかです。アプリ内のメンテナンス表示はPHP自身を通る場合があるため、それだけでアクセス遮断ができたと判断しません。

ロリポップの公式報告には、脆弱性を狙ったとみられるアクセスの確認もあります。ただし同社は、それによる不正アクセスや情報漏えいを告知時点では確認していないとしています。攻撃の試みと成功した侵害を区別し、個別サイトの状態はログ調査などで判断します。

静的サイトとCMS分離で公開面を減らすには

次は将来の構成を見直すための設計案です。更新頻度の低い記事や会社案内なら、ビルド時に原稿を取得してHTMLを生成し、公開側で静的ファイルを配る構成を検討できます。

genko.meも原稿をAPIで取得する選択肢の一つです。Astro連携でビルド時に取得できますが、PHP連携のようにPHPからREST APIを読む使い方もできます。公式PHPパッケージはなく、cURLなどで取得します。後者は公開PHPを残すため、そのPHPの更新が引き続き必要です。

静的化には、再ビルドと公開の待ち時間、プレビュー、予約公開の反映、検索や会員機能の再設計が伴います。WordPressの既存テーマ・プラグインや編集運用を維持する利点と、変更の工数を比較してください。静的ページでも、同じホスティング基盤の停止の影響までなくなるわけではありません。

検討の入口はWordPressとヘッドレスCMSの比較へ、非技術者への連絡はサイト運営者向けの確認手順へまとめています。

よくある質問

PHP2ShellはPHP-FPMなら影響しませんか？

PHP公式はFPMもリスク対象としています。SAPIやアプリによって経路は違いますが、FPMという理由で更新を省略できません。

php -vで古い番号が出たら脆弱ですか？

配布元がバックポートした可能性があり、番号だけでは断定できません。パッケージの完全なリビジョンと提供元の修正案内を確認し、Web側のPHPも別途照合します。

Dockerイメージをpullすれば対策は完了ですか？

取得だけでは稼働中コンテナは置き換わりません。アプリを再ビルド・再配備し、すべての稼働インスタンスへの反映を確認します。

静的サイトやヘッドレスCMSへ移行すれば安全ですか？

公開ページがPHPを実行しない設計では、その経路の公開PHPを減らせます。管理画面、API、フォーム、ビルド基盤の更新やアクセス制御は残り、CMSを変更するだけで安全性が保証されるものではありません。

出典

• PHP公式セキュリティ告知・10月23日の補足・ChangeLog

• CVE-2026-109618・CVE-2026-109619

• 公式アドバイザリ：OOM corruption・stale global state

• PHP Foundation：リリースと確認された攻撃経路

• IPAの注意喚起・JPCERT/CCの注意喚起

• PHP CLIオプション・phpinfo()

• Docker公式：PHPイメージのソース・docker exec・docker ps

• pixivの対応例・ロリポップの対応報告・ConoHa WINGの終報