PHP2Shellとは？サイト運営者が今やること3つ【10月22日時点】

2026年10月21日、PHP本体に見つかった2つの重大な脆弱性の修正版が公開されました。2つをつなげた攻撃ツールの名前から「PHP2Shell」と呼ばれています。この記事では、中小企業のホームページ担当者やWeb制作会社の方に向けて、何が起きたのか、自社サイトが対象になるか、今日なにをすればいいかを、2026年10月22日時点で確認できた一次情報をもとに整理します。

結論：PHP2Shellで今やること3つ（2026年10月22日時点）

PHP2Shellとは何か。PHP本体の脆弱性CVE-2026-109618とCVE-2026-109619の通称で、ログイン不要の外部からの通信だけで、サーバー上で任意のプログラムを動かされる（＝サイトを乗っ取られる）おそれがあるものです。深刻度はNVDのCVSS v3.1で9.8（10点満点）と評価されています。

誰が対象か。PHPで動いているサイトはほぼすべてです。WordPressのような個別のアプリの不具合ではなく、その下で動くPHPそのものの問題なので、サイトのプログラムがきれいに作られていても影響を受けます。

今やることは次の3つです。

1. サイトが使っているPHPのバージョンを確かめる。修正版はPHP 8.5.12／8.4.27／8.3.36／8.2.35です。これより古ければ対象です。
2. 修正版に更新する（レンタルサーバーなら事業者の対応状況を確認する）。PHP 8.1以前の場合、共用のレンタルサーバーなら、まず事業者のお知らせで、使っている版に修正が当たっているかを確かめます（さくら・XREA・コアサーバー・ConoHa WINGは古い版にも修正を当て、版の変更は不要と公表。hetemlも7.4に修正済み）。当たっていなければ、応急処置を頼むか、バックアップを取って試したうえで8.3以上へ切り替えます。自社で管理するサーバーなら、OSの配布元が出す修正済みパッケージを入れるか、8.3以上へ切り替えます。
3. 更新が終わったら、攻撃の痕跡を確認し、パスワードやAPIキー（外部サービスとの接続に使う鍵）を入れ替える。この脆弱性にはサーバーのメモリの中身が漏れる性質もあるためです。

PHPの公式発表は「更新だけが完全な対策」としています。WAF（不正な通信を止める防御サービス）や設定変更は、更新までの時間稼ぎと考えてください。

PHP2Shellとは：2つの脆弱性の中身

PHP2Shellは正式な脆弱性名ではなく、セキュリティ企業Califが2つの脆弱性を連結して作った攻撃ツールの名前で、報道や研究者がそのまま通称として使っています。中身は次の2件です。

RCE（リモートコード実行）とは、外部から送り込んだ命令をサーバー上で実行させられる状態のことです。深刻度の評価は、PHPプロジェクトがCVSS v4.0で9.2、米国のNVDがCVSS v3.1で9.8、Red Hatが8.1としています。

攻撃の入り口は、ファイル添付つきのフォーム送信などで使われる multipart/form-data という形式のリクエストです。PHPの既定の設定のままで影響を受けます。

もう一つ見落とせないのが情報漏えいの面です。調査会社Sansecによると、CVE-2026-109618ではサーバーのメモリの中身が PHPSESSID というクッキーに乗って外部に漏れることがあり、そこには他の利用者のパスワード、セッション情報、APIキー、TLS（https通信）の秘密鍵などが含まれうるとしています。アプリ側でセッション機能を使っていなくても起きるとされています。

Sansecは、Magento 2.4.9、WordPress 7.1.2、Drupal 11.4.3、Joomla 6.1.4、MediaWiki 1.46.2、Roundcube、phpMyAdmin 5.2.3、Nextcloud、Laravel 13.11、Symfony 8.1、WHMCSで、ログインなしにプログラムを実行できることをCalifが実証したと報告しています。原因がPHP本体にある以上、利用しているCMSやフレームワークの種類で安心はできません。

何が起きたか：発見から修正版公開までの時系列

時刻はすべて日本時間です。

修正版が出る前から攻撃の動きが観測されていた点が、今回の特徴です。修正版の公開から時間が経つほど攻撃の手口は広まるので、更新は早いほど安全です。

自社サイトは影響を受ける？運用形態別の判定表

同じ「PHPで動くサイト」でも、PHPを誰が更新するかで、担当者がやることは変わります。まず自社サイトがどの形態かを確かめてください。

サーバーでのPHPの動かし方による違い

