PHPの重大脆弱性「PHP2Shell」とは何か医療機関・病院・クリニックのための技術解説と、当社が実際に受けた攻撃事例

何が起きたのか——時系列

PHPは、WordPressをはじめ、世界中の非常に多くのWebサイトの裏側で動いているプログラミング言語（実行環境）です。今回の2件の脆弱性は「PHP2Shell」と呼ばれており、報道・研究者の整理では認証なしの単一のHTTPリクエストでリモートコード実行（RCE）に至り得る重大なものです。以下は、公開情報にもとづく時系列です（時刻は特記なき限り日本時間、報道・各社発表の記載に基づく）。

※悪用状況についての報告は一致していません。ある企業は「大規模な悪用」を報告し、別の企業は「自社の顧客環境では未確認」としています。いずれにせよ、修正版が公開され、攻撃者がパッチを解析できる状態になった以上、未修正環境のリスクは時間とともに上がると考えるのが妥当です。

国は何と言っているか

今回の件が異例なのは、日本の内閣総理大臣自身が、公式Xアカウントで全国民・全事業者に対して「今夜の対応」を呼びかけたことです。以下に、その投稿を引用します。

皆様に、今夜に対応して頂きたい大至急のお願いです。

多くのウェブサイトで使用されているPHPに関し、PHPのセキュリティチームが、重大な２件の脆弱性に関する注意喚起を行っています。

公開しているウェブサイトでPHPを使用しているか確認し、今夜、10月21日午後11時（日本時間）に公開される修正パッチについて、可及的速やかに適用できるよう準備をお願いします。

修正パッチを速やかに適用することが困難な場合は、例えばウェブサイト等を一時的に停止させることも、リスクを低減させるための有効策の一つと考えられます。

国家サイバー統括室のXアカウントでも関係する情報を発信していますので、そちらも参考にして下さい。

この呼びかけのポイントは3つです。

• 「PHPを使っているか確認」：まず自院のサイトがPHPで動いているかを知ること。
• 「修正パッチを可及的速やかに適用」：日本時間21日23時の公開に合わせて準備すること。
• 「一時的に停止させることも有効策」：適用できないなら、止めてよいという明確な方針です。

この投稿を、ITに詳しくない方向けに噛み砕いた解説も広く共有されています。たとえば taichi endoh 氏（X）は次のように整理しています（抜粋）。

「一時的に停止させることも有効策」＝今夜中に更新できないなら、サイトを止めてもいい、ということ。予約フォームなら、明日の朝まで電話受付にする、で足ります。

もう一つ。「PHPの緊急アップデートはこちら」というメールのリンクは踏まないでください。便乗した詐欺です。

この「予約フォームなら電話受付に切り替える」という考え方は、医療機関にそのまま当てはまる現実的な判断です。詳しくは医療機関が今日やるべきことで述べます。

海外でも、英国NCSCは「修正できないシステムはオフラインにすることを推奨」と報じられ、米CISAも修正版への即時更新を強く促しています。Wizの研究者は「PHPで発見された脆弱性の中でも最も深刻なものに数えられる」「フロンティアAIモデルが参入障壁を大きく下げた」と述べ、セキュリティ研究者のKevin Beaumont氏は「PHPの件は大量のインシデントを生む。ここ数年で最大級の脆弱性の一つ」とコメントしています（いずれも報道による引用）。

技術解説——2つの脆弱性の仕組み

ここからは技術的な解説です。悪用の具体的な手順は意図的に記載しません。防御側が仕組みを理解し、正しく判断するために必要な範囲、すなわちPHP公式のアドバイザリ（GHSA-w8hw-w9fx-j79w / GHSA-6wmf-4rv5-p3rp）および各社の公開分析で明らかになっている範囲に絞って説明します。

1. 前提：PHPの「リクエスト処理モデル」

PHPは、Webサーバー（Apache・Nginxなど）から渡されたHTTPリクエストを受け、スクリプトを実行して結果を返します。このとき、実行形態（SAPI：Server API）によって「リクエストをまたいでプロセスを使い回すか」が変わります。

• mod_php：Apacheの内部でPHPが動く。ワーカープロセスが多数のリクエストを順に処理する。
• PHP-FPM / LiteSpeed(LSAPI) / FrankenPHP：常駐ワーカーが多数のリクエストを順に処理する。
• php-cgi / CLI：基本的に1リクエスト（1実行）ごとにプロセスが終わる。

