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?

PHP2Shell で、対応をオープンにしている会社

1
Posted at

はじめに

2026 年 10 月 21 日に修正版が出た PHP の深刻な脆弱性 PHP2Shell では、修正版が出る前からサービスを止める会社も出るなど、緊急の対応が相次ぎました。

前回は、レンタルサーバー各社で、脆弱性のある状態で利用者のサイトに外部からアクセスできた時間を並べ、自前でサービスを動かしている所も 5 つ図に入れました。
前回の終わりに書いたとおり、自社でサービスとインフラの両方を持っていれば、止めるか、配布元を待たずに自分でビルドするか、いつ再開するかを、すべて自社で決められます。
今回は、自前で動かしている会社のうち、対応の経緯をオープンにしていた 3 社、GREE・pixiv・コドモンを紹介します。
自分たちで判断して手を動かし、その時刻や経緯を記録しているから、ここまでオープンにできるのだと考えています。

3 社がオープンにしていること

3 社とも、公式のお知らせやブログに次の 3 つを書いています。

  • サービスを止めた時刻
  • サービスを戻した時刻(一部だけ戻したのか、全部戻したのかも分けて)
  • 止めた理由が PHP の脆弱性であること

攻撃を避けるためにソフトウェアの名前を伏せる所や、始めた時刻だけをお知らせする所も多い中で、3 社はここまで公開していました。

3 社の止めた時間

PHP 公式は日本時間の 10/21 早朝、修正版を 23:00 に出すと予告しました(oss-security への投稿は 5:22)。実際に出たのは 30 分ほど早い 22:34 です(GitHub の security advisory の公開時刻)。

GREE

GREE はサービス全体を止めました。

  • 10/21 23:30 ごろ: サービス全体を止めて緊急メンテナンスを開始
  • 10/22 6:55 ごろ: メンテナンスを終了し、SNS や決済などを復旧(一部のゲームは復旧作業を続ける)
  • 10/22 15:30: 全体復旧の見込み(15 時ごろ)のあと、タイトルに「【復旧】」と付けてお知らせを更新

修正版が出てから 1 時間ほどでサービス全体を止め、7 時間半ほどで SNS や決済などのプラットフォームの機能から先に戻しています。

お知らせでは、PHP の脆弱性が公表されたことを受けてシステムの安全性を確保するための対応だと、理由を説明しています。使っているソフトウェアの名前を伏せずに示しています。

復旧作業が続いていた一部のゲームについては、各ゲームのお知らせを見るよう案内しています。全体の状況はこのお知らせ、個別のゲームは各ゲームのお知らせ、と案内先を分けています。

全体が復旧する見込みは 10/22 15 時ごろと示し、15:30 にはお知らせのタイトルに「【復旧】」と付けて更新しました。被害やデータの流出は確認されていないことも明記し、問い合わせフォームも案内しています。停止から一部の復旧、全体の復旧まで、段階ごとに時刻を追える書き方になっています。

pixiv

pixiv は修正版が出る前にサービスを止めて待機し、予定(23:00)より早く 22:34 に出た修正版を 22:41 に確認して、そこから 35 分で再開しました。
利用者向けのお知らせとは別に、公式ブログ(pixiv inside)に作業の時刻が分単位で残っています。

  • 10/21 19:00: 影響を受けうるサービスをメンテナンスモードにする
  • 22:41: 予定(23:00)より早く出た修正版(22:34 公開)を確認
  • 22:42〜22:56: コンテナイメージのビルド
  • 22:56〜23:16: Kubernetes へのデプロイ(ステージングでの確認を含む)
  • 23:16: メンテナンスモードを解除

35 分で戻せたのは、修正版が出る前に準備を済ませていたからです。
Docker 公式イメージのビルドスクリプトを使って、PHP のバージョンだけを差し替えられるようにしていました。公式イメージの公開を待たずに、ソースから自前でビルドする経路も用意していました。
Docker 公式イメージの更新がマージされたのは 10/22 0:16 で、pixiv が再開した 23:16 の 1 時間後です。配布元を待たずに自前でビルドしたことで、この 1 時間の待ち時間を減らせています。

またブログでは、メンテナンスモードが入っていないエンドポイントがあったことも課題として挙げています。今回は条件がそろっていただけで、毎回この手順で済むとは限らない、とも振り返っています。

コドモン

コドモンは、保育施設と保護者が使うサービスです。
修正版が出る 8 時間ほど前の 14:49 までに、対象となる全サービスを止めました。

  • 10/21 9:01: 社内で把握
  • 11:37: 23:00 の公開に合わせて、夜に止める方針で合意
  • 12:37: 情報が広まってきたのを受けて、前倒しで止めると決定
  • 13:00 ごろ〜14:49: 順に止め、全対象サービスの停止を完了
  • 22:38: 修正版の公開を検知
  • 10/22 3:22: 職員用の管理画面、保護者向けの連絡帳アプリなどを再開
  • 10/23 9:00: 最後まで止めていた所在確認アラートを再開

