【2026年10月21日】PHPに緊急の脆弱性｜企業サイトの対応手順と今後のセキュリティ管理

PHPに緊急の脆弱性が見つかり、自社サイトへの影響や対処法がわからず困っていませんか。

結論として、CMSやプラグインの更新だけでは解決せず、サーバー上のPHP自体を修正版へ更新する作業が必要です。PHP 8.1以前を使用している場合は、サポート中のバージョンへの移行もあわせて必要になります。本記事の手順に沿って契約先への確認とバックアップを行えば、更新作業を進めやすくなり、今後の運用体制も見直せます。

※本記事は2026年10月22日時点の情報をもとに作成しています。対象バージョンや対策は更新される可能性があるため、最新情報はPHP公式サイトやIPA（独立行政法人情報処理推進機構）の発表をご確認ください。

PHPに緊急の脆弱性が見つかった｜2026年10月21日に何が起きたか

2026年10月21日（日本時間）、Webサイト制作に広く用いられるプログラミング言語「PHP」の開発チームが、外部からWebサーバーを不正に操作されるおそれがある緊急の脆弱性（プログラムの不具合や設計上のミスによる情報セキュリティ上の欠陥）2件を修正した版を公開しました。国内でも予防措置としてサービスを一時停止する組織が相次ぎ、政府機関も対応を呼びかける事態となっています。

この問題がなぜ多くの企業にとって直ちに対処すべき事案となっているのか、まずはPHPの基本的な役割と今回の事象の全体像を整理します。

PHPとは？企業サイトの多くを支えるプログラミング言語

PHP（ピーエイチピー）とは、Webサーバー上で動作し、状況に応じてページの内容を動的に生成するサーバーサイドのプログラミング言語です。BtoB・BtoCを問わず、企業のWebサイトにおいて標準的な技術基盤として採用されています。

企業サイトでPHPが多用されている理由は、サイトのお問い合わせフォームの送信処理や社内データベースとの連携など、動的なWeb機能の実装に適しているためです。具体的には、以下のようなシステムや機能でPHPが稼働しています。

• WordPress（ワードプレス）などのCMS（コンテンツ管理システム：Webサイトのテキストや画像を専門知識なしで管理・更新できるシステム）の動作基盤
• お問い合わせフォームや資料請求フォームにおける入力データの処理・メール送信機能
• ECサイトや会員制サイトにおけるログイン認証、カート処理、顧客データの照会機能

このように、管理画面から記事を更新できるサイトや、ユーザーからの入力を受け付ける機能を持つ企業サイトの多くは、裏側でPHPがプログラムを処理しています。

脆弱性の概要（深刻度・件数・通称「php2shell」）

今回修正された脆弱性は2件で、セキュリティ研究者の間では通称「php2shell」と呼ばれています。PHPの開発チームによると、いずれも認証なしで、外部からサーバー上の任意のプログラムを実行される（リモートコード実行：RCE）おそれがあるものです。深刻度を示す国際的な指標「CVSS v4.0」では、2件とも10点満点中9.2の「緊急（Critical）」と評価されています。

それぞれの脆弱性の識別番号（CVE番号）と原因は、下表のとおりです。

米国のサイバーセキュリティ・インフラストラクチャセキュリティ庁（CISA）は、Webリクエストを処理するすべてのPHP環境が影響を受けるとしています。PHPの開発チームは、PHPをWebサーバーソフト「Apache」に組み込む形（mod_php）が最もリスクが高く、WordPressなどのプログラムが動き出す前の段階で攻撃が成立しうると説明しています。そのため、管理画面に複雑なパスワードを設定していても、それだけでは防げません。

なお、通称の「php2shell」は、サーバーの操作権限（シェル）を奪われうることに由来する呼び名で、PHPの公式名称ではありません。悪用された場合に想定される被害は下表のとおりです。

発表から修正版公開までの時系列

今回の脆弱性は、修正版の公開前に情報が流出し、開発チームの事前告知から1日ほどで修正版が公開されるという緊急のスケジュールで進みました。主な流れは下表のとおりです。

修正版の公開前から、脆弱性を検証するプログラム（PoC：概念実証コード）が公開されていたとの報告もあります。また、この脆弱性を狙う攻撃通信を観測したと公表しているセキュリティ事業者もある一方、IPAは10月21日時点で悪用による被害は確認していないとしています。未対策のサーバーは探索の対象になりやすいため、初動の早さが被害の有無を左右します。