重要なのは、多くの本番環境ではワーカーが使い回されるという点と、リクエストの解析（POSTデータ、マルチパートのファイルアップロード、セッション関連の前処理）がアプリケーションのコードより先に自動的に行われるという点です。今回の2件は、いずれもこの「アプリのコードが動く前の自動処理」と「リクエスト終了時の後片付け」に関わっています。

2. CVE-2026-109618：メモリ枯渇（OOM）時の破損によるRCE

公式の説明：「メモリ不足の処理が、内部のリクエストデータがまだ部分的にしか初期化されていない段階でPHPを中断させる可能性がある。その後のリクエスト後片付けが、不正なデータを正当なものとして扱い、リモートコード実行につながる」（GHSA-w8hw-w9fx-j79w）。

平たく言えば、次のような構造です。

1. PHPは通常、確保できるメモリの上限（memory_limit）に達するとその場でリクエスト処理を打ち切ります。
2. この「打ち切り」が、リクエストの初期化の途中で起きると、内部のデータ構造が半分だけ作られた不整合な状態で残ります。
3. その後の後片付け（クリーンアップ）処理は、不整合なデータを「正常」と信じて走り、壊れたポインタを読み書きしてしまう。ここが悪用の足場になります。

公開分析では、攻撃者がメモリ枯渇を意図的に起こすための入口として、マルチパート（ファイルアップロード形式）リクエストの処理が挙げられています。具体的には次の性質が指摘されています。

• 有効な Content-Length を持たないマルチパートのリクエストは、post_max_size によるサイズ検査をすり抜ける
• マルチパートの各パートに付けられるヘッダー数に実質的な上限がなく、メモリを大量に消費させられる
• 空のファイル欄は max_file_uploads の制限を回避しつつ、メタデータ用の配列を生成する
• 入れ子になったフィールド名が、処理量を増幅させる

修正方針：メモリ枯渇時に「その場で即中断」するのをやめ、安全な地点で制御可能に処理を止める“ソフトリミット”を導入し、2段階目の閾値で初めて強制終了する設計に改められました。つまり問題の本質は「メモリが足りなくなること」ではなく、「足りなくなったときの止まり方が、内部状態を壊す」ことでした。

3. CVE-2026-109619：残存した古い状態（Stale Global State）によるRCE

公式の説明：「リクエストが所有する内部状態が、その裏付けとなるメモリが解放された後も残り得る。同じワーカーが処理する後続のリクエストが、通常の初期化でリセットされる前にその古い状態を使い、RCEにつながり得る」（GHSA-6wmf-4rv5-p3rp）。

これはソフトウェアの世界でUse-After-Free（解放後使用）と呼ばれる種類の問題に相当します。常駐ワーカーはリクエスト間でグローバルな状態を保持しますが、その一部は「そのリクエストが確保したメモリ」を指しています。リクエストが致命的エラーなどで途中終了し、後片付けが完了しないと、メモリは解放されたのにポインタだけが生き残ることがあります。次のリクエストがそれを先に参照してしまうのが問題です。

悪用経路として確認されているのは次の2つです。

4. なぜ「WordPressのセキュリティ対策」では防げないのか

WordPressのセキュリティプラグイン、ログインURLの変更、二要素認証、ファイル改ざん検知——これらはすべてPHPの上で動くアプリケーション層の対策です。今回の脆弱性はその一段下、PHPの実行環境そのものにあり、公開分析では「アプリケーションの入力検証より前の、自動的なリクエスト解析の段階で悪用が成立する」と説明されています。

• Cloudflareは「サイトのコードやプラグインを更新しても、これらの欠陥は直らない。PHPのランタイムにあるからだ」と説明しています。
• PHP2Shellは、別系統のWordPress脆弱性（WP2Shell）とは別物です。「WordPress本体・プラグインを最新にした」だけでは不十分で、PHP自体の更新が別途必要です。
• WordPressだけでなく、Drupal・Joomla・Magento・Shopware・WooCommerceなど、PHPで動くあらゆる仕組みが対象になります。Wizは実験環境でWordPress・Drupal・Joomlaに対する悪用を実証したと報告されています。

影響範囲——SAPI別リスクと対象バージョン

SAPI別のリスク

