PHPの重大な脆弱性（PHP2Shell・2026年10月）最新情報｜修正版・対策と各社の対応状況

最終更新：10 月 23 日 11:37（日本時間） 新しい情報が出るたびに更新しています。
すぐ見る：最新の状況 ／ Web サービスの対応状況 ／ サーバー会社の対応状況 ／ 一般の人 ／ サイトの持ち主 ／ 管理者

PHP の開発チームは 10 月 21 日 22:34 ごろ（日本時間）、予定していた 23:00 より早く、重大な脆弱性 2 件を修正した PHP 8.5.12・8.4.27・8.3.36・8.2.35 を公開しました。どちらも、ログインなしで外からプログラムを実行されるおそれがある（リモートコード実行）もので、PHP 公式はすべての利用者にすぐ更新するよう強く勧めています。研究者や報道のあいだでは「PHP2Shell」と呼ばれ、SNS やニュースでは深刻度や影響範囲について、さまざまな情報が出回っています。

PHP は、WordPress をはじめ多くのホームページの仕組みを動かしているプログラミング言語です。この記事では、一般の人・サイトの持ち主・サーバーやサイトの管理者のそれぞれがいますることを先にまとめ、出回っている情報が公式に確かめられるものかの判定と、主要なサーバー会社の対応状況を続けます。新しい情報が出るたびに、日時つきで最新情報を追記します。

一般の人（サイトを持っていない人）がいますること

今回の脆弱性は、Web サイトを動かすサーバーの側の問題です。英国の国家サイバーセキュリティセンター（NCSC）も、PHP を Web サーバーの上で動いてページを作り、できあがったページを見る人のブラウザに届ける言語だと説明しています。スマホやパソコンに PHP を入れて使っているわけではないので、見る側が自分の端末で更新するものはありません（この記事での整理）。

• スマホやパソコンで、何かを更新・インストールする必要はない 「PHP の脆弱性対策」をうたうアプリやソフトのインストールや、リンクを開くよう求めるメール・SMS には応じないでください。
• 使っているサービスが止まっていても、慌てない 修正版を入れるまで、予防のためにサービスを止めている会社があります。各サービスの公式のお知らせで再開を待ちます（主な例は「主要な Web サービスの対応状況」）。
• パスワード変更の案内が来たら従う。使い回しているパスワードも変える 不正アクセスを公表したフューチャーショップは、同じパスワードをほかのサービスでも使っている場合は、そちらも変えるよう呼びかけています。
• そのサービスを装った連絡に気をつける フューチャーショップは、同社などを装った不審なメール・電話・SMS に注意するよう呼びかけ、メールや電話でパスワードやログイン情報を尋ねることはないとしています。
• 情報は公式のお知らせで確かめる SNS などでは、確かめられていない情報も出回っています（「出回っている情報は正しいか」）。

サイトの持ち主がいますること

修正版（8.5.12・8.4.27・8.3.36・8.2.35）はすでに出ています。今回の修正は PHP 本体のもので、WordPress 本体やプラグインを更新しても直りません。会社のホームページを持っていて、サーバーの管理は自分でしていない人向けです。

• 共用のレンタルサーバー（エックスサーバー・さくらのレンタルサーバ・ConoHa WING・ロリポップ！など）を使っている 修正版を入れるのはサーバー会社で、利用者が PHP 本体を入れ替えることはできません。サーバー会社のお知らせ・障害情報のページと公式の SNS を見て、修正版をいつ入れるか、利用者の作業が要るかを確かめます。管理画面が止まっている会社では、再開後のお知らせに利用者への依頼が書かれることがあるので、再開したら見落とさないように読みます。（各社の状況は「主要なサーバー・サービスの対応状況」）
• 制作会社・保守会社に任せている 任せきりにせず、連絡して 3 つを確かめます。サイトがどのサーバーの、どの PHP のバージョンで動いているか。修正版に更新したか（いつ更新するか）。PHP 8.1 以前で動いていないか。保守の契約に含まれない作業なら、費用と時期もこのとき決めます。
• サイトを自分で止める必要は、基本的にない 欧州連合や英国の機関が勧めているのは、すぐに修正できない場合に限った切り離しです。共用のレンタルサーバーなら、まずサーバー会社の案内に従います。管理画面に入れなくても、予防のために止めている会社があり、サイトの表示とメールは通常どおりとしている会社もあります。（各社の状況は「主要なサーバー・サービスの対応状況」）

