1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@dkuro

PHP2Shell で、サイトが無防備だった時間

1
Last updated at Posted at 2026-10-30

はじめに

PHP2Shell について、Qiita にもいろいろな記事が出ています。
みなさんの記事を読んでいてふと思いました。
利用者のサイトが脆弱性のある状態で外部からアクセスできるままになっていた時間を、各社のお知らせから測ってみようか、と。

ちなみに、私が昔いた現場はパッチの適用が数日遅れていました。さもありなん、です。

PHP の脆弱性の話になると、PHP を使う開発者だけでなく、レンタルサーバーの業者までいい加減なのでは、と言われがちです。私も最初はそう思っていました。
脆弱性のある状態で利用者のサイトを外部にさらしていたこと自体は、インフラを預かる業者の責任です。ただ、それが「いい加減だったから」なのか、作業の工程上しかたない部分があったのかを、公式のお知らせの時刻で確かめます。

予告から公開まで

PHP 公式は日本時間の 10/21 早朝、深刻度 9.2 の脆弱性 2 件の修正版を 23:00 に出すと予告しました（oss-security への投稿は 5:22）。実際に出たのは 22:34 です（GitHub の security advisory の公開時刻）。

一方で、悪用の試みは公表前の 10/17 から見つかっていたことが判明しています。
予告より早く出た理由は公表されていません。

各社の対応時刻と停止期間

安全になるための条件は、パッチを当て終えることです。
ただ、当て終えた時刻だけでは、危険だった時間は分かりません。先にサイトを止めていれば、そのあいだは外部からアクセスできないからです。

そこで、止めた時間と当て終えた時刻の両方を図にしました。

図の最上段は予告と公開の時刻です。その下がレンタルサーバー、いちばん下が自前でサービスを動かしている所で、バーの色は次のとおりです。

  • 赤いバー（露出）: 予告のあと、サイトの停止や緩和策、パッチの適用がまだで、脆弱性のある状態で外部からアクセスできた時間
  • 薄い青のバー（停止）: サイトやサービスを止めていた時間
  • 青紫のバー: 緩和策を入れていた時間、またはパッチを順番に当てていた時間
  • 灰色のバー: パッチを当て終えた後、または表示を再開した後

「自前」は、レンタルサーバーを借りずに、自社のサービスを自社で用意したサーバー（クラウドを含む）で動かしている所のことです。外部から見ても PHP を使っているかどうか分からないので、止めた時間だけを描いています。

図に入れた自前の 5 つは songchong さんの記事から取ったもので、どれも修正版が出る前に止めています（同じ記事にあるほかの 6 つは、公開のあとに止めています）。

レンタルサーバー各社の動きは次のとおりです。

  • ヘテムル・ロリポップ！: パッチが当たるまで利用者のサイトごと止めた 2 社です（ロリポップ！は止めた時刻の記載がないので図にはありません）
  • エックスサーバー: サイトは止めませんでしたが、公開前の 12:00 までに緩和策を入れ、公開後は順次パッチを当てています
  • コアサーバー V1 など: 止めずに、公開から 2 時間ほどで当て終えています

図に入れていない所は次のとおりです。

事業者 止めた・緩和策 パッチの適用
ロリポップ！ 10/21 からサイトの表示を停止 10/22 15:33 の更新で適用済み
さくらのレンタルサーバ 10/21 22:30 から会員関連の機能を緊急メンテナンス 10/23 に適用済み
WebARENA 10/21 に緩和策と、海外からのアクセスの停止 10/22 17:30 から緊急メンテナンス
ConoHa WING ファイルマネージャーと Web メールを停止 10/22 時点で順次適用中
CPI — 8.2〜8.4 は 10/22、7.4・8.0 は 10/27〜10/29

レンタルサーバーの時刻は、各社の公式のお知らせから拾いました（10/27 に確認）。並べたのはお知らせに書かれた時刻（またはお知らせの更新時刻）で、必ずしも全部のサーバーに当て終えた時刻ではありません。

ただ、こうして並べても「各社が何時間、脆弱性のある状態で外部にさらしていたか」は一つの数字に決まりません。
10/17（悪用の試みが見つかった日）と 10/21（公式の予告）のどちらから数えるかで 4 日ずれますし、サイトを止めたのか、お知らせに書いていないだけなのか、区別のつかない所があるからです。

どこから数えるか（10/17〜10/29）