公開分析（各SAPIの挙動に基づく評価）を整理します。ただし「リスクが低い」＝「安全」ではありません。実証の有無が異なるだけです。

対象バージョンと修正版

• 深刻度：PHP公式の評価はいずれもCVSS v4.0で9.2（Critical）。報道では、NVDがCVSS 3.1で9.8としているとも伝えられています。
• 古いPHPのまま動いているサイトは多い：あるサイト監視データ（2026年10月20日時点）では、サポート中のブランチ（8.2〜8.5）で動くサイトが77.3%、サポート終了版（8.1以下）が22.7%でした。WordPressサイトは新しめの傾向（82%がサポート中）でした。

暫定緩和策と、それが「応急処置」にすぎない理由

PHP公式は、「更新が唯一の安全な選択」「回避策は一部の攻撃経路を塞ぐだけで、環境を安全にするものではない」と明記しています。以下は、今すぐ更新できない環境が、更新までの間だけ露出を減らすための設定です。

CVE-2026-109618（メモリ枯渇）向け

; PHP-FPM のプール設定 または Apache の設定（アプリ側から上書きされないよう admin 指定）
php_admin_value[memory_limit]   = -1      ; ← FPM
; php_admin_value memory_limit -1         ; ← Apache(mod_php)

; リクエストサイズの上限を下げる（アップロードを使わないサイト: 8M、使うサイト: 32M）
post_max_size       = 8M
upload_max_filesize = 4M                  ; post_max_size より小さく

• なぜ memory_limit=-1 なのか：問題の引き金は「PHPが自分で決めた上限に達して中断すること」にあるため、その中断経路を通らせないという発想です。ただしこれは可用性のリスクを増やします。必ず次の対策と併用してください。
• コンテナ／cgroupのメモリ上限を、可用性の境界として設定する（影響を受けたワーカーだけが落ちるようにする）。
• Webサーバー／リバースプロキシ／WAF側で、デコード後のリクエストサイズ・フィールド数・マルチパートのパート数・ヘッダー数・ネストの深さに上限を設ける。Content-Length のないリクエストも対象にする。マルチパートを使わないサイトは、PHPに届く前に遮断する。
• 避けるべき設定：RLIMIT_AS / RLIMIT_DATA によるプロセス制限は、まさに脆弱な経路を通らせるため推奨されません。

CVE-2026-109619（古い状態）向け

; php.ini または FPM プール／サーバー設定（リクエスト解析より前に適用される場所で）
session.upload_progress.enabled = 0

; PHP 8.5 のみ
fatal_error_backtraces = 0

• 設定変更後は、すべてのワーカーを再起動してください。状態は「すでに動いているプロセス」の中にあるため、再起動しないと反映されません。
• 起動前の警告を出す不正・非推奨のINI設定を取り除く。
• 攻撃者が到達できる致命的エラーやタイムアウト（コールバック、アップロード／インポート処理、クリーンアップ処理）を修正する。

パッチ適用の手順（Debian／Ubuntu系の例）

以下は一般的な例です。ディストリビューションや提供元リポジトリによって、修正版パッケージが提供されるまでに時間差があります。必ず、ご利用のOS・ホスティング事業者の案内を確認してください。

# 1) 現在のバージョンを確認（「Webが実際に使っているPHP」を確認すること）
php -v                         # CLI（Webと異なる場合あり）
php-fpm8.4 -v                  # FPM（バージョン番号は環境に合わせる）
apachectl -M | grep -i php     # mod_php を使っているか

# 2) 修正版が配布されているか確認
sudo apt-get update
apt-cache policy php8.4-fpm    # Candidate が 8.4.27 以上か

# 3) 導入済みのPHPパッケージを一括更新（設定ファイルは維持）
sudo apt-get install --only-upgrade -y \
  -o Dpkg::Options::="--force-confold" \
  $(dpkg -l 'php8.4*' | awk '/^ii/ {print $2}')

# 4) 常駐プロセスを再起動して反映
sudo systemctl restart php8.4-fpm      # または apache2 など
# キューワーカー等、CLIで常駐しているPHPも再起動する