影響を受けるのは、mod_php、PHP-FPM、php-cgi、FrankenPHP、LiteSpeed（LSAPI）といった主要な動かし方のすべてです。中でもApacheに組み込むmod_phpはリスクが最も大きく、サイトのプログラムが動き出す前の段階で攻撃が成立することが実証されています。

Wizは、PHP 5.4以降のほぼすべての版が少なくとも1件の影響を受けるとしています。「うちは古いPHPだから最近の脆弱性とは関係ない」とは考えないでください。

修正版と、自社のPHPバージョンの確かめ方

PHPの公式発表による、系列ごとの修正版は次のとおりです。

PHP 8.1以前を使っている場合の考え方は、PHP 7.4・8.1など古いPHPを使っているサイトの対処で詳しく扱っています。今回8.2へ上げるだけだと、2か月あまりで再びサポート切れになる点にも注意が必要です。

PHPバージョンの確かめ方

• レンタルサーバー：サーバーの管理画面にある「PHPバージョン設定」などの画面で、サイト（ドメイン）ごとの設定を確認します。事業者ごとの画面の場所はレンタルサーバー別のPHP脆弱性対応とバージョンの確かめ方にまとめています。
• WordPress：管理画面の「ツール」→「サイトヘルス」→「情報」タブ→「サーバー」の欄にPHPのバージョンが表示されます。
• 自社サーバー：コマンドの php -v で確認できますが、コマンド用のPHPとWebサイトを動かしているPHPが別の場合があります。Webサーバー側の設定もあわせて確認してください。

Linuxのパッケージで入れている場合

Linuxの各ディストリビューションには事前に修正が提供されており、版番号が公式と違っても修正が取り込まれていることがあります。判断は各ディストリビューションのセキュリティ情報で行います。10月22日時点では、次の状況と報告されています。

• Debian：trixie・bookworm は修正済み
• Ubuntu：22.04〜26.10 は修正済み。20.04・18.04 は Ubuntu Pro で提供（USN-8948-1／-2）
• AlmaLinux 8・9・10、Rocky Linux：修正済み
• RHEL：一部提供（RHSB-2026-013）
• Amazon Linux 2023：php8.2〜8.5 は修正済み（php8.5 は ALAS2023-2026-3304）。Amazon Linux 2 の Extras の php8.2 も修正済み。Amazon Linux 2 の標準PHPと Amazon Linux 2023 の php8.1 は修正予定なし
• Remiリポジトリ：10月21日時点では未更新

すぐ更新できないときの暫定策

PHPの公式発表は、以下の対策は攻撃の経路を減らすだけで、サイトを安全にするものではないと明記しています。更新までのつなぎとして使い、更新の予定は必ず立ててください。

1. WAFを有効にする。Cloudflare（無料プランを含む全プラン）、Akamai、Imperva、Fastly、AWS WAF、Sucuri、攻撃遮断くん、WafCharmなどが対応ルールを出しています。いずれも補完策の位置づけです。
2. PHPの設定で入口を狭める。session.upload_progress.enabled=0 にする（php.ini かPHP-FPMのプール設定で行い、全プロセスを再起動。.user.ini や ini_set では効かない）、post_max_size を下げる（アップロード不要なら8M、必要なら32M）などが公式に示されています。
3. memory_limit=-1 は条件をそろえて使う。公式の暫定策に含まれます。アプリから上書きできない形（PHP-FPMのプールの php_admin_value など）で設定し、有限の上限に戻す設定（.htaccess・.user.ini・アプリ側の指定など）が残っていないかも確かめます。それでも、より下の層でメモリの確保に失敗すると脆弱な処理にまだ届くため、完全には塞げません。また、1つのリクエストがサーバーのメモリを食い尽くしうるので、コンテナや cgroup のメモリ上限を歯止めにして、問題のワーカーだけが止まるようにします。
4. Webサーバーで multipart/form-data を止めるか、静的なメンテナンス画面に切り替える。Sansecが示している方法で、ファイルのアップロードや一部の決済フォームは使えなくなります。

反対に、RLIMIT_AS や RLIMIT_DATA（ulimit -v など）でメモリを制限する方法は、かえって攻撃の引き金になるため使わないよう公式が注意しています。設定の具体例は古いPHPのまま当面しのぐ方法の記事で扱っています。

ここまで読んで、自社サイトがどの形態か分からない、サーバーの設定を触れる人が社内にいない、という方も多いと思います。Mihataはホームページの制作と保守をお引き受けしており、今回のような更新作業や、古いPHPからの移行もご相談いただけます。記事の途中で恐縮ですが、よろしければサービスの内容もご覧ください。

国内の影響：211組織が停止・メンテナンスを告知、WAF各社も対応