当て終えるまでに時間がかかった理由（推定）

  • 公式の修正版は 8.2〜8.5 だけで、古いバージョンはバックポートか独自の修正待ち
  • 一度に当てず順番に当てたので、全体が終わるまで時間がかかった（KAGOYA は 14:40〜24:00 の 9 時間あまり。順番にした理由はお知らせに書かれていません）
  • パッケージで PHP を入れている場合は、配布元（CloudLinux や remi など）のビルドを待つ必要があった（下の表）
  • 公開直後は配布元にアクセスが集中し、つながりにくくなった所があった（Ubuntu 向けパッケージの配布に使われる Launchpad が 503 エラー、php.net が 504 エラー）

修正版がサーバーに当たるまでの 3 つの経路

配布元が修正版のパッケージを出した時刻は次のとおりです（比較のため、先頭に PHP 公式の公開時刻を入れています）。

配布元 出た日時（日本時間） 修正版の公開から
PHP 公式（ソースコード） 10/21 22:34 —
Debian（DSA 6574-1） 10/21 22:45 11 分
Ubuntu（USN-8948-1） 10/21 22:56 22 分
Debian LTS（DLA 4848-1） 10/21 23:11 37 分
Ondřej Surý の PPA（Launchpad） 10/21 23:45 1 時間 11 分
Docker 公式イメージ（official-images へのマージ） 10/22 0:16 1 時間 42 分
Red Hat Enterprise Linux 8〜10（AlmaLinux 9 も同じ日） 10/21（UTC・時刻なし） —
remi（RHEL 系で広く使われるリポジトリ） 10/22 21:58 23 時間 24 分
Red Hat の延長サポート向け（EUS など） 10/23（UTC・時刻なし） —

多くの配布元は、公開から 2 時間以内にパッケージを出しています。待ちが長かったのは remi と、Red Hat の延長サポート向けです。
レンタルサーバー各社が修正をどこから得たかは、お知らせに次のように書かれています。

事業者 修正の出どころ（お知らせの記載）
エックスサーバー 8.2〜8.5 は修正版に更新、5.1〜8.1 はバージョンを変えずに修正パッチを適用。出どころの記載なし
コアサーバー V1 記載なし
mixhost 採用している CloudLinux の修正パッケージ。サポートが終わったバージョンも CloudLinux が独自に修正
ヘテムル 公式の修正版がない古いバージョンは、自社で修正を作成
ロリポップ！ 公式の修正版が出たバージョンはそれを適用し、ほかは自社で独自に修正
お名前.com バージョンを変えずにパッチを適用。出どころの記載なし
KAGOYA 修正版に更新。出どころの記載なし
さくらのレンタルサーバ 記載なし
WebARENA 記載なし
ConoHa WING バージョンを変えずにパッチを適用。出どころの記載なし
CPI 8.2〜8.4 は修正パッチを適用、7.4・8.0 はパッチ適用版を準備。出どころの記載なし

配布元のパッケージを待っていたと書いている所はありませんでした。当て終えるまでにかかった時間のうち、どこまでが配布元の待ちによるものかは、お知らせからは分かりません。

主な配布元の時刻を、さきほどの図の最上段に足すと次のとおりです（自前の段は省きました）。レンタルサーバー各社のバーと見比べられます。

危険な時間を減らすには

ここからは私の見方です。

いい加減だったのか

測ってみた結果、業者がいい加減だったとは言えません。時間がかかった所も、作業の工程の限界によるものだと私は見ています。

  • 主な配布元は修正版の公開から 2 時間以内にパッケージを出し、レンタルサーバーでも公開から 2 時間ほどで当て終えた所（コアサーバー V1 など）があります
  • 予告から公開までのあいだに、手を打った所があります。エックスサーバーは 12:00 までに緩和策を入れ、ヘテムルは 13:30 ごろから phpMyAdmin などの機能を止め始め（サイトの表示を止めたのは 10/22 3:05）、さくらは 22:30 から会員関連の機能の緊急メンテナンスに入りました
  • 公式の修正版がない古いバージョンにも手当てをしています。ヘテムルとロリポップ！は自社で修正を作り、mixhost は CloudLinux の修正を使い、エックスサーバーは 5.1 まで対応を広げました

もちろん、パッチが当たるまでのあいだ、脆弱性のある状態で利用者のサイトを外部にさらしていた責任は業者にあります。
ただ、完了が翌日以降になった所も、手を抜いていたとは言えません。古いバージョンを抱えていたり、配布元のパッケージを待つ構成だったり、順番に当てる必要があったりすれば、作業の工程上、すぐには当て終えられないからです。

