PHP 7.4・8.0・8.1のままのサーバーでPHP2Shellにどう対応するか ― 修正版リリースがない場合の手順
PHP 7.4・8.0・8.1にはPHP2Shellの修正版リリースがありません。ブランチ移行、ベンダーの修正、バックポートのビルド、隔離の順で対応方法を解説します。
PHP 7.4・8.0・8.1のままのサーバーでPHP2Shellにどう対応するか ― 修正版リリースがない場合の手順
2026年10月21日、PHPはPHP2Shellを修正する8.5.12、8.4.27、8.3.36、8.2.35を公開しました（脆弱性の概要はこちら）。7.4、8.0、8.1はいずれもサポート終了済みのため、新しいリリースはありません。運用担当者は、以下の選択肢から対応方針を判断する必要があります。
結論： PHPのセキュリティチームは7.4、8.0、8.1向けにソースのバックポートを公開しましたが、リリースや新しいバージョン番号はありません。次の順で検討してください。
- 可能なら、セキュリティ修正が続くブランチへ移行する
- 移行できなければ、ディストリビューションやベンダーの修正済みパッケージを入れる
- どちらもなく、ソースからPHPをビルドする体制がある場合に限り、公式バックポートからビルドする
- いずれも無理なら、CISAの勧告どおりオフラインにするか、カナダ・サイバーセキュリティセンターの勧告どおり公開ネットワークから隔離する
すぐに更新できない間は、1〜3を待たずにステップ4を暫定措置として実施してください。8.2は8.2.35をすぐ適用できますが、2026年12月31日にサポートが終了するため、次の移行計画も必要です。
ステップ1：移行先のブランチを選ぶ（php.netのサポート期限）
7.4や8.1から移行するなら8.3以降、できれば8.4か8.5を選びます。今8.2に移っても、残りは約2か月です。移行作業の中心はアプリケーションの動作検証ですが、本記事では扱いません。
PHP2ShellのCVEレコードが影響対象とするのは8.2〜8.5のみです。7.3以前については、第三者のwatchTowrとTenableが影響を受けると評価しており、PHPからの修正はありません。以下の日付は10月25日時点のphp.netによります。
| ブランチ | 状態（php.net） | セキュリティ修正の期限 | 最終リリース | PHPプロジェクトのリリース／ソースバックポート |
|---|
| 7.2以前 | サポート終了 | — | — | PHPプロジェクトの修正なし |
| 7.3 | 2021年12月6日に終了 | — | 7.3.33 | PHPプロジェクトの修正なし |
| 7.4 | 2022年11月28日に終了 | — | 7.4.33 | ソースのバックポートのみ |
| 8.0 | 2023年11月26日に終了 | — | 8.0.30 | ソースのバックポートのみ |
| 8.1 | 2025年12月31日に終了 | — | 8.1.34 | ソースのバックポートのみ |
| 8.2 | セキュリティ修正のみ | 2026年12月31日 | 8.2.35 | 修正版リリース |
| 8.3 | セキュリティ修正のみ | 2027年12月31日 | 8.3.36 | 修正版リリース |
| 8.4 | アクティブサポートは2026年12月31日まで | 2028年12月31日 | 8.4.27 | 修正版リリース |
| 8.5 | アクティブサポートは2027年12月31日まで | 2029年12月31日 | 8.5.12 | 修正版リリース |
ブランチが混在し手作業での管理が難しい場合は、プランと料金もご確認ください。
ソースのバックポートとは何か、なぜバージョン番号が変わらないのか
php.netによると、セキュリティチームは深刻度を踏まえ、ソースからビルドする利用者やLTSベンダーのない利用者向けに7.4、8.0、8.1の「minimal source-backports」を用意しました。php-srcのGitブランチ（7.4、8.0、8.1）で公開されています。
各ブランチには「Avoid state corruption via bailout」というコミットが1つ追加されています。コミットメッセージには「Minimal mitigation for EOL version.」とあり、CVE-2026-109618とCVE-2026-109619の両方の修正が明記されています。つまり1つのコミットで2件とも修正します。
ただし、リリースではありません。新しいタグもtarballもなく、PHPの2件のアドバイザリが修正版として挙げるのも8.2.35、8.3.36、8.4.27、8.5.12だけです。
バージョン番号は修正の証拠になりません。 バックポートのコミットはバージョン関連のファイルに触れていません。8.0や8.1のブランチからビルドしても configure.ac の値は8.0.30、8.1.34のままで、phpversion() は修正前とまったく同じ値を返します。7.4のブランチは2022年のコミットに由来する 7.4.34-dev のままで、これもリリース番号ではありません。
ベンダーのパッケージも同様で、上流のバージョンは同じでもパッケージのリリース番号が変わることがあります（例：Synologyの8.1.34-0120）。Pleskは番号を変えずにビルド日だけを更新しています。
ステップ2：ディストリビューションやベンダーの修正を入れる
以下は2026年10月25日時点の各ベンダーのページの内容です。判断の根拠はベンダーの最新のアドバイザリです。 対応前に各行のリンク先を必ず確認してください。下記の「未確認」「修正なし」も同様です。
| 提供元 | 修正された旧ブランチ | 確認方法 |
|---|
| Ubuntu 22.04（無償） | php8.1 | 8.1.2-1ubuntu2.28以降 |
| Ubuntu Pro（ESM） | php7.4（20.04）、php7.2（18.04）、php7.0（16.04）、php5（14.04） | 例：php7.4は7.4.3-4ubuntu2.29+esm5 |
| Red Hat（RHSA-2026:87080、RHSA-2026:87151） | RHEL 8のphp:7.4モジュール、RHEL 9のphp 8.0 | RHSA記載のパッケージバージョン |
| AlmaLinux | 8・9・10の全PHPストリーム | rpm -q php-common を告知と照合（AlmaLinux 10のPHP 8.4は rpm -q php8.4-common） |
| cPanel EasyApache 4 | ea-php74、ea-php80、ea-php81 | 25.91でバックポートを記載。25.92で ea-php74-meta、ea-php80-meta、ea-php81-meta を再ビルドし、変更履歴にも記載 |
| CloudLinux | alt-php 5.2〜5.6、7.0〜7.4、8.0〜8.5、ea-php52〜ea-php85 | alt-phpパッケージの変更履歴（下記コマンド） |
| Plesk for Linux | 7.4.33、8.0.30、8.1.34 | ビルド日が2026年10月21日以降 |
| DirectAdmin CustomBuild | 8.1、8.0、7.4、続いて7.3、7.2、7.1、7.0、5.6 | バージョンの後ろに * |
| Synology | PHP 7.4、8.0、8.1パッケージ | 7.4.33-0131、8.0.30-0122、8.1.34-0120以降 |
CloudLinuxのalt-phpパッケージは、CloudLinuxが案内する次のコマンドで確認できます（読み取り専用。パッケージ名のバージョン部分は環境に合わせて変更）。2件のCVEが表示されるはずです。
rpm -q --changelog alt-php74-common | grep -E "CVE-2026-(109618|109619)"
例外として、8.2.35や8.3.36にリベースされたネイティブのPHP 8.2・8.3パッケージは変更履歴にCVEが記載されないため、rpm -q php-cli でバージョンを確認します。いずれのコマンドもインストール済みパッケージを確認するだけで、サイトが実際に使っているランタイムは分かりません。
更新手順はホスティングパネルでのPHP更新と自社サーバーでのPHP更新をご覧ください。アプライアンスはPHPを同梱する製品をご覧ください（例：Check PointのHotfixはPHPの7.4向け修正を組み込んでいます）。
未確認： Ondřej SurýのLaunchpad PPAにあるphp7.4、8.0、8.1の新ビルドは、ビルドの変更履歴が「No-change backport」のみです。deb.sury.orgのパッケージインデックスには10月21日付のエントリーがありますが、CVEの修正を示すものではありません。Remi、Freexian ELTS、TuxCare ELS、ZendPHP LTSに修正があるとするのはSansecのみです。利用する場合は、2件のCVEを修正済みであることを書面で確認してください。
修正なし（10月25日時点）： Docker公式イメージの php:8.1 と php:8.0 は再ビルドされておらず、Azure App Serviceはサポート終了版のPHPにはこのパッチを提供しないとしています。
ステップ3：バックポートから自前でビルドする（経験のあるチームのみ）
最もリスクの高い選択肢で、ソースからPHPをビルドし保守している体制がある場合に限られます。パッケージで入れたPHPを手作業のビルドで上書きしないでください。本記事ではビルドコマンドを示しません。経験のあるチームはphp-srcのREADMEに従い、次の原則を守ってください。
- 現在と同じオプションでビルドする。 PHPマニュアルによると
php-config --configure-options で、インストール済みPHPの構成を再現するオプションが得られます。
- 正しいブランチからビルドし、来歴を記録する。 バックポートのコミットは
1d7dec178a094e6e75b229ce22754045f8c6070a（8.1）、82f8f31b16a035c1b67cc253e79f7cc288f4cc20（8.0）、712e60f9edfd03f0960fc4fc3c2c375f42b90aa2（7.4）です。バージョン番号からは分からないため、コミットSHAをビルドと一緒に記録します。
- 本番展開の前にステージングで検証する。
ビルドに使ったソースツリーは、次の読み取り専用コマンドで確認できます。Gitのドキュメントによると、指定したコミットが HEAD の祖先であれば終了ステータス0を返します。
git merge-base --is-ancestor 1d7dec178a094e6e75b229ce22754045f8c6070a HEAD && echo "commit is an ancestor of HEAD"
これが示すのはコミット履歴だけです。変更が取り消されていないこと、作業ツリーがビルド時と一致すること、稼働中のバイナリがこのツリー由来であることは分からないため、ビルド記録とWeb側の確認が別途必要です。Bitdefenderは、サポート対象ブランチへの移行だけが確実な対策だとしています。
ステップ4：更新できない間はオフライン化または隔離する
CISAのアラート（10月23日改訂）は、すぐに更新できない組織、またはサポート終了のPHP 8.1以前を使い続ける組織に対し、修正か更新ができるまでPHPベースのシステムをオフラインにするよう求めています。WAFについては、一定の防御になり得るとしています。バックポートには言及していません。カナダ・サイバーセキュリティセンターは、修正まではインターネット公開アプリケーションを公開ネットワークから隔離するよう勧めています。
PHPが示す暫定設定は特定の攻撃経路のリスクを下げますが、安全にはなりません。パッチ前にWAFでどこまで防げるかをご覧ください。10月17日以降インターネットに公開されていたホストは、ログから痕跡を探す作業も必要です。
効果を確認する
- すべてのPHPワーカーを再起動する。 ThaiCERTは、修正済みのバイナリを読み込むためにPHP-FPM、Apache、LiteSpeedの再起動を求めています。
- Web側でランタイムを確認する。 方法は全サイトのPHPバージョン確認のとおりです。上流のバージョンが変わらないことがあるため、確認済みのパッケージやビルドの記録と照合します。systemdを使うLinuxでは、
systemctl status <サービス名> の起動時刻は補助的な根拠にすぎません。全ワーカーの再起動や、どのバイナリがどのサイトを処理しているかは分からないためです。
- ホストごとに証跡を残す。 パッケージのバージョンかビルド日、ベンダーの告知またはコミットSHA、Web側の確認結果です。
古いAppServを使い続けている場合
AppServの最新版9.3.0（2019年9月29日公開）はPHP 7.3.10を同梱しています。AppServに新しい版はなく、PHPも7.3向けのソースバックポートを出していないため、AppServの更新もステップ3もありません。ステップ2には修正済みの7.3パッケージを出すベンダーもありますが、AppServの代替になるかは確認していません。確実なのはサポート対象のPHPへの移行で、それまではインターネットから切り離してください。AppServやXAMPPからの移行は自社サーバーでのPHP更新で解説しています。
本記事で扱わないこと
- ベンダーのバックポートが完全かどうか（ベンダーにしか保証できません）
- バックポートが塞ぐのはこの2件のCVEだけで、ブランチはサポート終了のままです
- いずれの手順も修正の有無を示すだけで、事前に侵害されたかどうかは分かりません。不安があれば侵害が疑われる場合の対応をご覧ください
次に備える：8.2は2026年12月31日に終了
この作業は8.2のサポート終了時にまた発生します。各サーバーで使用しているPHPのブランチ、導入元のパッケージ、そのブランチのサポート終了日を今のうちに記録しておけば、次回はすぐに着手できます。一覧を手作業で管理したくない場合、zcrXでソフトウェアごとのプロダクトライフサイクルとサポート終了（EOL）を追跡できますが、パッチ適用やブランチ移行の代わりにはなりません。
📞 無料相談
zcrはソフトウェアを提供しており、移行やビルドなどの実作業はチャネルパートナーを通じて行います。
関連記事
出典
- PHP News Archive 2026 — 修正版、7.4/8.0/8.1のソースバックポートとその目的、8.1以前はPHPの更新対象外、8.2のサポート終了、暫定設定では安全にならないこと
- PHP — Supported Versions、PHP — Unsupported Branches — 各ブランチの期限と最終リリース
- GitHubのphp-src：ブランチPHP-7.4、PHP-8.0、PHP-8.1、コミット1d7dec1（8.1） — コミットメッセージ、
configure.ac のバージョン
- GHSA-w8hw-w9fx-j79w（CVE-2026-109618）、GHSA-6wmf-4rv5-p3rp（CVE-2026-109619） — 修正版
- php-src README — Building PHP source code、PHP Manual — php-config、Git — git-merge-base
- CISA — Critical Vulnerabilities in PHP Require Immediate Patching — 8.1以前とWAF
- Canadian Centre for Cyber Security AL26-026 — 公開アプリケーションの隔離
- Ubuntu USN-8948-1、USN-8948-2、Red Hat RHSA-2026:87080、RHSA-2026:87151、AlmaLinux
- cPanel EasyApache 4 change log、CloudLinux status、Plesk、DirectAdminフォーラム（スタッフ投稿）、Synology-SA-26:14
- Check Point sk1000302
- Launchpad — ppa:ondrej/php、deb.sury.org、Sansec — PHP2Shell — 未確認の提供元
- Docker Hub — php、Azure App Service
- Bitdefender — PHP2Shell technical advisory
- watchTowr — PHP2Shell、Tenable — PHP2Shell FAQ — 7.3以前
- ThaiCERT — PHP2Shellに関する注意喚起（2026年10月22日、タイ語） — 更新後のワーカー再起動
- systemctl(1) —
status コマンド
- AppServ — Download — AppServ 9.3.0、PHP 7.3.10、2019-09-29
