タグ: 情報公開

PHP2Shell緊急対応の記録（2）事前情報を読む――23時の公開に備えたhsBoxの一夜

PHP2Shell対応の記録・第2話。第1話以降の状況の更新、hsBoxの一夜、各社の「影響なし」「対応中」告知の読み方を、大手レンタルサーバーの例とともに整理します。

筆者：muller｜2026年10月23日朝時点の情報です

第1話をお読みいただき、ありがとうございました。

第2話では、次の3点を書きます。第1話以降の状況の更新と補足、hsBoxの一夜、そして各社の「影響なし」「対応中」という告知をどう読むか、です。筆者は、hsBoxの情報公開をお手伝いした立場です。

1. 第1話からの更新と補足

国内の状況（22日昼時点）

  • 停止やメンテナンスを告知した組織は、22日午前の時点で、piyologの集計では211になりました。第1話の54は、21日の22時台までの数字です。
  • 主なサービスは次々に戻っています。pixivは21日23時30分にメンテナンスを終え、コドモンは22日3時22分、BASEは8時に再開しました。以上はzephel01氏のnoteの整理によります。
  • 同じnoteは、この脆弱性で侵害を受けたと公表した国内の組織は、22日12時15分ごろの時点で確認できないとしています。止めたのは「やられたから」ではなく、「やられる前に」止めたから、という整理です。

海外の状況

  • watchTowrは、修正版の公開とほぼ同じころに、実際の悪用の試みを観測したと報告しています。ただし、成功した例は観測していません。CloudflareやPatchstackも、より早い時間帯から試行を観測しています（SecurityWeek）。
  • Amazonは、公開前の10月17日に最初の試行を観測したと、Greenboneがまとめています。ニュージーランドのNCSCも、悪用の報告を把握しているとしています（Greenbone）。
  • Cloudflareは、一般への公開の約9時間前に防御を配備していました（セキュリティ対策Lab）。
  • 米CISAの悪用済み脆弱性カタログ（KEV）には、22日の時点で、2件とも掲載がありません（watchTowr）。

つまり、攻撃の試みは公開前から来ており、悪用を観測したとするベンダーも複数あります。一方で、CISAのKEVには、22日の時点でまだ載っていません。修正版を当てていないサーバーが安全という意味ではありません。

第1話への補足

首相の投稿の時刻。 第1話では「報じられました」と書いた首相の投稿は、21時55分に公式Xへ投稿されたものです。国家サイバー統括室は、その11分前の21時44分に同じ趣旨を投稿していました。どちらも、修正パッチの適用が難しければ、ウェブサイトの一時停止も有効策の一つだと述べています（INTERNET Watch）。

修正版の公開時刻。 第1話では「22時台」と書きましたが、出典によって幅があります。多くの資料や、国内事業者の告知（エックスサーバーなど）は、予告どおりの23時（14:00 UTC）としていますが、AlmaLinuxは12:59 UTC（日本時間21:59）、CERT-EUは13:30 UTC（日本時間22:30）と記しています。php.netとGHSA本体の公開時刻は、筆者はまだ特定できていません。【要確認】

当初の予定。 調整済みの公開日は、もともと22日だったとされています。漏えいを受けて1日前倒しされ、21日の公開になったと、SOCRadarなどが書いています。

2. hsBoxの一夜

事前情報を読む

最初の情報は、事前に追っていた情報から得ました。【ウォッチ対象：普段どの情報源を見ているか】筆者の経験では、重い脆弱性の公表が近づくと、事前に何かしらの気配が漏れてくるもので、見慣れてくると察しがつくようになります。

今回は、もう一つ警戒材料がありました。昨今、AIの関与が疑われる不正アクセスが相次いでいる状況です。INTERNET Watchも、AIが24時間休まず手数を増やしていることを要因とみる声が多いと書いています。今回の脆弱性との関連があったかどうかは、後の検証に委ねます。ただ、警戒すべき事前情報の一つとして頭に置いていたことは、書き残しておきます。なお、攻撃の試みは公開前から始まっていたと報告されています（上の「海外の状況」を参照）。事前情報を追う意味は、そこにもあります。

23時からの動き

  • 23時過ぎ：予告されていた23時の公開を把握していたので、確認を始めました。hsBoxで修正版のパッチを適用できるかの検証にとりかかりました。
  • 23時30分：適用できることを確認しました。ただちに情報発信の作業に移りました。
  • 【時刻】：情報を公開しました。https://x.com/hoscm2025/status/2112923979010965921

検証の開始から適用確認までは、約30分でした。【検証の内容：環境、手順、確認した項目】

なお、修正版の公開は予告より早かったとする資料もあります（上の「第1話への補足」を参照）。hsBoxの動き出しは、予告の23時を基準にしたものでした。公式の予告にも、前倒しもあり得ると書かれていました。

情報を絞って、最速で出す

情報公開で一番重視したのは、速さでした。利用者が一番知りたいのは、自分の環境が対策済みかどうかと、何をすればよいかです。そこで、載せる情報を絞って発信しました。

  • 後から伝えた情報：情報の読み取りかたについて補足情報を追加。

判定の基準については、第1話で書いたとおり、リリースとパッケージ名をセットで示す必要があります。

リリース確認後の情報公開としては早かったほうではないだろうか。引き続きよろしくお願い致します。