サーバー会社の作業が終わったら確かめること

1. WordPress なら、管理画面の「ツール」→「サイトヘルス」→「情報」→「サーバー」で PHP のバージョンを見る（手順は「自社のサイトの PHP のバージョンを確かめる」）
2. 8.2 系なら 8.2.35、8.3 系なら 8.3.36、8.4 系なら 8.4.27、8.5 系なら 8.5.12 以上になっていれば、修正版に切り替わっている
3. 8.1 以前なら、対処済みとは考えない。修正を入れるかをサーバー会社に確認し、8.2 以上（できれば 8.3 以上）へ上げる相談を制作会社・保守の担当に急いでする。上げる前にバックアップを取る
4. 切り替わったら、トップページ・主なページの表示と、問い合わせフォームの送信を試す

サーバー・サイトの管理者がいますること

VPS・クラウド・自社のサーバーを管理している人、保守を請け負っている制作会社の担当者向けです。誰も代わりに更新してくれません。

1. 管理しているサーバーとサイトのうち、PHP を使っているものを洗い出す。インターネットに公開しているものを優先する（英国 NCSC の呼びかけ）
2. すぐに修正版（8.5.12・8.4.27・8.3.36・8.2.35）へ更新し、PHP-FPM や Web サーバーなど PHP の作業プロセスを再起動する。Linux の配布元の更新パッケージで入れている場合は、配布元の更新を確かめる
3. Apache の mod_php で動かしているサーバーを最優先にする（PHP 公式がリスクが最も高いとしている）
4. 8.1 以前は公式の修正版が出ない。配布元・長期サポートの提供元が修正を出すかを確かめ、サポート中のバージョンへの移行を急ぐ
5. すぐに更新できない場合は、PHP 公式の暫定策（「PHP 公式の発表内容」）を入れたうえで、欧州連合や英国の機関が勧めるように、更新できるまで公開から外すことも検討する。暫定策だけでは安全にならない
6. 更新のあと、サイトの表示・フォーム・管理画面が動くかを確かめ、顧客のサイトを預かっている場合は、対応の状況を顧客に伝える
7. 更新と並行して、すでに攻撃を受けていないかを調べる。国内のセキュリティ事故への対応を調整する JPCERT/CC の注意喚起は、脆弱性の発見者らが公開した情報をもとに、ログで次の痕跡を確かめることを挙げている：不自然に長い、または形のおかしい PHPSESSID の Cookie を返していないか／不審な multipart/form-data のリクエストと、その前後に PHP のメモリ上限のエラーや HTTP 500 が出ていないか／PHP の作業プロセスが異常終了や再起動を繰り返していないか。痕跡が見つからなくても攻撃を受けていないとは言い切れないとしていて、不審なプロセス・外部への通信・不審なファイルも確かめ、疑わしければログを保全して切り離すよう求めている

これまでの経緯

日時は日本時間です。新しいものを上に足していきます。いちばん上の「【最新】」の行が、現在の状況です。

PHP 公式の発表内容

PHP は 10 月 21 日 22:34 ごろ、PHP 公式サイトのお知らせ「Security advisory: Critical remote code execution vulnerabilities, update now」と、開発元（GitHub の php-src）のセキュリティ勧告 2 件を公開しました。書かれていることを、ホームページの担当者向けにまとめます。

