Webサイトの安全性を考える / 実務編

PHP2Shellの影響と対策
企業サイト担当者向け確認チェックリスト

「更新しました」で終わらせず、本番で修正が有効かを確かめる。公式情報と実務上の確認項目を分けて、対応の順序を整理します。

制作・運営:株式会社MiToA
担当者同士でシステムの更新状況と確認項目を照合するイメージ
保守担当者と対応状況を確認するイメージ(AI生成)
優先するのは、本番PHPの修正確認です。

ローカル環境やCMSだけの更新では足りません。提供元の修正済みパッケージを本番へ反映し、追加注意への該当有無も確認してください。この記事は2026年10月26日時点の整理で、2026年11月2日にPHPを組み込んだ製品の確認(4章)を追記しました。

1. どの環境が対象になるのか

PHP公式は、Webリクエストを処理するPHP環境に更新を強く推奨しています。対象にはPHP-FPM、Apacheのmod_php、php-cgi、FrankenPHP、LiteSpeedなどが含まれます。攻撃の成立条件は構成により異なり、すべてのサイトで同じ手順が成立するという意味ではありません。

対象とリスクの説明:PHP公式・10月21日告知。

専門用語を整理:OOMと解放済みメモリ

OOM(Out of Memory)はメモリ不足です。処理途中で異常終了したとき、内部データの初期化や後片付けが適切に完了しないと、不正な状態が残ることがあります。解放したメモリへの参照を後で使う問題は、Use-after-freeと呼ばれます。

今回の2件の管理番号と原因
識別番号 原因の概要
CVE-2026-109618 メモリ不足による中断で、未完成の内部データを後処理が有効なものとして扱う。公式アドバイザリ
CVE-2026-109619 リクエストの内部状態が解放後も残り、同じワーカーが処理する後続リクエストで使われる。公式アドバイザリ

ワーカーとは、サーバーでリクエスト処理を担当するプロセスです。調査者は、PHPの実行方式や処理タイミングによって攻撃経路が変わることを報告しています。単に「PHP-FPMだから問題ない」とは判断できません。

実行方式ごとの技術的な違い:Calif Researchの報告。本記事では攻撃コードや再現手順は掲載しません。

2. 修正版は「系列ごと」に確認する

10月21日公開・上記2件に対する修正版
利用している系列 修正版
PHP 8.2 8.2.35
PHP 8.3 8.3.36
PHP 8.4 8.4.27
PHP 8.5 8.5.12

この表は2026年10月21日の修正版であり、今後も常に最新であることを示すものではありません。OSやホスティング提供元が既存バージョンへ修正を取り込む「バックポート」もあるため、提供元のセキュリティ告知とパッケージ情報で判断します。

PHP 8.1以前はPHPプロジェクトの通常サポート対象外です。サポート中の系列へ移行するか、利用しているOS・長期サポート提供元に修正の有無を確認してください。

バージョン・バックポート・旧系列の扱い:PHP公式告知。

3. 10月23日の追加注意を見落とさない

PHP公式は、セッションのアップロード進捗機能に関連するCVE-2026-115560について追加の注意を出しています。これは、21日の修正済みリリースでも特定条件で問題になる別の経路です。

条件は、session.serialize_handlerを設定でphp_binaryまたはphp_serializeにし、アプリ実行中にini_set()でphpへ変更してからsession_start()を呼び、さらにアップロード進捗機能が有効な場合です。

確認・設定変更は保守担当者が行ってください。
公式は次の通常修正版までsession.upload_progress.enabled=0を推奨しています。実行中に保存形式を変更しないアプリは、この追加問題について機能を有効のままにできると説明しています。設定変更時は関連機能への影響も確認します。

条件と推奨設定:PHP公式・10月23日の追加注意。修正済みリリースにも関係する点:Cloudflareの追記。

4. 10月29日の更新:PHPを組み込んだ製品も確認する

JPCERT/CCは2026年10月29日に注意喚起を更新し、あるファイアウォール製品の特定バージョンについて、本脆弱性を悪用した侵害の成功を示唆する痕跡が確認されたとの報告を紹介しました。注意喚起の本文では製品名やバージョンは特定されておらず、すべてのファイアウォール製品で侵害が起きたという意味ではありません。

