「PHPに重大な脆弱性。WordPressで動いている自社サイトは大丈夫なのか」。レンタルサーバーを使っていると、どこまで事業者に任せ、何を自分で確認するべきか迷います。
まず必要なのは、利用中のPHPの把握と、サーバー事業者への対応確認です。WordPressの更新だけでは、PHP本体の修正を適用したことにはなりません。
この記事では、2026年10月21日に修正版が公開されたPHPの重大脆弱性2件を取り上げます。一般のサイト運営者向けの確認手順と、制作会社・サーバー管理者向けの注意点を整理しました。
最新追記：2026年10月22日09:02（日本時間）。 エックスサーバーはPHP 8.2〜8.5の対象全サーバーへの修正パッチ適用完了、さくらはPHP更新保守の完了、mixhostはマイページ復旧を案内しています。対象と利用者側の確認事項は5社の対応状況に追記しました。これらは完了した作業の範囲が異なります。PHP公式の修正版は引き続き8.5.12・8.4.27・8.3.36・8.2.35です。
最初に押さえる3つのこと
- 新しいPHPを使っていても、今回の修正が入っているか確認する。 「PHP 8だから安全」「先週更新したから大丈夫」とは判断できません。
- PHP本体とWordPressの更新を分けて考える。 共用レンタルサーバーのPHP本体の修正は通常、事業者が行います。利用者には、ドメインごとのPHP選択やWordPress側の保守が残ります。
- 修正版の適用と、稼働環境への反映を確認する。 完全な版番号や事業者の案内で、今回の修正が反映されたことを確認します。変更が必要な場合に備え、対象サイト、バックアップ、連絡先、確認する機能もそろえます。すぐ修正できない公開環境は、アクセス制限や一時停止の要否を管理者と判断します。
何が発表されたのか。「重大なエラー」との違い
PHP公式の10月21日付発表は、認証なしで遠隔からコードを実行されるおそれがある2件の修正公開を案内しています。CVE識別子はCVE-2026-109618とCVE-2026-109619。どちらも深刻度の指標であるCVSS v4.0で9.2です。これは、個々のサイトが侵害される確率を示す数字ではありません。
IPAの10月21日付案内とCERT-EUの注意喚起も照合しました。10月21日23時台の再確認時点では、取得できた本文はいずれも修正版公開前の案内でした。10月22日朝もIPAの取得本文は事前案内のままで、CERT-EUはHTTP 403のため最新本文を再取得できていません。IPAは、同案内の発信時点で今回の2件を悪用した攻撃を確認しているわけではない、と説明しています。これは現在の世界全体で攻撃がないという保証ではありません。確定した修正版・技術条件は、公開後のPHP公式情報を基準にしています。
ここで、WordPressに表示される「このサイトで重大なエラーが発生しました」という障害メッセージと、今回の脆弱性を区別しましょう。表示エラーの有無だけでは、今回の脆弱性の影響を判断できません。 エラーが出ていなくてもPHPの確認は必要です。逆に、エラーが出たことだけで今回の攻撃を受けたとはいえません。
2件の原因と、実行方式ごとの違い
| 脆弱性 | 原因と、公式が示した成立条件 |
|---|---|
| CVE-2026-109618 | メモリ不足で処理が中断した後、初期化途中の状態を終了処理が扱う問題。Apacheのmod_phpでは、アプリケーションのコードが動く前の入力解析でコード実行を実証。PHP-FPMでもアプリ処理中のメモリ不足が影響し得るが、このCVE単独の完全な攻撃をFPMで実証したとはしていない |
| CVE-2026-109619 | 前のリクエストの解放済みメモリを指す状態が残り、同じワーカーの後続リクエストで使われる問題。セッション関連の経路ではmod_phpとFPMの両方でコード実行を実証。FPMでは、正常な初期化後に特定の状態を残して致命的エラーを起こすアプリ操作などの条件がある。PHP 8.5のエラー診断経路についてもmod_phpで実証 |
ワーカーは、リクエストを処理するサーバー側のプロセスです。実行方式やアプリの動きで攻撃経路は異なりますが、「FPMだから安全」とは判断できません。 PHP公式は、Webリクエストを扱うFPM、mod_php、php-cgi、FrankenPHP、LiteSpeedをリスク対象に挙げています。Linuxなら無関係、WindowsのCGIだけが対象、という問題ではありません。
なお、実証された経路の説明と、すべての構成で同じ攻撃が成立するという主張は別です。公式の技術情報を、自分の環境を調べずに「必ず侵入済み」「この構成なら影響なし」と読み替えないようにしてください。
全バージョンに脆弱性があるのか
サポート中の8.2〜8.5には、すべて今回の修正が必要です。「全バージョンが今も未修正」という意味ではなく、次の修正版が公開されています。
| PHP系列 | 今回の修正前の上流版 | 2件の修正版 |
|---|---|---|
| 8.5 | 8.5.0〜8.5.11 | 8.5.12 |
| 8.4 | 8.4.0〜8.4.26 | 8.4.27 |
| 8.3 | 8.3.0〜8.3.35 | 8.3.36 |
| 8.2 | 8.2.0〜8.2.34 | 8.2.35 |
出典：PHP公式リリース告知、変更履歴、上記2件のセキュリティアドバイザリ。OSやホスティング事業者の独自パッケージは、表示番号を変えずに修正を取り込む場合もあります。上の表はPHP本体の上流版での区切りです。
旧系列も、古いという理由で対象外にはできません。公開前のCERT-EUはPHP 5以降に広く影響し得ると案内しましたが、その広い範囲は外部研究者の情報に基づきます。PHP公式は公開後、7.4・8.0・8.1向けに今回の2件だけの最小限のソース修正を例外提供しました。これは通常サポートの再開でも、利用中の全旧版へ修正済みバイナリが自動配信されるという意味でもありません。さらに古い全版・全構成で同じ攻撃が成立するかまで、一律に断定することは避けます。
共用サーバーの利用者は独自ビルドを試すのではなく、提供元にバックポート（修正の取り込み）の有無を確認し、サポート中の系列への移行も進めてください。
「サポート中」と「今回の修正済み」は別
PHP公式のサポート表では、2026年10月21日現在のサポート対象は8.2〜8.5です。
| PHP系列 | 現在の保守状態 | セキュリティサポート終了日 | 今回の対応で見る点 |
|---|---|---|---|
| 8.5 | 通常サポート中 | 2029年12月31日 | 今回の修正を含む版・配布パッケージか確認 |
| 8.4 | 通常サポート中 | 2028年12月31日 | 同上 |
| 8.3 | セキュリティ修正のみ | 2027年12月31日 | 同上 |
| 8.2 | セキュリティ修正のみ | 2026年12月31日 | 今回の修正確認に加え、年内の移行計画を立てる |
| 8.1以前 | PHP公式のサポート終了 | 8.1は2025年12月31日。さらに古い系列も終了済み | 独自保守の有無を確認し、サポート対象系列へ移行 |
終了済み系列の出典：PHP公式 Unsupported Branches。この表は保守期限の整理です。7.4・8.0・8.1への今回限りのソース修正も、保守期限を延長するものではありません。
管理画面に古いPHPが残っていても、「選べるから安全」とは限りません。一方、事業者やOSベンダーが独自に修正を取り込む場合もあるため、表示番号だけで未修正と断定するのも早計です。契約先には、今回の2件の修正が、どの提供版・パッケージに、いつ入ったのかを確認しましょう。
WordPressはどこを更新すればよいのか
WordPressはPHPで動きますが、WordPressとPHPは別のソフトウェアです。WordPress公式のPHP更新ガイドも、WordPress本体・テーマ・プラグインの更新と、PHPの更新を分けて説明しています。
| 保守するもの | 共用レンタルサーバーでの主な担当 | 利用者が確認すること |
|---|---|---|
| PHP本体・実行環境 | サーバー事業者 | 今回の修正適用、対象サーバー、利用者操作の要否 |
| ドメインごとのPHP系列の選択 | サイト管理者・制作会社 | 古いPHPが個別指定されていないか |
| WordPress本体・テーマ・プラグイン | サイト管理者・制作会社。契約により保守事業者 | 更新、互換性、使っていない機能の整理 |
| Web以外のPHP実行 | 設定した担当者。契約により事業者 | 定期処理や独自導入PHPが残っていないか |
VPSや専用サーバーを自分で管理している場合は、PHPのパッケージ更新や実行プロセスへの反映も、自分たちの作業になります。「マネージド」という名前だけで任せきりにせず、契約上の保守範囲を確認してください。
WordPressが最新版でも、サーバー側のPHPが今回の修正前なら、PHPの対応確認は残ります。 反対に、PHPを修正しても、古いプラグインの別の脆弱性まで解消するわけではありません。
WordPress公式の推奨要件はPHP 8.3以上です。ただし、この推奨は今回の脆弱性に対する安全判定ではありません。テーマやプラグインの互換性を確かめつつ、今回の修正が適用された、サポート対象のPHPを使うことが必要です。
主要レンタルサーバー5社の対応状況
調査時刻：10月22日09:00〜09:02（日本時間）。各社の一般公開ページを再確認した結果です。 契約者としてログインした管理画面、個別通知、すべてのサーバー内の適用状態までは確認していません。告知がない・完了を確認できないことを「未対応」とは扱いません。
| サービス・確認した対象 | 公開情報で確認できた段階 | 利用者操作の要否・残る確認 |
|---|---|---|
| エックスサーバー公式の保守ページ（10月22日06:45更新、利用サーバー向け案内） | PHP 8.2〜8.5は対象全サーバーへの修正パッチ適用完了。 前夜の適用予定から進展。旧PHPは一部の版で準備が整い、検証済みから順次適用中。残る旧版も対応継続 | 自サイトが使うPHP系列と、管理画面再開後の追加案内を確認。具体的な追加必須操作はまだ提示されておらず、一律「操作不要」とは案内しない。画面・ツールは点検完了分から順次再開する方針で、全面再開は未確認 |
| ConoHa WINGの10月21日付保守告知（WINGの一部サーバー） | 確認した公開告知に実質的な変化なし。 10月21日19:00〜22日10:00のシステム保守予定を引き続き案内。今回のPHP・CVEとの関係、修正版の適用完了は未確認 | 今回のPHP切替等の要否は未確認。自分の対象サーバーと契約者向け通知、続報を確認。予定時刻だけで保守完了とは判断しない |
| ロリポップ！の緊急保守ページ（レンタルサーバーのサービスサイト・ユーザー専用ページ・MCP/API等） | 確認した本文は予防措置の案内のまま。 今回のPHP予告と公開前の保守を明記しているが、修正パッチの対象系列・適用完了の追加情報は確認できず | 具体的な追加操作の要否は未確認。ユーザー専用ページ等の停止中に切替できることを前提にせず、再開後に契約サーバーへの適用と追加案内を確認 |
| さくらのPHPバージョンアップ保守（レンタル・メールボックス・マネージド・リセール・ビジネスメール） | PHP更新保守が10月22日06:30に完了。 10月21日掲載の別告知を今回確認。作業期間は21日23:00〜22日06:30。CVE番号や完全な修正版番号の明記はなく、全旧系列を含む今回2件の修正完了までは断定しない | 古いPHP利用者へPHP 8.3の利用を依頼。 バックアップとテーマ・プラグインの互換性を確認し、公式の切替手順に沿って検討する。8.3という系列の選択だけで今回の修正適用済みとせず、提供版・適用状況も確認 |
| mixhostの保守完了情報（マイページ、10月22日08:31更新） | 08:30にマイページ保守完了、通常利用可能へ復旧。 前夜の終了未定から進展。ただしPHP・CVE・修正版の記載はなく、顧客PHPの修正完了を示す告知とは扱わない | マイページを再び利用できるため、契約先の案内を確認する。今回のPHP修正に関する追加操作の要否は未確認。Web・メールは保守中も通常利用可能と案内 |
保守中の公式ページにはHTTP 503を返しながら案内本文を表示するものがあり、本文も確認しています。これらは公開情報の観測結果であり、各社の全プラン・全サーバーの安全性を保証する一覧ではありません。
mixhostの10月21日付ニュースには終了未定の表記が残っていますが、同ページが最新情報として案内するステータスには08:30の完了が記載されています。今回は新しい完了記録を採用しています。
進展があった3社で、利用者が確認すること
- エックスサーバー：まず利用中のPHP系列を把握します。公式の完了範囲は8.2〜8.5で、旧系列は対応継続中です。管理画面が使えるようになったらドメインごとの系列と追加案内を確認してください。パッチ適用完了と、利用者のすべての保守作業が不要であることは別です。
- さくら：古いPHPを使っている場合は、提供元のPHP 8.3利用依頼を確認します。バックアップ・互換性・切替後の動作を確認しながら対応してください。今回の2件が修正済みかは、完全な版番号や提供元の適用情報でも確認します。
- mixhost：マイページ復旧により契約者向けの案内を確認できます。公開された復旧告知だけではPHP修正の追加操作要否は分からないため、必要な切替等があるかは契約先の案内で確かめてください。
さくらの総合案内がリンクする再起動を伴うシステム保守は、10月21日22:30完了の別作業です。今回確認したPHP更新保守や、別サービスのVPSへの対応と混同しないようにしています。
PHPを確認・変更する管理画面の入口
以下は、各社の公式マニュアルで確認した操作の入口です。サービスやプラン、管理画面の世代によって表示が異なります。
この表は、今回の2件への対策完了を示す一覧ではありません。 契約ごとの適用状況は、各社のお知らせ・契約者向け管理画面・サポートで確認してください。公開情報で完了告知を確認できないことと、「事業者が未対応」であることは同じではありません。
| サービス | PHPの確認・変更の入口 | 利用者が特に確認すること |
|---|---|---|
| エックスサーバー | サーバーパネル →「PHP Ver.切替」→ 対象ドメイン。公式手順 | ドメインごとの設定と、今回の修正を含む提供版かを確認 |
| ConoHa WING | WING → サイト管理 → サイト設定 → 応用設定 → PHP設定。公式手順 | サーバー共通設定だけでなく、ドメイン個別指定も確認。契約者向けのお知らせを読む |
| ロリポップ！ | ユーザー専用ページ → サーバーの管理・設定 → PHP設定。公式手順 | ドメイン別の設定と反映を確認。定期処理のPHPも別途確認 |
| さくらのレンタルサーバ | サーバーコントロールパネル → スクリプト設定 → 言語バージョン設定。公式手順 | 選択できる古い版の保守状況と、利用サーバーへの修正適用を確認 |
| mixhost | cPanel →「MultiPHP マネージャー」。旧プランは「Select PHP Version」。公式手順 | 新プランはドメイン単位、旧プランはアカウント単位。継承設定の実際のPHPも確認 |
過去の更新告知を、今回の修正と取り違えない
たとえばエックスサーバーの10月9日付の定期アップデート告知は、10月19日にPHP 8.5.11、8.4.26、8.3.35、8.2.34へ更新する内容です。いずれも今回公表された修正版より前の番号であり、この定期更新だけを今回の対策完了の根拠にはできません。独自修正の有無は別途確認が必要です。
同様に、一般的な「緊急メンテナンス」の告知だけでは、今回のPHP脆弱性に対応したかは読み取れません。対象の脆弱性、提供版、適用対象、完了時刻を確認してください。
また、さくらインターネットは10月21日、さくらのクラウドのデータベースアプライアンスについて、PHP脆弱性対応に伴うWeb UI機能の停止を公表しています。これは「さくらのレンタルサーバ」とは別サービスです。あるサービスの対応を、同じ会社の別サービス全体へ広げて解釈しないことも大切です。
サポートへ送る確認文の例
自分でPHP本体を更新できない場合は、次の形で確認すると状況を整理できます。パスワードや秘密鍵を文面に含める必要はありません。
PHPの重大脆弱性2件に関する、2026年10月21日のセキュリティリリースについて確認したいです。
PHP公式ではCVE-2026-109618、CVE-2026-109619として案内されています。
上流の修正版は8.5.12、8.4.27、8.3.36、8.2.35です。
対象：契約サービス名、サーバー識別情報、対象ドメイン
利用中のPHP：WordPressのサイトヘルス等で確認した完全な版番号
1. この契約・PHP実行環境への影響はありますか。
2. 修正適用済みですか。適用済みの場合、対象の提供版・パッケージと完了時刻を教えてください。
3. 利用者によるPHP切替や再設定などの作業は必要ですか。
4. 旧PHP系列、定期実行、管理ツールも対応範囲に含まれますか。
5. 直ちに修正できない場合、推奨する暫定的なアクセス制限はありますか。今すぐできること：修正適用を確認する5段階
ここからは、公式の注意喚起を受けて当社が提案する実務上の進め方です。実際の変更は、契約先の案内と自社の管理手順に合わせてください。
1. 公開サイトとPHPを一覧にする
まず、本番・テスト・旧サイトを含むドメイン一覧を作ります。WordPressだけでなく、問い合わせフォーム、独自のPHPプログラム、公開された管理ツールも対象です。PHPを利用していると把握できる機器・製品は、提供元の情報も確認します。
WordPressでは、管理画面 → ツール → サイトヘルス → 情報 → サーバー → PHPバージョンで確認できます。これは公式ガイドに記載された確認方法です。
| 記録するもの | 記入例・確認内容 |
|---|---|
| サイト | 本番、旧サイト、検証用サブドメイン |
| 契約先・担当者 | サーバー契約、制作会社、作業責任者 |
| PHP | 8.x.yまでの完全な版番号。事業者の独自修正有無は別記 |
| 更新状況 | 未確認／対象外と確認／修正適用を確認。根拠と確認時刻も記録 |
| 復旧準備 | ファイルとデータベースのバックアップ、復元手順 |
サイトヘルスの表示は手がかりであり、今回の2件が修正済みかを自動で保証するものではありません。確認のために、サーバー情報を大量に表示するphpinfo()のページを一般公開する必要もありません。
2. バックアップと作業の連絡先をそろえる
変更前に、ファイルとデータベースの両方をバックアップし、保存先と復元方法を確認します。バックアップファイルを誰でも取得できる公開ディレクトリに置かないようにしてください。
あわせて「誰がサーバーのお知らせを確認するか」「誰が変更できるか」「不具合が出たときに誰が判断するか」を決めます。緊急保守で管理画面を使えない場合は、公式の復旧・作業案内も確認します。
3. 適用までの公開範囲を判断する
CERT-EUは、直ちに修正できない場合、インターネット公開アプリケーションを公開ネットワークから隔離することを検討するよう勧めています。
具体的には、管理者と事業者へ相談し、サーバーやリバースプロキシなどPHPの処理に到達する前段でアクセス元を限定する、不要な検証サイトを非公開にする、必要に応じて一時停止する、といった方法を検討します。問い合わせや購入が止まる影響も確認して判断してください。
WordPressのメンテナンス表示プラグインは、表示を変えてもPHPの実行が続く場合があります。ログイン画面だけの制限でも、別のPHP処理が公開されたままなら、アプリケーション全体の隔離にはなりません。
Webアプリケーションファイアウォール（WAF）は補助策になりますが、今回の攻撃を遮断するルールや適用範囲が確認できなければ、「WAFを有効にしたから対応完了」とはいえません。 公開後のPHP公式も、設定変更だけによる完全な回避策はなく、修正版の適用が必要だとしています。
管理者向け：公開された暫定策の限界
以下はPHP公式が示した一時的な緩和策です。共用サーバーの利用者が見よう見まねで設定する手順ではなく、管理者が修正適用までの間に検討するものです。
| 暫定策 | 効果の範囲と注意点 |
|---|---|
memory_limit=-1を管理者側で強制し、有限値への上書きをなくす |
PHP内の予測可能なメモリ不足を減らす策。OSのメモリ割当失敗は残るため完全対策にならない。PHP内の上限を外すので、独立したリクエスト制限や適切なメモリ隔離がないと、メモリ枯渇・サービス停止を招くおそれがある |
session.upload_progress.enabled=0 |
確認済みのセッション関連経路を抑える。入力解析前に効くphp.ini・FPMプール・サーバー設定で指定し、全ワーカーを再起動する。ini_set()やFPMの.user.iniに頼らない。アップロード進捗表示への影響を確認 |
PHP 8.5のfatal_error_backtraces=0 |
確認済みのエラー診断経路に対する策。全ワーカーを再起動し、診断機能への影響も確認。ほかの経路まで解消するものではない |
| PHP前段での入力サイズ・項目数等の制限 | 大きな入力による負荷を減らす補助策。アップロード、フォーム等への影響を検証する。PHP公式はメモリ隔離の代替としてRLIMIT_AS・RLIMIT_DATAを使わないよう注意している |
設定変更を既存のワーカーにも反映させるには、全ワーカーの再起動が必要です。エラーの表示を隠すだけでは原因は解消しません。いずれの暫定策も、修正版の適用を先延ばしにする根拠にはしないでください。
4. 今回の修正を含むPHPを適用する
PHP公式の対象版・修正版情報と、契約先の対応案内を照合します。共用サーバーでは事業者の適用を確認し、利用者の切替が必要なら、バックアップと互換性確認のうえで実施します。「8.3」のような系列表示だけでは、8.3.36相当の修正が入っているかまでは判断できません。
同じ系列内の修正適用と、PHP 7系から8系などへの移行は、作業の大きさが異なります。互換性のある系列で今回の修正を取り込めるなら、まず緊急修正を進め、長期の移行計画とは分けて管理すると判断しやすくなります。ただし、サポート終了系列に留まり続ける理由にはなりません。
VPS・自前のサーバー・コンテナでは、OSベンダーやイメージ提供元の修正情報も確認します。パッケージやイメージを取得しただけで終わらず、必要な再起動・再作成などを提供元の手順に従って行い、稼働中の環境への反映を確かめます。
5. 適用を確認し、サイトの重要な動作を確かめる
適用後はPHPの情報と事業者の完了案内を記録し、トップページ、管理画面へのログイン、画像表示、投稿編集などを確認します。フォームはテスト宛先への到着まで、購入機能はテスト環境や決済事業者が提供するテスト機能を使って確認してください。
トップページが表示されたことと、修正が入ったこと、フォームや決済が正常に動くことは、それぞれ別の確認です。 セキュリティ修正の証拠と、機能が正常に動いた記録を両方残しましょう。
制作会社・管理者が見落としやすい3か所
Web用PHPと、定期処理用PHPの違い
サーバー上でコマンドを実行できる場合、php -vで分かるのは、そのコマンドが指すPHPの版です。Webサイトが使うPHPと一致するとは限りません。Web側の表示と、定期処理・コマンド側を分けて確認してください。
実例として、ロリポップのcronマニュアルは、ドメインのPHPを変更しても、既存のcron設定が使うPHPは変わらず、設定し直す必要があると説明しています。cronは、サーバー上で処理を定期実行する仕組みです。
使っていないつもりの旧サイトや管理ツール
通常のサイトを更新しても、移行前のWordPressや検証用サブドメインが公開されたままでは、確認漏れが残ります。不要な公開物も洗い出し、残すものには修正を適用します。
Web管理画面を一時停止する対応例も出ています。前述のさくらのクラウドの告知のように、普段意識していない管理ツールについても、その製品・サービスの提供元の案内を確認しましょう。
更新後の不具合で、古いPHPへ戻したままにする
PHPを切り替えてエラーになった場合は、テーマやプラグインの互換性、ログを調べます。業務継続のために一時的に戻す判断が必要でも、未修正の可能性がある環境を無期限に再公開するのは避けてください。公開制限、修正済みの別系列への切替、問題のある機能の停止などを管理者と相談します。
戻せる版に制限があるサービスもあります。たとえばロリポップの公式手順には、PHP 7.1未満から変更すると元の版へ戻せない旨の注意があります。「エラーなら必ず元に戻せる」と仮定せず、変更前に契約先の条件を読みましょう。
改ざんなどの異常がある場合は、修正適用だけで終えない
身に覚えのない管理者アカウント、ページの書き換え、不審な転送、見覚えのないファイルなどがあれば、今回の脆弱性との関係を断定せず、インシデントとして調査します。
公開範囲を制限し、気付いた時刻や症状、ログ、現在のファイルを保全したうえで、サーバー事業者や保守担当へ連絡してください。侵入経路を修正することと、既に置かれた不正ファイルや漏えいした認証情報への対応は別です。
WordPress公式の侵害対応ガイドも、症状の記録、ホスティング事業者への確認、ファイルとデータベースの保存、侵害の除去などを案内しています。原因を調べずにバックアップだけ戻すと、未修正の入口や不正な変更も戻してしまう可能性があります。
今日の対応を「誰かがやったはず」で終わらせない
今回、サイト運営者が今すぐできるのは、PHPを使う公開環境を把握し、契約先の対応を確認し、今回の修正が稼働環境に反映された証拠を残すことです。新しい系列のPHPを選ぶだけでも、WordPressの更新ボタンを押すだけでも、今回の対応確認を終えたことにはなりません。
最初の1件について、「どのサイトの、どのPHPに、今回の修正が、いつ適用されたか」を言える状態にしましょう。その確認を本番、旧サイト、検証環境、定期処理へ広げていくのが、具体的な一歩です。
PHPとあわせてNode.jsも使っている場合は、PHPの重大脆弱性への対応とあわせて、Node.jsも確認を——見落としたくない3つのポイントもご覧ください。HTTPSの接続先確認と、保守担当に聞く3つのことを図解で整理しました。
更新履歴
- 2026年10月22日09:02追記：5社を朝に再確認。エックスサーバーのPHP 8.2〜8.5修正完了と旧系列の継続対応、さくらのPHP更新保守完了・旧PHP利用者への案内、mixhostのマイページ復旧を反映しました。会社ごとの利用者操作と未確認範囲を追記し、画面復旧とPHP修正完了を区別しました。
- 2026年10月21日23:08追記：PHP公式の修正版と2件のCVEの対応、対象版、実行方式ごとの条件、旧系列への例外的ソース修正、暫定策を反映。5社の公式公開情報を再調査し、公開前の予告中心の記述を更新しました。
- 2026年10月21日21:55確認時点の初稿：23:00の修正公開予告を受け、棚卸し・契約先への確認と適用準備を整理しました。
参考：確認した一次情報
- PHP公式：Critical remote code execution vulnerabilities, update now／変更履歴
- PHP公式：CVE-2026-109618／CVE-2026-109619
- PHP公式の例外的なソース修正：7.4用／8.0用／8.1用
- PHP公式：Upcoming Critical PHP Security Release（10月20日付）
- IPA：PHPのセキュリティリリース公開予定について（10月21日公開）
- CERT-EU：Critical Vulnerabilities in PHP
- PHP公式：Supported Versions／Unsupported Branches
- WordPress公式：PHP更新ガイド／推奨要件／サイトヘルスの説明
各サーバーの操作手順と個別告知は、比較表と該当節から公式ページへリンクしています。情報は確認時点のものです。以後のPHP公式と契約先の最新案内も確認してください。