UbuntuとDebianのPHPをアップデートする手順（php2shell脆弱性への対応）

自分が所有する、または管理を任されているサーバーだけを確認してください。

結論

apt でPHPのパッケージをアップデートし、PHP-FPM（Apacheのmod_phpならApache）を再起動したうえで、インストールされているパッケージの版が下の表の「修正版（以上）」に達しているかを確認します。Ubuntuは、PHPの版番号を上げずに修正だけを取り込む（バックポート）ため、php.netの8.3.36のような番号ではなく、ディストリビューションが出した修正版のパッケージ番号と比べてください。Debianの12・13の修正版は、本家と同じ番号に上がったパッケージ（例：Debian 13の 8.4.27-1~deb13u1）ですが、こちらもパッケージ番号で比べます。

PHP公式は、2件の重大な脆弱性（CVE-2026-109618・CVE-2026-109619。いずれもCVSS 4.0で9.2）により、Webリクエストを処理するPHP全般で、認証なしのリモートコード実行（外部の第三者にサーバー上でプログラムを実行されること）が起こり得ると公表しています。完全な緩和策はなく、更新が唯一の対処だとも説明しています（PHP公式アドバイザリ）。早めの対応をおすすめします。

この記事の表は、2026年10月22日に各公式ページで確認した内容です。

版番号を入力して確認したい場合はチェックツール、全環境の一覧は修正版一覧をご覧ください。レンタルサーバーを使っている場合は対応状況ページで確認できます。

手順1：今のOSとPHPの版を調べる

. /etc/os-release && echo "$PRETTY_NAME"
dpkg-query -W -f='${Package} ${Version}\n' 'php*-cli' 'php*-fpm' 'libapache2-mod-php*' 2>/dev/null
apt policy php8.3-cli   # 8.3は自分の系統に置き換え。どのリポジトリから入ったかが分かります

apt policy の出力に ppa.launchpadcontent.net/ondrej（Ubuntu）や packages.sury.org（Debian）が出る場合は、サードパーティ製のPHPです。下の「サードパーティのPHPリポジトリ（ondrej PPA・sury）を使っている場合」の節にある版と比べてください。

手順2：修正版のパッケージ番号と比べる

Ubuntu（公式アーカイブ）

出典：USN-8948-1、USN-8948-2、Ubuntu公式のCVE-2026-109618・CVE-2026-109619のページ。

補足です。

• Ubuntu 22.04のPHP 8.1は、php.netでは既にサポートが終了した系統です。 それでもUbuntuが独自に修正パッケージを出しているので、「8.1.x」ではなく 8.1.2-1ubuntu2.28 で判断します。
• 25.10と25.04は、通常サポートもESM（延長セキュリティ保守）も終了しており（25.10は2026-07-09、25.04は2026-01-15）、今回の公告にも載っていません。サポート中のリリースへ移行してください。
• 20.04以前の修正は、Ubuntu Proを有効にしないと届きません。Ubuntu Proは、個人利用なら無料とCanonicalが案内しています。16.04と14.04は、Proに加えてLegacy Supportアドオンが必要です。

Debian（公式アーカイブ）

出典：DSA-6574-1、DLA-4848-1、Debian Security Tracker（CVE-2026-109619）。

補足です。

• bookwormのセキュリティ対応は2026年7月にDebian LTSチームへ引き継がれました。Debian 11のLTSは2026年8月31日に終了しています（Debian公式ニュース）。Debian自身には、今回の2件に対するphp7.4の記載がありません。Debian公式としてのDebian 11の修正は未確認です。なお、有償の拡張LTS（Freexian）は、ELA-1853-1で 7.4.33-1+deb11u14 を修正版としています。これは契約者向けの非公開リポジトリでのみ提供されます。サポート中のリリースへの移行を計画してください。
• トラッカー上では、bookwormの元の版 8.2.32-1~deb12u1 とtrixieの元の版 8.4.24-1~deb13u1 は「vulnerable（脆弱）」と表示されています。unstable（sid）は 8.4.27-1 が修正版で、アーカイブにも php8.4-cli 8.4.27-1 があります。トラッカーのリリース別の表でも、sidは 8.4.27-1 が修正済み、forky（testing）は 8.4.26-1 のままで脆弱と表示されており、forkyには修正版がまだ届いていません。最新の状況はトラッカーで確認してください。

コマンドで修正版かどうかを判定する

