この記事でわかること

  • 2026年10月にPHPが公表した2件の緊急の脆弱性の概要
  • 自分のサーバーのPHPが対象かを確かめる方法(版・動かし方・入れた先)
  • 更新と再起動の手順と、更新できたかの確かめ方
  • すぐに更新できないときの一時的な緩和と、更新した後に確かめること

PHPで動くWebサイトやアプリを自分のサーバーで動かしていると、PHPに緊急の脆弱性が見つかったときに、自分のサーバーが対象か、何から手を付けるかを短い時間で判断する必要があります。この記事では、2026年10月21日にPHPが公表した2件の脆弱性を例に、対象の確かめ方から更新、更新した後の確認までの手順を紹介します。

脆弱性の内容と直った版、緩和の方法は、PHPのセキュリティの告知と、AlmaLinuxの告知で確かめた内容です。攻撃の方法は書きません。

先に結論: 対象かを確かめて、すぐに更新する

先に結論を書くと、Webのリクエストを処理しているPHPは対象と考え、入れた先(OSの配布元・別のリポジトリ・ホスティングの会社)の修正版へすぐに更新します。更新した後は、パッケージの版と、PHPの作業プロセスが再起動されたことを確かめます。 設定での緩和は、更新できるまでのつなぎです。

状況 すること
自分で入れたPHP 修正版へ更新
共用のサーバー 提供元に確認
すぐ更新できない 一時的な緩和
古い版(8.1以前) 移行を計画

2026年10月に公表された2件の脆弱性

PHPは、2026年10月21日に、2件の緊急の脆弱性を公表しました。番号はCVE-2026-109618とCVE-2026-109619です。PHPの告知では、PHP 8.5.12、8.4.27、8.3.36、8.2.35で、認証なしでリモートからコードを実行されるおそれのある2件の脆弱性を直したとしています。

  • 深刻度: AlmaLinuxの告知では、PHPは2件ともCVSS v4.0で9.2(緊急)と評価しているとしています
  • 起きうること: AlmaLinuxの告知では、どちらも細工したHTTPのリクエストで、PHPを動かしている利用者の権限でコードを実行される可能性があるとしています
  • 対象: PHPの告知では、Webのリクエストを処理しているすべてのPHPの環境としていて、PHP-FPM、ApacheのPHPのモジュール(mod_php)、php-cgi、FrankenPHP、LiteSpeedを挙げています
  • 特に危ない形: PHPの告知では、危険がもっとも高いのはmod_phpとしています

AlmaLinuxの告知では、この2件に「php2shell」という呼び名が付いていると紹介しています。

自分のサーバーが対象かを確かめる

まずは何も変えずに、版・動かし方・入れた先の3つを確かめます。ここで紹介するコマンドは、AlmaLinux 8を例にした読み取りだけのものです。

【実行場所】サーバーに接続したターミナル(読み取りだけ)

# 入っているPHPのパッケージと版を見る(何も変えない)
rpm -q php-common
rpm -qa 'php*' | sort

# Apacheが読み込んでいるモジュールに、PHPのモジュールとprefork方式があるかを見る
httpd -M 2>/dev/null | grep -E 'mpm_|php'

# PHP-FPMが動いているかを見る
systemctl is-active php-fpm

# 有効になっているPHPのモジュールの系統を見る([e]の印が有効)
dnf module list php
  • パッケージの版: AlmaLinuxの告知では、修正を取り込んでいるため php -v には頼らず、rpm -q php-common の結果を告知の版と見比べるとしています。php -v の番号が古いままでも、修正済みのことがあります
  • 動かし方: AlmaLinuxの告知では、結果にmpm_prefork_moduleとphp_module(またはphp7_module)があれば、mod_phpで動いているとしています。AlmaLinux 8のmod_phpは、Apacheがprefork方式のときだけ読み込まれます
  • 入れた先: AlmaLinuxの告知では、AlmaLinuxのパッケージが更新するのはAlmaLinuxのリポジトリから入れたPHPだけで、管理画面やホスティングの会社、別のリポジトリから入れた場合は、その提供元に修正と時期を確かめるよう書いています

