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の扱いに加えて、実際のサーバーで修正が入ったかを確かめる手順(版数、チェンジログ、再起動の確認)を整理します。

参考情報

2026/10/21 PHP2Shell、眠れなかった夜(第1話)23時の約束――予告から修正版公開までの記録

筆者:muller|2026年10月22日時点の情報です

2026年10月21日の夜、PHPの緊急セキュリティリリースへの対応で、眠れなかったエンジニアは少なくなかったと思います。筆者は、hsBoxの情報公開をお手伝いする立場で、この夜を過ごしました。

あの夜、現場では何が起きていたのか。公式の発表、各社の動き、そして情報の読み方を、数回に分けて整理していきます。第1話では、予告が出てから修正版が公開されるまでの一夜を振り返ります。

1. 予告から公開まで(日本時間)

  • 10月20日(協定世界時):PHPのセキュリティチームが、重大な脆弱性2件(いずれもCVSS v4.0で9.2)を修正する緊急リリースを予告しました。公開は10月21日14:00(協定世界時)、日本時間の23:00です。詳細、影響バージョン、修正版は公開と同時に発表するとされ、詳細が先に公になった場合や悪用の証拠が見つかった場合は、前倒しもあり得るとも書かれていました。
  • 21日未明:Sansecによると、日本時間21日0:20ごろ、PHPのリモートコード実行の脆弱性2件がまもなく開示される、という投稿がHacker Newsに現れ、のちに削除されました。watchTowrは、エンバーゴ下にあった情報が漏えいし、実在すると確認できたと発信し、2件をCVE-2026-109618とCVE-2026-109619だと指摘しました。
  • 21日日中:CERT-EU、オーストラリアのASD/ACSC、IPA、国家サイバー統括室などが、注意喚起や事前準備の呼びかけを出しました。IPAは、PHPを使うシステムの棚卸し、公式情報の注視、公開後すぐに適用できる体制づくりを挙げています。
  • 21日14時ごろ:GMO Flatt Securityが、緩和策として挙げていたsession.upload_progress.enabled=0は、攻撃自体を防げない見込みだと見解を改めました。同日、この脆弱性を悪用できると主張するコードがネット上に出回り始めたとも記しています。
  • 21日15時台から:国内サービスの停止や緊急メンテナンスが始まりました。BASEは15:50から、厚生労働省の介護サービス情報公表システムとエックスサーバーのサービスサイトおよび管理画面は16時から止まっています。夜にかけて広がり、22時台までに告知が確認できた組織は54に達しました。
  • 21日夜:首相が公式Xで、今夜の対応を呼びかけたと報じられました。
  • 22時台〜23時:修正版のPHP 8.5.12、8.4.27、8.3.36、8.2.35が公開されました。【要確認:公式アドバイザリやCVEレコードは、予告の23時より前の22時台に公開されていたとする記録があります。正確な時刻はphp.netとGHSAのタイムスタンプで確認します】

2. 「事実」と「見立て」を分けて読む

昼の時点で、公式が明らかにしていたのは、「2件」「CVSS 9.2」「23時リリース」の3点だけでした。CVE番号、リモートコード実行であること、PHP 5以降に影響しうるという範囲は、研究者や公的機関の見立てに基づくもので、開発元が確認したものではありませんでした。IPAも、影響バージョンは確認できていないと断った上で、CERT-EUの注意喚起を紹介する形をとっていました。

のちに公開された公式アドバイザリでは、CVE-2026-109618はメモリ不足時の処理に起因する破損、CVE-2026-109619は解放済みメモリを指す状態が残る問題と説明されました。影響を受けるのはPHP-FPM、mod_php、php-cgi、FrankenPHP、LiteSpeedで、なかでもmod_phpが最も危険とされています。緩和策については、公式は特定の攻撃経路を減らすだけで、更新が唯一の安全な選択肢だとしています。

