サイト所有者向けガイド · PHP

PHPのバージョンを確認し、安全に更新する方法

サイト所有者向けに、WordPress・管理パネル・SSHでのPHP確認、完全バックアップ、環境別の2026年10月の修正適用手順を説明します。

更新が必要な理由

PHPは2026年10月21日、CVE-2026-109618とCVE-2026-109619の修正を公開しました。Webリクエストを処理するPHP環境で、認証なしのリモートコード実行につながる脆弱性です。サイトが使うブランチを修正版に更新するか、両方の修正を含むベンダーのパッケージを適用してください。

PHPブランチPHP.netの修正版
PHP 8.58.5.12
PHP 8.48.4.27
PHP 8.38.3.36
PHP 8.28.2.35

PHP 8.1以前にはPHP.netの通常リリースによる更新がありません。ディストリビューションやLTSベンダーのバックポートを確認するか、サポート中のブランチに移行してください。PHP 8.2も2026年12月31日にサポート終了となるため、移行を計画しましょう。

公式情報: PHP.net · 2026

1. 変更前に完全バックアップを取る

  1. ファイル・データベース・設定を保存

    サイトと対象サーバーまたはサービスの完全バックアップを取ります。アップロード済みファイル、PHP設定、Webサーバー設定も含めてください。サーバー外にコピーを保管し、復元できることを確認します。

  2. 検証とメンテナンスの準備

    各サイトの現在のバージョン、拡張機能、ドメイン、プールを記録します。可能ならステージング環境で試し、互換性の問題が出た場合の復旧方法を決めます。脆弱なPHPに戻す必要がある場合は、修正までサイトを停止したままにしてください。

2. サイトが実際に使うPHPを確認する

  1. WordPress

    管理画面で「ツール → サイトヘルス → 情報 → サーバー」（Tools → Site Health → Info → Server）を開き、PHPバージョンを記録します。これはWeb側の情報です。ディストリビューションのパッケージを使う場合は、完全なパッケージリビジョンもホストに確認します。

  2. cPanel / Plesk

    cPanelでは「Software → MultiPHP Manager」で各ドメインを確認します。Pleskでは「Websites & Domains → 対象ドメイン → PHP Settings」を開きます。有効なバージョンとハンドラーを記録してください。ドメインごとにPHPが異なる場合があります。

  3. SSH：CLIとPHP-FPM

    所有するサーバーで両方を確認します。CLIとWeb側のPHPは一致するとは限りません。php-fpmコマンドがない場合はphp8.3-fpm -vのようなブランチ別のコマンドを使います。Apacheのmod_phpを使う場合は、有効なモジュールとパッケージも確認します。

    php -v
php-fpm -v

  4. Ubuntu / Debian：パッケージ全体の番号を確認

    以下はPHP 8.3とFPMの例です。名前は実際の環境に合わせます。apt policyではインストール済み・候補バージョンとリポジトリを、dpkg -lではPHP・拡張機能・Apacheモジュールを確認できます。

    php8.3-fpm -v
apt policy php8.3-fpm php8.3-cli php8.3-common
dpkg -l 'php*' 'libapache2-mod-php*'

ディストリビューションは古いPHPの番号を維持したまま修正を取り込むことがあります。UbuntuのPHP 8.3.6でも修正済みの場合があるため、php -vだけで判断せず、完全なパッケージリビジョンと配布元を公式の通知と照合してください。以下は公開済みの修正リビジョンです。それ以降の番号も同じベンダーで確認してください。

OSとパッケージ修正済みリビジョン
Ubuntu 22.04 · php8.18.1.2-1ubuntu2.28
Ubuntu 24.04 · php8.38.3.6-0ubuntu0.24.04.13
Ubuntu 26.04 · php8.58.5.4-0ubuntu1.5
Ubuntu 26.10 · php8.58.5.9-0ubuntu2.1
Debian bookworm · php8.2 · DLA-4848-18.2.35-1~deb12u1
Debian trixie · php8.4 · DSA-6574-18.4.27-1~deb13u1

UbuntuはUSN-8948-1を参照してください。古いOSではUbuntu Proが必要な場合があります。DebianはtrixieがDSA-6574-1、bookwormがDLA-4848-1です。このガイドの情報時点でsidは未修正とされています。別のOSやリリース用の番号を流用しないでください。

公式情報: Ubuntu · USN-8948-1 · Debian · DSA-6574-1 / DLA-4848-1

3. 環境に合う方法で更新する

どの方法でも、最初に手順1の完全バックアップを取ります。自分の環境に該当する方法だけを実施し、再起動または再デプロイ後にWeb側を確認してください。