同じ注意喚起は、PHPを使用する製品やLinuxディストリビューションが提供するPHPも影響を受ける可能性があるとして、製品やOSの提供元が公開する情報もあわせて確認するよう呼びかけています。Webサイトのサーバーを更新しただけでは、社内の機器や別の製品まで対応が済んだとは限りません。

  1. 対象を洗い出す。Web環境に加え、利用中のネットワーク機器や業務製品について、提供元から関連する告知が出ていないかを保守担当者に確認します。
  2. 提供元の手順に従う。製品名・バージョン・構成を照合し、機器内部のPHPを自己判断で差し替えず、製品提供元の修正や手順に従います。
  3. 更新と侵害調査を分けて確認する。修正の適用状況と、侵害を受けた可能性の調査状況を別々に確認します。JPCERT/CCは、痕跡が見つからなくても攻撃を受けていないとは断定できないとしています。
架空の例で考える
Webサイトの保守を制作会社へ、ネットワーク機器の保守を別の会社へ依頼している会社では、Web担当の「対応済み」に機器が含まれていないことがあり得ます。依頼先ごとに対象・担当・確認結果を整理すると、確認漏れを見つけやすくなります。(説明用の架空例であり、MiToAの顧客事例ではありません)

侵害が疑われる場合は、ログなどを保全したうえで、保守担当者や専門の窓口へ相談してください。

更新内容と確認の呼びかけ:JPCERT/CC・PHPにおける複数の脆弱性に関する注意喚起(10月29日更新)。OS・LTS提供元のパッケージ確認:PHP公式・10月21日告知。

5. 対応チェックリスト

対策は「確認 → 更新 → 本番で検証」

01使っているか確認本体サイト・管理画面・接続先
02修正を反映更新・再起動・再デプロイ
03本番で確かめる設定・動作・対応記録
ローカルで更新しただけでは完了ではありません。実際にアクセスを受けている環境で確認します。

以下は、公開された対策情報をもとにMiToAが整理した確認手順です。個別環境の診断や侵害調査を代替するものではありません。

  1. 確認対象と担当者を決める

    本体サイト、管理画面、フォーム送信先、サブドメイン、外部PHPバックエンドを一覧化。URL・ホスト・管理会社・確認担当を紐づけます。

  2. 本番の実行環境を確かめる

    PHPの利用有無、バージョン、実行方式、提供元の修正情報を確認。端末で実行するPHPとWebで動くPHPは異なる場合があるため、CLIの表示だけで完了としません。確認用のphpinfoページを一般公開したままにしないでください。

  3. 更新と反映を確認する

    バックアップと復旧手順を確認し、影響度に応じて迅速に更新。コンテナは修正済みイメージで再構築・再配備し、古いワーカーが残らないようにします。問い合わせ・ログイン・アップロード等の動作も確認します。

  4. 追加注意と外部接続先を確認する

    10月23日の条件を照合し、必要な設定を反映します。WAFを通らず直接アクセスできる接続先があれば、そのサーバー側の修正も確認してください。

  5. 対応結果と異常の有無を記録する

    対象、修正済みパッケージ、反映日時、担当者、動作確認結果、未確認範囲を残します。不審なファイル・通信・認証の痕跡があればログを保全し、保守会社や専門担当者に調査を依頼してください。更新だけで侵害の有無は判定できません。

本番への反映・接続先の確認:Vercel公式。公開前からの攻撃試行の観測:AWSの原報告。AWSは、観測した試行が実環境で成功したかは不明としています。

6. 暫定対策とWAFだけでは完了しない

WAFは既知の攻撃パターンを遮断するための補助です。Vercelは保護ルールの自動適用を案内していますが、Vercelを経由しない外部PHPバックエンドへの直接アクセスは対象外です。Cloudflareも保護条件を説明しています。

Vercelの保護範囲・Cloudflareの保護条件。

公式の暫定設定には、攻撃経路を一部抑えるものがありますが、更新を置き換えるものではありません。例えばアップロード進捗の無効化は、リクエスト解析前に適用される設定で行い、ワーカーの再起動が必要です。アプリ内のini_set()だけに頼らないよう注意してください。

設定の適用位置と対策の限界:PHP公式アドバイザリ。

SNSの設定例を、そのまま本番へ貼り付けないでください。
memory_limit=-1などの設定には可用性への影響があります。メモリ制限やリクエスト制限を含む公式の条件全体を読み、保守担当者が判断する必要があります。OOMに関する公式の暫定対策をご確認ください。

