1. ホーム
  2. ブログ
  3. サーバー会社別

Ubuntu・Debian・RHEL・AlmaLinux の PHP2Shell 修正状況|php -v で確かめてはいけない理由

公開
著者
編集部

Linux の配布元の PHP は、修正を入れても版の番号が変わらない。Ubuntu・Debian・RHEL・AlmaLinux の修正の出方と、修正済みかどうかの正しい確かめ方をまとめた。

この記事の流れ約25秒
この記事で分かること

Ubuntu・Debian・RHEL・AlmaLinux の PHP2Shell 修正状況|php -v で確かめてはいけない理由

  • 配布元は、修正だけを元の版に入れる(バックポート)。だから php -v の番号は変わらない
  • 確かめるのは、パッケージの番号と、更新履歴に CVE-2026-109618 / 109619 があるか
  • Ubuntu・AlmaLinux は21日のうちに修正を出した。RHEL はストリームによって出た時期が違う
  • 更新したら、PHP-FPM や Apache を再起動しないと、古いものが動き続ける
1 / 4

なぜ番号が変わらないのか

配布元は、動作を変えないために、新しい版に入れ替えるのではなく、修正の部分だけを今の版に入れる

ここを読む
配布元の PHP は、直しても番号が変わらない
2 / 4

配布元ごとの状況

ここを読む
3 / 4

確かめ方

ここを読む
4 / 4

更新のあとに忘れがちなこと

  • 再起動:PHP-FPM(systemctl restart php8.3-fpm など)か、mod_php なら Apache を再起動する。再起動しないと、古い PHP が動き続ける
  • Web で動いている PHP を確かめる:コマンドの PHP(CLI)と、Web で動いている PHP は別のことがある
  • 使っていない古い PHP を消す:複数の版を入れている場合、使っていない古い版が Web から呼べないかを確かめる
ここを読む

VPS や自社のサーバーで、Linux の配布元(Ubuntu・Debian・RHEL・AlmaLinux など)の PHP を使っている場合、PHP2Shell の確かめ方に落とし穴がある。修正を入れても、php -v に出る版の番号が変わらないのだ。

この記事の要点
  • 配布元は、修正だけを元の版に入れる(バックポート)。だから php -v の番号は変わらない
  • 確かめるのは、パッケージの番号と、更新履歴に CVE-2026-109618 / 109619 があるか
  • Ubuntu・AlmaLinux は21日のうちに修正を出した。RHEL はストリームによって出た時期が違う
  • 更新したら、PHP-FPM や Apache を再起動しないと、古いものが動き続ける

なぜ番号が変わらないのか

配布元の PHP は、直しても番号が変わらない
配布元の PHP は、直しても番号が変わらない

配布元は、動作を変えないために、新しい版に入れ替えるのではなく、修正の部分だけを今の版に入れる。これをバックポートと呼ぶ。たとえば Ubuntu 24.04 の PHP は、修正後も PHP 8.3.6 と表示される。php.net の修正版(8.3.36)の番号と比べると「古いまま」に見えるが、修正は入っている。

逆に言えば、php -v を見て「8.3.6 だから危ない」「8.3.36 じゃないから未対応」と判断すると、間違える。

配布元ごとの状況

Ubuntu

10月21日に USN-8948-1 で修正を出した。修正が入ったパッケージの番号は次のとおり。

Ubuntu修正が入った番号
26.108.5.9-0ubuntu2.1
26.04 LTS8.5.4-0ubuntu1.5
24.04 LTS8.3.6-0ubuntu0.24.04.13
22.04 LTS8.1.2-1ubuntu2.28

Ubuntu は「ふつうのシステムの更新で、必要な変更はすべて入る」としている。

AlmaLinux

21日のうちに、AlmaLinux 8・9・10 のすべての PHP のストリームで、修正したパッケージの配布を始めた。パッケージの番号の最後に .alma.1 のような印が付く。保守の終わったストリーム(8 の php:7.2・7.3・8.0、9 の php:8.1)にも今回は修正を入れたが、次からも入るとは限らないとしている。

RHEL(Red Hat)

修正の告知(RHSA)を順に出しているが、ストリームによって出た時期が違う。22日の時点で、まだ修正が出ていないストリームがあったという報告もある。使っているストリームの告知を Red Hat のサイトで確かめる。

Debian

Debian 13(trixie)の php8.4 は、DSA-6574-1 で修正された。Debian 12 については、情報源によって書いてあることが違うので、Debian のセキュリティの追跡ページで直接確かめる。

古い PHP の追加のリポジトリ

Debian・Ubuntu で広く使われている追加のリポジトリ(Ondřej Surý 氏の packages.sury.org や PPA)は、保守中の4つの系列に加えて、保守の終わった 8.1〜5.6 にも修正を入れたと報じられている。

確かめ方

Ubuntu・Debian

# 入っている PHP のパッケージと番号
dpkg -l 'php*' 'libapache2-mod-php*'
# 更新履歴(php8.3 の部分は使っている版に合わせる)
apt changelog php8.3-fpm

RHEL・AlmaLinux

# 入っている PHP のパッケージと番号
rpm -q php-common
# 更新履歴
rpm -q --changelog php-common
# 今使っているストリーム([e] の付いたもの)
dnf module list php

更新履歴の中に CVE-2026-109618 と CVE-2026-109619 があれば、修正が入っている。パッケージの番号は、上の各配布元の告知にある番号以上かを比べる。

更新のあとに忘れがちなこと

  1. 再起動:PHP-FPM(systemctl restart php8.3-fpm など)か、mod_php なら Apache を再起動する。再起動しないと、古い PHP が動き続ける
  2. Web で動いている PHP を確かめる:コマンドの PHP(CLI)と、Web で動いている PHP は別のことがある
  3. 使っていない古い PHP を消す:複数の版を入れている場合、使っていない古い版が Web から呼べないかを確かめる

配布元の PHP でも、保守の期限はある。PHP 8.2 は php.net の保守が 2026年12月31日で終わるが、配布元はそれぞれの期限で修正を続けることがある。期限は配布元ごとに違うので、配布元の保守期限の記事 も見ておく。

よくある質問

php -v で 8.3.6 と出ます。危ないですか?

Ubuntu などの配布元の PHP なら、修正後も番号は変わりません。
パッケージの番号と更新履歴に CVE-2026-109618 / 109619 があるかで確かめてください。

パッケージを更新すれば終わりですか?

PHP-FPM か Apache の再起動も必要です。
再起動しないと、古い PHP が動き続けます。

保守の終わった PHP のストリームも直りますか?

今回は、AlmaLinux などが保守の終わったストリームにも修正を入れました。
ただし、次からも入るとは限りません。
保守中のストリームへ移る計画を立ててください。

無料ツールPHP2Shell の無料診断PHP のバージョンとサーバー会社を選ぶだけで、危険度と今やることが分かります。

参考にした情報

この記事の情報

2026年10月22日時点の公開情報にもとづく。PHP2Shell の状況は日々変わるので、最新は php.net・IPA・JPCERT/CC と、利用中のサービスの公式の告知を確認すること。

URL を入れるだけで、今のサイトの仕組みと PHP の状態が分かる。移行の相談もできる。

無料で診断する

この記事の著者

編集部