国内サービスの緊急メンテナンスとIPAの注意喚起

今回の特徴は、被害が確認される前に、予防措置としてサービスを止める判断が多くの組織でとられたことです。EC構築サービスや動画配信サービス、オンラインゲーム、金融機関、鉄道会社などの公式サイトやサービスが一時停止し、大手レンタルサーバー各社も緊急メンテナンスを実施しました。

政府も対応を呼びかけています。国家サイバー統括室は修正プログラムを含めた速やかな対応を求め、首相も自身のSNSで、修正版をすぐに適用できない場合はWebサイトの一時停止もリスクを下げる有効な手段の一つだと呼びかけました。IPAも10月21日に、PHPを利用するWebサイトの運営者に向けて注意喚起を公表しています（IPA 重要なセキュリティ情報）。

共用レンタルサーバー（1台のサーバーを複数の契約者で共有するサービス）では事業者側で対応が進む一方、自社でサーバー環境を構築している場合や、専用サーバー・VPS（仮想専用サーバー：1台のサーバー上に独立した仮想領域を構築し、管理者権限を持って運用するサービス）を利用している場合は、自社で更新作業を行わなければ脆弱性は解消されません。事業者の自動更新の対象外となっているサーバーを運用している企業は、早急に自社の環境を確認する必要があります。

自社サイトは影響を受ける？確認すべきポイント

自社サイトが今回の脆弱性の影響を受けるかどうかは、サイトがPHPで稼働しているか、および現在稼働中のPHPバージョンが何かという2点を確認することで判断できます。PHPはサーバー上でWebページを動的に生成する仕組みに広く使われており、制作時にPHPを意識していなくても、裏側で稼働しているケースが多いためです。BtoBやBtoCを問わず、情報発信や問い合わせ受付を行う一般的な企業サイトでは、まずシステム構成とバージョンの確認から始めてください。

WordPressで作ったサイトは対象になりうる

WordPress（Webサイトのコンテンツを管理・更新するためのシステムであるCMSの一種）で構築された企業サイトは、原則として今回のPHPの脆弱性の確認対象になります。WordPress本体やテーマ、プラグイン（拡張機能）はすべてPHPで記述されており、サーバー上でPHPが動作することを前提としているためです。

企業サイトでよく見られる構築方法別の影響範囲は、下表のとおりです。

仮にトップページや会社概要ページが静的なファイルで作られていても、お問い合わせフォームや資料請求ページ、新着情報の更新システムだけにPHPを組み込んでいる場合は影響を受ける可能性があります。自社のサイトにログインして記事を更新する画面があるか、またはURLの末尾が「.php」となっているページが存在するかを確認してください。

WordPressやプラグインの更新では直らない理由

今回の脆弱性は、WordPress本体やプラグインを最新バージョンにアップデートするだけでは解消されません。問題の原因がWordPressというアプリケーション側ではなく、それを動かしている土台であるサーバー内のPHP自体に存在するためです。

Webサイトのシステム構造を階層に分けると、下から順に「サーバーOS（基本ソフトウェア）」「ミドルウェア（PHPやデータベースなど）」「CMS（WordPressやプラグイン）」という構造になっています。WordPressの管理画面から日頃行っている更新作業は、一番上のCMSの層を修復する作業にとどまります。

したがって、土台であるミドルウェア層のPHPに存在する脆弱性を塞ぐには、レンタルサーバーやクラウドサーバーの管理画面へログインし、PHPそのもののバージョンを修正版へ引き上げる作業が必要です。

PHPのバージョンを確認する方法

自社のWebサイトで使用しているPHPのバージョンは、WordPressの管理画面、または契約しているサーバーの管理画面（コントロールパネル）から確認できます。外部の制作会社や保守業者へ連絡する前に、社内のWeb担当者でも数分で現状を把握できます。

具体的な確認手順は以下の3通りです。

