どうもTORAです。
2026年10月21日、PHPの重大な脆弱性への対応で、僕も会社のWordPressサイトを一時的に非公開にして止めました。ITエンジニアとして、この日の顛末を書き残しておこうと思います。
PHPは、Webサーバーの側で動くプログラミング言語です。WordPressはこのPHPで動いていて、WordPressで作られたサイトは世界中にたくさんあります。うちの会社のホームページもWordPressで、レンタルサーバーを借りて運用しています。つまり、裏ではPHPが動いている。僕と今回の件の関わりは、ここです。
厄介だったのは、WordPressのプラグインのような個別のソフトではなく、PHPを動かす本体のほうに穴があったことです。PHP公式のセキュリティ告知によると、穴はCVE-2026-109618とCVE-2026-109619の2件です（CVEは、脆弱性ごとに振られる識別番号）。どちらも、PHPがメモリ不足やエラーを処理する途中の不備です。中途半端な状態の内部データを正しいものとして扱ったり、解放済みのメモリを指す情報が残っていて、後のリクエストで使われてしまったりします。
その結果、認証なしで外から任意のコードを実行されるおそれがあり、深刻度の指標（CVSS v4.0）は10点中で9.2でした。修正版より前のPHPでWebのリクエストを処理していれば、基本的に対象です。攻撃が成立する条件は構成によって違いますが、特にApacheのmod_phpという構成では、WordPressのようなアプリのコードが動き出す前に攻撃が成立することも実証されています。
ざっくり言えば、PHPを使っているだけで狙われる可能性がある。下手をするとサイトを乗っ取られて、気づいたときには攻撃に使う何かを埋め込まれている、ということもあり得る危険度でした。「PHP2Shell」という呼び名で見かけた人もいるかもしれません（JPCERT/CCの注意喚起の参考情報にも、この名前の資料が挙がっています）。
社長からの連絡
21日は、日本でも異例のことが起きました。ITmedia NEWSの10月22日の記事によると、高市首相が21日の夜10時前に自身のXで、修正パッチをすぐ適用できるよう準備してほしいと呼びかけたそうです。すぐに当てられない場合は、Webサイトなどを一時的に止めることもリスクを下げる有効策の一つ、とも書いていたとのこと。首相が個別のソフトウェアの脆弱性についてXで直接呼びかけるのは異例だと、記事にもありました。日本の総理大臣がITのことでこういう緊急の発信をするのは、僕の記憶にはないです。
たぶん世界中そうだったと思いますが、僕も「うわっ」となりました。うちの社長もニュースを見たようで、PHPを使っているところがあれば緊急で止めてくれ、と連絡が来ました。僕もちょうどニュースを見ていたところだったので、すぐ止めますと返して、会社のコーポレートサイトを一時的に非公開にしました。
止めるといっても、やり方には気をつけたいところです。WordPressの「メンテナンス中」の表示のように、PHPが動いたまま画面だけ切り替える形だと、それだけで今回の攻撃を防げるとは言えません。さっき書いたとおり、構成によってはアプリのコードより前の段階で攻撃が成立するからです。
WordPress公式のお知らせにも、こう書かれていました。PHP 8.2より前の版で動くサイトで、自分でサーバーを管理している場合は、新しいPHPへ上げる準備ができるまでサーバーをオフラインにすることも考えるように。英国の国家サイバーセキュリティセンターの助言も引用されていて、すぐに直せないならシステムをオフラインにすることも検討すべき、という内容でした。
公表は一日前倒しになっていた
僕の感覚だと、事の発端は21日の発表でした。ただ、この脆弱性自体は21日に突然見つかったものではありません。PHP Foundationの経緯説明によると、修正は事前に準備が進められていて、もともとは10月22日に一斉に公開する予定でした。
それが、公開予定のおよそ2日前に崩れます。日本時間で並べるとこうです。
- 10月21日 0時ごろ：2件のCVE番号が、ネットの掲示板やSNSで出回り始める。間違った公開時刻と、CVSS 10.0という誤ったスコア付きだった（実際は9.2）。技術的な詳細は漏れていない
- 4時30分：PHP側が事前告知を前倒しで出し、修正版の公開を22日23時から21日23時へ1日早める
- 5時ごろ：報告していたセキュリティ企業の一社が、攻撃の実証動画を誤って公開。動画は削除されたが、コピーがSNSで出回る
- 16時41分：事前に修正を受け取っていた配布元の一社が、一斉公開を待たずに修正入りのビルド済みイメージを公開
- 22時前：高市首相がXで呼びかけ（報道による）
- 23時ごろ：PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 が公開される
- 10月22日：JPCERT/CCが注意喚起を公開
番号が出回ってから修正版が出るまで、使う側はほぼ丸一日待つしかなかったわけです。
メンテが明けても、すぐには戻せない
僕の使っているレンタルサーバーでは、21日の夜23時から緊急メンテナンスに入りました。メンテは翌朝くらいまで続きました。朝に一区切りついてからもしばらくはメンテ状態のままで、機能が順番に開放されていきました。最初は管理ページのファイルマネージャーが使えるようになったり、という感じです。サーバー側の対応は、ひとまず終わっています。
じゃあメンテが終わったからサイトを再開、とはいかないんです。PHPのバージョンをただ上げればいい、という話でもなくて。いや、もちろん上げればいいんですけど。WordPressのサイトだと、新しいPHPの上でWordPress本体やテーマ、プラグインがちゃんと動くかが問題になります。で、WordPressとPHPで作ったいろんなサイトって、そこまでちゃんとメンテされていないものが多いんですよね。
うちの会社もそうで、数年前にサイトを作り直してから、特に害もないからと、PHPのアップデートはちょっとサボっていました。なので、このときのPHPは古いままでした。
ここは混同しやすいので分けておくと、今回の穴を直すのはPHPの更新です。WordPress公式のお知らせでも、この件はWordPress特有の問題ではなく、WordPressの更新は必要ないし予定もない、とされています。WordPress本体やテーマ、プラグインを新しくするのは、新しいPHPへ移ったときにサイトがちゃんと動くようにするための準備です。
WordPress公式のPHP更新の案内では、事前の準備としていくつかの流れが紹介されています。サイトのバックアップを取ること。WordPress本体とテーマ・プラグインを更新して、サイトが動くか確かめること。互換性チェック用のプラグインで、テーマやプラグインに問題がないか調べること。ただ、チェック用のプラグインには見落としや誤検知もあると書かれているので、それだけで安心はできません。
もう一つ、ホストのメンテが終わったことと、自分のサイトが修正済みのPHPで動いていることも別の話です。レンタルサーバーでは、PHP本体の修正版を用意するのはサーバー会社です。利用者の側では、サーバー会社の案内と、自分のサイトが実際にどの版のPHPで動いているかを確認します。サイトごとにPHPのバージョンを選ぶ仕組みのサーバーも多いと思うので、サーバー側で修正版が用意されても、サイトが古い版を選んだままなら、修正の入っていないPHPで動いている可能性があります。
WordPress公式も、ホストがPHPの更新や防御ルール（WAF）の追加を進めているかもしれないけれど、ホストの案内は自分でも確認して、必要ならすぐにPHPを更新するように、と書いています。今動いているPHPのバージョンは、WordPressの管理画面で「ツール」→「サイトヘルス」と開き、「情報」タブの「サーバー」の項目で確認できます。ホストの管理パネルに出ていることも多いです。
PHP 8.1以前は、PHPプロジェクトの通常の更新対象から外れています。今回は深刻さを考えて、7.4・8.0・8.1向けにも最小限の修正がソースの形で出されました。ただ、これは通常の更新版ではなく、ソースからビルドする場合などに使う最小限の修正です。レンタルサーバーで使っているなら、サーバー会社がどう対応しているかを確認しながら、サポートされている版へ上げていくことになります。8.2も、2026年12月31日でセキュリティ修正が終わるとPHP公式で告知されています。
このときの予定は、新しいPHPのバージョンにしたときにサイトがちゃんと動くかをチェックして、問題ないことを確認してから、バージョンを上げてサイトを再開する、という感じでした。中身はほとんど普通の静的なコンテンツで、動くものといっても問い合わせフォームがあるくらいです。WordPressの場合、見た目が静的なページでもPHPが組み立てて表示しているので、確かめるのはフォームだけではないんですが、動かなくなることはないと思っていました。とはいえ、チェックしてからじゃないと再開はできないなと。
それから、修正版に上げたら全部おしまい、でもありません。JPCERT/CCの注意喚起は、修正版の適用とあわせて、攻撃を受けていないかの調査も求めています。確認する点として挙がっているのは、たとえば次のようなものです。
- 異常に長かったり形がおかしかったりするセッション用のCookie（PHPSESSID）が返されていないか
- ファイル送信などに使う形式（multipart/form-data）の不審なリクエストが来ていないか
- そうしたリクエストの前後に、メモリ上限のエラーやHTTP 500エラーが出ていないか
ただし、痕跡が見つからなくても、攻撃を受けていないとは言い切れないそうです。不審なプロセスや外部への通信、不審なファイルがないかも確認して、疑わしければログなどを保全したうえで対応するよう勧めています。
AIは守る側でも使われていた
ハッカーたちがAIを使いまくって攻撃してくる時代になっちゃったので、こういうことはしばらく続くんだろうなと思っています。
一方で、今回の脆弱性は、見つけて直す側でもAIが使われていました。Google Cloudの公式ブログによると、公表に関わったWizの研究チームは、複数のAIモデルを使って脆弱性を突き止め、修正を手伝ったそうです。中でもGoogleのGemini 4 Argonは、次の作業に大きく貢献したと書かれています。
- 脆弱性の発見
- 攻撃が成立するかを確かめるコードの開発
- 攻撃の検知
- 修正パッチの検証
今回の件で実際の被害がどこまで出たのかは、僕にはまだ見えていません。いつこういうのが収束していくのかも、まだ分からないです。
2026年10月21日は、AI時代のセキュリティの課題を目の当たりにしたというか、世界中がそれを認識した日だったと思います。僕にとっても、記憶に残る一日になりました。
その後、PHPを8.3.36に上げて、サイトの動作確認をしたうえで、会社のサイトの公開を再開しました。うちのサイトは、これでひとまず対処完了です。