• 重大な脆弱性が 2 件。どちらもリモートコード実行 CVE-2026-109618 は、メモリが足りなくなったときの処理の不具合です。処理が途中で中断されると、準備の途中のデータを、後片付けの処理が正しいデータとして扱ってしまいます。CVE-2026-109619 は、前のリクエストで使った情報が、メモリを解放したあとも残ってしまう不具合です。同じ作業プロセスが次のリクエストを処理するときに、その古い情報を使ってしまいます。どちらも、ログインなしで外からプログラムを実行されるおそれがあります。深刻度はどちらも CVSS v4.0 で 9.2 です。CVSS は脆弱性の深刻度を 0〜10 で表す共通の尺度で、CVSS の仕様書（CVSS v4.0 Specification Document）の区分では、9.0〜10.0 は 5 段階のうち「Critical」にあたります。
• 修正版は 8.5.12・8.4.27・8.3.36・8.2.35 PHP 公式は、すべての利用者にすぐ更新するよう強く勧めています。Linux の配布元や長期サポートの提供元には事前に修正を渡してあるとして、サーバーを自社で管理している場合は、使っている配布元の更新を確かめるよう案内しています。
• Web のリクエストを処理するすべての PHP が対象 PHP-FPM、Apache の mod_php、php-cgi、FrankenPHP、LiteSpeed を挙げています。PHP 公式サイトのセキュリティのお知らせによると、中でも mod_php は、ログインなしのリクエストでプログラムが動く前に攻撃が成り立つことが示されていて、リスクが最も高いと PHP 公式は見ています。
• 8.1 以前は PHP 公式の更新の対象外 8.1 以前には、8.3.36 のような新しいバージョン（公式が組み立てて配る完成品）は出ません。深刻さを考えて、7.4・8.0・8.1 向けには「プログラムのこの部分をこう直す」という最小限の修正（ソースコード）を公開しましたが、これは PHP を自分で組み立てられる技術者やサーバー会社が使う材料です。共用のレンタルサーバーの利用者が自分で当てることはできず、守られるかどうかはサーバー会社がこれで直すかしだいです。PHP 公式も、提供元に確認するか、サポート中のバージョンへ上げるよう勧めています。
• 完全な対策は更新だけ すぐに更新できない場合の設定の変更も示していますが、特定の攻撃の経路を減らすだけで、安全にはならないとしています。

すぐに更新できない場合として PHP 公式が挙げている暫定策は、次のとおりです。どれもサーバーの設定を変えるもので、サーバーを自社で管理している場合の話です。共用のレンタルサーバーの利用者が自分で変えられるものは限られるため、サーバー会社の案内を待つのが基本です。

• CVE-2026-109618 向け memory_limit を -1 にしてアプリ側で上書きできないようにする、post_max_size を小さくする（アップロードが要らなければ 8M、要るなら 32M）、Web サーバー側でリクエストの大きさや項目の数を制限する、など。それでも別の経路は残るとしています。
• CVE-2026-109619 向け session.upload_progress.enabled を 0 にしてすべての作業プロセスを再起動する（ini_set() や .user.ini では効かない）、PHP 8.5 なら fatal_error_backtraces を 0 にする、など。確認された経路の一部を止めるだけで、ほかの経路は防げないとしています。

出回っている情報は正しいか

PHP 公式が詳細を出していない間に、報道やセキュリティ企業の発言で、公式より踏み込んだ情報が広まっています。PHP 公式・公的機関の発表と照らした、現時点の判定です（この記事での整理）。

