RHEL・AlmaLinux・Rocky LinuxのPHPをアップデートする手順（php2shell脆弱性への対応）

自分が所有する、または管理を任されているサーバーだけを確認してください。運営は Zane です。PHP Group および php.net とは関係のない独立サイトです。サイトやサーバーへアクセスして検査することはありません。

結論

PHP本家は、2件の脆弱性（CVE-2026-109618・CVE-2026-109619。いずれもPHP Groupの評価でCVSS 4.0の9.2）を 8.2.35・8.3.36・8.4.27・8.5.12 で修正しました。RHEL系のディストリビューションは修正を自社のパッケージにバックポートして配布するため、php.netの版番号ではなく、下の表のディストリビューション側の修正パッケージのバージョンと比べてください。2026-10-22 時点の状況は次のとおりです。

• RHEL 8・9・10：ほとんどのストリームに、Red Hatの修正アドバイザリがあります。例外のRHEL 9の php:8.4 は、修正パッケージも公告もまだありません。Red Hat の表記：「Affected」（影響あり）。
• Rocky Linux：アドバイザリのあるストリームに修正パッケージがあります。Rocky Linux 9の php:8.4 は、未確認です。このストリームの Rocky Linux の公告はまだありません。Rocky Linux 8は php:7.4 と php:8.2 に修正パッケージ（RLSA-2026:87080・RLSA-2026:87073）があり、そのほかのストリームは、確認時点ではアドバイザリが見つかっていません。
• Oracle Linux：Oracle Linux 10の php・php8.4 と、Oracle Linux 9の php（PHP 8.0）・php:8.2・php:8.3、Oracle Linux 8の php:7.4・php:8.2 に、修正パッケージがあります。Oracle Linux 9のそのほかのモジュールストリーム（php:8.4など）は、その他のストリームは未確認です。Oracle の CVE ページには、Oracle Linux 9 では php（8.0）、php:8.2、php:8.3 しか記載がありません。Oracle Linux 8のそのほかのストリームは、その他のストリームは未確認です。Oracle の CVE ページには、Oracle Linux 8 では php:7.4 と php:8.2 のストリームしか記載がありません。
• AlmaLinux：10の php（8.3）・php8.4、9の php:8.3、8の php:7.4 に修正パッケージがあります。AlmaLinux 9の php:8.2 は、公告が2件のCVEを挙げているものの、php本体のパッケージが一覧にないため、未確認です。そのほかのビルドは、その他のビルドは未確認です。AlmaLinux の公告で修正済み php ビルドが記載されているのは php:8.3 のみです。
• Remiリポジトリ：EL 8・9・10に、修正版の上流PHPに基づくビルドがあります。Remiのパッケージ一覧にはCVE番号が書かれていないため、上流の版番号で判断します。

「修正パッケージがない」「未確認」という表示は、その環境に問題がないという意味ではありません。まだ修正を確認できていない、という意味です。更新後は、PHP-FPM（Apacheのmod_phpならApache）の再起動も必要です。

手元の版を入力して確認したい場合はチェックツール、全環境の一覧は修正版一覧をご覧ください。Amazon Linuxは別のガイドにまとめています。

背景

PHP公式は、Webリクエストを処理するPHPの構成全般（PHP-FPM、Apacheのmod_php、php-cgi、FrankenPHP、LiteSpeedなど）がリスクにさらされ、中でもmod_phpのリスクが最も高いと公表しています。認証なしのリモートコード実行（外部の第三者にサーバー上でプログラムを実行されること）が起こり得るためです（PHP公式アドバイザリ）。同じ文書は、完全な解決策は更新だけであり、暫定対策は特定の攻撃経路への露出を減らすだけで、インストールを安全にするものではないとも説明しています。

PHP公式はあわせて、Linuxディストリビューションと長期サポートの提供元には事前にパッチが渡されており、更新パッケージは提供元で確認するよう案内しています。PHP 8.1以前は、PHPプロジェクトからの更新がもうありません。ディストリビューションによってはバックポートの修正を提供するので、詳細は提供元に問い合わせるか、サポートされる版へ移行する、という案内です。

Red Hatは修正アドバイザリの件名に Important と付けています。RHEL 9の php は「Important: php security update」（RHSA-2026:87151）、RHEL 10の php8.4 は「Important: php8.4 security update」（RHSA-2026:87071）です。これはRed Hat独自の4段階（Low・Moderate・Important・Critical）の評価で、CVSSの基本スコアとは別に付けられるものです（Red Hatの深刻度の分類）。この評価は、PHP公式の案内を変えるものではありません。更新が必要かどうかは、PHP公式の案内に従って判断してください。