共有ホスティング：cPanel / Plesk

  1. バックアップ後、ホストに修正を依頼

    PHP切り替え前に完全バックアップを保管します。利用者権限しかない場合は、ホストに修正パッケージの適用を依頼してください。「8.3」や「8.4」を選ぶだけでは修正済みと確認できません。

  2. cPanel：EasyApacheを更新してドメインに適用

    管理者がWHMでEasyApache 4を更新します。修正版はea-php85 8.5.12、ea-php84 8.4.27、ea-php83 8.3.36、ea-php82 8.2.35です。その後MultiPHP Managerで対象ドメインを選び、互換性のある修正済みブランチを適用します。

  3. Plesk：ランタイムとPHP設定を更新

    管理者がPleskインストーラーからPHPを更新し、ドメインのPHP Settingsでランタイムを選びます。通知のLinux向け修正版は8.5.12 / 8.4.27 / 8.3.36 / 8.2.35です。WindowsやPHP 7.4〜8.1の提供状況はホストに確認してください。

  4. 再起動と各ドメインの動作を確認

    サイトを処理するPHP-FPMまたはApacheのワーカー再起動を依頼します。実際のランタイムを再確認し、通常のログイン・フォーム・アップロードを試します。

公式情報: cPanel · EasyApache 4 · Plesk · PHP

Ubuntu / Debian・OndřejのPPA：apt

  1. バックアップ後、ブランチと配布元を確認

    完全バックアップを用意し、apt policyをUSN-8948-1またはDebianの通知と照合します。Ubuntuで既にppa:ondrej/phpを使っている場合は、10月21日にjammy / noble向けに公開された修正版8.2.35 / 8.3.36 / 8.4.27 / 8.5.12を確認します。DebianにUbuntu用PPAを追加したり、配布元を混在させたりしないでください。

  2. 使用中ブランチのパッケージを更新

    以下はPHP 8.3とFPMの例です。8.3を実際のブランチに置き換え、アプリが使うインストール済み拡張パッケージも更新対象に含めます。mod_phpなら該当ブランチのlibapache2-mod-phpも更新します。修正済み候補が表示されなければ、先に配布元へ確認してください。

    sudo apt update
apt policy php8.3-fpm php8.3-cli php8.3-common
sudo apt install --only-upgrade php8.3-fpm php8.3-cli php8.3-common

  3. FPMを使う場合は再起動

    Web側で使用中のブランチのサービスを指定し、関連するすべてのプール・サービス・サーバーを対象にします。以下はPHP 8.3の例です。

    sudo systemctl restart php8.3-fpm

  4. Apacheを使う場合は再起動

    mod_phpでは修正済みランタイムを読み込むために必要です。ApacheからFPMを使う場合は該当するFPMも再起動します。その後apt policy、Webサイト、ログを確認します。

    sudo systemctl restart apache2

公式情報: Ubuntu · USN-8948-1 · Debian · DSA-6574-1 / DLA-4848-1 · Ondřej Surý · Launchpad

Docker：PHP公式イメージ

  1. 永続データもバックアップ

    再ビルドの前にデータベース、アップロード、ボリューム、設定を保存します。コンテナーイメージだけではこれらのデータはバックアップされません。

  2. 修正版タグを指定

    php:8.5.12、php:8.4.27、php:8.3.36、php:8.2.35のいずれかに、-fpmや-apacheなど適切な種類を指定します。アプリに必要なOSの種類と拡張機能を維持してください。Dockerfileの例：

    FROM php:8.4.27-fpm

  3. 再ビルドして再デプロイ

    以下はDockerfileからビルドするComposeサービスの例です。更新されたベースを取得し、キャッシュなしで再ビルドします。他の基盤では通常の手順で新イメージを公開・デプロイします。Composeでimage:のみを使う場合は、タグを変更して修正イメージを取得してからサービスを再作成します。

    docker compose build --pull --no-cache
docker compose up -d

  4. 全レプリカを確認

    新コンテナー内のPHPとWeb側のランタイムを確認します。古いレプリカにトラフィックが流れていないことを確認し、アプリを試します。

公式情報: Docker · Official Images / PHP · PHP.net · 2026