• WordPressの管理画面から確認する：管理画面にログインし、左メニューの「ツール」から「サイトヘルス」を開きます。画面上部の「情報」タブを選択し、「サーバー」という項目を開くと「PHPバージョン」の数値が表示されます。
• レンタルサーバーの管理画面から確認する：サーバー会社の管理画面にログインし、「PHP設定」や「PHPバージョン切り替え」といったメニューを開くと、対象のドメイン（サイトのURL）ごとに現在適用されているバージョンが表示されます。
• 制作会社・保守管理会社へ問い合わせる：社内に管理画面のログイン情報がない場合や、自社でサーバーを直接契約していない場合は、サイトを管理している委託先へ現在のPHPバージョンを直接確認します。

確認したバージョンが、利用中の系列の修正版（8.5系なら8.5.12、8.4系なら8.4.27、8.3系なら8.3.36、8.2系なら8.2.35）以上であれば、今回の脆弱性への対応は済んでいます。

PHP 8.1以前を使っているサイトは特に注意

確認の結果、現在のバージョンがPHP 8.1以前（PHP 8.1、8.0、7.4、5.6など）であった場合は、サポート中の新しいバージョンへの移行が必要です。これらの古いバージョンはすでに開発元による公式なセキュリティサポートが終了しており、今回の脆弱性に対する公式の修正版が提供されないためです。一部のサーバー会社やOSの提供元が独自に修正を提供している場合もあるため、利用中のサーバー会社の案内もあわせて確認してください。

PHP公式のサポートバージョン一覧をもとに、各バージョンのサポート状況を整理すると下表のとおりです。

PHPの公式サポート期間は、リリースから2年間のバグ修正期間と、その後2年間のセキュリティ修正期間を合わせた計4年間が基本です。サポート期限切れ（EOL：End Of Life）を迎えたバージョンを使い続けると、今回のような緊急の脆弱性に対して公式の修正を受けられません。また、PHP 8.2を使用しているサイトも2026年末にサポート期限を迎えるため、今回の対応とあわせて上位バージョンへの引き上げを検討してください。

企業サイトの対応手順

自社サイトが今回の脆弱性の影響を受けると判明した場合は、案内情報の確認、担当と期限の決定、事前バックアップ、修正版への更新と動作確認の4段階を順に進めてください。事前の確認や準備を省いていきなりPHPのバージョンを変更すると、サイトの表示崩れやシステム停止といった二次被害を招くおそれがあるため、手順に沿って対応することが望ましいです。

手順1　サーバー会社・制作会社からの案内を確認する

最初のステップとして、契約しているレンタルサーバー会社からのメンテナンス情報と、サイト制作会社との保守契約範囲を確認してください。利用しているサーバー環境や契約形態によって、自社で作業すべきか、あるいは外部業者の対応を待つべきかが異なるためです。

サーバー環境ごとの主な対応方針は、下表のとおりです。

共用レンタルサーバーでは、同じ系列内の修正（例：PHP 8.3系の修正版への更新）であればサーバー会社側で順次適用されるケースが一般的です。一方、PHP 8.1以前から8.2以降へ引き上げるような系列をまたぐ変更は、サイト側の動作に影響するため、管理画面から手動で切り替える必要があります。

手順2　修正版へ更新する担当者と期限を決める

サーバー側の状況を把握した後は、実作業を行う担当者と更新完了の期限を明確に設定してください。緊急時の対応において担当と期限が曖昧な状態は、社内や委託先との間で「相手が対応しているだろう」という思い込みを生み、結果として脆弱性を放置する原因となります。

担当者と期限を決める際は、以下の項目を関係者とすり合わせます。

• 作業実施者（社内の情報システム部門、Web担当者、または外部の制作会社）
• テスト環境での検証完了日時と、本番環境への適用日時
• 万が一サイトに不具合が生じた場合の切り戻し判断者および連絡先

BtoB企業では、取引先や見込み客のアクセスが集中する平日の日中に更新作業を行うと、一時的なエラー表示が機会損失につながります。アクセス解析ツールで時間帯別の流入数を確認し、訪問者が少ない時間帯に作業を設定してください。ただし今回は緊急性が高いため、作業時間の調整で更新を先延ばしにしないよう注意が必要です。

手順3　更新前にバックアップを取る

PHPの更新作業に着手する直前に、Webサイトの構成ファイル一式とデータベースのバックアップを取得してください。PHPのバージョンやパッチの適用によって既存のプログラムが動かなくなった場合でも、バックアップがあれば更新前の状態へ戻しやすくなります。

具体的には、以下の対象をセットで保存します。