• 「深刻度は CVSS 10.0（満点）」 判定：公式と食い違う。PHP 公式は CVSS v4.0 で 9.2。10.0 は、公式の告知より前に海外の掲示板や研究者の発言として広まった数字
• 「CVE 番号は CVE-2026-109618 と CVE-2026-109619」 判定：正しい（公式で確認済み）。PHP の開発元が 22:34 に公開したセキュリティ勧告が、この 2 つの番号を使っている
• 「PHP 5 以降のすべて（5・6・7・8）が影響を受ける」 判定：一部は不正確。PHP 公式は、サポート中の 8.2〜8.5 に修正版を出し、8.1 以前は公式の更新の対象外とした（7.4・8.0・8.1 向けには、技術者向けの最小限の修正だけを公開）。それより古いバージョンについてお知らせは触れていない。一方で Cloudflare は、PHP 5.4 以降を動かすすべての Web サーバーが影響を受けるとしていて、8.1 以前も対象と見てよい。なお PHP 6 は正式なリリースに至らず、次のバージョンは 7 になった（PHP 公式の Wiki）
• 「外から PHP のプログラムを実行される（リモートコード実行）」 判定：正しい（公式で確認済み）。PHP 公式は、2 件ともログインなしでリモートコード実行を許すおそれがあるとしている
• 「詳細が予定より早く漏えいした」 判定：公式は未確認。報道とセキュリティ企業の主張。PHP 公式の告知に漏えいという言葉はない（詳細が公になった場合は前倒しで公開する、とだけ書いている）
• 「すでに攻撃に使われている」 判定：攻撃の試みは観測されている。Web の配信と防御のサービスを提供する Cloudflare は、脆弱性の情報が公式の公開日より前に漏れていて、利用者を狙う攻撃の通信を観測したとしている。修正版の公開前、IPA は悪用した攻撃を確認しているわけではないとしていた。一方で GMO Flatt Security は、悪用できると主張するコードがインターネット上に出回り始めているとしており、修正版が出たらすぐに当てられる準備が要る。修正版の公開後には、レンタルサーバーのヘテムルも、脆弱性を狙ったとみられるアクセスを確認したと公表した（それによる不正アクセスや情報漏えいは確認されていないとしている）。なお、EC サイトの仕組みを提供するフューチャーショップは 21 日、一部のサーバーへの不正アクセスを確認したと公表したが、影響範囲は調査中としており、PHP の脆弱性によるものとは書いていない（PHP の脆弱性については、別のお知らせで予防のために一部の機能を止めたと説明している）
• 「php.ini の設定（session.upload_progress.enabled を無効にする）で防げる」 判定：それだけでは防げない（公式で確認済み）。PHP 公式は、この設定は確認された経路の一部を止めるだけで、ほかの経路は防げないとし、完全な対策は更新だけだとしている。この設定を最初に勧めた GMO Flatt Security も、根本的には修正版の適用が必要だと追記している
• 「EU や英国の当局がサイトを止めるよう警告している（自社のサイトも止めるべき）」 判定：条件つき。欧州連合の機関の CERT-EU は、修正版をすぐに適用する準備を勧めたうえで、すぐに修正できない場合に限り、インターネットに公開しているアプリを修正まで切り離すことを検討するよう勧めている。英国の国家サイバーセキュリティセンター（NCSC）も、PHP を使うシステムをすぐに更新できるよう準備し、すぐに対処できない場合は、対処できるまでシステムをオフラインにすることを検討するよう勧めている。どちらも、止めることを一律に求めているわけではない。レンタルサーバーなら、まずサーバー会社の案内に従う。8.1 以前で修正版が出ないなど、すぐに直せない事情がある場合は、一時停止も含めて制作会社・保守の担当と相談する
• 「PHP はウェブの 7 割で使われている」 判定：おおむね正しい（数え方に条件あり）。Web 技術の利用状況を集計している W3Techs の 10 月 21 日の数字では、サーバー側のプログラミング言語が分かるサイトの 69.3% が PHP を使っている。同じ集計で、PHP を使うサイトのうちバージョン 7 は 27.0%、5 は 7.7% あり、どちらもサポートを終えたバージョン
• 「WordPress を最新にすれば大丈夫」 判定：誤り。PHP はサーバーに入っているもので、更新はサーバーの設定かサーバー会社が行う（WordPress 公式の説明）。WordPress の更新では PHP は変わらない
• 「サーバーの管理画面に入れない＝サイトが止まった・被害を受けた」 判定：そうとは限らない。エックスサーバーは予防のために管理画面などを止めていて、不正アクセスによるものではなく、サイトの表示とメールは通常どおりとしている（サーバー会社の対応状況）