止めると決めた理由も書いています。お預かりしているお子さまの情報を守ることを最優先にした、という判断です。
一部のサービスだけ止める案、お迎えの時間まで動かす案、監視を強めて検知したら止める案も検討し、採らなかった理由を一つずつ書いています。

反省点も並べています。修正版が届く時刻が PHP の配布元ごとに違うことを事前に把握していなかったこと、作業と判断が深夜に集中したこと、予防のための停止だと利用者に伝わりにくかったこと、などです。

何を重視するかで、止め方は変わる

3 社とも自社で決められる立場でしたが、止めた時刻と戻し方はそれぞれ違っていました。コドモンは修正版が出る 8 時間ほど前の 14:49 までに、pixiv は出る前の 19:00 に、GREE は出てから 1 時間ほどあとの 23:30 ごろに止めています。

自分のサービスで同じ判断をするなら、何を重視するかで、次のように選び方が変わります。

何を重視するか 止め方 近い対応をした会社
利用者の情報を守ることを最優先 修正版が出る前に、日中でも前倒しで止める コドモン
止める時間を短くしたい 準備を済ませてから止めて待ち、出たらすぐ当てて戻す pixiv
公開まではふだんどおり動かし、戻すときは確実に 出てからサービス全体を止め、段階的に戻す GREE
  • コドモン は、お迎えの時間まで動かす案も比べたうえで、お子さまの情報を守ることを最優先にして日中に止めました。主要なサービスを 10/22 3:22 に戻し、残りの機能も翌日に再開しています
  • pixiv は、修正版をすぐ当てられるように準備してから 19:00 に止めました。修正版が出たあと自前でビルドして当て、23:16 に再開しています
  • GREE は、修正版が出たあとの 23:30 ごろにサービス全体を止めました。翌朝 6:55 ごろに SNS や決済などのプラットフォームを先に戻し、各ゲームの復旧はそれぞれのお知らせで案内しています

修正版が出る前から止めて安全を優先するやり方も、準備を整えて止める時間を短くするやり方も、公開後に全体を止めて段階的に戻すやり方もあります。唯一の正解はなく、サービスの性質と何を守りたいかで、選び方は変わります。

自分たちで決めて記録しているから、オープンにできる

3 社に共通するのは、サービスもインフラも自社で持っていることです。止めるかどうか、どこまで止めるか、いつ戻すかを、配布元やほかの会社の判断を待たずに自分たちで決められます。
自分たちで決めて自分たちで作業しているので、いつ何をしたか、なぜそうしたかを、自社の記録だけで正確に書けます。

  • GREE は、全体を止めるタイミングも、SNS や決済から先に戻す順番も自社で決めています。そのため、停止から一部の復旧、全体の復旧まで、段階ごとの時刻をそのままお知らせに出せています
  • pixiv は、Docker 公式イメージの更新を待たずに、コンテナイメージのビルドから Kubernetes へのデプロイまでを自分たちで動かしています。作業を自社で完結させているから、分単位の記録をブログに残せています
  • コドモン は、社内で把握した 9:01 から方針を変えた 12:37 まで、判断した時刻と理由を記録していました。自分たちで比較して決めているから、採らなかった案とその理由まで公開できています

判断から作業までが自社の中で完結していて、その記録も残っているから、ここまで具体的な時刻や経緯をオープンにできます。

前回のレンタルサーバーは、この点で条件が違います。インフラは業者のものでも、その上で動くサイトは利用者のものです。業者が利用者のサイトを止めれば、利用者の業務も止まるため、業者だけの判断では止めにくい事情があります。また、自前でビルドするのではなく配布元のパッケージを待つ構成なら、対応を始める時刻も配布元しだいになります。利用者との関係や作業工程の制約があるので、すべてを自社だけで決めて動ける 3 社と同じようにはいかない所があるのは仕方ありません。

おわりに

今回紹介した 3 社は、対応を自社で決めるだけでなく、サービスを止めた時刻と再開した時刻、そして PHP の脆弱性への対応であることを明記していました。さらに pixiv はビルドからデプロイまでの分単位の記録を、コドモンは方針変更の時刻や採らなかった案の理由まで公開しています。

自分たちで判断して対応し、その記録を残しているから、いつ止めていつ戻したかを正確に出せるだけでなく、判断や作業の経緯までオープンにできる。そこがこの 3 社の良さです。

本記事の情報は 10/29 時点のものです。

参考文献

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
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?