1. Home
  2. Webサイト運営・解析
  3. PHPの重大な脆弱性とサイトの502エラー|管理側の対応記録

PHPの重大な脆弱性とサイトの502エラー|管理側の対応記録

PHPの重大な脆弱性とサイトの502エラー|管理側の対応記録

PHPに重大な脆弱性が見つかり、レンタルサーバー各社で緊急対応が進められています。

Webuzzが管理するWebサイトでも、利用するサーバーによって状況が分かれています。

2026年10月22日午前8時30分時点で、ロリポップやheteml上の管理サイトでは502エラーを確認しました。

サーバーの管理画面にも入れず、設定を変更できない状態です。

一方、エックスサーバー上の管理サイトは通常どおり表示され、PHPが今回の修正版である8.4.27になっていることを確認しました。

ただし、サーバーの管理画面にはアクセスできませんでした。

緊急対応が行われていても、Webサイトの表示や管理機能への影響は、環境によって異なります。

この記事では、PHP公式の発表と、Webuzzの管理環境で確認した状況、顧客への案内、復旧後に確認することを整理します。

*管理サイトの状況は、2026年10月22日午前8時30分(日本時間)時点の記録です。公式発表と管理サイトの確認結果は、それぞれの日時を区別して記載しています。

PHPに重大な脆弱性、修正版が公開

PHPは、WordPressなどのWebサイトをサーバー側で動かすために使われているプログラミング言語です。

PHP公式の告知(英語)によると、2026年10月21日、認証なしで外部からコードを実行される可能性がある、2件の重大な脆弱性への修正版が公開されました。

対象の識別番号は、CVE-2026-109618とCVE-2026-109619です。

修正版として、次のバージョンが案内されています。

系列今回の修正版
PHP 8.28.2.35
PHP 8.38.3.36
PHP 8.48.4.27
PHP 8.58.5.12

PHP公式は、Webリクエストを処理する幅広い環境に注意を呼びかけています。

設定変更による軽減策もありますが、完全な対処には更新が必要と説明しています。

サポート終了済みのPHP 7.4・8.0・8.1にも、例外的にソースコード向けの修正パッチが提供されています。ただし、通常のサポートが再開されたという意味ではありません。

レンタルサーバーでは、PHP本体の更新をサーバー事業者が管理している場合があります。

利用者側で必要な作業があるかも含め、契約しているサービスの公式案内を確認する必要があります。

修正版の公開前に情報が出回ったとの報告も

セキュリティ企業のHuntress(英語)は、修正版の公開前に、重大な脆弱性の存在を示す情報がオンラインで出回ったと報告しています。

PHP公式も、10月20日に翌日のセキュリティリリースを予告し、公開後すぐに更新できるよう準備を呼びかけていました。

こうした状況で懸念されるのは、利用者が修正版を適用できるようになる前に、攻撃側が情報を得て準備を進められることです。

Huntressは、日本時間10月22日午前5時30分時点で、同社のパートナー環境では今回の脆弱性の悪用を観測していないと説明しています。

一方、同記事では、他者による攻撃発生の報告にも触れています。

同社の環境で未観測であることは、攻撃が起きていないことを意味しません。

Webuzzの管理サイトについても、今回の表示障害が攻撃や侵害によるものとは確認できていません。

サーバーによって、表示や管理機能への影響は異なる

今回の対応状況を見るうえでは、公開中のWebサイトと、サーバーの管理機能を分けて確認する必要があります。

管理画面に入れなくても、Webサイトは表示されている場合があります。反対に、Webサイトの表示にも影響が出ている場合があります。

Webuzzの管理環境では、次の状況を確認できたため、一部共有します。

利用サーバーWebサイトの表示サーバー管理画面PHPの修正状況
ロリポップ502エラーアクセス不可未確認
heteml502エラーアクセス不可未確認
エックスサーバー通常表示を確認アクセス不可修正版8.4.27を確認

*2026年10月22日午前8時30分(日本時間)時点の観測です。各社の全サーバー・全契約で同じ状態になることを示すものではありません。

エックスサーバー上の管理サイトでは、PHPのバージョン表示が、今回の修正版である8.4.27になっていました。

サーバーの管理画面にはアクセスできなくても、公開中のWebサイトは表示されている状況です。

ロリポップは、PHPの重大な脆弱性への予防措置として、サービスサイトやユーザー専用ページなどを順次停止すると告知しています。

また、安全な運用に支障がある場合は、顧客のWebサイトも予告なく停止・制限する場合があると説明しています。

Webuzzが管理するロリポップ上のサイトでは、午前8時30分時点で502エラーを確認しました。このエラーが、告知された予防的な停止措置によるものかは確認できていません。

hetemlについても、管理サイトの502エラーと管理画面へのアクセス不可を確認しています。

利用するサーバーや環境によって、サイトの表示状況や管理機能への影響は異なります。

サイトが表示されること、管理画面を操作できること、今回の脆弱性への対応が完了していることは、それぞれ別の確認事項です。

表示状態だけで安全性や修正状況を判断せず、利用環境の情報と公式案内を照合します。

