2026 年 10 月 21 日 (水)、PHP の脆弱性「PHP2Shell」(CVE-2026-109618 / CVE-2026-109619) への対応が各所で行われました。弊社が管理している病院・クリニックなどのサイトも多くが PHP (WordPress) で動いており、対応が必要になりました。

先に結論を書くと、現時点で、弊社が確認したサーバーに侵入の痕跡は見つかっていません。本記事では、そこに至るまでの対応を公開できる範囲でまとめます。

徹夜に近い一晩でした

修正版の PHP が公開されたのは、10 月 21 日 (水) の 22:52 (日本時間) です。各レンタルサーバー会社の緊急メンテナンスは 22 時ごろから始まり、弊社でも VPS の更新に取りかかりました。配布元の混雑でパッケージが取得できず、インストールを終えられたのは深夜 3 時ごろ。最後のレンタルサーバーで修正版への入れ替えが終わったのは、翌朝 7 時半すぎでした。

攻撃方法はすでに出回っており、朝を待ってから動くという選択肢はありませんでした。対応は、徹夜に近い一晩がかりのものになりました。

AI 時代のパニックには、AI の力で対応する

今回の騒動の特徴は、その速さにあります。脆弱性の詳細は修正版の公開より前に流出し、流出から数時間のうちに悪用の報告が出ています。情報が広まり、攻撃に使われるまでの時間は、もはや人の手作業で追える速さではありません。

弊社が管理するサイトは、病院・クリニックを中心に多くの法人にわたり、サーバーの数も相当なものになります。確認すべきことも、PHP の版、修正前の時間帯に届いたアクセス、新しく増えたファイル、不審な定期実行など、1 台あたりで多岐にわたります。これを攻撃が続いているさなかに全台で確認するには、人の手で 1 台ずつ見ていく方法では間に合いません。

AI 時代の速さで広がる攻撃には、守る側も AI の力で対応するしかありません。弊社では、ssh で接続できるサーバーを読み取りのみで横断的に調べ、ログを解析し、異常の有無を判定する作業に AI を使い、修正版の公開から数日のうちに 2 回確認しました。今回の対応を経て、弊社のセキュリティ確認は AI による定期チェックを軸とする体制へ一気に移っています。

AI による調査とサーバーの相性

これまでサーバーを、AI が操作しやすいかどうかという観点で比べたことはありませんでした。ただ、今回のように AI に確認作業を任せる場合、サーバーによって調べやすさに違いが出ます。AI がサーバーに接続し、必要な情報を自分で集められるかどうかで、確認の速さや網羅性が変わってきます。

弊社が扱う病院サイトの規模では、さくらのレンタルサーバ・エックスサーバー・ロリポップを利用するケースが多く、そのほかのレンタルサーバー上で動いているサイトもあります。今回の作業から見えた違いは次のとおりです。なお、使える機能はプランや契約によって異なるため、あくまで弊社が扱っている環境での状況です。

サーバー	AI による操作のしやすさ
さくらのレンタルサーバ	ssh で接続でき、アクセスログ・エラーログもサーバー上から取得できる。調査しやすい
エックスサーバー	同じく ssh で接続でき、ログも取得できる。調査しやすい
ロリポップ	ssh で接続でき、ファイルの確認はできる。ただしアクセスログは ssh で取得できず、手動でのダウンロードが必要。定期的なチェックには不利
Bizメール	今回の環境では ssh を使えず、調べられる範囲は限られる。ログは FTP で取得できる
ConoHa WING	今回の環境では ssh を使えず、調べられる範囲は限られる。ログは FTP で取得できる
Web アリーナ	今回の環境では ssh を使えず、調べられる範囲は限られる。ログは FTP で取得できる。10 月 23 日にはメンテナンスでサイトが 1 日ほど表示できない状態になり、復旧まで弊社側では手の打ちようがなかった

ログを人の手で取りに行く必要がある環境では、その部分だけ AI に任せられず、確認の頻度も網羅性も落ちます。管理画面の手軽さと、ssh の自由さのバランスがよいレンタルサーバーが、AI との相性はよさそうです。

Cloudflare Workers への移行

弊社が扱う構成の中で、今回もっとも安心して見ていられたのが、Cloudflare Workers を使った構成です。Cloudflare Workers は、自前のサーバーを持たずに、Cloudflare の配信網の上で直接サイトを動かせる仕組みです。構成がシンプルで、PHP のようなサーバー側のソフトウェアを自分たちで抱えずに済みます。弊社では今回の騒動の前から、公開サイトをこの仕組みで配信する運用を始めており、ちょうど移行を進めている時期でした。