修正パッケージの一覧

下の表は、各ディストリビューションの公式のアドバイザリやCVEのページに基づく、当サイトのデータから自動で表示しています。「修正版（以上）」の列が、各行で修正を含む最初のパッケージのバージョンです。番号がなく状況の語だけの行は、提供元が修正パッケージを示していない行です。Red HatのCVEのページの内容は、2026-10-22 に当サイトのデータと照合しました（CVE-2026-109618、CVE-2026-109619）。

RHEL（Red Hat Enterprise Linux）

RHEL 10は、Red Hatのドキュメントによればモジュール（ストリーム）形式のアプリケーションストリームを配布しないため、php・php8.4 のようなパッケージ名で分かれています。RHEL 8・9は php:8.2 のようなモジュールのストリームです（RHEL 10への移行の考慮事項）。

RHEL 7と6は、2件のCVEで状況の表記が異なります。上の表の注記は、Red Hatの表記をそのまま載せています。

AlmaLinux

AlmaLinuxは、公式のerrata（errata.almalinux.org）に、10・9・8の一部のストリームの公告が出ています（2026-10-22 確認）。AlmaLinux 9の php:8.2 の公告は2件のCVEを挙げていますが、パッケージ一覧にphp本体がなく（php-pecl-*のみ）、php:8.2 は未確認のままです。AlmaLinux 8の php:8.2 と9のphp 8.0は、公告が見つかっていません。公告がないことは、修正がないことや、問題がないことの証明ではありません。公告が確認できるまでは「未確認」として扱います。

Rocky Linux

Rocky Linuxは、Red Hatとは別に独自のアドバイザリ（RLSA）を出します。そのため、Red Hatにアドバイザリがあるストリームでも、Rocky Linux側ではまだ出ていないことがあります。上の表のとおりです（RockyのアドバイザリAPI）。Rocky Linux 8は、php:7.4 と php:8.2 のアドバイザリを確認済みで、表の最終行は、そのほかのPHPのビルドの扱いです。

Oracle Linux

Oracle Linuxも独自のアドバイザリ（ELSA）を出します。Oracle Linux 8は、php:7.4 と php:8.2 のモジュールストリームだけが、OracleのCVEのページに載っています。そのほかのストリームは、表の最終行のとおりです。最新の状況は、Oracleの公式ページで確認してください。CVE-2026-109618とCVE-2026-109619のOracle公式ページです。

Remiリポジトリ（EL 8・9・10）

Remiのリポジトリには、修正版の上流PHPに基づくビルドがEL 8・9・10向けに並んでいます（Remiのパッケージ一覧（EL 9）、EL 8・10の一覧も同様。2026-10-22 確認）。Remiの一覧にはCVE番号が書かれていないので、上流の修正版に基づく版かどうかで判断します。表の版（以上）が、その修正版に基づくビルドです。

• Remiは、Linuxディストリビューションの提供元ではなく、サードパーティのリポジトリです。PHP公式は、公表日の10月21日の時点で、ボランティアが運営するRemiのリポジトリに頼っている場合は、ディストリビューションのパッケージかソースからのビルドに切り替えるよう強く勧め、このリポジトリにはその日の更新がない、と案内していました（PHP公式アドバイザリ）。その後の 2026-10-22 の確認では、上のとおり修正版に基づくビルドが並んでいます。
• モジュール版（php:remi-8.4 のようなストリーム）のパッケージは、release の部分に module_php.8.4 のような表記が入り、表と見た目が違います（Remiの一覧）。迷う場合は、rpm -q の出力全体をチェックツールに貼って比べてください。
• Remiの案内ページ（rpms.remirepo.net/wizard）が表示する版番号は、上の表より古い場合があります。表示された版番号ではなく、上の表と比べてください。ストリーム名は php:remi-8.4 のような形式で、EL 10向けの案内にも同じ形式が出ます。

手順1：OSとPHPのパッケージを調べる

cat /etc/os-release | head -n 3
dnf list installed 'php*'          # 出力の最後の列にリポジトリ名が出ます
dnf module list --enabled php      # RHEL 8・9、およびRemiを使っている場合：有効なストリーム