制作側でも、直接復旧できない場面がある

Webサイトは、制作したプログラムや画像だけで動いているわけではありません。

サーバー、PHP、データベース、ネットワークなど、複数の仕組みが組み合わさって動いています。

制作側で修正できる部分もあれば、サーバー事業者が管理している部分もあります。

今回のようにサーバーの管理画面にも入れない状況では、制作側から直接行える操作が限られます。

Webuzzでは、表示障害が続いている管理サイトについて、サーバー側の復旧を待ち、復旧後に表示・動作を確認する方針としました。

直接復旧できないときは、こちらで操作できる範囲と、事業者の対応を待つ範囲を整理する必要があります。

原因が分からないままサイト側の設定を変更すると、その後の状況を確認しにくくなる可能性もあります。

復旧を急ぐ場面でも、公式案内と利用環境の状態を確認し、必要な操作を判断することが大切です。

復旧を待つ間も、管理業務は続く

今回、表示障害が起きている管理サイトの顧客には、現状と今後の対応方針をメールで案内しました。

伝えたのは、次の内容です。

  • Webサイトが正常に表示されない状況
  • PHPに重大なセキュリティ上の問題が見つかっていること
  • 現時点ではサーバー側の復旧を待つ必要があること
  • 復旧後に表示・動作を確認し、必要な対応を行うこと

顧客への続報でも、サーバー事業者の公式案内と、管理サイトで確認した状況を整理して伝えます。

復旧予定が分からなくても、現状は報告できる

障害の発生直後には、原因や復旧時刻が分からないこともあります。

それでも、現在の状況、確認できていないこと、取っている対応、復旧後の予定は伝えられます。

復旧の見通しが立っていないことと、何も案内できないことは同じではありません。

Webサイトを使う顧客にとっては、問題が把握されているか、誰が確認を進めているかも大切な情報です。

状況が変わった際には、確認結果を整理して追加で案内します。

復旧後は、表示と必要な機能を確認する

復旧後は、トップページが開くだけで確認を終えず、主要ページや必要な機能を確認する予定です。

確認する項目確認する内容
ページの表示トップページや主要ページが正常に開くか
管理画面サーバーやWordPressにログインし、必要な操作ができるか
フォーム送信できるか、自動返信・通知メールが届くか
事業者の案内対応完了や、利用者側の追加作業が案内されているか

表示障害が続いているサイトでは、これらの確認はまだできていません。復旧後に実施し、結果を記録したうえで、問題があれば必要な対応を行います。

自分のWebサイトで確認したい3つのこと

同じPHPを利用していても、契約サービスや管理方法によって必要な対応は異なります。

Webサイトを運営している場合は、次の3点を確認してください。

  1. 利用しているサーバーの公式案内を確認する
    対象サービスやサーバー、停止する機能、対応状況、利用者側の作業の有無を確認します。
  2. PHP本体を誰が更新する環境か確認する
    サーバー事業者が管理する環境なのか、自分や管理担当者が更新する環境なのかを把握します。
    自分で管理する場合は、PHP公式とOS・パッケージ提供元の案内に従って修正を適用します。
  3. 更新・復旧後の表示と動作を確認する
    Webサイトが開くかに加え、管理画面やフォームなど、必要な機能が使えるかを確認します。

WordPress本体の更新と、サーバー側のPHP本体の更新は別の作業です。

WordPressを最新にしていることだけで、今回のPHPの問題にも対応できているとは判断できません。

障害時こそ、確認と説明を止めない

今回、Webuzzの管理環境では、表示障害が続いているサイトと、修正版のPHPで通常どおり表示されているサイトがありました。

サーバー事業者の対応状況も一様ではなく、会社名だけで状態を判断することはできません。

Webサイトの管理には、直接修正する作業だけでなく、状況を確認し、顧客に説明し、復旧後の動作を確かめる役割もあります。

原因や復旧時刻を確約できない場面でも、確認できた事実をもとに案内し、その後の動作まで見届ける。

Webuzzでは、引き続きその方針で対応を進めます。

代表 徳利 豪

この記事は、Webuzz編集部代表の徳利が執筆しました。 多様なWeb案件に携わってきた経験をもとに、分析・コンサルティング・運用の観点から、読者の皆さまに役立つ情報をお届けしています。
 プロフィールを見る
徳利 豪

この記事で気になったことはありませんか? お気軽にコメントください。スタッフが返信します。

まだこの記事にコメントは届いていません。

「これ良かった!」「どうして?」など、どんな一言でも大歓迎です。
下のコメントフォームからお気軽にどうぞ!

コメントフォーム

前の記事を読む検索順位が下がったら?原因の確認手順と対応を決める判断基準
検索順位が下がったら?原因の確認手順と対応を決める判断基準
次の記事を読む この記事が最新です。

関連投稿:

  1. Google「2026年8月スパムアップデート」の確認ポイント
  2. CloudSecure WP Securityの使い方と設定方法
  3. noindexタグによって除外されましたとは?原因と対処法を解説
  4. ソフト404とは?原因と対処法を解説