インストール済みのパッケージが修正版以上かを、dpkg で判定できます。表の自分の行の版に置き換えてください。

dpkg --compare-versions "$(dpkg-query -W -f='${Version}' php8.3-common)" ge 8.3.6-0ubuntu0.24.04.13 \
  && echo "OK: 修正版です" || echo "OLD: 更新が必要です"

複数の系統（8.2と8.3など）を入れている場合は、すべての系統で確認します。

手順3：バックアップを取ってから、aptでセキュリティアップデートを適用する

まずスナップショットかバックアップを取ります（VPSならスナップショット、最低でも /etc/php とサイトのファイル）。同じリリースの中でのセキュリティアップデートは影響が小さいものの、元に戻せる状態にしておくと安心です。22.04から24.04、Debian 12から13のような「リリースの引き上げ」は、必ずサーバー全体のスナップショットを取り、検証用の環境で先に試してください。

sudo apt update
apt list --upgradable 2>/dev/null | grep -i php     # 何が更新されるか確認
sudo apt install --only-upgrade '*php8.3*'          # 8.3は自分の系統に置き換え

sudo apt upgrade で全体を更新しても構いません。--only-upgrade を付けると、新しいPHPパッケージは増やさず、すでに入っているものだけを更新します。複数の系統が同居しているなら、系統ごとに繰り返してください（例：'*php8.2*'）。

Ubuntu 20.04以前は、先にUbuntu Proを有効にする

ubuntu.com/pro でアカウントを作ってトークンを取得し、次を実行します（16.04・14.04は、先にLegacy Supportアドオンの契約が必要です）。

sudo pro attach あなたのトークン
pro status          # esm-infra が enabled になっているか確認（16.04・14.04は esm-infra-legacy）
sudo apt update && sudo apt install --only-upgrade '*php7.4*'   # 7.4は自分の系統に置き換え

手順4：php-fpm・Apacheを再起動する

パッケージを更新しても、動き続けているPHPのプロセスが新しい版に入れ替わるとは限りません。必ず自分で再起動します。

sudo systemctl restart php8.3-fpm     # PHP-FPM（8.3は自分の系統に置き換え）
sudo systemctl restart apache2        # Apache + mod_php、またはApacheからFPMを呼ぶ構成

php.netは、mod_phpを最もリスクが高い構成として挙げています。libapache2-mod-php を使っているなら、Apacheの再起動を省かないでください。Nginxの場合は、PHP-FPMの再起動だけで足ります。FPMが複数あるときは systemctl list-units --type=service 'php*fpm*' で一覧できます。

手順5：更新できたか確認する

dpkg-query -W -f='${Package} ${Version}\n' 'php*-common'
php-fpm8.3 -v                                      # FPMが実行するバイナリ（8.3は自分の系統に置き換え）
systemctl status php8.3-fpm --no-pager | head -5   # active (running) で、起動時刻が更新後になっているか

Ubuntuの公式パッケージでは、修正後も php -v の表示が元の版番号（例：8.3.6）のままです。Debianの修正版は版番号自体が上がります（例：8.2.35-1~deb12u1、8.4.27-1~deb13u1）。どちらの場合も、判断には dpkg-query で出るパッケージの版を使い、手順2の dpkg --compare-versions をもう一度実行してください。最後にサイトのページを1つ開き、表示に問題がないかを見ます。

版が古いままなら、apt policy パッケージ名 で更新を提供しているリポジトリを確認します。よくある原因は、/etc/apt/sources.list* にセキュリティ用の行がない、Ubuntu Proが未登録、バージョンの固定（pin）です。

サードパーティのPHPリポジトリ（ondrej PPA・sury）を使っている場合

apt policy に ppa:ondrej/php（Ubuntu）や packages.sury.org（Debian）が出るなら、PHPはUbuntu・Debianではなく、Ondřej Surý氏が運営するサードパーティ製リポジトリのものです。この場合はディストリビューションの公告は当てはまらず、下の版と比べます。出典は各リポジトリのチェンジログで、独立した公告ページは見つかっていません。

PHP本家の修正版は 8.5.12・8.4.27・8.3.36・8.2.35 です（php.net）。

Ubuntu ppa:ondrej/php（Launchpadで2026-10-21に公開。チェンジログに「CVE-2026-109618, CVE-2026-109619: Avoid state corruption via bailout」の記載あり）。下は24.04の例です。22.04では ubuntu24.04 を ubuntu22.04 に読み替えます。