'php*' のようにパッケージ名にワイルドカードを使う書き方は、DNFの公式ドキュメントにあるとおりです。dnf module list --enabled は、有効になっているモジュールのストリームを一覧します（同じドキュメントのDNF 4の説明）。RHEL 10のRed Hatのドキュメントにも、dnf check-update や dnf upgrade <パッケージ名> の説明があり、このガイドの dnf コマンドはRHEL 10でも使います（RHEL 10：RHELコンテンツの更新）。

リポジトリ名で、どの提供元のアドバイザリが当てはまるかが決まります。RHEL系の公式リポジトリから入れたPHPはそのディストリビューションのアドバイザリに、remi から入れたPHPはRemiの扱いに従います。

PHPはPHP-FPM（サービス名は php-fpm）経由で、NginxやApacheの背後で動かすのが一般的です。Red Hatのドキュメントには、RHEL 9ではApacheが既定でPHP-FPM経由でPHPを実行する、とあります（RHEL 9：PHPスクリプト言語の使用）。Apacheのmod_phpなら、PHPは httpd の中で動きます。php.netはmod_phpを最もリスクが高い構成としています。どちらかによって、手順4で再起動する対象が変わります。

手順2：修正パッケージが出ているか確認する

上の表で自分の行を探します。そのうえで、サーバー側でメタデータを更新して、提供されている更新を確認します。

sudo dnf clean expire-cache
sudo dnf check-update 'php*'

dnf clean expire-cache はリポジトリのメタデータを期限切れにし、dnf check-update は指定したパッケージの更新があるかを調べます。DNF 4のドキュメントでは、更新があると終了コードは100になります（DNFのコマンドリファレンス）。RHEL 10のドキュメントに出てくるのは dnf check-update と dnf upgrade です。dnf clean expire-cache と --refresh はRHEL 10のそのページには出てこないため、使えない場合は外して実行してください。

何も表示されなければ、今のところ新しいPHPのパッケージは届いていません。表で「修正パッケージなし」や「未確認」となっているストリームでは、それが想定どおりの結果です。PHPのパッケージが表示された場合は、その バージョン-リリース の全体を、表の自分の行の修正版と比べます。または、提供元のアドバイザリが2件のCVE（CVE-2026-109618とCVE-2026-109619）を挙げていることを確認します。PHPに関係する別の更新だけでは、修正とは言えません。

手順3：バックアップを取ってから更新する

更新前に、仮想マシンのスナップショットかバックアップを取ります。PHPのストリームや大きな版を変える場合は、特に重要です。

RHEL 8・9、AlmaLinux、Rocky Linux、Oracle Linux（モジュールのストリーム）

通常の更新は、有効になっているストリームの中にとどまります。表の自分のストリームに修正パッケージが提供されていれば、このコマンドでその版に更新されます。更新後は手順5で確認してください。

sudo dnf upgrade --refresh 'php*'

dnf upgrade <パッケージ> は、指定したパッケージを利用できる最新の版に更新します。--refresh は、実行前にメタデータを期限切れにします（DNFのコマンドリファレンス）。

まだ修正がないストリームは、表を参照してください。AlmaLinuxは、アドバイザリが確認できていないストリーム（8の php:8.2、9の php:8.2 など）では、dnf が修正を示さない可能性があります。該当する場合は、上のコマンドを毎日実行して、修正が出たかを確認してください。

別のストリームへ移ると、アプリケーションが動くPHPの版が変わります。必ず検証環境で動作を確認してから行ってください。たとえば、修正のないストリームから、同じディストリビューションで修正のあるストリームへ切り替える場合は、次のようにします。

sudo dnf module list php
sudo dnf module switch-to php:8.3    # 表で修正版のあるストリームに置き換え。実行計画を読んでから確定

dnf module switch-to は、ストリームを切り替え、インストール済みのパッケージを新しいストリームが提供する版に変更するコマンドです（DNFのコマンドリファレンス）。

RHEL 8の php:7.4（Rocky Linux 8・Oracle Linux 8の php:7.4 も同様）は、表に修正パッケージがありますが、PHP 7.4自体は、上流では2022年11月にサポートが終了しています（php.net/eol.php）。いずれ移行を計画してください。考え方はPHP 7.4・8.0・8.1 サポート終了後の対応をご覧ください。

RHEL 10（Rocky Linux・Oracle Linux・AlmaLinuxの10も同様）