つまり、夜のあいだに出回った情報の多くは、あとから「当たっていた部分」と「評価が変わった部分」に分かれました。緩和策の評価が14時に変わったのはその一例です。情報を追うときは、誰が、いつ、何を根拠に言っているのかを、時刻付きで切り分けておく必要がありました。

3. 止まった国内サービスと、その判断

piyologの集計では、22時台までに各社の告知で確認できた停止・メンテナンスの組織は54でした。サービス全体を止めたところ、管理画面や新規受付など一部だけ止めたところ、自社サイトだけ止めたところに分かれます。たとえばエックスサーバーは、サービスサイトと管理画面を止めた一方、利用者のサーバーは稼働を続けると案内しました。Cygamesのように、23時の予定より前倒しで止めたサービスもあります。

なお、この数字には注意書きがつきます。個人のアカウントの告知やBASEの出店者の措置は数えておらず、告知にPHPと明記していない組織も含まれています。

ここで強調しておきたいのは、停止は侵害を意味しないということです。多くは、修正版を当てるまでの予防的な措置でした。

筆者の見立てですが、停止が一気に広がった背景には、14時に緩和策の限界が示されたことと、実証コードの流通が伝えられたことがあったのではないでしょうか。設定変更で粘って23時を待つより、いったん止めて修正を待つほうが、説明のつく判断になっていたはずです。

4. hsBoxの一夜

hsBoxも、昨夜、利用者向けに情報公開を行いました。筆者は、文面の確認、技術面の確認、公開作業などでこの公開をお手伝いしました。

公開した内容は次のとおりです。

確実な適用方法と確認方法を重視してできるだけ即座に適用できる方法を公開する方針で対応するようにコメントしました。パッチ適用検証にて日本時間2026/10/21 23:50ころには適用方法と適用確認方法について確認できたので情報公開しました。

5. 番号だけでは判断できない:Ubuntuの例

hsBox 1.4はUbuntu 26.04 LTSをベースにしています。Ubuntu標準のphp8.5パッケージであれば、「8.5.4-0ubuntu1.5以降なら対策済み」という案内が成り立ちます。

ただし、この一文が成り立つのは、Ubuntu 26.04 LTSのphp8.5に限られます。Ubuntuの公式情報では、修正版は次のようにリリースごとに異なります。

  • 26.10:php8.5の8.5.9-0ubuntu2.1
  • 26.04 LTS:php8.5の8.5.4-0ubuntu1.5
  • 24.04 LTS:php8.3の8.3.6-0ubuntu0.24.04.13
  • 22.04 LTS:php8.1の8.1.2-1ubuntu2.28

Ubuntuは修正を元の版に取り込む(バックポートする)ため、php -vの表示がPHP公式の修正版(8.5.12など)と一致するとは限りません。26.04 LTSの基準を26.10にあてはめると、未修正のパッケージを対策済みと誤判定するおそれもあります。利用者に伝えるときは、「Ubuntuのリリース」「パッケージ名」「版数」をセットで書くのが安全です。

もう一点、パッケージを更新しただけでは対応は終わりません。PHP-FPMやApacheなどを再起動して、はじめて修正版が動きます。

6. 第1話のまとめ

  • 公式発表は最小限で、残りは各社の見立てだった。時刻付きで追い、「いつ・誰が・何を根拠に」を切り分ける
  • 国内の54組織の停止は、予防的な判断が中心で、侵害を意味しない
  • 修正済みかどうかは、番号だけでなく、ディストリビューションとパッケージの条件で確認する

次回の第2話では、昨夜の対応を書き残した人たちの記録を読みます。続く回では、修正版が手元のサーバーに届くまでの距離、そしてAIが見つけた脆弱性という背景を取り上げる予定です。

