PHP 7.4・8.0・8.1 のサポート終了と脆弱性（php2shell）：修正版の有無と 8.2 以上への移行

自分が所有している、または管理を任されているシステムだけを確認してください。当サイトは PHP Group・php.net とは関係のない独立サイトです。

結論：PHP 7.4・8.0・8.1 は本家から修正版が出ていません

PHP の公式サイト（php.net）は 2026年10月21日、重大な脆弱性2件（CVE-2026-109618 / CVE-2026-109619）を PHP 8.2.35・8.3.36・8.4.27・8.5.12 で修正しました。ただし、サポートが終了している PHP 7.4・8.0・8.1 には、修正版のリリースがありません。7.4・8.0・8.1 を使い続けてよいかどうかは、お使いの OS やレンタルサーバー事業者が修正を取り込んでいるか（バックポート。新しい版の修正を古い版に移植すること）で決まります。取り込まれていない場合は、8.2 以上へ移行するのが確実です。

Ubuntu など一部のディストリビューションのパッケージは、修正を取り込んでも古い番号（例: 8.1.2）のままです。Debian や RHEL の新しい系統のように、本家と同じ番号の版へ更新されるものもあります。PHP 本家の番号ではなく、ベンダーが公表する「修正済みパッケージのバージョン」と比べてください。

2026年10月22日時点の情報です。各社の対応は更新が続いているため、下記の公式ページで最新を確認してください。

PHP 7.4・8.0・8.1 のサポート終了日と php.net の対応

日付と最終リリースは php.net の「Unsupported Branches」 によります。

php.net のセキュリティ告知は、次のように説明しています（原文の要旨）。

• PHP 8.1 以前は、PHP プロジェクトからの更新が提供されない。
• 深刻度を踏まえ、PHP セキュリティチームは 7.4・8.0・8.1 向けに「最小限のソース移植（ソースバックポート）」 を用意した。ソースからビルドする人や、LTS ベンダーを利用できない人のためのもの。
• 対象は Web リクエストを処理するすべての PHP（PHP-FPM、Apache の mod_php、php-cgi、FrankenPHP、LiteSpeed を含む）。ログインなしで、外部からコードを実行される可能性がある。
• 完全な緩和策はなく、更新が唯一の対処である。

（本サイトの補足）一部のディストリビューションや LTS（長期サポート）ベンダーは、自社で修正を移植して提供している場合があります（php.net の発表の内容ではありません）。ベンダーに確認するか、サポート中のバージョンへ更新してください。

CVE の発表元（PHP Group）と GitHub のアドバイザリが載せている影響範囲は 8.2〜8.5 ですが、サポート終了の系統が「対象外」という意味ではありません。脆弱性データベースの NVD（CVE-2026-109618）は、製品の機械可読な一覧（CPE）で、8.2.35 より前のすべてのバージョンを対象に含めており、8.1 以前もこれに入ります。フランスの CERT-FR は 5.x〜7.x、8.0.x、8.1.x も影響ありとして挙げています。7.3 以前については、php.net は移植版に触れていません。修正は提供されないものとして扱い、早めに移行してください。

日本の IPA（情報処理推進機構）は、修正版の公開前に事前告知を出しています。この告知は修正版の公開前のもので、執筆時点では修正版も影響バージョンも確認できていないとしています。あわせて「PHP 5以降」との記載があります。

ディストリビューション別：バックポートされた修正版

下表は 自分のパッケージ番号が「修正済みパッケージのバージョン」以上か を比べるための一覧です。

補足です。

• Ubuntu Pro は Canonical（Ubuntu の開発元）の有料サブスクリプションですが、個人利用は無料と、Canonical は案内しています。20.04 は Pro を有効にしないと修正が届きません。
• Debian 11 の LTS は2026年8月31日で終了しています（Debian ニュース）。延長サポート（Freexian ELTS）は別契約の有料サービスで、Freexian は修正版を 7.4.33-1+deb11u14 として公開していますが、配布は契約者向けの非公開リポジトリだけです。Debian 自身は php7.4 の修正を載せていないため、契約していない環境では**「未確認」であり、「修正済み」ではありません。**
• 上表は 7.4・8.0 系だけを載せています。RHEL・Rocky Linux・Oracle Linux には、8.2 以上のストリーム（php:8.2、php:8.3、RHEL 10 の php 8.3・php8.4 など）の修正版もあります（Rocky Linux 8 と Oracle Linux 8 の php:8.2 を含む。全体は修正版バージョン一覧）。一方、Rocky Linux 9 の php:8.4、Rocky Linux 8 と Oracle Linux 8 の php:7.4・php:8.2 以外のストリーム、Oracle Linux 9 の php:8.4 は、確認時点でアドバイザリが見つかっていません。RHEL 9 の php:8.4 には修正版が出ていません。AlmaLinux は、8 の php:7.4、9 の php:8.3、10 の php 8.3・php8.4 にアドバイザリがありますが（8.2 以上のストリームを含め、全体は修正版バージョン一覧を参照）、AlmaLinux 8 の php:8.2 と 9 の php 8.0・php:8.2 は未確認です。
• sury.org と ppa:ondrej/php は Debian の PHP メンテナーによる第三者リポジトリで、OS 公式のアーカイブではありません。パッケージの変更履歴には、両方の CVE の修正が記載されています。
• Remi の RPM リポジトリについて、php.net は公開時点で「ボランティア運営のため、当日は更新がない」と述べていました。その後、EL8・EL9・EL10 向けに 8.2〜8.5 の修正済みビルド（例: 8.2.35-1.el9.remi）が公開されています。7.4・8.0・8.1 向けの修正版は、本サイトでは確認できていません。
• 最新の状況は修正済みバージョン一覧とホスティング別の対応状況で確認してください。

