【ITニュース解説】The WordPress PHP Vulnerability Is Three CVEs With Three Owners

現在、世界中で広く使われているウェブサイト作成システム「WordPress」について、非常に重要なセキュリティ情報が発表された。今回の話は、単一の脆弱性ではなく、三つの異なる原因が絡み合った複雑な問題であり、それぞれ異なる場所で発生し、異なる方法で対処する必要があるという点が特徴的だ。システムエンジニアを目指す皆さんにとって、これは現実の世界でセキュリティ対策がいかに多層的で複雑であるかを学ぶ良い機会となるだろう。

まず、一つ目の問題はWordPressの「コア」部分、つまりWordPress本体の根幹にある脆弱性だ。これはCVE-2026-119977という識別番号が付けられている。この脆弱性は特に緊急性が高く、アメリカのサイバーセキュリティ当局であるCISA（サイバーセキュリティ・社会基盤安全保障庁）が、活発に悪用されている既知の脆弱性リストに追加し、早急な対策を強く求めている。この脆弱性の仕組みは少し特殊で、「Time-of-Check-to-Time-of-Use（TOCTOU）レース条件」と呼ばれる種類のものだ。これは、WordPressをアップデートする際、一時的にファイルを保存する「ステージングディレクトリ」という場所が、予測可能な名前で作られてしまうことに起因する。攻撃者は、この予測可能な名前を利用し、アップデート処理中にごく短い時間だけ開く「窓」のような隙を突いて、サーバー上で不正なコードを実行できてしまう。つまり、アップデート作業そのものが、攻撃を受けるきっかけになってしまうという、皮肉な状況を生んでいたのだ。この問題はWordPressのバージョン4.7.0から7.1.3までが影響を受け、バージョン7.1.4で修正された。修正内容は、ステージングディレクトリの名前を推測困難なランダムな名前に変更し、不正な設定データの読み込みを防ぐといった対策が盛り込まれている。このコアの脆弱性はすでに悪用が確認されており、迅速なアップデートが不可欠である。特に、バージョン4.6以前の古いWordPressを使っている場合は、パッチが提供されないため、バージョンを大きく引き上げて更新する必要がある。

次に、二つ目の問題はWordPressが動作する基盤となる「PHPランタイム」に関する脆弱性だ。これはCVE-2026-109618とCVE-2026-109619という二つの識別番号を持つ脆弱性で、「php2shell」とも呼ばれている。この脆弱性は、PHPというプログラミング言語そのものの実行エンジン、つまりWordPressアプリケーションのさらに下層で発生する問題だ。これは何を意味するかというと、たとえあなたのWordPress本体やインストールしているすべてのプラグインが最新の状態であっても、PHPランタイムが古ければ、サイトは依然として攻撃される危険があるということだ。CVE-2026-109618は、メモリ不足エラーが発生した後のリクエストのメモリ処理に関わる問題で、CVE-2026-109619は、以前のリクエストで使われた古い情報が、次のリクエストに誤って引き継がれてしまうという問題だ。これらの脆弱性はPHPのバージョン8.2から8.2.34、8.3から8.3.35、8.4から8.4.26、8.5から8.5.11が影響を受け、2024年10月21日にリリースされたPHPの更新で修正されている。ここで注意すべきは、コマンドラインでphp -vと入力して表示されるPHPのバージョンが、実際にウェブサーバー上でWordPressを動かしているPHPのバージョンと異なる場合があるという点だ。必ずウェブサーバーが利用しているPHPのバージョンを確認し、もしホスティングサービスを利用している場合は、サービス提供元に確認して、PHPのバージョンを最新に更新してもらう必要がある。PHPの公式アドバイザリでは、特にsession.upload_progressという機能を無効にすることで、CVE-2026-109619の一部の攻撃経路をブロックできるとされている。WordPressコアはこの機能を使っていないため、使っていなければ無効にしておくことが推奨される。

そして三つ目の問題は、WordPressに追加する「プラグイン」に関する脆弱性だ。具体的には、ACF Extended PROというプラグインのバージョン0.9.2.6以前に、CVE-2026-120534という識別番号の脆弱性が存在していた。これは「危険な種類のファイルを制限なくアップロードできてしまう」という非常に深刻な問題（CWE-434）であり、脆弱性の深刻度を示すCVSSスコアは9.8と、ほぼ最高に近い値が付けられている。これは、攻撃者が巧妙な手口を使うことで、サーバー上に悪意のあるファイルをアップロードし、そこからさらにサーバーを乗っ取ったり、情報を盗み出したりする可能性があることを意味する。この脆弱性はバージョン0.9.2.7で修正されたとされているが、実はこのプラグインには、同時期に他にも二つの脆弱性（認証なしでの任意のショートコード実行、寄稿者レベルのXSS）が発見されており、これらはバージョン0.9.2.8でまとめて修正されている。したがって、もしこのACF Extended PROプラグインを利用しているのであれば、単に0.9.2.7にするだけでなく、0.9.2.8以降のバージョンに更新することが強く推奨される。また、たとえプラグインを「無効化」している状態であっても、そのプラグインのファイルがサーバーのディスク上に残っている限り、攻撃を受ける危険性が完全に排除されるわけではないという点も忘れてはならない。