22:34 の公式の発表で、CVE 番号とリモートコード実行は正しかったと確かめられました。一方で CVSS 10.0 は公式と食い違ったままで、影響する範囲も「PHP 5 以降のすべて」という言い方は公式の発表と合いません。

主要なサーバー・サービスの対応状況

各社の公式のお知らせ・公式アカウントに書かれていることだけを並べています（10 月 23 日 11:37 時点。状況の列は各社の告知にもとづく）。PHP の件と書かれていないメンテナンスは、そのことを明記して載せています。

このほかのサーバー会社は、確認した時点で今回の件のお知らせが見つからなかったか、確認できていないものです。載っていないからといって対応していないわけではありません。契約しているサーバー会社のお知らせ・障害情報のページと、公式の SNS アカウントを確かめてください。管理画面が止まっている間は、PHP のバージョンを切り替える操作もできません。

サーバー会社ごとの状況

エックスサーバー の PHP の脆弱性への対応状況

パッチ適用済み 22 日 6:44、PHP 8.2〜8.5 について、対象となるすべてのサーバーへの修正パッチの適用が完了したと告知（公式 X）。22 日 12:08 に PHP 7.4〜8.1、14:03 に PHP 5.6〜7.3 についても、対象のすべてのサーバーへの修正パッチの適用が完了したと告知。5.5 以前は修正パッチの準備と検証を進めている。22 日 10:21 にアカウント管理画面などの機能と、ドメイン関連を除く新規申し込みの受付を再開（公式 X）。各種サービスサイトも 20:10 から順次再開（一部の機能はメンテナンスを継続）。21:14 時点で、PHP 5.6〜8.5 は対象のすべてのサーバーで修正パッチを適用済み、5.5 以下は修正パッチの作成と検証を続けていると告知し、定期的な状況報告はいったん終了（公式 X）。サイトの表示とメールの送受信は通常どおり

確認：10 月 23 日 11:37 時点（日本時間）／公式の出典： エックスサーバー公式 X

さくらのレンタルサーバ の PHP の脆弱性への対応状況

完了 22 日のお知らせで、レンタルサーバ・マネージドサーバ・リセール向けサービスについて、コントロールパネルで選べるすべての PHP のバージョンで脆弱性への対応を完了したと告知。利用者が急いでする対応はないが、サポート中の最新の PHP への移行も検討するよう勧めている。phpMyAdmin とウェブメールも対応を進め、ウェブメールは 13:45 に完了。VPS の緊急メンテナンスは 22 日 17:40 に完了

確認：10 月 23 日 11:37 時点（日本時間）／公式の出典： さくらインターネットのお知らせ

ロリポップ！ の PHP の脆弱性への対応状況

再開 PHP の重大な脆弱性への予防措置として、21 日夜からサービスサイト・ユーザー専用ページなどを停止。停止していた利用者のサイトは、修正版を適用して 22 日 13:11 に再開。公式の修正版がない旧バージョンの PHP にも独自の修正を適用し、サービスサイトも一部を除きまもなく再開予定（公式 X）

確認：10 月 23 日 11:37 時点（日本時間）／公式の出典： ロリポップ！公式 X

ヘテムル の PHP の脆弱性への対応状況

再開 修正の適用が終わるまで、22 日 3:05 ごろから一部のサーバーで利用者のサイトの表示を止め、11:24 に再開（コントロールパネルは 12:12）。8.2〜8.5 は公式の修正版、7.4〜8.1 は公式の修正コード、5.6〜7.3 は自社で作った修正を適用し、すべてのバージョンで session.upload_progress を無効にしたので、サイトの動作確認を求めている。脆弱性を狙ったとみられるアクセスを確認したが、不正アクセスや情報漏えいは確認されていない（22 日 18:05 のお知らせ）

確認：10 月 23 日 11:37 時点（日本時間）／公式の出典： ヘテムルのお知らせ

KAGOYA の PHP の脆弱性への対応状況