• コンテナ環境は、ベースイメージを更新して再ビルド・再デプロイする（コンテナ内の php -v だけを確認しても不十分）。
• レンタルサーバー・マネージドホスティングは、管理画面で選べるPHPバージョンに修正版が反映されているかをホスティング会社に確認する。修正版が選べない場合は、サポートに問い合わせる。
• 導入元によっては、OSの自動セキュリティ更新ではPHPが更新されない構成があります（外部リポジトリからPHPを入れている場合など）。「自動更新だから大丈夫」と考えないでください。

侵害されていないかを確認する（検知とIoC）

2026年10月22日時点で、公式に確定したIoC（侵害指標）は公表されていません。以下は、公開分析で示されている「挙動ベースの兆候」です。

• PHPのワーカー（php-fpm・php-cgi・httpd・apache2）が、sh・bash・cmd.exe・powershell.exe などのシェルを子プロセスとして起動している
• 通常と異なるマルチパートのリクエストの直後に、HTTP 500 が続く
• コマンドラインに /dev/tcp/、fsockopen、mkfifo を含む文字列（リバースシェルの典型）
• 公開ディレクトリ（ドキュメントルート）に見覚えのない .php ファイル（ウェブシェル）が増えている／新しいcronジョブやスケジュールタスクが追加されている

# 直近N日で更新されたPHPファイルの一覧（ドキュメントルートで）
find . -type f -name '*.php' -mtime -7 -printf '%TY-%Tm-%Td %TH:%TM  %p\n' | sort

# PHPワーカーの子プロセスにシェルがいないか
ps -eo pid,ppid,user,cmd --forest | grep -E 'php-fpm|apache2|httpd' -A2 | grep -E 'sh|bash'

# cron の不審な追加
crontab -l; ls -la /etc/cron.d/ /var/spool/cron/ 2>/dev/null

当社が実際に受けた攻撃——MF-2026-0812

当社（株式会社Medi Face／医療法人鳳應会グループ）は、2026年8月、PHPウェブシェルを起点とする標的型の攻撃を実際に受けました。今回のPHPの脆弱性が「PHPが動いているサーバーが攻撃の入口・足場になる」という現実を突きつけている今、当事者として何が起き、何を学んだかを記します。

何が起きたのか

攻撃の技術的な特徴

• PHPウェブシェルによるサーバー全体の掌握：6種類のバックドア（fgh.php ほか）を複数のファイル名・ディレクトリに冗長に設置。
• LD+JSON注入：ページ上には見えず、検索エンジンのクローラーだけが読む構造化データに賭博サイト名を埋め込み、医療サイトの高い信頼性（YMYL）を悪用。
• ジオクローキング：日本からのアクセスや調査には無害なページを見せ、検索エンジンやインドネシアのモバイル利用者にだけ違法賭博へ誘導。院長やスタッフが毎日サイトを見ても気づけない設計でした。
• ブランド偽装：被害法人のブランド名を模したCloudflare Pagesの偽ページを事前に構築し、Googleサーチコンソールにも攻撃者が登録。
• 二重脅迫の設計：アフィリエイト収益に加え、「被害法人が違法オンラインカジノを運営している」という偽の証拠を永続的に作り込む、脅迫の足場としての側面。
• 追撃のフィッシング：攻撃の後、ホスティング会社を装うフィッシングメールが41件届きました（認証情報の窃取を狙うもの）。今回のPHPの件でも「緊急アップデート」を装った便乗メールに警戒してください。

PHP2Shellとの関係——断定できること、できないこと

当社が下した判断：PHP／WordPress依存からの脱却

当社は事案の発覚から48時間以内に全サイトを静的サイトへ移行し、8月26日までにインフラの完全移管を終えました。その後も、PHPの残骸を含めて置き換えを進めています。これは費用（当社は事案対応に1万ドル以上を要しました）と手間のかかる判断でしたが、結果として今回のように「PHPそのものに重大な欠陥が見つかる」局面でも、緊急の対応に追われない構造になりました。当社代表の近澤徹は、今回の報道を受けて次のように投稿しています。

いろんなところから問合せ来てるなーと思ったら、PHPこんな大問題なってるのか。早めにサイバー攻撃受けておいて良かったほんと。

うちは今年の夏以降、phpの残骸も含め全てリプレイスしています。

「攻撃を受けておいてよかった」という言葉は、被害の重さを軽んじるものではありません。被害に遭った当事者が、同じ経験を他の医療機関にさせたくない——その思いから、当社は事案の詳細を公開しています（技術解析レポート：MF-2026-0812（日本語）／Medi Face Security Research）。