• サーバー上の全ファイル（WordPress本体、テーマ、プラグイン、画像データ、設定ファイルである.htaccessやphp.iniなど）
• データベース（MySQLやMariaDBなどに格納された記事データ、顧客情報、各種設定値）

レンタルサーバーの自動バックアップ機能を利用している場合でも、直近の更新分が含まれていない可能性があるため、作業直前に手動でデータを書き出し、サーバー外（手元のパソコンやクラウドストレージ）にも保管しておくと安全です。

手順4　更新後にサイトの表示・フォームを確認する

PHPを修正版へ更新した直後は、トップページだけでなく、サイト内の主要ページと動的機能が正常に稼働しているかを点検してください。PHPの仕様変更や修正の影響は、ページを開いた瞬間だけでなく、データの送信処理など特定の動作を行った際に初めて表面化することがあるためです。

なお、VPSやクラウドサーバーで自社管理している場合は、PHPを更新した後にPHP-FPMやWebサーバーを再起動しないと、新しいPHPが読み込まれないことがあります。作業担当者に再起動まで完了しているかを確認してください。

更新後にWeb担当者が優先して確認すべき項目は以下のとおりです。

• 主要ページの表示（トップページ、サービス紹介、記事一覧、固定ページでレイアウト崩れや警告文の表示がないか）
• お問い合わせ・資料請求フォーム（テスト送信を行い、完了画面の表示、管理者宛の通知メール、自動返信メールが正常に届くか）
• サイト内検索や絞り込み機能（検索結果が正しく出力されるか）
• CMSの管理画面（ログインの可否、新規記事の投稿・編集・保存がエラーなく完了するか）

もし画面が真っ白になる、あるいはエラーメッセージが表示されて操作できなくなった場合は、手順3で取得したバックアップを用いて復旧させ、原因となったプログラムやプラグインの改修を行ってください。なお、脆弱性のある古いバージョンへ戻した状態での公開は避け、下記の暫定措置もあわせて検討してください。

すぐに更新できない場合の考え方

独自の業務システムを組み込んでいるなどの理由でPHPをすぐに更新できない場合は、リスクを下げる暫定措置を検討してください。ただし、PHPの開発チームは完全な緩和策はなく、更新以外に安全な対処はないとしています。暫定措置はあくまで更新までのつなぎとして位置づけてください。

環境に応じた主な暫定措置は、下表のとおりです。

これらの措置を講じても、PHP自体の脆弱性が消えるわけではありません。暫定措置を講じている間に、システム改修やサーバー移転の計画を速やかに進めてください。具体的な設定方法は、サーバー会社や保守会社にご相談ください。

今回の件で見えた、自社でサーバーを管理するリスク

自社でサーバー環境やPHPのバージョンを管理している企業サイトでは、緊急の脆弱性が発見された際に迅速な更新ができず、サイバー攻撃の被害に遭う危険性が高まります。日常業務と並行してセキュリティ情報を監視し、Webサイトの表示崩れやシステム停止を防ぎながらミドルウェア（OSとWebサイトの間で動くPHPなどの基本ソフトウェア）を更新するには、専門的な知識と明確な運用体制が必要だからです。

IPAが公開している情報セキュリティ10大脅威 2026でも、「システムの脆弱性を悪用した攻撃」が組織向けの脅威の一つに選ばれています。ひとたび攻撃を受けてWebサイトが改ざんされたり、お問い合わせフォームから個人情報が漏えいしたりすれば、BtoB・BtoCを問わず企業の社会的信用は大きく損なわれます。さらに、検索結果に警告が表示されて自然検索からの流入が減ったり、Web広告の配信が止まったりする場合もあります。今回の事案を通じて浮き彫りになった、自社管理における3つの構造的な課題を解説します。

脆弱性対応は「誰がやるか」が決まっていないと遅れる

緊急の脆弱性対応が遅れる大きな原因は、社内と外部委託先の間でミドルウェアを更新する責任の所在が曖昧になっていることです。Webサイトの立ち上げ時に、日々の記事更新やコンテンツ追加の担当者は決めても、サーバー内部のプログラム更新を誰が担当するかまで取り決めていないケースが多いためです。

一般的な企業サイトの運用では、関わるプレイヤーの役割と対応範囲が下表のとおり分かれています。