モジュールのストリームではなく、パッケージ名で更新します。php と php8.4 に、RHEL・Rocky Linux・Oracle Linuxの10向けの修正パッケージがあります。AlmaLinux 10は、php（8.3）と php8.4 にアドバイザリがあります。

sudo dnf upgrade 'php*'

Remiリポジトリ

dnf module list php                  # [e] が付くのが有効なストリーム（例：php:remi-8.4）
sudo dnf upgrade --refresh 'php*'

Remiの案内ページ（rpms.remirepo.net/wizard）には、OSとPHPの版ごとのコマンドが出ます。ストリームを切り替える場合は、dnf module switch-to php:remi-8.4 のような形式です。複数の版を並べて入れるRemiの方式（php84-php など）では、パッケージ名やサービス名に版が入ります。そのため、手順4の php-fpm のサービス名は、systemctl list-units 'php*' に出る実際の名前に読み替えてください。

手順4：再起動する

パッケージを更新しても、動いているプロセスが入れ替わるまでは、修正は効きません。Red Hatのアドバイザリは、更新の適用方法として「パッケージ更新の適用方法」の記事を案内しており、アドバイザリ自体に再起動の指示は書かれていません。再起動は自分で行います。

sudo systemctl try-restart php-fpm httpd
systemctl is-active php-fpm httpd nginx    # 動いているサービスの確認

try-restart は、動いているサービスだけを再起動し、止まっているサービスには何もしません（systemctlのマニュアル）。どのサービスを再起動するかは、次の needs-restarting -s の出力に従ってください。

更新後も古いプロセスが残っていないかを調べたい場合は、dnf-plugins-core の needs-restarting が使えます。更新後に、更新されたパッケージのファイルを使い続けているプロセスを探すコマンドで、-s を付けると、再起動が必要なsystemdのサービスだけを一覧します（DNFプラグインのドキュメント）。

sudo dnf needs-restarting -s

コンテナでPHPを動かしている場合は、パッケージを更新するのではなく、イメージをビルドし直してコンテナを作り直します。

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

rpm -q php-fpm php-cli                                   # Remiの複数版方式では php84-php-fpm のような名前
rpm -q --changelog $(rpm -qa 'php*-common') | head -n 20

rpm -q --changelog は、パッケージの変更履歴を表示します（rpmのマニュアル）。

• 表の修正版と、rpm -q が表示する バージョン-リリース の全体を比べます。php -v の表示ではなく、パッケージのバージョンで判断します。
• 変更履歴に2件のCVE番号が出ていれば、確認の補助になります。ただし、CVE番号が出ないことは、脆弱性が残っているという意味ではなく、修正を確認できていないという意味です。Remiのパッケージは、版が修正版に基づいているかで見ます。
• 出力は、当サイトのチェックツールに貼り付けても、同じデータとの比較ができます。入力した内容はブラウザの中だけで処理され、外部には送信されません。
• 再起動してから確認してください。ディスク上のパッケージが新しくなっていても、メモリ上のプロセスが古いままのことがあります。
• レンタルサーバーやマネージドホスティングを使っている場合は、ホスティング別 対応状況を確認してください。

修正パッケージがない場合

表で「修正パッケージなし」や「未確認」となっている行が該当します。

• 更新コマンドを毎日実行するか、提供元のセキュリティ情報を購読して、修正が出たらすぐ適用できるようにしてください。
• 暫定的な対策はPHP公式アドバイザリを確認してください。ただし、更新の代わりにはならず、特定の攻撃経路への露出を減らすだけです。
• 待っている間も、SELinuxやファイアウォールの設定は緩めないでください。
• PHPをphp.netのソースからビルドする方法もありますが、以後の更新と拡張モジュールとの不整合の対応をすべて自分で負うことになります。版番号を揃えるためだけに行うのはおすすめしません。ディストリビューションの修正は、提供元のパッケージとして届きます。

関連ガイド

• 修正版一覧：全ディストリビューション・全系統
• ホスティング別 対応状況
• Amazon LinuxのPHPアップデート手順
• UbuntuとDebianのPHPアップデート手順
• PHPバージョンの確認方法
• PHP 7.4・8.0・8.1 サポート終了後の対応
• WordPressサイトの対応手順

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

ストリームやリポジトリの選び方、再起動の順番を自分で整理するのが難しい場合は、$49の個別パッチ対応プランがあります。お使いの環境に合わせた手順を、24時間以内にメールでお届けします。サーバーにログインすることはなく、手順書をお届けする形です。詳しくはこちらをご覧ください。