別のリポジトリのPHPを使っている場合は、パッケージの名前に提供元の名前が入っていることが多いので、rpm -qa の結果で見分けます。PHPの告知では、ボランティアが運営しているRemiのリポジトリは、公表の当日には更新されないとしていました。使っている場合は、修正版が届いているかを提供元の一覧で確かめてから更新します。

修正版へ更新する

対象だと分かったら、更新します。更新の前に、今の版の一覧を控えておくと、後で何が変わったかを確かめられます。

【実行場所】サーバーに接続したターミナル(変更する。管理者の権限が必要)

# 更新の前に、今のPHPのパッケージの一覧を控える
rpm -qa 'php*' | sort > ~/php-before-update.txt

# パッケージの情報を新しくして、PHPのパッケージを更新する
sudo dnf clean metadata && sudo dnf upgrade 'php*'

# PHP-FPMで動かしている場合は、PHP-FPMを再起動する
sudo systemctl restart php-fpm

# 更新できたかを確かめる
rpm -q php-common
systemctl is-active php-fpm
  • 更新の一覧: dnf upgrade の確認の画面で、更新されるのがPHPのパッケージだけかを見てから進めます。ほかのパッケージが多く入っているときは、いったん止めて中身を確かめます
  • 再起動: AlmaLinuxの告知では、mod_phpを使っているAlmaLinux 8では、PHP-FPMの代わりにApacheを再起動するとしています。再起動しないと、古いPHPの作業プロセスが動き続けます
  • 確かめ方: rpm -q php-common の版が、配布元が告知した修正版と同じか、それより新しいことを見ます。PHP-FPMの状態がactiveで、サイトが表示されることも確かめます

戻し方は、控えた一覧と配布元の告知を見て判断します。古い版に戻すと脆弱性も戻るため、戻すのは更新でサイトが動かなくなったときの最後の手段にし、その場合も原因を確かめてから修正版へ進めます。更新の前に、サイトのファイルとデータベースのバックアップがあるかも確かめておきます。手順はサーバーのバックアップと復元確認|pg_dump・tar・世代管理をClaude Codeと作るで紹介しています。

すぐに更新できないときの一時的な緩和

PHPの告知では、完全な対策は更新だけとしたうえで、すぐに更新できない場合に、攻撃の経路の一部を減らす設定を挙げています。どれも、設定すれば安全になるものではありません。更新できるまでのつなぎとして使います。

【実行場所】PHPの設定ファイル(php.ini)またはPHP-FPMのプールの設定(変更する。管理者の権限が必要)

; CVE-2026-109618(メモリ不足の扱い)への緩和
memory_limit = -1
post_max_size = 8M
upload_max_filesize = 4M

; CVE-2026-109619(リクエストをまたいで残る状態)への緩和
session.upload_progress.enabled = 0
  • memory_limit: PHPの告知では、memory_limitを-1にし、アプリが書き換えられない場所(PHP-FPMのプールの設定など)で指定するとしています。ほかの設定で上限が付け直されていないかも確かめます
  • post_max_size: PHPの告知では、ファイルのアップロードが要らないアプリは8M、必要なアプリは32Mにし、upload_max_filesizeはpost_max_sizeより小さくするとしています
  • 使ってはいけない制限: PHPの告知では、RLIMIT_ASやRLIMIT_DATAで代わりに制限すると、脆弱性につながるメモリの割り当ての失敗を起こすことがあるとして、使わないよう書いています
  • session.upload_progress.enabled: PHPの告知では、0にしてすべての作業プロセスを再起動するとしています。ini_set()やPHP-FPMの.user.iniには頼らないよう書いています

設定を変える前に、元の設定ファイルを控えておきます。変えた後は、PHP-FPMを再起動し(mod_phpの場合はApache)、サイトが表示されることを確かめます。表示されなくなったときは、控えたファイルで元に戻してから再起動します。