これらの複数の脆弱性に対応するために、パッチを適用する際には、いくつかの重要な手順と心構えがある。まず、緊急事態であっても、無関係なシステムの変更は凍結し、セキュリティに関する修正作業だけに集中することが重要だ。これにより、もし問題が発生しても、原因を特定しやすくなる。次に、PHPのバージョン、WordPressコアのバージョン、すべてのプラグインとテーマ、カスタムコード、そしてホスティング環境など、サイトを構成するすべての要素（三つのレイヤー）を正確に把握する「棚卸し」を行う必要がある。もしすでにサイトが侵害されている可能性がある場合は、ログやデプロイ記録などの「証拠」を、他の更新で上書きされる前に必ず保全することが最優先事項だ。これは一度失われると二度と取り戻せない情報だからだ。その後、データベース、アップロードファイル、設定など、サイト全体の「リストア可能なバックアップ」を必ず取得し、万一の事態に備えて、そのバックアップから正常に復元できるかどうかのテストも実施する。そして、本番環境と全く同じPHP設定、拡張機能、ウェブサーバーの挙動を持つ「ステージング環境」を用意し、そこで実際のパッチ適用作業を「リハーサル」する。ログイン、フォーム、公開機能、支払い処理、管理画面のワークフローなど、サイトの主要な機能が正常に動作するかを徹底的にテストする。これらの準備が整った上で、本番環境で各レイヤーにパッチを適用し、再度サイトの基本的な機能が問題なく動くか「スモークテスト」と呼ばれる簡単な動作確認を行う。そして、すべての変更作業の記録（バージョン、タイムスタンプ、承認記録、テスト結果、ロールバックの判断など）を必ず保存しておくことが重要だ。パッチを適用する順番は、サイトの露出度やホスティング環境によって異なる。例えば、ホスティングサービスがアプリケーションに影響を与えずにPHPを更新できるなら、先にPHPを更新してリスクを減らすといった判断も有効だ。

最後に、パッチを適用したからといって、サイトが完全に安全であると考えるのは間違いであるという点も強調しておく。パッチはあくまで「既知の攻撃経路を閉じる」ものであり、パッチを適用する前にすでにその経路が悪用されていなかったことを証明するものではない。特にWordPressコアの脆弱性は、10月末から活発に悪用が確認されているため、「アップデートした」ことと「一度も侵害されなかった」ことは全く別の話だ。パッチ適用後も、サイトがすでに侵害されていないかを徹底的に確認する作業、「ポストパッチトリアージ」が必要となる。具体的には、ウェブサーバー、PHP、アプリケーション、WAF/CDN、認証システム、ホスティングサービスのコントロールパネルのログを詳細に確認する。不審な管理者アカウントやAPI認証情報、見慣れない定期実行タスク、設定変更、あるいは改ざんされたPHPファイル、不審なプラグインやテーマ、書き込み可能なディレクトリに追加されたファイルがないかを検査する。外部への不審な通信、サーバー上のプロセス活動、リダイレクト設定、平常時とは異なるトラフィックなども注意深く監視する必要がある。サイトのデプロイ履歴を確認し、信頼できる過去のバージョンとのファイル整合性を検証することも有効だ。また、ログが脆弱性が存在していた期間をカバーしているか、そして複数のシステムの時刻が正確に同期しているかどうかも、調査の正確性を左右する重要なポイントとなる。これらの指標がないからといって、侵害がないとは断定できない。スキャナーは、すでに削除された不正なファイルや、その可視範囲外の事象を見落とす可能性があるからだ。

今回の件から学ぶべき最も重要な教訓は、「最速の対応」とは、闇雲にすべてを一括アップデートすることではなく、「正確な所有権」に基づいた対応であるということだ。誰がPHPランタイムの管理責任者なのか、誰がWordPressコアの管理責任者なのか、そして誰がプラグインの管理責任者なのかを明確にし、それぞれの担当者が適切に対応しない限り、真に完全なセキュリティ対策とは言えない。セキュリティ対策は、これらの多層的な関係者が連携して初めて成立する、継続的なプロセスなのである。