参考として、サポート中の 8.2 以上を OS 標準のパッケージで使う場合の修正済み番号です。Ubuntu 24.04 の php8.3 は 8.3.6-0ubuntu0.24.04.13、Debian 12 の php8.2 は 8.2.35-1~deb12u1、Debian 13 の php8.4 は 8.4.27-1~deb13u1 です（出典: Ubuntu、Debian 12: DLA-4848-1、Debian 13: DSA-6574-1）。

Ubuntu / Debian：修正版を適用して確かめる

作業前にスナップショットかバックアップを取ってください。以下は Ubuntu 22.04 の PHP 8.1 の例です（バージョン番号は環境に合わせて読み替えてください）。

# 1. 現在のパッケージ版を確認
dpkg-query -W -f='${Package} ${Version}\n' 'php8.1*' | head

# 2. 更新（Apache モジュールを入れていない環境では自動で無視されます）
sudo apt update
sudo apt install --only-upgrade 'php8.1*' 'libapache2-mod-php8.1'

# 3. PHP を動かしているサービスを再起動（使っているものだけ）
sudo systemctl restart php8.1-fpm
sudo systemctl restart apache2

# 4. 確認：修正済みバージョン以上なら OK と表示
dpkg --compare-versions "$(dpkg-query -W -f='${Version}' php8.1-common)" ge '8.1.2-1ubuntu2.28' && echo OK || echo STILL-OLD

8.1.2-1ubuntu2.28 の部分は、上の表にある自分の環境の修正済みバージョンに置き換えてください。STILL-OLD と表示された場合は、まだ修正が入っていません。

Ubuntu 20.04 は、先に Ubuntu Pro を有効にしてから同じ更新を行います。

sudo pro attach <YOUR_TOKEN>      # トークンは Ubuntu Pro のアカウントページで取得
sudo pro status                   # esm-infra が enabled になっていること
sudo apt update && sudo apt install --only-upgrade 'php7.4*'

修正版が手に入らない場合の最終手段：ソースからビルド

ほかに手段がない場合の一時しのぎです。php.net 自身が「最小限」の移植と位置づけています。ソースのブランチは php-src の PHP-7.4-CVE-2026-109618-109619、PHP-8.0-CVE-2026-109618-109619、PHP-8.1-CVE-2026-109618-109619 です。

php -i | grep 'Configure Command'      # 既存の configure オプションを控える
git clone --depth 1 --branch PHP-8.1-CVE-2026-109618-109619 https://github.com/php/php-src.git
git -C php-src log -1 --format=%H      # このコミットID を作業記録に残す

本サイトで記録している各ブランチのコミットは、7.4 が 712e60f9edfd…、8.0 が 82f8f31b16a0…、8.1 が 1d7dec178a09… です（コミット日はいずれも2026年10月18日 UTC）。ブランチの先頭は今後変わることがあるため、上のコマンドで取得したコミットIDと見比べてください。控えておいた configure オプションでビルドして入れ替え、php-fpm や Apache を再起動します。このブランチには新しいバージョン番号が付いていないため、php -v は 7.4.33 や 8.1.34 のままで、番号だけでは修正済みか判別できません。 ビルドしたコミット ID は自分で記録しておいてください。ビルドや保守の手間を考えると、後述の 8.2 以上への移行のほうが現実的です。

レンタルサーバー（さくら・エックスサーバーなど）の場合

サーバー側の PHP は、ホスティング事業者が更新します。7.4・8.0・8.1 については、公式の修正版がないため、事業者が独自に対応する形になります。当サイトが記録している各社の公式発表は、次のとおりです（2026年10月22日時点）。

上の一覧以外や、各社の最新の状況はホスティング別の対応状況にまとめています。

「修正を適用した」という発表には、修正後のバージョン番号が書かれていないものが多く、番号が変わらない会社もあります。そのため、管理画面や php -v に 7.4.33 や 8.1.34 と出ていても、それだけで未修正とは判断できません。会社の発表で確認してください。一方、8.2.35・8.3.36・8.4.27・8.5.12 以上の番号が出ていれば、PHP公式の修正版以上です（正式リリースでない8.6.0のリリース候補版などは対象外で、本番では使わないでください）。