参考情報

  • The PHP Group「Upcoming Critical PHP Security Release」:https://www.php.net/archive/2026.php
  • piyolog「修正予告されたPHPの2件の深刻な脆弱性についてまとめてみた」:https://piyolog.hatenadiary.jp/entry/2026/10/21/174516
  • GMO Flatt Security Blog「PHPの重大な脆弱性「php2shell」の概要と対応指針」:https://blog.flatt.tech/entry/php2shell
  • IPA「【事前準備のお願い】PHPのセキュリティリリース公開予定について」:https://www.ipa.go.jp/security/security-alert/2026/pre-alert20261021.html
  • CERT-EU「Critical Vulnerabilities in PHP」:https://cert.europa.eu/publications/security-advisories/2026-018/
  • ITmedia NEWS「PHPの「緊急」レベルの脆弱性、開発元が修正バージョン公開」:https://www.itmedia.co.jp/news/article/2610/22/2000002480/
  • Ubuntu Security「CVE-2026-109618」:https://ubuntu.com/security/CVE-2026-109618
  • Ubuntu blog「php2shell vulnerability fixes available」:https://ubuntu.com/blog/php2shell-vulnerability-fixes-available
  • PHP公式アドバイザリ(GitHub):https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w および https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp

WordPress 5.3 Betaリリース、 旧版へのセキュリティパッチは?

2019年9月23日にWordPress5.3Beta1がリリースされていますが、旧版へのセキュリティパッチの情報は特にありません。WordPressは新版をリリースするときは1か月くらいかけて毎週のように更新版を出してきます。開発のほうに力を入れていて、セキュリティへの対処へ使うパワーがあまりない感じがします。
セキュリティ対処は外部の人の力に頼っていて、自己対処ができていないのではないかと思われます。このような状態では、新規開発部分に作りこまれる脆弱性は減らず、脆弱性がどんどん増えていく状態になるのではないでしょうか?

さて、追加でWordPress 5.2.3 で対処された脆弱性について確認します。 影響度と影響範囲の情報について追加情報が出ていますが、あまり詳しくありません。 CVE-2019-16220 (JVNDB-2019-009141)の場合、影響バージョンは WordPress 5.2.3 未満 となっています。該当機能が、初期バージョンから存在するのか疑問ですが、該当機能はかなり以前からあるので事実上すべてのバージョンに影響があるといってもよいのかもしれません。それから9/12の午後以降にJVNの情報公開がされていました。今後のセキュリティパッチはWordPress5.3に対して提供されることになると思われるので、どのタイミングでWordPress5.3に上げるのか、検証計画を立てておくなど検討しておいたほうがよさそうです。

WordPress セキュリティパッチのみ自動適用するには

 WordPressのセキュリティパッチに関して検討および対処してきましたが、多数のプラグインの利用とWordPressのパッチリリースのスタンスや情報公開の仕方を考慮してパッチリリース状況の監視と適用の手順を見直しました。
 セキュリティパッチのみを適用するということが、WordPressの場合は「セキュリティ修正が含まれているのにメンテナンスパッチ」となっていたり、「プラグインのセキュリティ問題の対処をセキュリティ修正としない」とされていたりする状況からあまり妥当でないとなっていると判断しました。

つまり、ポイントは次の2点です。
・WordPressがいうところのメンテナンスリリースとセキュリティリリースとを区別して別の取り扱いをする意味はあまりない。メンテナンスリリースとされていてもセキュリティの対処が含まれている場合がある。
・ メンテナンスリリースとセキュリティリリースのどちらも適用しないと問題があるかどうかを確認できない場合がある。

以上の状況から、つぎのようにします。

「テスト用サイトを立ち上げておいて、テスト用のサイトについてはパッチを自動適用する設定にしておく、パッチ適用のメールが来たら動作確認を行い、本番環境に適用するかどうかを吟味し適用手順を確立したうえで適用作業を行う。」

WordPress 5.2.3 セキュリティパッチの適用