国内の対応状況をまとめているpiyologの集計では、10月22日1時台までに211の組織がサービスの停止やメンテナンスを告知しました。省庁や自治体、銀行、ゲーム、ECサイトなど業種は幅広くなっています。

主なレンタルサーバー・サイト作成サービスの対応は次のとおりです（10月22日朝、piyolog集計による）。状況は時間とともに変わるため、最新の情報は各社のお知らせで確認してください。

このほか、Movable Typeのクラウド版が緊急メンテナンスを予定し、PowerCMSの開発元は利用者に一時停止の検討を呼びかけています。事業者ごとの詳しい対応と、利用者側の作業はレンタルサーバー各社の対応まとめをご覧ください。

攻撃は始まっているのか

10月22日朝の時点で、各社の見方は分かれています。

• 悪用ありとする報告：Cloudflareは修正版の公開前に初期の攻撃を確認したとしています。watchTowrはおとりのサーバー（ハニーポット）で攻撃を観測したと報告し、Patchstackはホスティング事業者から複数の報告を受けたとしています（侵害の確証はまだないとのこと）。
• 観測なしとする報告：米CISAは10月21日時点で悪用を観測していないとしており、悪用が確認された脆弱性の一覧（KEV）にも登録していません。Huntressも観測していないとしています。
• 攻撃コード：オランダのNCSCによると、実証用の攻撃コード（PoC）が公開されています。

攻撃コードが出回っている以上、「まだ大規模な被害の報告がない」ことは更新を後回しにする理由になりません。

よくある誤解：この対策では防げない

WordPressやプラグインを更新すれば直る

直りません。原因はWordPressではなく、その下で動くPHPにあります。WordPress本体やプラグインを最新にしていても、サーバーのPHPが修正版でなければ対象のままです。逆に、PHPを更新すればWordPress側の作業は不要です（ただし古いPHPから大きく上げる場合は、プラグインが動くかの確認が必要になります）。

メンテナンスモードにしておけば防げる

WordPressやMagentoなどアプリの機能で出す「メンテナンスモード」では防げません。Sansecによると、PHPがリクエストを読み込む段階で攻撃が成立するため、アプリがメンテナンス画面を出すより先に問題が起きます。止めるなら、Webサーバー側で静的なHTMLのメンテナンス画面を返す形にする必要があります。

エラー表示を隠せばよい

意味がありません。PHPの公式発表は、error_reporting や display_errors の設定、@ 演算子でエラーを隠しても対策にならないと明記しています。画面にエラーが出ていないことは、安全であることを意味しません。

更新が終わったら：痕跡の確認と鍵の入れ替え

修正版にしたあとも、それ以前に攻撃を受けていた可能性は残ります。現時点で、侵害の痕跡（IoC）の公式な一覧はありません。手がかりとして挙げられているのは次のようなものです。

• multipart/form-data 形式の大きなリクエストがアクセスログに残っている
• PHPSESSID クッキーに、メモリの中身らしき長い値が入っている
• メモリの使用量が急に増えた記録がある
• PHPのプロセスがメモリ不足（OOM）で異常終了したログがある

メモリの中身が漏れた可能性がある以上、管理画面のパスワード、データベースのパスワード、外部サービスのAPIキー、必要に応じてTLS証明書の鍵の入れ替えも検討してください。手順はPHP2Shell対応後のチェックリスト（痕跡の確認と鍵の入れ替え）にまとめています。すでに改ざんの兆候がある場合はホームページが改ざんされたときの確認と復旧の手順を参照してください。

まとめ

PHP2Shellは、PHPで動くほぼすべてのサイトに関わる脆弱性です。担当者がやることは、PHPのバージョン確認、修正版（8.5.12／8.4.27／8.3.36／8.2.35）への更新、更新後の痕跡確認と鍵の入れ替えの3つです。レンタルサーバーなら事業者の対応を確かめ、PHP 8.1以前を選んでいれば、その版に修正が当たっているかを確かめる。当たっていなければ応急処置を頼むか、バックアップを取って試したうえで8.3以上へ切り替える。自社サーバーなら自分で更新する。WordPressの更新やメンテナンスモードでは防げない、という点だけは覚えておいてください。

今回のような緊急対応は、日ごろ「誰がサーバーを管理しているか」が決まっていないと一気に難しくなります。普段の備えについては中小企業のホームページで最低限やるセキュリティ対策も参考にしてください。

自社サイトのPHPが何なのか分からない、更新を頼める相手がいない、という段階からでもかまいません。Mihataでは中小企業のホームページの制作と保守を行っており、現状の確認からお手伝いできます。気になることがあれば、お気軽にご相談ください。