このように、サーバー会社は「環境の提供まで」、制作会社は「依頼された制作の範囲まで」と認識している場合、PHPの更新作業はどの業務範囲からも漏れてしまいます。緊急時に誰が作業を行うかという責任分界点が決まっていなければ、社内稟議や制作会社への見積もり依頼に時間を取られ、修正版の適用が大幅に遅れる事態を招きます。

PHPのサポート期限切れを放置しているサイトは少なくない

Webサイトが問題なく表示されていることを理由に、サポート期限（EOL：End of Lifeの略で、開発元による修正プログラムの提供が終了すること）を迎えた古いPHPを放置している企業は少なくありません。PHPのバージョンアップを行うと、既存のプログラムやCMS（WordPressなどWebサイトのコンテンツを管理・更新するシステム）のプラグインが新しい仕様に対応できず、画面が真っ白になるエラーやフォームが送信できなくなる不具合が起きるおそれがあるためです。

PHPの各バージョンには明確なサポート期間が定められており、公開から2年間の通常サポートと、その後2年間のセキュリティ修正のみの提供期間を経て、計4年間でサポートが終了するのが基本です。たとえば、PHP 8.1以前のバージョンはすでにサポート期限を迎えており、公式からのセキュリティ修正プログラムは提供されません。

古いバージョンを使い続けているサイトが直面する具体的な問題は以下のとおりです。

• 脆弱性が発見されても公式の修正版が配布されないため、上位バージョンへ引き上げる以外の有効な防御手段が限られる
• バージョンを大きく跨ぐ更新（PHP 7系から8系への移行など）ほどプログラムの仕様変更が多く、互換性エラーが起きやすい
• エラーを解消するためのプログラム改修や動作検証に追加の費用と期間がかかり、すぐに脆弱性を塞ぐことができない

日頃から計画的にバージョンを引き上げていないサイトほど、緊急時にすぐ更新作業へ踏み切れず、攻撃に対して無防備な状態が続くことになります。

Web担当者が一人の企業ほど負担が大きい

専任のシステム部門がなく、1人のWeb担当者がサイト運用を一手に引き受けている企業ほど、緊急の脆弱性対応は業務を圧迫する大きな負担となります。中小企業やBtoB企業では、Web担当者が広報、営業企画、あるいはSEOやGA4（Google アナリティクス 4）を用いたアクセス解析、ランディングページ（LP）の改善といったマーケティング業務を兼任しているケースが多いためです。

サーバーやPHPに関する専門知識を持たない担当者が、突発的な脆弱性への対応を迫られた場合、通常業務を止めて以下の作業をこなさなければなりません。

• サーバー会社や公的機関の発表を読み解き、自社サイトが該当する環境・バージョンであるかを調査する
• 本番環境と同じ状態を再現したテスト環境を用意し、PHPの更新によって表示崩れや機能不全が起きないか検証する
• 不具合が発生した場合に原因となっているコードやプラグインを特定し、外部のエンジニアや制作会社へ改修を手配する
• 万が一のトラブルに備え、アクセスが少ない時間帯に本番環境への切り替え作業とバックアップからの復旧準備を行う

これらの作業を1人の担当者に委ねる体制は、対応の遅れによるセキュリティ事故のリスクを高めるだけでなく、本来の目的である集客や売上向上のためのWeb施策が滞る原因にもなります。属人化した管理体制の限界を認識し、専門知識がなくても安全性を保ちやすい仕組みへの移行を検討することが望ましいです。

今後のセキュリティ管理を見直す選択肢

緊急の脆弱性対応で生じるWeb担当者の負担や対応遅れのリスクを減らすには、自社の予算や運用体制に合わせてサイトの管理方法を見直すことが有効です。対応の選択肢は、外部の専門会社への保守委託、サーバー管理が不要なシステムへの移行、そしてサイト全体のリニューアルの3つに大別されます。

PHPやCMS（Webサイトのコンテンツを管理・更新するシステム）のセキュリティ更新は、単なるボタン操作では完結しません。更新によって画面が真っ白になる表示崩れや、お問い合わせフォームが動作しなくなる不具合を防ぐため、事前の検証作業が欠かせません。社内に検証環境を構築・維持できる技術者がいない場合、無理に自社対応を続けるよりも、管理の仕組み自体を変える方が結果的にコストとリスクを抑えられる場合があります。

3つの選択肢における管理範囲や向いている企業の特徴は、下表のとおりです。最適な選択肢は、企業の規模や業種、サイトの構成によって異なります。