Debian packages.sury.org/php（bullseye・bookworm・trixie。根拠は公開されているソースパッケージ内のチェンジログ）。

実際のビルドには、8.4.27-1+0~20261021.57+debian12~1.gbp7636b9 のような接尾辞が付きます。表の修正版以上であれば修正済みなので、dpkg --compare-versions ... ge の判定にそのまま使えます。7.4以前を含むほかの系統は、修正版一覧を見てください。8.1以前はPHP本家ではサポート終了のため、リポジトリ側がバックポートした独自の修正です。

2つを混同しないでください。 PPAを使った22.04の8.1は 8.1.34-9+ubuntu22.04.1+deb.sury.org+1、Ubuntu公式の22.04の8.1は 8.1.2-1ubuntu2.28 です。apt policy に出たリポジトリの行の版を使います。

更新と再起動の手順は同じです。

sudo apt update && sudo apt install --only-upgrade '*php8.3*'
sudo systemctl restart php8.3-fpm

個人運営の外部リポジトリに頼りたくない場合は、Ubuntu 24.04やDebian 12・13の標準パッケージに切り替える方法もあります（アプリが必要とするPHPの系統が標準パッケージにあることが条件です）。

RHEL系（Red Hat・Rocky・Oracle・AlmaLinux）の場合

RHEL系は、リリースとPHPのストリーム（php:8.3 のようなモジュール）ごとに状況が違います。2026年10月22日に各社の公式ページで確認した内容は次のとおりです。

出典はRed HatのCVE-2026-109618のページとCVE-2026-109619のページ、各RHSAです。RHEL 7は、CVE-2026-109618 が 「Under investigation」（調査中）、CVE-2026-109619 が 「Not affected」（影響なし）で、修正パッケージはありません。

• Rocky Linuxは、2026年10月22日付で、RHELと同じ番号の公告（RLSA-2026:87070など）を出しています。ただし、Rocky Linux 9のphp:8.4には、まだ公告がありません。Rocky Linux 8は、php:7.4（RLSA-2026:87080）とphp:8.2（RLSA-2026:87073）の公告があり、そのほかのストリームは確認時点では公告が見つかっていません。Rockyのモジュール版（php:8.3など）は、ビルド番号がRed Hatと異なるため、修正版一覧の自分の行と比べてください。
• Oracle Linuxは、10（ELSA-2026-87070・ELSA-2026-87071）と9のphp 8.0（ELSA-2026-87151）・php:8.2（ELSA-2026-87072）・php:8.3（ELSA-2026-87079）の公告を出しています。Oracle Linux 8は、php:7.4（ELSA-2026-87080）とphp:8.2（ELSA-2026-87073）の公告を出しています。9のそのほかのモジュール版（php:8.4など）と、8のそのほかのストリームは、確認時点では記載がありません。
• AlmaLinuxは、10のphp（8.3、ALSA-2026:87070）とphp8.4（ALSA-2026:87071）、9のphp:8.3（ALSA-2026:87079）、8のphp:7.4（ALSA-2026:87080）に公告があります。9のphp:8.2の公告は2件のCVEを挙げていますが、php本体のパッケージが一覧にないため、未確認です。そのほかのストリームは、公告が見つかっていません。

公開済みのものは sudo dnf update 'php*'（モジュール方式ならストリームに合わせて更新）で入ります。更新後は、手順4と同じようにPHP-FPM（php-fpm）またはApache（httpd）を再起動し、rpm -q php の版を上の表（または自分のディストリビューションの公告）と比べてください。公開状況は上のページと修正版一覧で確認できます。

今すぐ更新できないとき

php.netは、暫定的に使えるサーバー設定上の制限を挙げています。ただし「特定の攻撃経路への露出を減らすだけで、完全な緩和策はない」と明記しています。更新までのつなぎとしてのみ使い、内容はPHP公式アドバイザリで確認してください。

関連ガイド

• PHPバージョンの確認方法
• PHP 7.4・8.0・8.1 サポート終了後の対応
• WordPressサイトの対応手順

自分のサーバーに合わせた手順がほしいとき

「サーバー構成が複雑で、どこを直せばいいか分からない」という方向けに、$49の個別パッチ対応プランがあります。お使いの環境に合わせた手順を、24時間以内にメールでお届けします。サーバーにログインすることはなく、手順書をお届けする形です。詳しくはこちらをご覧ください。