修正を「案内した」で終えず、対象に「適用された」まで確かめる考え方は、社員のパソコンのブラウザー更新でも同じです。AIが脆弱性を見つける時代のブラウザー更新もあわせてご覧ください。

7. よくある質問

Q. PHP2Shellの対象になるのは、どのような環境ですか?

PHP公式は、Webリクエストを処理するPHP環境に更新を強く推奨しています。PHP-FPM、Apacheのmod_php、php-cgi、FrankenPHP、LiteSpeedなどが含まれます。また、JPCERT/CCは2026年10月29日の更新で、PHPを使用する製品やLinuxディストリビューションが提供するPHPも影響を受ける可能性があるとして、提供元の情報も確認するよう呼びかけています。

Q. どのバージョンに更新すれば修正済みですか?

2026年10月21日の修正版は、PHP 8.2.35、8.3.36、8.4.27、8.5.12です。OSやホスティング提供元が既存バージョンに修正を取り込む場合もあるため、バージョン番号だけで判断せず、提供元の修正情報を確認してください。修正版でも、10月23日の追加注意(CVE-2026-115560)の条件に当てはまらないかを確認する必要があります。

Q. WAFで防げていれば、PHPを更新しなくてもよいですか?

いいえ。WAFは既知の攻撃パターンを遮断するための補助で、WAFを経由しない外部のPHPバックエンドへの直接アクセスは守れない場合があります。公式の暫定設定も更新を置き換えるものではないため、本番環境に修正済みのPHPを反映し、反映を確認するまでが対応です。

8. 一次情報・SNSの読み方

対策は開発元の告知を基準にし、技術的背景は調査当事者、利用サービスの対応は提供元で確認します。更新日とCVE番号まで照合することが大切です。

  1. PHP公式:修正版と追加注意2026年10月21日・23日。対象・修正・設定の判断基準。
  2. JPCERT/CC:PHPにおける複数の脆弱性に関する注意喚起2026年10月22日公開、10月29日更新。特定製品での侵害を示唆する報告の紹介と、製品・OS提供元の情報確認の呼びかけ。
  3. X:JPCERT/CC公式の更新告知2026年10月29日。注意喚起の更新を知らせる投稿。内容は注意喚起本文で確認してください。
  4. Calif Research:PHP2Shellの技術解説調査当事者による原因・検証・発見経緯。
  5. Wiz Research:影響と調査内容PHP本体の問題と、アプリをまたぐ影響を解説。
  6. PHP Foundation:修正公開の経緯SNSに流れた誤ったCVSSスコアにも言及。重大度は9.2と説明しています。
  7. Vercel公式の対応案内 / Cloudflare公式の対応案内提供サービスによる防御の範囲と限界。
  8. AWS Security:攻撃試行の観測自社の観測データに基づく報告。試行と侵害成功を区別。
  9. X:OpenAI公式の協調対応に関する投稿2026年10月21日。調査・修正に関わった当事者の発信。最新の対策はPHP公式で再確認してください。

Instagram・Threadsも調査対象としましたが、本記事作成時点で開発元・発見者による該当投稿を一次情報として確認できなかったため、掲載していません。SNSの投稿数や拡散数は、正確性の根拠にはしていません。

この記事を書いた人

株式会社MiToA(ミトア)

名古屋大学発ベンチャー認定のAIスタートアップ。中小企業を中心に、業務特化型AIエージェントの開発やAI人材育成・内製化支援を展開。「4週間のスモールスタート(MVP開発)」と現場目線の伴走サポートを強みに、IT専門人材が不在の企業でもリスクを抑えたAI活用を実現します。

専門分野:AIエージェント開発 / 業務効率化 / AI人材育成・内製化研修

代表取締役:井上貴雅

公式サイト:株式会社MiToA 公式HP / お問い合わせ・ご相談はこちら

本記事はPHP開発元・研究者等の公開一次資料を基に、AIによる調査・執筆補助を用いて作成しています。大学による記事の監修・保証を示すものではありません。実際の対応は、最新の公式情報と利用環境に基づき、保守担当者へご確認ください。

情報確認日:2026年10月26日(4章の追記は2026年11月2日)。設定の実施は保守担当者が最新の公式告知を確認して判断してください。訂正のご連絡はお問い合わせ窓口へお願いします。

あわせて読む / 基礎編PHPとは?身近なたとえで理解する →