この構成では、公開サイトへのアクセスを Cloudflare Workers が受け、PHP が公開側に出ません。今回のような PHP 本体の脆弱性は、そもそも攻撃の届く場所がない、ということになります。各社のメンテナンスや修正版の取得を待つ必要もなく、深夜の対応のさなかでも、この構成のサイトについては対応の必要がないと判断できました。AI による確認以前に、確認すべき対象そのものが公開側に無いということです。

脆弱性への対応は「早く直す」ことが基本ですが、「直す必要のある部品を公開側に置かない」ことは、それより前段の対策になります。今回の対応を通して、そのことを改めて感じました。

2026年10月21日(水): 情報が出てから 23 時までにやったこと

10 月 20 日に PHP 側から「21 日に修正版を出します」という予告があり、その前後で脆弱性の詳細が外部に流出しました。21 日の昼前には流出した情報が出回りはじめ、夕方には悪用の報告も出ています。修正版の公開は 21 日の 22:52 (日本時間) でした。

攻撃方法は知られているものの、修正版はまだ無い、という状態が半日ほど続きました。

PHP のバージョンの整理

まず、管理一覧をもとに、各サイトがどのサーバー会社の、どの系列の PHP で動いているかを整理しました。

PHP 本家の修正版は 8.2 / 8.3 / 8.4 / 8.5 系の各系列に出ることになっていたため、系列ごとに更新の段取りを確認しました。

サーバー会社が対応しなかった場合の備え

次に、レンタルサーバー会社がマネージドサーバーなどの個別プランまで対応しなかった場合に、弊社側で何ができるかを調べました。共用のレンタルサーバーでは PHP 本体を入れ替えられないため、できるのは設定の変更に限られます。

調べていくと、セッションの「アップロード進捗」の機能 (session.upload_progress) を止めておくと、今回の攻撃で使われうる入口を減らせる、という情報が得られたため、対象のサイトの .user.ini に次の 1 行を入れました。

session.upload_progress.enabled = 0

一般的な WordPress サイトではこの機能は使われていないため、止めても影響はありません。

※ 攻撃の入口を減らすための応急処置であり、PHP の修正版の代わりにはなりません。

2026年10月21日(水) 22 時〜: レンタルサーバー各社のメンテナンス

22 時ごろから、各レンタルサーバー会社が緊急メンテナンスに入りはじめました。弊社が主に利用している各社の対応は次のとおりです (時刻はサーバー上のファイルの日時などから弊社で確認したものです)。

サーバー	修正版の PHP に入れ替わった時間帯 (日本時間)
さくらのレンタルサーバ	10/21 22:42 〜 10/22 01:27
エックスサーバー (共用)	10/21 23:09 〜 10/22 04:31
ロリポップ	10/22 01:21 〜 07:37 (サイトの表示は 10/22 13 時ごろ再開)

いずれも PHP の公開とほぼ同時に対応が始まっていました。ロリポップは、修正を終えるまでサイトの表示を止める方式をとっており、10 月 22 日 (木) の午前中は表示できない状態が続きました。各社の対応の詳細は、表の各社名から公式のお知らせをご覧ください。

2026年10月21日(水) 深夜: VPS のパッチが取得できない

レンタルサーバーと異なり、VPS (弊社で PHP を入れて管理しているサーバー) は弊社で修正版に更新する必要があります。

23 時ごろから、Ubuntu の VPS で修正版 (同じ系列の minor update) への更新を始めました。ところが、PHP のパッケージを配っているリポジトリ (PPA) の配布用サーバーが、公開直後でアクセスが集中しており、503 (混雑) を返し続けたため、ダウンロードできませんでした。

3 時ごろ: 別の経路から取得

深夜 3 時ごろ、通常とは別の経路でパッケージを取得してインストールしました。

PPA のパッケージ (.deb ファイル) は、apt がふだん使う配布用のサーバーとは別に、PPA の仕組み (Launchpad) の本体側にもファイル置き場があります。中身は配布用サーバーと同じファイルで、こちらは混雑していなかったため、必要な 12 個のファイルをここから取得しました。

ただし、この方法では apt が通常行う署名の確認を経由しないため、ファイルが正しいかを別途確かめる必要があります。