保守契約を見直して更新対応を任せる

現在のWordPressサイトを維持したままセキュリティリスクを下げるには、Web制作会社や保守専門会社との契約内容を見直し、PHPやミドルウェアの更新まで含めて外部に委託するのが有力な方法です。

一般的なWebサイトの保守契約では、作業範囲が「ドメイン・サーバーの契約維持」や「定期的なバックアップの取得」のみに限定されているケースが少なくありません。CMS本体やプラグイン（拡張機能）、さらに土台となるPHPのバージョンアップが「別途お見積もり」となっている場合、緊急時にすぐ対応してもらえない原因になります。

既存の契約書や仕様書を確認し、保守会社と協議する際は以下の項目が作業範囲に含まれているかを明確にします。

• PHPおよびCMS本体・プラグインの定期的なバージョンアップ作業
• 緊急の脆弱性が発表された際の臨時対応と、完了までの目標時間
• 本番環境へ適用する前のテスト環境での表示・動作検証
• バージョンアップに伴って不具合が発生した際のプログラム改修費用の上限や負担割合

これらを月額の保守メニューに組み込むことで、突発的な脆弱性情報が出た際にも、社内稟議を待たずに専門家による迅速なアップデートを依頼しやすくなります。

サーバー管理が不要なクラウドCMSへ移行する

自社でのサーバー管理やPHPのバージョンアップ作業そのものを減らすには、インフラの保守をベンダー（提供会社）が担うクラウドCMS（SaaS型CMS）への移行が適しています。

WordPressに代表されるインストール型CMSは、自社で契約したレンタルサーバー等にプログラムを設置するため、自由度が高い反面、サーバー環境やPHPの保守責任はサイト運営者側にあります。一方、クラウドCMSはベンダーが管理するシステムをインターネット経由で利用する仕組みであるため、サーバーの脆弱性対応やシステムの更新は原則としてベンダー側で実施されます。

BtoBおよびBtoC企業で導入されている主な選択肢には、以下のようなタイプがあります。

• マーケティング機能を備えたクラウドCMS：フォーム作成やアクセス解析、顧客管理などの機能を標準で備え、サイト運用からリード獲得までを一つのツールで進められます。
• ノーコードWeb制作ツール：コードを記述せずにデザイン性の高いサイトを構築でき、サーバーの保守を自社で抱えずに運用できます。
• ヘッドレスCMSと静的サイトの組み合わせ：管理画面と表示画面を切り離す仕組みで、公開側のサーバーでPHPを動かさない構成にできるため、今回のようなPHPの脆弱性の影響を受けにくくなります。

ただし、現在のサイトで会員専用ページや外部の基幹システムとの複雑なデータ連携をPHPで独自開発している場合、クラウドCMSでは同じ機能を再現できないことがあります。移行を検討する際は、現在使用している機能を洗い出し、移行先の標準機能で代替できるかを確認することが先決です。

サイトリニューアルを検討するタイミング

PHPのバージョンアップに伴うプログラムの修正範囲が広く、改修費用が高額になる場合は、既存サイトの延命ではなくサイト全体のリニューアルを検討することが望ましいタイミングです。

古いバージョンのPHPから最新のPHP 8系へ引き上げる際、過去に作られた独自のテーマ（デザインテンプレート）や古いプラグインが新しい仕様に対応しておらず、サイトが正常に動かなくなることがあります。この不具合を解消するために当時のプログラムを解析して書き直す作業は、新規にプログラムを組むのと同程度以上の工数と費用がかかるケースも少なくありません。

自社のサイトが以下の条件に複数当てはまる場合は、スポットでの改修ではなくリニューアルの検討を推奨します。

• 前回のサイト制作・リニューアルから、目安として5年以上が経過している
• 制作当時の担当者や外注先の制作会社とすでに連絡が取れず、仕様書も残っていない
• PHPのバージョンアップに伴う不具合改修の見積もりが、当初の想定を大きく上回る規模になった
• 現在の事業内容やターゲット層と、サイト内の情報・デザインが合わなくなっている

単なるセキュリティ維持のためだけに高額な改修費用を払うのではなく、営業DXの推進やお問い合わせ数の増加といったマーケティング上の目的も合わせたリニューアルとして予算を組み直す方が、投資対効果を高めやすくなります。

