PHP の脆弱性 php2shell に、自分のサーバーで対応してみました

10 月 21 日、PHP 本体の脆弱性「php2shell」に、このサイトのサーバーで対応しました。夕方のニュースで知ってから、修正版を入れてサイトを戻すまで、ちょうど 8 時間です。

どんな脆弱性なのかと上げる版の番号は、速報 と 続報 に書きました。この記事では、実際にやった順番と途中で詰まったこと、次に同じことが起きたら変えたいことを書いておこうと思います。

8 時間でやったこと

先に、流れを表にしておきます。時刻は日本時間です。

16:00	ニュースで知る。サーバーの PHP の版と、同じ PHP で動いているサイトを洗い出す
16:12	つなぎの設定を 2 つ入れる。データベースと設定ファイルのバックアップも取る
16:27	使っていない試作のサイト 2 つを止めて、片付ける
16 時半すぎ	サーバー会社の緊急メンテナンスで、サーバーが 17 時すぎまで応答しなくなる
17:48	速報の記事を公開する
22:36	サイトを閉じる。自分の回線とサーバー自身からしか見えないようにする
23:00	PHP の修正版が公開される
23:58	Ubuntu の修正版のパッケージを入れる
23:59	サイトを開けて、つなぎの設定を外す

最初の 30 分で、入口を減らした

最初に見たのは、サーバーの PHP の版です。このサイトのサーバーは Ubuntu の PHP を使っていて、修正が出る系列でした。あとは修正版を待って入れればいい、と分かって少し落ち着きました。

次に、同じ PHP で動いているサイトを数えました。ここで、試作のまま使っていなかったサイトが 2 つ、動いたままになっているのに気づいたんです。どちらももう使っていないので、ファイルとデータベースを退避してから、その場で消しました。

つなぎの設定は 2 つです。どちらも完全な対策ではないと分かっていたので、入口を少しでも狭める、くらいの気持ちで入れました。

• PHP の Session Upload Progress を切る
• ファイルを送る形の POST（multipart）を、PHP に届く前に Web サーバーで止める。自分の回線からは通す

このサイトには、訪問者がファイルを送るフォームがありません。なので、multipart の POST を止めても困る人はいないんです。夕方から夜までの間に、この遮断に引っかかったのは、セキュリティ会社のスキャナーから来た 1 件だけでした。

あとで出た公式の告知を読むと、この 2 つはどちらも実際の攻撃経路に関わる場所でした。Upload Progress は 2 件目の経路の 1 つで、multipart の読み取りは 1 件目の手口に挙がっています。

途中で、サーバーが応答しなくなった

詰まったのは、16 時半すぎです。使っていないサイトを片付けている最中に、サーバーがまったく応答しなくなりました。Web も SSH も、ping も返ってきません。

設定を触った直後だったので、自分で何か壊したのかと、かなり焦りました。原因は、サーバー会社の緊急メンテナンスです。21 日の 15 時から翌日の 18 時までに、ホストを順に再起動するという案内が、メールで届いていたんです。

17 時すぎに戻ったあと、サーバーの時計が 10 分近く遅れていました。仮想マシンが一時停止していた間、時計も止まっていたんだと思います。時刻合わせのサービスを再起動して直しました。ログの時刻がずれたままだと、あとで攻撃の跡を追うときに困るところでした。

サイトを閉じて、修正版を待った

23 時に修正版が出る前に、サイトを閉じることにしました。修正版が出ると、その差分から攻撃のしかたを割り出されます。セキュリティ会社の Sansec は、公開から 15 分以内に大規模な攻撃が始まると見ていました。

このサイトは、1 日止まっても困る人はいません。それなら、修正版を入れるまで閉じてしまうのがいちばん確実です。22 時 36 分から、自分の回線とサーバー自身以外には、503 を返すようにしました。

503 にしたのは、検索エンジンに「一時的に止めている」と伝えるためです。404 を返すと、ページが消えたと受け取られるおそれがあります。

閉じていた 1 時間 23 分の間に、外から来たアクセスは 360 件でした。どれも PHP に届く前に止まっています。閉じる前の時間も含めて、PHP のプロセスが異常終了した記録はありませんでした。

23 時に、PHP の公式が修正版を出しました。ただ、このサイトのサーバーに入るのは、Ubuntu が自分のパッケージに修正を取り込んでからです。その Ubuntu の修正版が届いたのは、公開からおよそ 1 時間後でした。

23 時 14 分の時点で、Ubuntu のセキュリティ情報には修正版の番号が出ていました。それでも、サーバーで apt を見ると、新しい版がなかなか出てきません。23 時 36 分にもまだ無く、23 時 57 分に確かめたときに届いていました。配信の一覧には 23 時 4 分の日付が付いていたので、使っている配信サーバーに届くまでに時間がかかったようです。

入れたのは 23 時 58 分です。PHP の 15 個のパッケージをまとめて更新して、PHP-FPM が再起動したのを確かめました。更新の履歴には、CVE-2026-109618 と CVE-2026-109619 の修正が載っています。

23 時 59 分にサイトを開けて、つなぎの設定も外しました。トップや記事、管理画面が普段どおり動くのも確かめています。

自動更新に任せていたら、どうなっていたか。Ubuntu の自動更新は 1 日 1 回で、このサーバーの次の出番は朝 6 時台でした。修正版が届いてから 7 時間近く、穴が開いたままだったことになります。

次に同じことが起きたら

今回やってみて、次からはこうしたい、と思ったことが 3 つあります。

• 使っていないサイトは、早めに消す： 試作のサイトは、置いておくだけで入口になります。今回いちばん反省したところです
• 閉じる手順は、昼のうちに作っておく： 閉じる設定と開ける手順を先に用意して試しておいたので、夜はそれを流すだけで済みました
• 修正版は、自分で見に行く： 緊急の修正が予告されたら、公開の時刻に合わせて apt を確かめます。自動更新の出番を待たないほうが早いです

PHP で自分のサーバーを動かしている人は、使っていないサイトの片付けと、サイトを閉じる手順だけでも、先にやっておくと気持ちが楽だと思います。