2019年9月5日にリリースされたセキュリティ&メンテナンスパッチWordPress5.2.3について書きます。 wp-config-sample.phpが更新されていましたが、動作に影響がある変更はなく実質的には気にする必要はありませんでした。5.2.1のように白画面になることもありませんでした。
 しかし、” Page Visit Counter ”がエラー(具体的に何のエラーなのか情報がない)で止まっていました。この停止問題はプラグインを設定ページで有効化することで解決しています。

WordPress 5.2.3 で対処された脆弱性について確認します。 WordPressのサイトの情報では1件ごとに明確にされるべき影響度とか影響範囲の情報がなく、問題検出者への感謝?の公開の場でしかありません。何とかしてほしいが、他のサイトで確認してみましょう。 9/12時点でJVNのほうにはまだ登録されていないように見えます。NVDの情報では、つぎの7件がWordPress5.2.3で対処されたことが分かります。

CVE-2019-16223WordPress before 5.2.3 allows XSS in post previews by authenticated users.
CVE-2019-16222WordPress before 5.2.3 has an issue with URL sanitization in wp_kses_bad_protocol_once in wp-includes/kses.php that can lead to cross-site scripting (XSS) attacks.
CVE-2019-16221WordPress before 5.2.3 allows reflected XSS in the dashboard.
CVE-2019-16220In WordPress before 5.2.3, validation and sanitization of a URL in wp_validate_redirect in wp-includes/pluggable.php could lead to an open redirect.
CVE-2019-16219WordPress before 5.2.3 allows XSS in shortcode previews.
CVE-2019-16218WordPress before 5.2.3 allows XSS in stored comments.
CVE-2019-16217WordPress before 5.2.3 allows XSS in media uploads because wp_ajax_upload_attachment is mishandled.

9/11にDBに登録されたばかりで影響範囲など詳しい情報はまだありませんでした。

想像ですが、9/12時点で過去バージョンに対してセキュリティ修正のみ(WordPress5.1.2?)を提供しようと準備しているように見えます。5.2.3のリリースには「In addition to the above changes, we are also updating jQuery on older versions of WordPress. This change was added in 5.2.1 and is now being brought to older versions. 」の記述があります。しかし明示的には5.1.2について特にアナウンスしているようには見えないので、本当にリリースされるかはわかりません。どうしても欲しければチームに入って推進すればよいかもしれません。

WordPress 5.2.2の後に特に情報なし?

WordPress 5.2.2はセキュリティ修正のようなリリースのされ方でしたが、7/4時時点でWordPressのサイトでは5.2.2はメンテナンスリリースとしかかかれていません。ほかのOSSの情報公開のタイミングを参考にして後から公開されるものとして書いていました。ここでは、過去のWordPressセキュリティ公開タイミングを再確認して、5.2.1、5.2.2がどうなのかを推測してみます。

 直近のセキュリティ修正5.1.1と5.0.1についてみます。

 WordPress5.1.1
・WordPressサイトでの5.1.1リリース日 2019/3/12
・WordPressサイトでの5.1.1セキュリティ情報公開日 2019/3/12
・JVNへの5.1.1(CVE-2019-9787)の情報登録日 2019/4/10 約1か月後

 WordPress5.0.1
・WordPressサイトでの5.0.1リリース日 2018/12/13
・WordPressサイトでの5.0.1セキュリティ情報公開日 2018/12/13
・JVNへの5.0.1(CVE-2019-8942)の情報登録日 2019/4/1 約3か月後

その他(CVE-2019-8943(5.0.3まで?))
・→ まだパッチが公開されていないとされている(2019/7/4時点)

パッチ公開とほぼ同時に脆弱性情報が公開されるパターンもあれば、パッチがない脆弱性情報が公開されるパターンもあります。 CVE-2019-8942 についてはWordPressサイトの セキュリティ情報公開日 しているものがWordPress5.0.1のリリース日でしかなく、JVNへの登録日の直前に情報公開されたのなら、パッチリリルースの3か月後に脆弱性情報が公開されたことになる。このようにいろいろなパターンがあるので、5.2.1も5.2.2もいずれも今後セキュリティ情報が公開される可能性がまだ残っているということになりそうです。  もしもそうなら、CVE-2019-8943 は5.2.1で修正されていたということなると推測します。