CERT-EU・英国の NCSC・米国の NSA・日本の IPA は、すぐ当てられないなら止めるよう呼びかけていました。サイトを止めてからパッチを当てるやり方は、再開が遅くなっても安全です。呼びかけどおりサイトごと止めたヘテムルとロリポップ！がこれにあたります。

とはいえ、レンタルサーバーが利用者のサイトを止めるのは簡単ではありません。
レンタルサーバーの業者はインフラを持っていますが、その上で動くサイト（サービス）は利用者のものです。止めれば利用者の業務が止まり、動かし続ければ脆弱性にさらされるので、業者だけでは決めにくい立場にあります。

これに対して、自社でサービスとインフラの両方を持っている会社は、サービスを止めるか、配布元を待たずに自分でビルドするか、いつ再開するかを、すべて自社で決められます。さきほどの図で、自前の 5 つが修正版の公開前に止めていたのも、自社で決められる立場にあったから取れた手です。

時刻を分単位で出している所は、測られてもいいと分かって出している所です。書いていない所が悪い、という話ではありません。

どこで露出していたか

ここまでの図と表から、露出していた時間は 2 つに分かれます。

露出していた時間は 2 つに分かれる（レンタルサーバー）

1 つ目の「予告から公開まで」は、この図のレンタルサーバーではエックスサーバーが 12:00 までに緩和策を入れ、さきほどのガントチャートにあった自前の 5 つが公開前にサービスを止めていました。

2 つ目の「公開から当て終える・止めるまで」は、サポート切れの古いバージョンほど長引いています。公式の修正版がないため自社で作るか CloudLinux などから得る必要があり、図に入れていない CPI の PHP 7.4・8.0 は適用が 10/27〜10/29 でした。

減らすためにできること

1 で「予告から公開まで」、2・3 で「公開から当て終えるまで」の 2 つの露出時間を減らし、4・5 で利用者ごとの影響と確認の手間を減らせます。

2 つの時間を、どこで減らすか

  1. 予告の段階（止めるか遮断するか）: 止めるか動かし続けるかを利用者が前もって選べる設定（Google Compute Engine のメンテナンス設定のようなもの）を用意し、動かし続ける利用者は WAF で攻撃のリクエストを遮断します。Cloudflare は今回、修正版の公開の 10 時間半ほど前に、PHP2Shell を遮断するルールを既定でオンにしています
  2. 配布元を待たない経路: ソースからビルドできるようにしておけば、パッケージを待たずに済みます。pixiv は公式イメージの公開を待たずにビルドする経路を用意していて、修正版に気づいてから 35 分で再開しました。Docker 公式イメージの更新がマージされたのは、その 1 時間後の 10/22 0:16 です
  3. サポート切れのバージョンへの備え: 古いバージョンほど修正に時間がかかりました。移行の期限を決めておくか、TuxCare のようなバックポートを使えるようにしておきます
  4. アカウントごとの実行環境の分離: 順番に当てると全体が終わるまで時間がかかります。mixhost が採用している CloudLinux には、アカウントごとに PHP を選べる PHP Selector があります
  5. 露出していた時間の利用者ごとの通知: 順番に当てた場合、全体の完了時刻だけでは自分のサイトがいつまで露出していたか分かりません。その利用者のサイトに外部からアクセスできた時間を知らせます

処理の流れにすると、次のとおりです。

危険な時間を減らす処理の流れ

必要な仕組みは、どれも既存の製品や機能にあります。これらをあらかじめ組み合わせておけば、作業の工程でどうしてもかかる時間があっても、外部にさらす時間は減らせます。

もっとも、いちばん強いのは、外部からアクセスできる公開側に PHP の実行環境（ランタイム）を置かないことです。前回の話のとおり、置かなければ、さきほどの対応の図に並ぶこともありません。

おわりに

脆弱性のある状態でサイトを外部にさらしていた責任はレンタルサーバー業者にあります。ただ、時間がかかったのは業者がいい加減だったからではなく、作業の工程や、利用者のサイトを業者だけでは止めにくい立場によるものです。そのうえで、前もって仕組みを組み合わせておけば、危険な時間はまだ減らせます。

一方で、自社でサービスとインフラの両方を持っていれば、止める判断もビルドの手順も自分で決められます。次の記事では、自前でサービスを動かしている会社のお知らせから、止めた時刻と戻した時刻、そこに至る経緯まで詳しく公開していた 3 社（GREE・pixiv・コドモン）を取り上げています。

10/27 時点の情報です。サイトの側から見た Tivo0921 さんの記事もあわせてどうぞ。

興味のある方の参考になれば幸いです。ご指摘は歓迎します。

参考文献

1
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?