医療機関が今日やるべきこと

クリニックの院長・事務長が、ITの知識がなくても今日できることを、優先度順に整理します。

ステップ1：制作会社・サーバー会社に、この4点を聞く（メールで構いません）

ステップ2：「自院のどのシステムがPHPか」を洗い出す

ステップ3：すぐに更新できない場合は「止める」判断を恐れない

首相の呼びかけにあるとおり、修正の適用が困難なら、サイトを一時的に停止することは有効なリスク低減策です。医療機関では、診療に直結する部分を優先して残し、そうでない部分を止める、という考え方が現実的です。

• 予約フォーム／問診フォーム：一時停止し、「ただいまメンテナンス中のため、お電話でご予約ください」と案内（電話・LINEなど、PHPに依存しない窓口）。
• ホームページ本体：アクセス情報・診療時間・電話番号だけの静的な臨時ページに差し替える。
• 患者さんへの周知：閲覧するだけの患者さんには、何も操作は求められません。「緊急のPHPアップデート」を装うメールやSMSのリンクを開かないよう、院内掲示やLINEで一言添えると安心です。

ステップ4：更新後に確認すること

• 更新後のバージョンがWebで実際に使われているもので、修正版以上になっていること。
• PHPのワーカーが再起動されていること（更新しただけで古いプロセスが残っていないか）。
• 見覚えのないPHPファイル・管理者アカウント・不審なcronがないこと（検知とIoC）。
• Googleサーチコンソールで、検索流入の異常な増減やセキュリティの問題が出ていないこと（検出方法）。

個人情報が漏えいした可能性がある場合

患者さんの氏名・連絡先・症状などを扱うフォームが侵害された場合、個人情報保護法にもとづく報告・通知が必要になる可能性があります。詳しくは「医療サイトが改ざんされたら個人情報漏洩の報告義務はあるか」、および厚生労働省の指針については「厚生労働省のサイバーセキュリティ指針とクリニックが取るべき対策」を参照してください。

「PHPに依存しない」という選択肢

今回のようにランタイムそのものに欠陥が見つかると、「アプリを最新にする」では間に合いません。根本的な発想の転換として、そもそもPHPを公開サーバーで動かさないという設計があります。

静的化は万能ではありません。予約・問診・お問い合わせなど動的な機能は別の安全な仕組みで受ける設計が必要で、ビルドやデプロイの環境、DNS、外部サービスの認証情報という新しい守る対象も生まれます。それでも、「公開サーバーでPHPを動かさない」ことで、今回のようなランタイム級の脆弱性に直撃されないという構造上の利点は、医療機関にとって大きな選択肢です。当社がMF-2026-0812の後に選んだのも、この道でした。

よくある質問

一次情報・参考資料

• PHP.net — 2026年のニュースアーカイブ（セキュリティリリース告知）
• PHP公式セキュリティアドバイザリ：GHSA-w8hw-w9fx-j79w（CVE-2026-109618）／GHSA-6wmf-4rv5-p3rp（CVE-2026-109619）
• Help Net Security — PHP2Shell: Critical PHP vulnerabilities patched, update now!
• watchTowr — PHP Remote Code Execution FAQ: CVE-2026-109618
• DEV Community — PHP Patched the Two Critical RCE Flaws: Versions, Risk by SAPI, and Stopgaps
• Brandefense — PHP2Shell: Fixed PHP Versions and Free Check
• Laravel Forge — PHP security advisory (CVE-2026-109618, CVE-2026-109619)
• mySites.guru — PHP's Critical Security Release（WordPress／Joomlaへの影響）
• 高市早苗（内閣総理大臣）公式X @takaichi_sanae、2026年10月21日夜の投稿
• Medi Face Security Research — 医療サイバーセキュリティ研究（公開研究サイト）
• Medi Face — MF-2026-0812 技術解析レポート（日本語）／GitHub
• Medi Face プレスリリース（PR TIMES）

※本記事は2026年10月22日時点の公開情報にもとづく一般的な情報提供であり、個別の環境における安全性を保証するものではありません。悪用状況・パッケージの提供状況は刻々と変わります。最新の情報はPHP公式・ご利用のOS／ホスティング事業者の案内をご確認ください。技術的な誤りやご指摘は info@medi-face.co.jp までお知らせください。