対応中 レンタルサーバープランの PHP 7.4・8.1〜8.5 系は修正版への更新を順次進めていて、22 日 24 時の完了を見込む（18:15 更新）。マネージド専用・共用・WordPress 専用サーバープランは恒久的な対応を調整中で、当面のリスクを下げる方法として、サイトの公開停止（メンテナンス画面への切り替え）やアクセス制限の検討を呼びかけ、.htaccess でアクセスを止める書き方も案内している

確認：10 月 23 日 11:37 時点（日本時間）／公式の出典： KAGOYA のお知らせ

ConoHa WING の PHP の脆弱性への対応状況

一部停止 21 日 19:00〜22 日 10:00 に緊急のサーバーメンテナンス（システムの保守作業。終了の告知はまだ）。22 日、予防保守としてファイルマネージャーと Web メールを一時停止し、再開までメールソフトや FTP ソフトでの代用を案内（PHP とは明記していない）

確認：10 月 23 日 11:37 時点（日本時間）／公式の出典： ConoHa WING のお知らせ

お名前.com レンタルサーバー の PHP の脆弱性への対応状況

メンテナンス ベーシック・RS プランなどは 21 日 19:00〜22 日 10:00、共用サーバー GS は 21 日 23:00〜22 日 9:00 に、緊急のサーバーメンテナンス（システムの保守作業）。予定の時刻は過ぎたが、完了の告知は見当たらない（PHP とは明記していない）

確認：10 月 23 日 11:37 時点（日本時間）／公式の出典： お名前.com のお知らせ

カラフルボックス の PHP の脆弱性への対応状況

完了 PHP の脆弱性について、全サーバーの保護措置と修正版への更新は 22 日朝までにすべて完了したと告知。8.2〜8.5 に加え、7.4・8.0・8.1 などの旧バージョンもサーバー側で修正と保護措置を適用済みで、利用者がバージョンを変える作業は不要

確認：10 月 23 日 11:37 時点（日本時間）／公式の出典： カラフルボックスのサーバーステータス

バリューサーバー・コアサーバー の PHP の脆弱性への対応状況

完了 PHP の脆弱性への対応として全サーバーのソフトウェア更新を実施し、バリューサーバーとコアサーバー V1 は 22 日 0:50、コアサーバー V2 は 11:13 に完了。利用者が PHP のバージョンを変える必要はない

確認：10 月 23 日 11:37 時点（日本時間）／公式の出典： バリューサーバーのお知らせ

mixhost の PHP の脆弱性への対応状況

完了 21 日に一部のサーバーで「サーバー安定化のため」の緊急メンテナンスを実施し、完了済み（PHP とは明記していない）

確認：10 月 23 日 11:37 時点（日本時間）／公式の出典： mixhost のお知らせ

主要な Web サービスの対応状況（順次追記）

ふだん使われている Web サービスでも、予防のためのメンテナンスや停止が相次いでいます。ここでは、通販・業務システム・ゲーム・アプリ・金融など、利用者が直接使うサービスに絞り（会社の Web サイトだけの停止は載せていません）、各社の公式のお知らせ・公式アカウントで確かめられたものから順に載せ、確認でき次第追記します（10 月 23 日 11:37 時点。状況の列は各社の告知にもとづく）。止まっていても、多くは予防のための停止です。再開や利用者へのお願いは、各サービスの公式のお知らせで確かめてください。

IPA は事前の準備を呼びかけている

情報処理推進機構（IPA）は 10 月 21 日、「【事前準備のお願い】PHPのセキュリティリリース公開予定について」を掲載しました。今回の 2 つの脆弱性について、現時点で悪用した攻撃を確認しているわけではないとしたうえで、修正版の公開後すぐに適用できるよう、事前の準備を求めています。

IPA は、サポートを終えた古い PHP を使い続けているウェブサイトも見受けられるとし、攻撃者が極めて短い時間で攻撃を実行する可能性もあるため、修正の公表後はできるだけ早く適用できるよう準備してほしいとしています。そのために、PHP を使っているものを可能な範囲で棚卸しするよう勧めています。