Laravel Forge

  1. サーバーとアプリをバックアップ

    変更前に完全バックアップを保存します。10月21日17:12 UTC更新のLaravel公式通知は、ブランチごとに更新方法を案内しています。

  2. PHP 8.5：Update PHP

    Forgeのダッシュボードでサーバーを開き、Update PHPを押します。修正済みリビジョンへの更新完了とサービス再起動を確認してください。

  3. PHP 8.2〜8.4：SSHとapt

    その通知に従い、SSHで接続してこのガイドのapt手順を使います。使用中ブランチのパッケージとサービスを指定し、該当するPHP-FPM・Apacheを再起動します。アプリの常駐プロセスも確認します。

  4. 更新できない場合

    Laravelは修正を適用できるまでサーバーを停止するよう勧めています。先にバックアップを保存してください。Vaporの場合は、更新済みランタイムを取り込むため再デプロイするよう案内されています。

公式情報: Laravel · 2026-10-21

WordPress：ホスト側のPHPを修正

  1. WordPress全体をバックアップ

    ファイル、アップロード、データベース、設定を保存し、ランタイム変更前に復元方法を確認します。

  2. WordPressを実行するPHPを更新

    ホスティング・apt・Dockerのうち、利用環境に合う方法に従います。WordPress本体、テーマ、プラグインの更新では今回のPHPランタイムの脆弱性は修正されません。ホスト管理の場合は両方の修正適用を確認してください。

  3. サイトヘルスを再確認

    「ツール → サイトヘルス → 情報 → サーバー」を再確認します。バックポートの場合は完全なパッケージリビジョンも確認し、管理画面、フォーム、購入、アップロードを試します。

公式情報: PHP.net · 2026

4. 完了前に更新を確認する

  1. Web側のPHPとパッケージを照合

    修正版またはベンダーのバックポート、全ワーカーの再起動、すべてのドメイン・サーバー・レプリカを確認します。CLIの更新だけではWeb側の修正は証明できません。

  2. 通常の操作を試す

    ページ、ログイン、フォーム、アップロード、決済など必要な機能を試します。エラーを確認し、バックアップと適用バージョンの記録を保管します。

Cloudflare：更新までの暫定的な防御

  1. オレンジ色の雲でプロキシを確認

    Cloudflareによると、2026年10月21日03:02 UTCから全プランにルールが自動展開され、FreeにもCloudflare Managed Free Rulesetで提供されています。WebサイトのDNS名がプロキシ経由で、オレンジ色の雲になっていることを確認します。

  2. Pro / Business / EnterpriseはBlockを確認

    Cloudflare Managed Rulesetの展開と、保護ルールのBlockモードを確認します。Security → Security Analytics → Eventsで動作を確認してください。

WAFはパッチの代わりにはなりません。Cloudflareを通る通信だけが対象で、サーバーのPHP自体は修正されません。ルールが有効でもPHPの更新を完了してください。

公式情報: Cloudflare · WAF

PHP.netの暫定対策：完全な修正ではありません

パッチ適用を準備している間のみ、管理者と実施してください。設定変更前に完全バックアップを取ります。これらの設定だけで脆弱な環境が安全になるわけではありません。

  1. 管理者設定でmemory_limit=-1

    PHP.netは、アプリが有限の上限に戻せないようphp_admin_valueでPHPのメモリ制限を解除するよう案内しています。以下はFPMプールの例で、Apacheではphp_admin_value memory_limit -1です。メモリ使用量が増える可能性があるため、管理者がサーバー容量を監視してください。

    php_admin_value[memory_limit] = -1

  2. POSTサイズとアップロード進捗の設定

    php.iniまたはサーバー設定で、アップロード不要ならpost_max_size=8M、必要なら32Mとし、upload_max_filesizeはそれより小さくします。session.upload_progress.enabled=0をリクエスト処理前に適用します。ini_set()や.user.iniだけでは不十分です。以下の例はサイトに合わせて調整してください。

    post_max_size = 8M
upload_max_filesize = 2M
session.upload_progress.enabled = 0

  3. PHP 8.5：致命的エラーのバックトレースを無効化

    PHP 8.5のみ、サーバー設定でこの項目も適用します。

    fatal_error_backtraces = 0

  4. 全ワーカーを再起動

    対象となるPHP-FPMまたはApacheをすべて再起動し、各サイトの実効設定を確認します。対策の効果は部分的なため、必ず修正パッチまで適用してください。

更新に代わる完全な暫定対策はありません。修正できない場合は、所有者と調整してサービスを一時停止してください。

公式情報: PHP.net · 2026

お困りですか？更新作業をご依頼ください

ランタイムの確認、バックアップ、更新、サイトの動作確認をお手伝いします。

PHP更新を依頼するHumbertoにメール

所有者から書面で許可を得たサイトのみ作業します。変更前には必ず完全バックアップを取ります。