【実行場所】サーバーに接続したターミナル(変更する。管理者の権限が必要)

# 設定を変える前に控えを取る
sudo cp -a /etc/php.ini /etc/php.ini.bak

# 設定を変えた後に、PHP-FPMを再起動して状態を確かめる
sudo systemctl restart php-fpm
systemctl is-active php-fpm

PHPの告知では、エラーの表示をerror_reportingやdisplay_errors、@で隠しても効果がないとしています。メモリの上限を外すと、1つのリクエストが多くのメモリを使えるようになるため、サーバーのメモリの使い方も見ながら、できるだけ早く更新に切り替えます。

更新した後に確かめること

更新が終わったら、次の4つを確かめます。

  • パッケージの版: rpm -q php-common が修正版になっているか
  • 作業プロセス: PHP-FPMの作業プロセスが、更新の後の時刻に起動し直しているか
  • サイトの表示: PHPで動くページが、これまでどおり表示されるか
  • 痕跡: 公表の前後の期間に、PHPの作業プロセスの異常な終了や、Webの公開フォルダーに見覚えのないファイルが増えていないか

痕跡の確認では、ApacheのアクセスログとPHP-FPMのエラーログを読むには、多くの場合、管理者の権限が要ります。Claude Codeにサーバーを調べさせるときは、変更しない読み取りの作業から任せると安全です。任せ方はサーバーの状態確認をClaude Codeに読み取り専用で任せる方法で紹介しています。

このサイトのサーバーで行ったこと

このサイトのサーバーも、対象の版のPHPをPHP-FPMで動かしていました。公表の翌日に、Claude Codeに読み取りだけで版と動かし方を確かめてもらい、対象だと分かりました。

外出中だったため、管理画面のコマンドの画面から更新しました。管理者のパスワードは、Claude Codeには渡していません。更新の後の確認は、Claude Codeに読み取りだけで任せました。パッケージの版、PHP-FPMの状態、PHPで動くページの表示を確かめ、一般のユーザーで読める範囲では、攻撃の痕跡は見つかりませんでした。管理者の権限でしか読めないログは、別に確かめる必要があります。

自分で対応するか、任せるかの判断

迷ったときは、「PHPを自分で入れたか」で決めます。自分で借りたサーバーにOSのパッケージなどでPHPを入れたなら、この記事の手順で自分で更新します。共用のレンタルサーバーなど、PHPを提供元が管理しているなら、提供元の告知を確かめ、PHPの版を選べる場合は修正版を選びます。

WordPressなどのアプリが使うPHPの版を上げるときの確かめ方は、WordPressのPHPのバージョンを上げる前に確かめることで紹介しています。

つまずきやすいところ

  • php -v だけで判断する: 配布元が修正を取り込むと、php -v の番号は変わらないことがあります。パッケージの版で確かめます
  • 再起動を忘れる: パッケージを更新しても、PHP-FPMやApacheを再起動しないと、古い作業プロセスが動き続けます
  • 入れた先を取り違える: 別のリポジトリから入れたPHPは、OSの配布元の更新では直りません。rpm -qa の結果で入れた先を確かめます
  • 緩和だけで終える: PHPの告知では、設定での緩和は安全にするものではないとしています。更新を後回しにしません
  • 古い版を使い続ける: PHPの告知では、PHP 8.1より古い版はPHPの開発チームから更新が出ないとしています。配布元の修正の有無を確かめ、移行を計画します

まとめ

  • 2026年10月21日にPHPが公表した2件の脆弱性は、Webのリクエストを処理しているPHPが対象です
  • 版はパッケージ(rpm -q php-common)で、動かし方は httpd -M と PHP-FPM の状態で、入れた先は rpm -qa の結果で確かめます
  • 入れた先の修正版へ更新し、PHP-FPM(mod_phpならApache)を再起動して、版とサイトの表示を確かめます
  • すぐに更新できないときの設定での緩和はつなぎです。できるだけ早く更新します