2026年10月22日 アピステクノロジー株式会社
2026年10月21日、Webサイトを動かすソフトウェア「PHP」に重大な脆弱性があることが公表され、修正版が公開されました。脆弱性とは、外部からの不正な操作につながり得る、ソフトウェアの弱点のことです。今回の問題が悪用されると、情報漏えいやサイトの停止、不正なプログラムの実行などにつながるおそれがあります。
PHPは、WordPressのサイトやネットショップ、Web業務システムなどで使われています。普段PHPを意識していない方のサイトでも、確認が必要な場合があります。ただし、この発表は「PHPを使うサイトがすべて被害を受けた」という意味ではありません。
「自分のサイトも対象なのか」「誰に頼めばよいのか」「何を更新するのか」。この記事では、Webサイトを公開している方に向けて、今回起きたことと確認・対応の手順を説明します。
1．まず、PHPとは何でしょうか
Webサイトでは、閲覧者の操作に応じてページを表示したり、商品の注文を受け付けたりします。PHPは、サーバーの中でこうした処理を動かすためのソフトウェアです。この記事では、その動作する仕組みを「PHP実行環境」と呼びます。
例えるなら、サイトの文章や画像が「お店の展示」、WordPressなどが「お店の業務の仕組み」、PHP実行環境はそれを動かす「設備」です。今回、修正が必要なのは、このPHP本体です。
サイトの文章を直したり、WordPressやプラグインだけを更新したりしても、PHP本体の修正の代わりにはなりません。一方で、お客様のサイトの作り方に問題があったと決まったわけでも、すぐサイト全体を作り直すという話でもありません。
どの部分に修正が必要なのか、サイトの仕組みの中で見てみましょう。
図のオレンジ色の部分が今回の修正対象です。記事や画像を変更する作業ではなく、サイトを動かすPHP本体への対応が必要です。
2．サイト運営者は、最初に何をすればよいでしょうか
まず、サーバーの管理担当者に「このサイトはPHPを使っていますか。今回の脆弱性への修正は済んでいますか」と確認してください。対象のPHPを使い、まだ修正されていない場合は、PHP実行環境の更新が必要です。
すぐに修正できない場合は、それまで公開を続けてよいか、一時的な公開停止やアクセス制限が必要かを管理者と判断します。最初からすべてのサイトを停止するということではなく、利用環境と修正状況を確認することが出発点です。
専門知識がなくても、ご自身でサーバーを操作する必要はありません。管理担当者が分からない場合は、サーバーの契約先やサイトの制作会社に、誰が運用を担当しているか尋ねましょう。
3．誰が更新するのかは、サーバーの利用方法で変わります
共有レンタルサーバー：通常はサーバー会社が更新します
サーバー会社が用意したPHP実行環境を、各サイトが利用する仕組みです。会社側がその環境を修正済みに更新すれば、それを使っているサイトは通常、そのまま更新後のPHPで動きます。利用者がサイトごとにPHP本体をインストールし直すという意味ではありません。
ただし、別のサーバーや別系列のPHP、独自環境まで更新されたとは限りません。会社側の案内を読み、自分のサイトが使う環境も修正済みか確認してください。サービスによっては利用者の操作が必要な場合もあります。
VPS・専用サーバー：中身を運用する担当者が更新します
サーバーを借りていても、その中のOSやPHPを自社で管理している場合は、自社の管理者が対応します。運用を委託している場合は、その委託先へ確認します。サーバーの貸出契約だけで、PHPまで更新してもらえるとは限りません。
AWSなどのクラウド：サービスと管理契約を確認します
例えば自社管理のAWS EC2では、OSやPHPなどの更新は利用者側の管理範囲です。AWSという名前だけで、自動的にPHPも更新されるとは判断できません。マネージドサービスでは、サービス仕様・設定・契約によって管理の分担が異なります。[4]
自分の契約では誰に依頼するのか、次の図で確認してください。
左はサーバー会社が用意するPHPを使う場合、右は自社や委託先がPHPを管理する場合です。まず自分のサイトがどちらに当たるかを確認します。
4．「修正版への更新」と「PHPの系列変更」は別の話です
PHP開発元は10月20日に緊急更新を予告し、21日に修正版を公開しました。案内されている修正版は8.2.35、8.3.36、8.4.27、8.5.12です。
ここで混同しやすいのが、「8.2.35への更新」と「8.4への変更」です。8.2.35は、引き続き8.2系列です。同じ系列の中で修正を取り込むことと、別の系列へ移ることは分けて考えます。
例えば、8.2.30から8.2.35への更新は8.2系列内の修正です。共有サーバー会社が提供する8.2環境を8.2.35へ更新すれば、その環境を選んでいるサイトは通常、引き続き8.2を選択したまま修正後の環境を利用します。この数字の例は、特定のお客様の利用状況を示すものではありません。
一方、8.2から8.4への変更は系列の変更です。共有サーバーでは、利用者が管理画面で切り替えたり、管理担当者に依頼したりする操作にあたります。サイトのプログラムが正しく動くか、事前の互換性確認が重要です。
今回の修正が適用された8.2.35を利用できるなら、この脆弱性への対策として必ず8.4へ変更するという意味ではありません。同一系列の修正であっても、適用後の表示・注文・予約などの動作確認は行いましょう。
「8.2.35にする」と「8.4にする」の違いは、次の図の上段と下段で分かります。
上段は同じ8.2系列の修正更新、下段は系列そのものの変更です。今回の修正が入った8.2.35で動いていれば、この問題への対策のためだけに8.4へ変える必要はありません。
5．修正版が公開されたら、自分のサイトも安全になるのでしょうか
「修正版が公開されたこと」と「自分のサイトで修正済みの環境を使っていること」は別です。確認には3つの段階があります。
① PHP開発元などが修正版を公開する。
② サーバー管理者が、利用するPHP実行環境へ修正を適用する。
③ 対象のサイトが、その修正済みの環境で動いていると確認する。
サイト運営者が管理者に確認したいのは③までです。OSの提供元が表示上のバージョン番号を変えずに修正を組み込むこともあるため、番号だけではなく、今回の脆弱性への修正適用を確認してください。[1]
問い合わせる際は、次の文面をお使いいただけます。CVEで始まる番号は、今回の問題を識別するための番号です。
「当社サイト【サイトURL】について、PHPを使用しているか、今回の脆弱性（CVE-2026-109618・CVE-2026-109619）への修正が実際に適用済みかをご確認ください。未修正の場合は、対応予定日と、それまで公開を続ける場合に必要な対策をお知らせください。」
6．古いPHPや、すぐ更新できないサイトはどうすればよいでしょうか
古いPHPも確認から外せません。CloudflareはPHP 5.4以降の系列に影響すると説明しています。ただし、修正済みの環境は未修正の環境と区別します。今回参照した情報だけでPHP 5.0～5.3を安全と判断することもできません。[2]
古い環境から一気に新しい系列へ変更すると、サイトの機能が動かなくなる場合があります。バックアップや検証環境での確認が必要ですが、その間も未修正で公開してよいとは限りません。
英国NCSCは、すぐに修正できない場合、十分な対策が整うまでオフラインにすることを検討するよう案内しています。停止やアクセス制限は、PHPにアクセスが届かない方法を管理者に選んでもらいます。WordPressのメンテナンス画面を出すだけでは、PHP自体が動き続ける場合があります。
WAFなどの防御機能も、PHP本体の更新の代わりにはなりません。 PHP 7.4・8.0・8.1には今回に絞ったソースコードの修正も案内されていますが、通常サポートが復活したわけではありません。専門担当者と緊急対応を判断し、長期的な更新・改修・移行計画を別に整理します。
管理者から回答を得たら、次の図で自分のサイトの状態と次の対応を確認してください。
「不明」は「修正済み」ではありません。修正の証拠を確認し、未修正なら更新、すぐ更新できなければ公開範囲の制限や停止を管理者と判断します。
7．修正が済めば、確認は終わりですか？
修正適用後は、サイトの表示や注文・予約などの動作を確認します。また、管理者によるアクセス記録や不審な変更の確認も重要です。更新しただけで、過去に侵害がなかったことまで証明できるわけではありません。
被害が発生したと決めつける必要はありませんが、普段どおり表示されているから安全とも判断できません。「自分のサイトが使っている環境の修正状況」を確認し、未修正であれば担当者と対応を進めてください。
弊社へのご相談について
当社の通常の保守契約はアプリケーション保守が対象です。サーバー基盤やPHP実行環境の更新作業は契約対象外のため、保守契約のあるお客様についても別途お見積もりとなります。ご契約先・管理体制・必要な作業範囲を確認し、ご承認後に対応します。
一次情報・参考資料
[1] PHP開発元：2026年10月のリリース・セキュリティ情報
[2] Cloudflare：PHP脆弱性とWAF保護に関する説明
[3] 英国NCSC：Critical security issue affecting PHP
[4] AWS：Amazon EC2におけるセキュリティの責任分担
情報確認：2026年10月22日 9:35（日本時間）。本記事は公開情報に基づく一般的な説明です。個別サイトの安全性や侵害の有無を判定するものではありません。最新の公式情報と利用環境を確認して対応してください。
コメント