まとめ

2026年10月21日に修正版が公開されたPHPの脆弱性に対し、企業のWeb担当者には自社サイトのPHPバージョンを確認し、速やかに修正版へ更新する対応が求められます。PHPの脆弱性は、WordPress本体やプラグインの更新だけでは解消されないため、サーバー環境そのもののアップデートが必要です。

BtoB・BtoCを問わず、企業サイトが改ざんや情報漏えいの被害に遭うと、事業継続や取引先からの信用に直結します。対応の遅れを防ぐため、現在の管理状況に応じた優先アクションは下表のとおりです。

目先の脆弱性対応を完了させた後は、社内の運用体制に合わせて保守契約の範囲変更やクラウドCMSへの移行を検討し、特定の担当者に負担が集中しないセキュリティ管理体制を整えてください。

PHPの脆弱性に関するよくある質問

PHPの脆弱性対応を進めるにあたり、自社のサーバー環境やサイト構造が対象になるか判断に迷うケースが少なくありません。企業のWeb担当者から寄せられる代表的な3つの疑問について、判断基準と確認手順を解説します。

レンタルサーバーなら自動で更新される？

共用レンタルサーバーを利用している場合、同じ系列内のセキュリティ修正はサーバー会社によって適用されるケースが一般的ですが、利用中の設定や契約プランによって対応が分かれます。系列の切り替え（8.1系から8.3系への変更など）や、サポート期限切れバージョンの利用時は、契約者自身で管理画面から変更作業を行わなければならない場合が多いためです。

また、VPS（仮想専用サーバー）やクラウドサーバーを自社で構築・管理している場合は、原則として自動更新は行われません。契約しているサーバー種別ごとの一般的な対応範囲は、下表のとおりです。

共用レンタルサーバーであっても、全サーバーへの適用には時間差が生じることがあります。管理画面のメンテナンス情報で自社の収容サーバーが更新済みかを確認し、未適用の場合はサーバー会社に対応状況を問い合わせることが推奨されます。

HTML（静的サイト）でも影響はある？

ページの大半がHTMLやCSS、JavaScriptで構成されているサイトでも、一部にPHPプログラムを組み込んでいる場合は脆弱性の影響を受けます。Webサイトの表示自体はHTMLファイルで行われていても、裏側の処理でPHPが動作していれば攻撃の対象となりうるためです。

また、現在のサイトでPHPを使っていないつもりでも、過去に設置したプログラムやテスト用のPHPファイルがサーバー上に残っていると、そこを起点に攻撃を受けるおそれがあります。HTMLを主体としたサイトで特に確認すべき箇所は以下のとおりです。

• お問い合わせフォームや資料請求フォームの送信処理プログラム（sendmail.phpなど）
• 新着情報やブログ記事など、一部ページのみに導入している簡易CMS
• サイト内検索機能やアンケート集計用のスクリプト
• HTMLファイル内でPHPを動作させるための設定ファイル（.htaccessなど）

これらの機能を1つでも利用している場合は、通常の動的サイトと同様にPHPのアップデートが必要です。サイト全体でPHPを使っていないことが確認できた場合は、不要なPHPファイルを削除したうえで、サーバーの管理画面からPHPの実行機能を無効化（オフ）するか、修正版のバージョンへ設定を変更しておくことでリスクを下げられます。

WordPressのバージョンが最新なら大丈夫？

WordPress本体やプラグインを最新バージョンに保っていても、サーバーのPHP自体を更新しなければ今回の脆弱性は解消されません。WordPressはPHPというプログラミング言語の上で動くシステム（CMS）であり、その土台となるPHP自体の欠陥は、WordPress側のプログラム修正では塞ぐことができないためです。

この関係性は、スマートフォンのOS（基本ソフト）とアプリに例えると理解しやすくなります。アプリ（WordPress）を最新にしても、OS（PHP）に深刻な欠陥があれば、端末全体（サーバー）が危険にさらされるのと同じ構造です。企業サイトを安全に運用するために管理すべき3つの階層は、下表のとおりです。

WordPressの管理画面上で「すべて最新です」と表示されていても、それはあくまでWordPress本体とプラグインの状態を示しているに過ぎません。WordPressの管理画面とは別に、サーバー会社の管理画面へログインしてPHP自体のバージョンを確認・更新してください。