そこで、サーバーが保持しているパッケージ一覧 (apt が署名を確認したうえで取得したもの) に記載されたチェックサム (SHA256) と、取得した 12 個を照合しました。12 個とも一致し、apt で通常どおり取得した場合と同一のファイルであることを確認したうえでインストールしています。

2026年10月22日(木): レンタルサーバーの対応完了

10 月 22 日 (木) の朝には、さくらインターネットやエックスサーバーから「PHP の脆弱性への対応が完了しました」との案内がありました。ロリポップも 13 時ごろにサイトの表示を再開し、主なレンタルサーバー上のサイトの対応が完了しました。

同日、弊社が ssh で接続できるサーバーすべてを読み取りのみで確認し、実際に動いている PHP の版を調べました。

その後: 侵入の有無の確認

修正版の適用後は、修正前に侵入されていないかを確認する必要があります。各サーバーを読み取りのみで確認するスクリプトを用意し、次の項目を調べました。

• 期間中に新しく作られた・書き換えられた PHP ファイルや .htaccess / .user.ini
• 画像などを置く wp-content/uploads に PHP ファイルが紛れていないか
• webshell (サーバーを外から操るための不正なファイル) によく出てくる書き方が無いか
• 見覚えのない定期実行 (cron) が増えていないか
• アクセスログ・エラーログ: 攻撃っぽい大量の POST、PHP のクラッシュ、見覚えのない場所からの管理画面ログイン

10 月 23 日と 26 日の 2 回確認し、いずれも ssh で接続できるサーバーすべてが対象です。侵入の痕跡 (webshell・uploads 内の PHP・改ざん) は見つかっていません。

修正前の時間帯に、今回の脆弱性を狙ったとみられる大量のアクセスを受けたサイトもありましたが、いずれもエラーやクラッシュは起きておらず、ファイルの変化もありませんでした。それ以外は、平常時から見られる無差別な攻撃 (設定ファイルの探索やログイン画面の総当たりなど) でした。

※ アクセスログには POST の内容が残らないため、攻撃が成功していないと断定はできません。

今後もしばらくは、定期的な確認を続けます。

個別対応 1: サーバー移管

ある病院では、修正版への切り替えを確実に行うため、修正済みの PHP を入れた VPS を新たに用意し、サイトを急きょ移管しました。移管先では、混雑していた PPA ではなく Ubuntu 標準の PHP パッケージを使っており、こちらは修正版を取得できました。新しいサーバーは 10 月 22 日 0 時すぎに構築し、そのまま切り替えています。

個別対応 2: サーバー停止中の仮サイト公開

10 月 23 日 (金)、ある病院のサイトが置かれていたレンタルサーバーが、予告なくメンテナンスに入り、公開中のサイトも閲覧できなくなりました。復旧はサーバー会社の対応を待つほかない状況でした。

診療時間や休診のお知らせを確認したい患者さんもいるため、暫定措置として次の対応を行いました。

1. その病院のドメインと同じ名前で、末尾だけ違うドメイン (.jp に対して .net) を新しく取得
2. WordPress などは使わず、HTML のみの静的サイトとして、病院名で仮公開
3. 病院側から公式の Facebook・Instagram・X で仮サイトを周知してもらう

病院名で類似ドメインのサイトを出すため、見た目はなりすましサイトと区別しにくくなります。そのため、病院の公式 SNS から案内してもらい、正式なサイトであることを示せる形にしました。

元のサイトは、10 月 24 日 (土) の夕方ごろに復旧しました。

余談: 技術の外まで届いた騒動

今回の脅威の大きさを実感したのは、技術の外側での出来事でした。

10 月 21 日の夜には、高市総理が X で修正パッチの適用準備を呼びかけました。首相が個別のソフトウェアの脆弱性について直接対応を求めるのは異例のことで、報道でも大きく取り上げられています (ITmedia NEWS)。

病院とのやりとりの中では、「○○県から PHP の調査の連絡があって」という言い方をされたところもありました。警察ではないとのことで、行政の側から病院へ確認の連絡が回っていたようです。病院の側から見ても、ふだんのサイト運用とは違う種類の問い合わせだったことがうかがえます。

さらに、技術とはまったく関係のない Vtuber の雑談配信で「PHP が大変らしいけど……」という会話が出ていたのには驚きました。プログラミング言語の脆弱性が、日常の雑談の話題にまでなっていたわけです。