ホームページの担当者にとっての棚卸しは、自社のサイト（会社のサイト・採用サイト・予約やお問い合わせの仕組みなど）が、どのサーバーで、どの PHP のバージョンで動いているかを書き出しておくことです。

修正版が出るのはサポート中のバージョンだけ

PHP 公式サイトのサポート期間の表（Supported Versions）によると、PHP の各バージョン（系統）は、最初のリリースから 2 年間は全面的にサポートされ、その後の 2 年間は重大なセキュリティの問題だけが修正されます。合わせて 4 年のサポートが終わると、その系統はサポートを終え、修正版は出ません。

今回の修正版も、サポート中の 8.2〜8.5 にだけ出ました。PHP 公式サイトのサポート終了の表（Unsupported Branches）のとおり 8.1 はすでにサポートを終えていて、8.1 以前で動いているサイトには公式の修正版が届きません。8.2 もサポートの残りは約 2 か月です。

WordPress 公式サイトは、WordPress を動かすサーバーに PHP 8.3 以上を推奨しています。PHP 7.4 以上でも動作はするものの、サポートを終えたバージョンはサイトがセキュリティの脆弱性にさらされる可能性があるとして、アップグレードを強く勧めています。

自社のサイトの PHP のバージョンを確かめる

WordPress なら、管理画面から確かめられます。WordPress 公式サイトの PHP の更新の案内（Update PHP）が示している手順です。

1. 管理画面の左のメニューで「ツール」→「サイトヘルス」を開く
2. 上部の「情報」タブを開く
3. 「サーバー」の項目を開き、「PHP バージョン」の行を見る（例: 8.3.35）

「8.3.35」のうち、前の「8.3」が系統、最後の「35」がその系統の中の修正の番号です。今回の修正版は 8.2 系なら 8.2.35、8.3 系なら 8.3.36、8.4 系なら 8.4.27、8.5 系なら 8.5.12 です。これ以上の番号になっていれば、修正版に切り替わっています。

管理画面に入れない場合や WordPress 以外の仕組みの場合は、契約しているレンタルサーバーの管理画面で、ドメインごとの PHP のバージョンの設定を確かめます。

サーバー会社と制作会社に確認すること

WordPress 公式サイトの PHP の更新の案内は、PHP はサイトのサーバーに入っているため、更新するにはサーバーの設定を操作するか、サーバー会社に頼むことになると説明しています。共用のレンタルサーバーなら、修正版を入れるのはサーバー会社で、利用者の側では管理画面でドメインごとにどの系統を使うかを選ぶのが一般的です。誰に何を確認するかを分けておきます（この記事での整理）。

系統を上げる（例: 8.1 から 8.3 へ）ときは、古いテーマやプラグインが動かなくなることがあります。いきなり本番を切り替えず、制作会社や保守の担当に確かめてから進めます。

ソフトの更新・パスワード・バックアップなど、普段からの対策は ホームページのセキュリティ対策 に、保守を頼むときの費用の考え方は ホームページの維持費 にまとめています。

作り方は 3 つ｜完成済み・自作・オーダーメイド

作り方はどれでも選べます。優劣ではなく、向いているケースが違います。

• オーダーメイドで作る（制作会社に依頼） 要件を渡せば設計から任せられます。自社に合わせて一から作りたい場合や、撮影・原稿まで任せたい場合に向きます。SITE PICK でもオーダーメイド制作の相談を受け付けています。

  オーダーメイド制作を相談する オーダーメイド制作との違い

• 自分で作る（自作） 費用は抑えられます。そのかわり、今回のような PHP や WordPress の更新の確認を、公開後もずっと自分で続けることになります。
• 完成済みのサイトから選ぶ（完成済み） 構成・更新の仕組み・入口が組まれた状態を実物で確かめ、社名・写真・文章を差し替えて公開します。完成形を先に確認してから決めたい場合に向きます。この記事の集計は、その実際のサイトのデータです。

  完成済みのサイトを実物で見る