ただし、7.4・8.0・8.1 は PHP 公式のサポートが終わっています。会社が自社の修正を適用したと発表している場合でも、8.2 以上（できれば 8.3 以上）への切り替えを強くおすすめします。 切り替え前のバックアップや動作確認の進め方は次の節を、さくらの切り替え方法は「PHPのバージョンを変更したい」のサポートページを参照してください。

8.2 以上への移行手順

php.net の対応バージョン一覧では、セキュリティ修正の提供期限は 8.2 が2026年12月31日、8.3 が2027年12月31日、8.4 が2028年12月31日、8.5 が2029年12月31日です。8.2 は修正済みの最低ラインですが期限が最も近いので、WordPress やプラグインが対応していれば 8.3 以上を選んでください。

1. バックアップを取る。 バージョンを変える前に、サーバーのスナップショット、またはデータベースとファイルのバックアップを取ります。レンタルサーバーでも、WordPress のバックアップは必須です。

2. テスト用の環境で試す。 本番と同じ OS・拡張モジュール・Web サーバー設定の複製を使い、本番でいきなり試さないでください。レンタルサーバーなら、テスト用のサブドメインやステージング機能を使います。

3. 動作に問題がないか確認する。 WordPress 本体・テーマ・プラグイン、フレームワークを、移行先の PHP に対応した版に更新します。自作コードがある場合は次を実行します。

   composer check-platform-reqs                 # 新しい php バイナリで実行
   composer why-not php 8.4
   find . -name '*.php' -not -path './vendor/*' -print0 | xargs -0 -n1 php -l | grep -v '^No syntax errors'
   php -m                                       # 旧サーバーと拡張モジュールを見比べる

   error_reporting=E_ALL でログをファイルに出しながら、主要ページを一通り操作します。段階ごとの変更点は php.net の移行ガイド（8.0、8.1、8.2、8.3、8.4、8.5）に載っています。7.4 から上げる場合は、途中の版の変更点もまとめて読んでください。

4. 新しい版を旧版と並べて入れる。 Ubuntu 24.04 の標準パッケージは PHP 8.3 です（修正済みは 8.3.6-0ubuntu0.24.04.13）。8.4 や 8.5 が必要なら、第三者リポジトリの ppa:ondrej/php を使う方法があります。

   sudo add-apt-repository ppa:ondrej/php && sudo apt update
   sudo apt install php8.4-fpm php8.4-cli   # `php -m` で控えた拡張も追加

5. 切り替える。 nginx なら fastcgi_pass を unix:/run/php/php8.4-fpm.sock に変更し、sudo nginx -t && sudo systemctl reload nginx。Apache の mod_php なら sudo a2dismod php8.1 && sudo a2enmod php8.4 && sudo systemctl restart apache2。

6. Web サーバー側で確認する。 php -v で分かるのはコマンドライン版の情報だけです。実際にリクエストを処理しているサービスのバージョンを確認します。

   systemctl is-active php8.4-fpm
   dpkg-query -W -f='${Version}\n' php8.4-fpm

   バージョンが 8.4.27 以上（またはベンダーの修正済みパッケージ以上）であることを確認し、サイトが安定してから旧サービスを止めます（sudo systemctl disable --now php8.1-fpm）。それまでは旧パッケージを残しておくと戻せます。

7. 最後にチェッカーで再確認する。 自分の PHP バージョンや環境を入力すると判定します（入力した内容をブラウザ内で表と照合するだけで、サイトやサーバーにはアクセスしません）。

Docker で動かしている場合

Docker Hub の公式 php イメージでは、7.4・8.0・8.1 の最新タグは 7.4.33・8.0.30・8.1.34 のままで、修正済みのイメージはありません。一方、8.2〜8.5 の最新タグ（php:8.2〜php:8.5）は、8.2.35・8.3.36・8.4.27・8.5.12 になっています（いずれも2026年10月22日時点）。Dockerfile の FROM php:8.1-… を php:8.4-… などに書き換え、イメージとコンテナを作り直します。

docker compose build --pull
docker compose up -d --force-recreate
docker compose exec <サービス名> php -v    # 8.4.27 以上なら修正済み（8.4 の場合）

Windows 版（windows.php.net）も、7.4・8.0・8.1 の最新ビルドは 7.4.33・8.0.30・8.1.34 のままで、修正済みのバイナリはありません。XAMPP のインストーラーに入っている PHP（8.0.30・8.1.25・8.2.12）も、修正版より古い番号です。php フォルダを 8.2 以上の公式ビルドに入れ替えるか、環境ごと新しくしてください。

暫定対策は修正の代わりにならない

php.net は、設定や Web サーバー側で被害の可能性を下げる暫定策も案内していますが、これらは特定の攻撃経路への露出を減らすだけで、完全な対処は更新だけだと明記しています。更新の準備ができるまでのつなぎとして、内容は php.net の告知で確認してください。

自分の環境でどの行が当てはまるか分からない場合は、$49 の個人向けパッチ対応プランがあります。お使いの環境に合わせた手順を、24時間以内にメールでお届けします。詳しくは対応プランのページをご覧ください。