WordPress 5.2.2の修正内容 と脆弱性  

WordPress5.2.2のことを書く前に、以前に書いたWordPress脆弱性で完結できていないものを再確認します。
まず以前に書いたCVE-2017-6514について書きます。JVNのDBには2019/6/6に登録されています。これは私がここに投稿した日より2週間ほど遅い。JVNの情報から修正内容など新たに分かる情報はありませんでした。最近の動きは6/14にある脆弱性チェックツールで検出できるように強化されたことが情報公開されています。このタイミングでの情報公開なのでWordPressの修正コードなどの情報をもとにチェックルールを作成したものと推測されます。まだWordPress側では脆弱性情報が公開されていません。現在関係機関と公開に向けて調整しているのではないかと推測します。
つぎに、WordPress5.2.1の修正情報の再チェックです。前回チェックしたときに内容チェックに終始して、後で更新されることは想定していませんでした。ぱっと見た範囲では、変わっていません。この状況だと更新される可能性がありそうです。
さて、本題のWordPress5.2.2の修正内容についてです。13件のバグ修正とWordPress5.2で追加したサイトヘルス機能をちょっと更新したとリリース情報には記載されています。

#45094 #46289 #46997 #47227 #47429 #47558 #47475 なし

#46749 4.3

#46881 #46957 #46960 #47070 #47158 5.2

作り込みバージョンの記載がないもの7件、4.3が1件、5.2が5件です。
バージョンの記載がないものの修正内容は次ように、脆弱性に関係しそうな記述はありませんでした。
#45094 ダッシュボードのいくつかのエレメントでフォーカスされない
#46289 メディアモーダルでのナビゲーションアローのリンク先間違い
#46997 テーマの更新でリンクが動作しない
#47227 サイトヘルスタブの文字列修正 → 5.2での強化分の修正
#47429 更新パッケージ
#47558 更新ページのアップデート → 5.2.2で勝手にアップデートした件でしょう
#47475 typoの修正

脆弱性に該当しそうな修正内容の情報はありません。5.2.2は”セキュリティ更新”として更新が自動適用されたり、修正公開の事前情報など脆弱性対処をしたりした状況と推測される状況なので、セキュリティ修正がリポジトリには登録されたソースコードはあるが、公開された修正項目には情報がないという状態だと思われます。
 以上の状況から、別途公開済みの5.2.2か5.2.1で修正された脆弱性情報が後日公開されるものと推測されます。


それから、サービス停止を引き起こしかねないアップデートを勝手に適用するというはそれ自体がDOSの脆弱性と言ってしまってもよいのではないでしょうか。サービス停止したことを自動検知して自動リカバリするとかいろいろな対処がありそうです。

なにー、WordPress5.2.2。 やってくれたな。

どこかで、自動アップグレードする設定とかあったのでしょうか?  更新ボタンも押していないのに「WordPress5.2.2にアップグレードした」とメールが送られてきた。たしかに、WordPress5.2.2 が6/18にリリースされていて、  https://wordpress.org/news/2019/06/wordpress-5-2-2-maintenance-release/  このサイトにも勝手に適用されていた。
 ”更新”の記載には「最新バージョンの WordPress をお使いです。 今後のセキュリティ更新は自動的に適用されます。」と書かれている。 これを信じるならば、まだ セキュリティ情報は出ていないが 5.2.2で脆弱性の対処が行われたのでしょう。
以前に予想したとおりの状況ですが、勝手に修正を適用されてしまうのは想定外でした。 5.2.1の時みたいにセキュリティ強化した権限設定の影響でサービスダウンしてしまったらどうしてくれるつもりでしょうか。その辺の不満を越える危険をはらんだ問題だというならわからなくはないが、この仕掛けを基盤にして業務用に使用しているところは沢山あります。業務が止まったら大変なことになります。この辺を踏まえて設定で自動適用するかとか自動適用する脆弱性の深刻度レベルを設定できるようにするとか、工夫してほしい。