3. 「影響なし」「対応中」という告知をどう読むか

今回は、多くの組織が告知を出しました。利用者や取引先は、その告知を読む側に回ったことになります。筆者が気になったのは、内容の差よりも、書き方の差です。特定の組織を評価する意図はなく、公開されている告知から読み取れたことだけを書きます。

「影響なし」には、根拠と時点が必要です

  • 根拠が書かれている例があります。はてなは、はてなブログとはてなCMSがPHPを使っておらず影響を受けないと発表しました（セキュリティ対策Lab）。ニコニコは、一部のサービスについて、影響を受けない技術構成だと説明しています（zephel01氏のnote）。LegalOn Technologiesは、11時15分の更新で、複数のサービスが影響を受けないと説明しました（セキュリティ対策Lab）。
  • 確認の範囲も大事です。自社が書いたコードだけでなく、依存しているソフトウェアや機器、委託先まで見ているかどうかです。たとえばPalo Alto Networksは、自社製品のPAN-OSとPanoramaにも影響があると公表しています（セキュリティ対策Lab）。PHPを使っていないつもりでも、機器の中にPHPが入っている場合があります。また、HTMLだけのサイトでも、同じサーバーにPHPが組み込まれていれば影響を免れない、とINTERNET Watchは指摘しています。
  • 「影響なし」と「被害は確認されていない」は別の話です。前者は構成の話、後者はログなどを調べた結果の話です。両方が書かれていると、受け手は判断しやすくなります。

「対応中」には、見通しと暫定策がほしい

  • KAGOYAは、事業者側ではサイトを止めず、PHP 8.2〜8.5の修正版への更新を調整中としました。その間の暫定策として、利用者にサイトの公開停止やアクセス制限の検討を案内し、被害は確認されていないとしています（22日10時35分時点、zephel01氏のnoteによる）。
  • 一方、ConoHa WINGやお名前.comの告知は「システムの保守作業」とあり、PHPという言葉が出てきません（zephel01氏のnote、セキュリティ対策Lab）。
  • 攻撃者に情報を与えないために、書き方を絞るという考え方もあるでしょう。ただ、利用者が自分のサイトへの影響を判断するには、PHPへの対応かどうか、適用済みかどうかが読み取れるほうが動きやすいと、筆者は感じました。
  • 正直に言えば、告知の時点で適用状況や見通しが読み取れない事業者については、利用者の立場で心配になります。ただし、遅れている＝怠慢とは限りません。顧客の環境が多様で、古いPHPには個別の修正が必要だからです。PHP公式は、サポートが終わった系列に通常のリリースを出していません。最小限のバックポートのソースが公開されただけです（Tenable）。そのため、エックスサーバーのように独自の修正を作る事業者や、mixhostのようにCloudLinuxの修正パッケージを使う事業者もあります。この話は第3話で扱います。

見通しを示した例：大手レンタルサーバーの告知

参考までに、レンタルサーバー大手のエックスサーバーの対応を、大まかに紹介します。

同社は、修正版の公開前から緩和措置を入れ、公開の数時間前にサービスサイトと管理画面へのアクセスを止めました。公開後は、公式の修正版や自社で作った修正を、新しいPHPから順に全サーバーへ適用しています。22日の早朝にPHP 8.2〜8.5、昼ごろに7.4〜8.1、午後の早い時間に5.6〜7.3を終えました。5.5以下は、告知の時点では検証中でした。管理画面は22日の朝から、サービスサイトは夜から、順次再開しています。

告知の良い点は、時系列を表で示し、適用が済んだ系列と済んでいない系列を分けて書いていることです。未完の部分を隠さず、利用者に追加の対策をお願いする場合があることも、先に書いています。見通しが読み取れる告知の例です。

利用者の運用管理者にとっては、その間、管理画面にも入れず、何もできない夜でした。ただ、共用サーバーのPHPは、もともと利用者が更新できるものではありません。提供者が全サーバーへ一括で、公式の修正がない古い系列まで手当てしてくれるのは、この形態の強みです。一方で、適用が終わるまでの間に不審な動きがなかったかを、アプリのログや管理者アカウントで確認することは、利用者側に残ります。

「誰が直すのか」は、立場によって変わります。共用サーバーなら提供者、VPSや自前のサーバーなら利用者です。この整理は、第3話で扱います。

受け手が告知を読むときの5つの視点

  1. PHPの脆弱性への対応だと明記されているか
  2. 適用済みか、調整中か、そもそも対象外か
  3. いつ時点の情報か
  4. 暫定策（アクセス制限など）が示されているか
  5. 被害の確認状況と、調べた範囲が書かれているか

深い考察は、状況が落ち着いてからにします。OSSのセキュリティを長く見てきた立場からの論点は、別稿でまとめる予定です。

4. 第2話のまとめ

  • 事前情報を追っていたから、23時過ぎにすぐ検証へ入れた
  • 最速で出すために、情報を絞った
  • 告知は、根拠・時点・範囲・暫定策を見て読む
  • 「誰が直すのか」で、利用者にできることが変わる

次回の第3話では、修正版が手元のサーバーに届くまでの距離を取り上げます。レンタルサーバー各社とLinuxディストリビューションの対応、サポートが終わったPHPの扱いに加えて、実際のサーバーで修正が入ったかを確かめる手順（版数、チェンジログ、再起動の確認）を整理します。

参考情報