こんにちは、岩﨑将史(まさふみ)です。
10月21日の夕方。
PHPに、危険度9.2の脆弱性が見つかったというニュースが流れてきました。
PHPは、WordPressを動かしている土台の言語です。
世界中のブログや会社のホームページの多くが、この上で動いています。
私の本業は作曲家・音楽プロデューサーですが、音楽関連を中心に自社と受託先を合わせて6つのWordPressサイトを管理しています。
今回は、どのサイトも一度も止めずに乗り切る事ができました。
本体の修正はサーバー会社がやってくれたので、私がやったのは「把握・決断・告知・確認」の4つです。
作曲家がサーバーまで見ている理由
私が管理しているのは、次のようなサイトです。
- 会社（株式会社フルハウス）の公式サイト
- 私の個人サイトと、このブログ
- 私がプロデュースしているアーティストのサイト
- 制作をお引き受けしたお客様のサイト
サイトは作って終わりではありません。
記事を書き、検索で見つけてもらい、問い合わせにつなげる。
そこまでが仕事です。
このブログもそうですが、アーティストのプロデュースにもWEBサイトは欠かせない。
また私がデジタルマーケティング関連の繋がりが多いこともあり、音楽とは関係のないサイトも知人の伝で頼まれていくつかケアさせてもらっています。
今回の問題は乗っ取られたら終わり。
早めに対応することにしました。
10月21日の夜：ニュースを見て、まず決めたこと
何が起きたのか
PHPの開発チームが、2件の重大な脆弱性を修正すると予告。
番号は CVE-2026-109618 と CVE-2026-109619。
危険度を表す CVSS の値は、どちらも 9.2。
9.0以上は「緊急」に分類されます。
欧州の機関（CERT-EU）は「リモートからプログラムを実行されるおそれがある」とみていました。
PHP 5以降の全バージョンが影響を受ける懸念がある、とも伝えられていました。
修正版の公開は、日本時間の21日23時。
詳しい中身は、その時まで伏せられていました。
エックスサーバーは管理画面を止めた
私のサイトは、すべてエックスサーバーにあります。
そのエックスサーバーが、21日の16時に管理画面を止めました。
止めたのは、契約者がログインする画面やサーバーパネルなどです。
サイトとメールは動いたままでした。
「予防的な安全対策」という説明です。
サイトは通常通りに見られるが、設定は何も触れない。
「止めずに備えて待つ」と決めた
そこでエックスサーバーの対応とメンテが終わるまで、やるべきことをやることにしました。
最初にやったのは、管理しているサイトの洗い出し。
私はサイトの一覧表（台帳）を作ってあります。
サーバー、PHPのバージョン、バックアップの有無まで書いてあります。
これを確認して穴がないのかを見ます。
1つだけ担当が私ではないサイトがあり、PHPのバージョンが古い事が確認できました。
これをまず最初に対応する次項に入れました。
次に、サイトを止めるかどうかの判断。
大手サービスは早め早めに一度停止するという動きが主流でした。
私の結論は「今回は止めない」。
理由は3つです。
- 悪用されたという報告はまだ出ていない
- サーバー会社が、修正を当てると表明している
- 止めれば、お客様の集客もその間止まる
ただし、23時以降のサーバー側の修正の結果次第では、サイトを外から切り離すと決めました。
ちなみに私の長男が大学で工学でデータサイエンスやセキュリティ関連を学んでいる真っ最中。
夜帰宅するなりに「大学のサーバーは全部、先生と学生で手分けしてポート閉じで切り離してきた」と。
大学など膨大かつ貴重なデータを扱うサーバーはその方が賢明だと思います。
受託先へは、その夜のうちに知らせた
クライアントのサイトの中には、サーバーの管理がクライアント側にあるものもあります。
私はそのサーバーに入れません。一部入れるものもありますが、技術的な責任を取る立場にはない。
そこで、この様なクライアントには早めに「知らせること」にしました。
各サイトやサーバーの情報を網羅したPDFのシートを作成し、今後予想される状況や取るべき対応を記載。
21日の20時過ぎには、クライアント担当者さんへ連絡しました。
10月22日：朝はサーバー、昼は静岡で本番
22日(木)は終日、演奏仕事の本番の日。
朝5時半。
会場へ向かう車の助手席で、作業を開始。
まずはエックスサーバーの「お知らせ」を確認。
修正版は予定どおり公開されていました。
エックスサーバーは、新しいPHPから順番に修正を当てていました。
バージョン8の対応はくると思っていましたが、7も対応済み。
そして驚いたのはこの後も5までは遡って対応していくというアナウンス。
エックスサーバー、流石です。
早速クライアント向けに「PHPとWordPressのバージョン一覧」を作成。
どのサイトから先に手を付けるべきか、優先順も明記し6時過ぎにクライアントへ送付。
静岡へ向かう車の中でした。
この日は、私がピアノとキーボードで参加しているバンド「Famille（ファミーユ）」の学校公演。
静岡県のとある高校にて。
8時45分に会場入り。
照明機材、音響機材をガッチリと組み、体育館を完全なライブハウスに仕立てます。
11時15分からリハーサルを行い、本番は13時30分から。
400人を超える生徒さんの前で演奏し、過去イチの熱狂の盛り上がりでした。
そんな私がステージに立っている裏側での、エックスサーバーの修正は進んでいました。
公式発表では、次の順で修正が当たっています。
| PHPのバージョン | 修正の適用が終わった時刻（10月22日） |
|---|---|
| 8.2〜8.5 | 6時45分 |
| 7.4〜8.1 | 12時 |
| 5.6〜7.3 | 14時 |
| 5.5以下 | 修正を作成・検証中（23日夕方の時点） |
私が管理しているサイトはすべて PHP 8.3 にしていましたので、本番の前に、修正パッチ当ては完了していたことになります。
10月23日の朝：管理画面が戻ってから確かめた3つ
本番明けの23日の朝。
サーバー管理画面にも入れるようになっており、3つの事を確かめました。
WAF：一度も設定していなかった
WAF(ウェブ・アプリケーション・ファイアーウォール)は、サイトへの怪しいアクセスを入口で止める仕組みです。
エックスサーバーでは、項目ごとにON・OFFを切り替えます。
開いてみると、全部のドメインで、全部の項目がOFFでした。
これは駄目です。
その場で、全部ONにしました。
おそらくチェック漏れで以前よりOFFになっていたと思われます。
折角の防衛機能も有効にしていなければ意味がありません。
PHP：いつの間にか最新版になっていた
PHPのバージョンを見ると、8.3.36 になっていました。
10月10日に私が切り替えたときは 8.3.33 でした。
自分では何もしていません。
エックスサーバーが、末尾の数字（マイナーバージョン）を自動で上げていたようです。
今回の修正も、この 8.3.36 に入っているとみています。
エックスサーバーは版の番号までは書いていませんが、時期がぴったり合います。
ただし、サイトを置いていない初期ドメインだけ、PHP 7.4 のまま。
サイトはないので、今回のタイプの脆弱性で狙われることはないが、古いものは残さない方が良いだろうということで、最新に切り替えました。
バックアップ：どこに、何日分あるか
最後にバックアップ。
エックスサーバーは、サイトのデータとデータベースを毎日自動で保存しています。
過去14日分まで戻せることを確かめました。
ただ、これはサーバー会社の中にあるバックアップ。
サーバー会社そのものに何かあれば、一緒に消える。
私の自社サイトは、プラグインでローカルと別のクラウドにもバックアップを取っています。
ところが受託先のサイトの1つに、それが入っていませんでした。
これは管理を社員に任せていたサイトです。
これは駄目なので、私の方で直ちに設定しました。
設定では1つつまずきました。
その話は別の記事にまとめています。
メンテ中の大手サイト達
この日は今回のfamille学校公演の請求書も作ろうとしました。
ところが…
高速道路のETCの利用証明を取ろうとしたら、サイトがメンテナンス中。
おそらく今回の件に対するメンテナンス。
ETCの利用証明と領収書が取れないと出張演奏料など請求ができない。
早く再開することを期待しています。
もう一つ余談ですが、夕飯にキーマカレーを作ろうと思いS&Bのレシピサイトを見たらこちらも「メンテナンス中」でみられませんでした。
S&Bは23日の夜に再開を確認
関係者の皆様お疲れ様です。
頑張ってください。
PHPだけではない：JavaとNode.js
同じ日に、別の話も入ってきていました。
1つはJava。
IPA（情報処理推進機構）が、Oracle Java の脆弱性について注意を呼びかけ。
もう1つはNode.js。
Node.jsも21日に、10件の脆弱性を修正した版を公開していました。
Node.jsは、ClaudeやChatGPTに外部ツールをつなぐ仕組み（MCP）の多くで使われています。
私も仕事でAIにMCPをつないでおり、「AI秘書」が仕事をするために欠かせないのがNode.jsなのです。
そこで、会社のMacを全台点検しました。
私のメイン機のNode.jsは、修正前の版ということで、すぐに最新版へ更新。
社員のMacでも、Node.jsの更新が要るものが見つかりました。
古いJavaの部品が残っていたMacもありました。
残りの数台も、順番に点検を進めています。
AIにMCPを入れている方は、Node.jsのバージョンの確認を推奨します。
長男に聞いた今回の脆弱性
22日の夜、長男が帰ってきて今回の脆弱性の内容を詳しく教えてくれました。
肝は「データをアップロードするときに、意図的にメモリを書き換えられること」。
これによりサーバーを乗っ取ることができるようになる。
ということでやはり危険度は最大と言ってよいのでは？と感じました。
ただし、実際に攻撃を成功させるのはとても大変とのこと。
攻撃する側にとっては大きな見返りがあるサイトでなければ割に合わないだろうと。
まとめ：サイトを預かる側として大事にしていること
3日間でやったことをまとめると、次の4つでした。
- サイト台帳を再整備：どのサイトが、どのサーバーで、どのバージョンか。見渡せるようにしておく。
- 止める基準を先に決める：慌てて止めない。でも、止める条件は決めておく。今回はサーバー側の対応が迅速だったので止める決断は必要なかった。
- すぐに知らせる：自分が触れないサイトほど、早く知らせる。アドバイザリーやWEBマーケティングのコンサルティング関連のクライアントには直ぐに現状と対応方法をお知らせした。
- 最新にして、確かめる：PHP・WAF・バックアップを再確認。有効になっているかまでみる。
今回の問題が明るみになったのは、公演本番日の前日の夕方。
そこから対応し、1日は本番、夜と翌日の対応。
久々に熱い3日間でした。
今回の件は、全国的にもこれで落ち着いてくると思います。
ただAI化したこの世界線。
この様な騒動の頻度が増えてくるかもしれませんね。
そうならないことを願いつつ。
今回はこの辺で。
ではまた。
コメント