WordPress5.2.2の修正内容をチェックはまた明日。

WordPress脆弱性 、対処するも白画面そして解決 

WordPress脆弱性はプラグインでの新たな情報が出ていますが、本体とこのサイトで使用しているプラグインについての新たな情報はありませんでした。代わりといっては何ですがWordPress5.2.1の修正内容をチェックしました。重要な修正の内容は5.2で作りこまれたバグの修正でしたが、他の修正内容も確認しました。

5件は作りこみバージョンの情報がないもので、6件はWordPress5.1.1以前が作りこみバージョンのもの、それ以外はWordPress5.2で作りこまれたものです。作りこみバージョンがWordPress5.1.1とされた修正で、”jQuery Update 3.4.0”のアップデートがありました。これはWordPressで作りこんだバグではありませんが、jQueryでは”vulnerbility”とされているので、WordPressもこの脆弱性の影響があると判断したほうが良いでしょう。これは、 jQuery 3.4.0で対処された CVE-2019-11358 のことでしょう。ということでWordPress5.1.1も、 jQuery におけるクロスサイトスクリプティングの脆弱性の影響を受けるということなので、コメントを介して攻撃を受ける可能性があると判断し、WordPress5.2.1に更新します。

WordPress5.1.1から5.2.1にアップデートしましたが、 困ったことに 更新処理の途中で失敗し白画面となってしまいました。管理画面も白画面となり対処不能となったので仕方なくバックアップから書き戻していったん復旧しました。 類似の事象がないかチェックしましたがほぼ同じパターンのアップデートが成功していそうな情報がありました。違う条件はPHPのバージョンでした。そこで、PHP5.6をPHP7.2に上げて再度確認しましたが、アップグレード途中で失敗し白画面(500エラー)になる問題が再発しました。5.2.2で対処されることを期待して5.2.2を待とうかと思いましたが、うまくアップロードができている事例があるので、ログとかを見て調査することにしました。

まず、画面内容を再確認。

wordpress-5.2.1.zip から更新をダウンロード中…
更新を展開しています…
展開したファイルをチェックしています…
最新版をインストールする準備をしています…
メンテナンスモードを有効にします…
必要なファイルをコピーしています…
メンテナンスモードを無効にします…
更新が必要な翻訳が一部あります。更新が終わるまでしばらくお持ちください。WordPress (ja) の翻訳を更新しています…
翻訳が正常に更新されました。
ファイルをコピーできませんでした。: wp-admin/site-health.php
インストール失敗
WordPress のご利用ありがとうございます。 バージョン 5.1.1

インストール前の状態で、” site-health.php ”のファイルは存在しないので、ファイルを書き込み出来ていないのが原因でしょう。 wp-admin/ のフォルダの書き込み権限がないのでそれが原因でしょう。セキュリティ強化としてこのフォルダの書き込み権限を落としていました。書き込み権限を付加して、再度WordPress5.2.1へのアップグレードを行うことでアップグレードに成功しました。 アップグレード後は ” site-health.php ”などのファイル が作成されていました。書き込み権限を落として作業完了しました。

WordPress5.2.2については次回チェックします。5.1からのバグの修正があります。現時点では優先度はいずれもNormalなので近く公開されようとしている理由となっている修正はこの一覧にはないのかもしれません。

バージョンアップ情報、脆弱性情報の自動チェックを正式運用開始

先に書いた「Webページの更新内容自体が、動的更新によるものかどうかを自動チェックして、通知するかどうかを切り分けるように強化」の完了し、うまく機能することが確認できたので、正式に運用を開始しました。また、「日本語でのメール送信」機能も組み込んだので見やすく、作業効率が改善しました。今後、新たなソフトウェアのチェックが必要になったときにチェックルールをメンテナンスしていきます。